Systembeskrivelse for AgentBase

Felt	Værdi
Dokumenttitel	Systembeskrivelse for AgentBase
Version	1.9
Senest opdateret	2026-09-09
Dokumentejer	syv.ai (kontakt: mads@syv.ai)
Reviewfrekvens	Mindst én gang årligt og ved væsentlige ændringer i platformen, datahåndtering eller risikobillede

Dette dokument er udarbejdet med henblik på at opfylde dokumentationskravene i Europa-Parlamentets og Rådets forordning (EU) 2024/1689 om kunstig intelligens (AI-forordningen), særligt artikel 11 og bilag IV. Dokumentet beskriver AgentBase som AI-system, herunder formål, arkitektur, datahåndtering, risikostyring, menneskeligt tilsyn, gennemsigtighed og logning.

Beskrivelsen er den generelle systembeskrivelse for selve platformen. Den enkelte agent eller app, som bygges på AgentBase, kan i sig selv udgøre et AI-system, og det er den pågældende udvikler/idriftsætter, der er ansvarlig for at supplere denne systembeskrivelse med en specifik beskrivelse af det færdige anvendelsestilfælde.

1. Generel beskrivelse af AI-systemet

1.1 Identifikation

Felt	Værdi
Systemets navn	AgentBase
Udbyder	syv.ai
Kontakt	mads@syv.ai
Rolle i forsyningskæden (jf. art. 3)	Udbyder af AI-system (provider)
AI-systemets type	Komponentbaseret platform til opbygning og kørsel af automatiserede arbejdsgange (DAGs), ofte med integration til generelle AI-modeller (GPAI)

1.2 Tilsigtet formål

AgentBase er en platform, der gør det muligt for organisationer at:

• Bygge automatiserede arbejdsgange (agents) ved at sammenkoble byggeklodser (nodes) i en visuel editor.
• Publicere arbejdsgange som apps med brugervenlige formularer.
• Anvende sprogmodeller (LLM'er), OCR, dokumentopslag og lignende AI-funktionalitet som dele af en arbejdsgang.
• Versionsstyre, godkende og dele arbejdsgange på tværs af teams.

Platformen er beregnet til professionelle brugere i virksomheder og offentlige myndigheder, der ønsker at automatisere arbejdsprocesser med eller uden brug af AI-komponenter.

1.3 Tilsigtede brugere

Rolle	Anvendelse
Bruger	Kører publicerede apps via formularer
Anmelder	Bedømmer agents i kvalitetskontrollen, godkender og forsegler eller afviser dem inden publicering — udgiver ikke selv
Udvikler	Bygger og redigerer agents, udgiver den godkendte version, administrerer API-nøgler
Administrator	Bruger- og teamadministration samt adgang til alt indhold i sin egen organisation
Superadministrator	syv.ai's platformoperatør; systemdækkende adgang på tværs af organisationer, fx til drift og support

1.4 Klassifikation efter AI-forordningen

AgentBase er en almenanvendelig platform til opbygning og kørsel af automatiserede arbejdsgange. Platformen leverer funktionelle byggeklodser og en eksekveringsmotor, men træffer ikke selv beslutninger på vegne af slutbrugere. Klassifikationen af det færdige AI-system efter AI-forordningen afhænger derfor af det konkrete formål, som idriftsætter (deployer) bygger og udruller, og foretages af denne i forbindelse med ibrugtagningen.

Følgende forhold gælder for platformen som sådan:

• Forbudte anvendelser (art. 5): Platformen må ikke anvendes til formål, der er forbudt efter art. 5 (fx social scoring, manipulerende systemer, real-time biometrisk fjernidentifikation i offentlige rum). Dette håndhæves kontraktligt via vilkår og adfærdspolitikker.
• Gennemsigtighedsforpligtelser (art. 50): Når agents genererer eller manipulerer indhold, der præsenteres for fysiske personer (fx chatbots, syntetisk tekst eller billeder), skal idriftsætter sikre passende mærkning og oplysning.
• GPAI-modeller (kapitel V): AgentBase integrerer med flere tredjepartsudbydere af GPAI-modeller. OpenAI Ireland Ltd. leverer sprogmodeller, og Mistral AI SAS leverer både en sprogmodel, du kan vælge i Sprogmodel-noden, og OCR/dokumentudtræk. Google leverer en OCR-motor, du kan vælge i stedet for Mistral, og syv.ai's egen transskriptionstjeneste anvendes af Transkriber-noden. Billedgenerering leveres af Eleven Labs Inc. via billedmodellen gpt-image-2 fra ElevenLabs' underdatabehandler OpenAI. Forpligtelser efter art. 53–55 påhviler den enkelte modeludbyder; AgentBase formidler udelukkende adgang via API. Genererede billeder er syntetisk indhold, og idriftsætter skal sikre mærkning efter art. 50, når de præsenteres for fysiske personer.

1.5 Forsyningskæde og afgrænsning

┌──────────────────────┐    API     ┌──────────────────────┐
│ Eksterne             │ ◄────────► │ AgentBase backend    │
│ underdatabehandlere  │            │ (FastAPI, Python)    │
│ (se listen nedenfor) │            │                      │
│                      │            │  • Node-registry     │
└──────────────────────┘            │  • DAG-eksekvering   │
                                    │  • Bruger/teams      │
                                    │  • Versionering      │
                                    │  • Logning           │
                                    └──────────┬───────────┘
                                               │ HTTP/REST
                                               ▼
                                    ┌──────────────────────┐
                                    │ React-frontend       │
                                    │ (TypeScript, Vite)   │
                                    └──────────────────────┘
                                               │
                                               ▼
                                    ┌──────────────────────┐
                                    │ PostgreSQL           │
                                    │ (data, versioner,    │
                                    │  kørsler, logs)      │
                                    └──────────────────────┘

Eksterne underdatabehandlere, som platformen kan sende data til, afhængigt af hvilke byggeklodser din agent bruger:

• OpenAI — sprogmodeller.
• Mistral AI — sprogmodel samt OCR/dokumentudtræk.
• Google — OCR/dokumentudtræk (valgbar motor).
• syv.ai (platform.syv.ai) — transskription af lyd.
• Lettermint — afsendelse af e-mail.
• ElevenLabs — billedgenerering (Billedgenerering-noden og chat-værktøjet "Generér billede"); amerikansk leverandør under EU-U.S. Data Privacy Framework, se Underdatabehandlere.

Bruger din organisation sine egne API-nøgler (se §3.2), kan listen se anderledes ud.

2. Detaljeret beskrivelse af elementer og udviklingsproces

2.1 Tekniske komponenter

Backend (Python 3.12+):

• FastAPI som REST API-lag.
• SQLModel/Pydantic til datavalidering og ORM.
• Alembic til databasemigreringer.
• Loguru til struktureret logning.

Frontend (TypeScript):

• React 19 med Vite som byggeværktøj.
• Auto-genererede TypeScript-typer fra OpenAPI-specifikationen, så frontend og backend altid er kontrakt-konsistente.
• @xyflow/react til den visuelle DAG-editor.

Datalag:

• PostgreSQL 16+ til persistente data (brugere, teams, agents, versioner, kørsler, dokumenter).

Eksterne afhængigheder:

• OpenAI API (sprogmodeller)
• Mistral API (sprogmodel samt OCR-/dokumentudtræksnoder)
• Google Gemini API (OCR/dokumentudtræk, valgbar motor)
• syv.ai's transskriptionstjeneste (lyd til tekst)
• Lettermint (afsendelse af e-mail)
• ElevenLabs API (billedgenerering)

2.2 Eksekveringsmodel

En agent er en orienteret acyklisk graf (DAG) af noder. Ved kørsel:

1. Validering: Det kontrolleres, at alle nodetyper er registreret, og at alle kanter peger på eksisterende noder.
2. Topologisk sortering: Eksekveringsrækkefølge bestemmes; cykler afvises.
3. Inputopløsning: For hver node opløses input i prioriteret rækkefølge fra (a) opstrømsoutput, (b) statisk konfiguration i UI, (c) defaultværdier i funktionssignaturen.
4. Eksekvering: Noder eksekveres i orden, og resultater gemmes.
5. Streaming: Status sendes løbende til frontend via Server-Sent Events.

2.3 Indbyggede nodetyper

Platformen leveres med blandt andet følgende noder:

Byggeklodserne er inddelt i fem aktive kategorier, som du også ser dem i nodepaletten (paletten viser derudover en Udfaset-kategori med ældre versioner, der stadig kører i eksisterende flows):

Kategori	Eksempler på byggeklodser
AI	Sprogmodel, Indlæs dokument (OCR), Sortér dokumenter, Fil til struktureret data, Anonymiser tekst, Transkriber
Data	Kombiner, Opdeler, Sammenlign tekster, Konverter Datatype, Indlæs CSV-data, Udtræk data-felter, JSON til Excel, Excel til JSON, Dato og tid, Hent fra API, Databaseforespørgsel, CVR Opslag, Datafordeler, Plandata, Ejendomsoverblik, SMV-status, Søg lovgivning, Søg overenskomst, App-version
Input	Tekstinput, Skabelon, Hent Dokument, Søg Dokumenter, Slå Dokumenter Op, Hent Dokument Indhold, Dokumentliste, Hent Lovgivning, Hent overenskomst
Logik	Hvis / ellers, Forgrening, Løkke Start, Løkke Slut, Løkke Afbryd, Løkke Spring Over, Python Kode (sandkasse-eksekvering)
Output	Tekst til dokument, Send Email
Udfaset	Ældre versioner, der stadig kører i eksisterende flows (fx Udtræk struktureret data, Fildetaljer, Tekstliste, Filliste)

Derudover kan et flow, din organisation selv har udgivet som byggeklods, bruges som node i andre flows. Den fulde og altid opdaterede liste findes i Byggeklodser.

Nye noder registreres via en @node-dekoratør i Python og bliver automatisk eksponeret i frontend og OpenAPI-spec.

2.4 Versionering og godkendelse

• Hver agent har semantisk versionering (major.minor).
• Minor-versioner inkrementeres automatisk ved ændringer.
• Major-versioner kræver et todelt forløb: en bruger med mindst Anmelder-rollen bedømmer testene og forsegler accepttest-rapporten, hvorefter en bruger med mindst Udvikler-rollen udgiver versionen (Administrator ligger over begge i hierarkiet og opfylder derfor også kravene). Én bruger med mindst Udvikler-rollen kan udføre begge trin — det oplyses i så fald i den forseglede rapport, jf. §5.
• Godkendelsesprocessen er dokumenteret i Anmeldelser.
• Kravet om en forseglet accepttest-rapport gælder apps i Galleriet: en app, der er udstillet i Galleriet, kan ikke begynde at servere en version, der ikke er forseglet. Den allerførste udgivelse af en publikation og udgivelsen af et flow som byggeklods kræver derimod ikke en kvalitetskontrolrunde — her er den menneskelige kontrol rollebaseret (mindst Udvikler-rollen).
• Tidligere versioner bevares og kan tilgås, hvilket understøtter sporbarhed.

2.5 Udviklingsproces

• Kildekode versionsstyres i Git med pull request-baseret review.
• CI/CD via GitHub Actions kører enheds- og integrationstest, typecheck (ty, tsc), linting (ruff, eslint) og end-to-end-test (Playwright) ved hver ændring.
• Docker-builds fejler, hvis test eller typecheck fejler.
• OpenAPI-specifikationen valideres i CI mod backend-koden, så frontend og API ikke kan komme ud af synkronisering.

3. Data og datahåndtering

3.1 Datakategorier

AgentBase opbevarer og behandler følgende data:

Datakategori	Formål	Opbevaringssted
Brugerkonti (e-mail, hashed password, rolle, team)	Adgangsstyring	PostgreSQL
Agents og versioner (graf, konfiguration)	Modeller af arbejdsgange	PostgreSQL
Apps (publicerede agents med formularer)	Slutbrugeradgang	PostgreSQL
Appens hukommelse (data en app gemmer for sine slutbrugere)	Vedvarende tilstand i apps (kladder, sager)	PostgreSQL
Kørselsdata (input, output, fejl, tidsstempler)	Sporbarhed og fejlsøgning	PostgreSQL
Dokumenter uploadet af brugere	Inputmateriale til agents	PostgreSQL — kun den tekst, dokumentet indeholder, gemmes; selve filen opbevares ikke
API-nøgler og hemmeligheder	Integration med eksterne systemer	PostgreSQL (krypteret)
Organisationsvariabler og integrationslegitimationer	Adgang til organisationens egne systemer og modeller	PostgreSQL (krypteret)
Chat (samtaler, beskeder og dokumentpanelet)	Samtaler med assistenten og de dokumenter, den skriver	PostgreSQL
Webhook-modtagelser (modtaget forespørgsel, svar og afsenderens IP-adresse)	Fejlsøgning af integrationer	PostgreSQL
Mellemresultater (cache)	Genbrug af beregninger, så en kørsel bliver hurtigere og billigere	PostgreSQL
Login-links, links til nulstilling af adgangskode og invitationer	Adgang og onboarding	PostgreSQL
Kvalitetskontrolmateriale (testsager, bedømmelser og forseglede accepttest-rapporter)	Dokumentation af menneskelig godkendelse	PostgreSQL

3.2 Træning af modeller

AgentBase træner ikke selv AI-modeller. Platformen kalder eksterne modeller via API. Datasæt-, validerings- og testkrav efter art. 10 i AI-forordningen påhviler dermed den underliggende GPAI-modeludbyder (OpenAI Ireland Ltd.). AgentBase understøtter ikke, at idriftsætter træner egne modeller.

Din organisation kan derimod lægge sine egne API-nøgler ind under Administration → Organisation → Integrationer, enten for hele organisationen eller for et enkelt team. Det gælder også en egen Azure OpenAI-opsætning eller en selvhostet, OpenAI-kompatibel server. Bruger organisationen sine egne nøgler, sker kaldene på organisationens eget aftalegrundlag med den pågældende leverandør.

3.3 Databehandling og GDPR

• Behandling af personoplysninger sker efter forordning (EU) 2016/679 (GDPR).
• Der indgås databehandleraftaler med eksterne underleverandører, der kan tilgå personoplysninger.
• Brugeren kan eksplicit anonymisere data via anonymization-noden inden videresendelse til ekstern model.
• Inputdata sendt til eksterne LLM-udbydere er underlagt udbyderens vilkår; idriftsætter er ansvarlig for, at der ikke sendes personoplysninger ud over det aftalte grundlag.

3.4 Datakvalitet og bias

For platformkomponenter, der ikke selv genererer ny indlæring, er datakvalitet et ansvar for idriftsætter. AgentBase tilbyder værktøjer, der understøtter datakvalitet:

• Anonymiseringsnode for fjernelse af personoplysninger.
• Strukturerede output-skemaer der validerer modeloutput før det viderebehandles.
• Versionering og evalueringer så ændringer kan testes mod kendt baseline før publicering.

4. Risikostyring

Risikostyringen følger principperne i art. 9 i AI-forordningen og opdeles i platform-niveau og anvendelses-niveau.

4.1 Identificerede risici (platformniveau)

Risiko	Mitigation
Uautoriseret adgang til agents eller data	Rollebaseret adgangskontrol (RBAC), JWT-tokens, team-isolation
Overforbrug eller misbrug af eksterne API'er	Konfigurérbare grænser for antal noder og kanter i et flow, for hvor mange gentagelser af en løkke der kører samtidig, og for hvor længe og hvor mange modelkald en agent-samtale må bruge. Offentlige indgange (scanner, indlejret widget, webhooks og login-links) har desuden hastighedsbegrænsning. API-nøgler oprettes pr. bruger og arver brugerens rettigheder. Organisationen kan lægge sine egne API-nøgler ind, så forbruget afregnes og styres hos den selv
Eksekvering af ondsindet brugerkode	python_code-noden eksekverer i begrænset miljø; tilgang til netværk og filsystem er kontrolleret
Uendelige løkker eller cykliske grafer	Topologisk sortering afviser cykler ved validering
Datalækage til eksterne modeller	Anonymiseringsnode, dokumenteret dataflow, kontraktlige vilkår over for idriftsætter
Tab af sporbarhed	Komplet logning af kørsler, versionering af agents
Hallucinationer eller fejl fra LLM	Strukturerede outputs, evalueringsfunktioner, menneskeligt tilsyn (se afsnit 5)

4.2 Idriftsætterens ansvar

Når en idriftsætter bygger en konkret anvendelse, skal denne foretage en supplerende risikovurdering, der er passende i forhold til formålet, samt tilpasse menneskeligt tilsyn, logning og brugerinformation til det specifikke anvendelsestilfælde.

5. Menneskeligt tilsyn

I overensstemmelse med art. 14 understøtter platformen menneskeligt tilsyn på flere niveauer:

• Godkendelse af et menneske: Enhver udgivelse udføres af et menneske med mindst Udvikler-rollen — der findes ingen automatisk udgivelse. For apps i Galleriet gælder desuden kvalitetskontrollen: testsagerne bedømmes af et menneske med mindst Anmelder-rollen og forsegles i en uforanderlig rapport, og en app i Galleriet kan ikke begynde at servere en version uden en sådan forsegling.
• Ærlig oplysning frem for teknisk adskillelse: Platformen håndhæver ikke teknisk, at indsender og godkender er forskellige personer. Er de samme person, oplyses det tydeligt i den forseglede rapport (solo-aktør-markering), så dokumentationen viser hvem der faktisk gjorde hvad. Ønsker organisationen et fire-øjne-princip, håndhæves det gennem rolletildelingen — en Anmelder kan bedømme og forsegle, men ikke udgive, så adskillelsen opnås ved at give de to roller til forskellige medarbejdere. Et teknisk per-organisation-krav er en planlagt, endnu ikke aktiveret funktion.
• Versionering: Tidligere versioner kan til enhver tid genindføres, hvis en nyere version udviser uønsket adfærd.
• Manuel kørsel: Apps kan startes manuelt af en bruger, der godkender input før kørsel.
• Resultatvisning: Brugeren ser modeloutput og kan vurdere det inden eventuel videreanvendelse.
• Stop-funktion: En administrator kan deaktivere en publiceret app, hvis problemer opstår.
• Adgangskontrol: Administratorer kan tilbagekalde adgang og deaktivere brugere.

Vær opmærksom på

Forseglingen er ikke en teknisk spærring på alle veje. Den allerførste udgivelse af en publikation og udgivelsen af et flow som byggeklods kræver ikke en kvalitetskontrolrunde. Vil din organisation have kvalitetskontrol på alt, hvad der sættes i drift, skal det sikres gennem rolletildeling og interne arbejdsgange.

6. Nøjagtighed, robusthed og cybersikkerhed

6.1 Nøjagtighed

• Platformen leverer determineret eksekvering af DAGs; outputvariation skyldes alene ikke-determinerede noder (typisk LLM-kald).
• For LLM-noder kan idriftsætter fastsætte temperatur, model og strukturerede outputskemaer for at øge forudsigelighed.
• Evalueringsmodulet gør det muligt at teste agents mod faste testsæt før publicering.

6.2 Robusthed

• DAG-validering sikrer, at ugyldige grafer ikke kan eksekveres.
• Fejler en node, stopper kørslen, men fejlen henføres præcist til den node, der fejlede: kørselshistorikken viser nodens navn, fejltypen og en brugervenlig forklaring.
• Strømmet eksekvering konverterer fejl til SSE-events, så brugeren ser fejl i realtid.
• Konfigurérbare grænser for antal noder/kanter forhindrer ressourceudtømmelse.
• CI/CD kører enheds-, integrations- og end-to-end-test ved hver kodeændring.

6.3 Cybersikkerhed

• Autentifikation sker via JWT-tokens med konfigurérbar levetid (ACCESS_TOKEN_EXPIRE_MINUTES).
• Adgangskoder hashes med en moderne adaptiv hash-algoritme.
• Kommunikation mellem klient og server sker over TLS i produktion.
• API-nøgler og hemmeligheder opbevares krypteret i databasen.
• Koden gennemgår statisk analyse (ruff), typecheck (ty, tsc) og automatiseret test ved hver ændring.
• Afhængigheder opdateres automatisk via Dependabot.
• Inputvalidering sker på alle systemgrænser via Pydantic.

7. Logning og sporbarhed

I overensstemmelse med art. 12 logger AgentBase automatisk centrale hændelser:

Hændelse	Indhold	Opbevaringssted
HTTP-forespørgsler til API'et	Tidsstempel, sti, statuskode, varighed	Webserverens adgangslog (og, hvis observabilitetsværktøjet er slået til, detaljerede forespørgselsspor)
Oprettelse/ændring af agent	Bruger, version, ændringssæt	Database (versionshistorik)
Kørsler af agents og apps	Input, output, status pr. node, varighed, fejl	Database (kørselshistorik)
Administrative handlinger	Ændring af opbevaringsperioden og rydning af kørselshistorik	Database (auditlog)

Bemærk

Auditloggen dækker i dag netop de to handlinger ovenfor. Bruger- og rolleadministration (fx aktivering af en bruger eller ændring af en rolle) har endnu ikke et dedikeret revisionsspor, og der registreres hverken særskilte login- og logud-hændelser eller bruger-id pr. API-kald. Har din organisation brug for det, kan sporet suppleres i jeres eget SIEM.

7.1 Opbevaringsperiode

Opbevaringsperioden for kørselsdata konfigureres af organisationens administrator direkte i AgentBase under Administration → Organisation → Generelt → Dataopbevaring, mellem 7 og 3653 dage; standard er 6 måneder (184 dage). Når oprydningen kører, slettes en kørsels input, output og fejldetaljer sammen med resultatet fra hver byggeklods, og koblingen til den bruger, der startede kørslen, fjernes. Registreringen af kørslen (status, varighed, tidspunkter og antal) bevares altid af hensyn til fakturering og statistik.

Den automatiske sletning skal aktiveres på platformen

Den løbende, automatiske oprydning er en funktion, der slås til på platformen, og den er som udgangspunkt slået fra. Er den ikke aktiveret, gemmes din indstilling, men selve sletningen sættes først i værk, når funktionen aktiveres — det oplyser AgentBase dig også om på siden Dataopbevaring. Kontakt syv.ai (mads@syv.ai) for at få den aktuelle status for jeres installation.

Datatype	Opbevaring	Bemærkning
Kørselshistorik (input, output, fejl)	Organisationens valgte periode (standard 184 dage)	Indholdet slettes automatisk; registreringen bevares. Kørsler kan desuden slettes manuelt pr. kørsel eller pr. flow af brugere med mindst Udvikler-rollen. Kørsler, der indgår som test-evidens i kvalitetskontrollen, slettes ikke automatisk, så længe de indgår som evidens
Dokumenter uploadet som input til en kørsel	Følger kørselshistorikken	Indgår i kørslens data og slettes sammen med den
Dokumentbiblioteket (Dokumenter)	Kundeadministreret	Slettes af organisationen selv, ikke af den automatiske oprydning
Appens hukommelse (data en app gemmer for sine slutbrugere)	Kundeadministreret	Omfattes ikke af den automatiske oprydning. Data slettes, når appens ejer sletter en enkelt nøgle eller en hel gruppe (Udvikler-rollen eller højere), og de slettes sammen med appen. Men en publiceret app kan ikke slettes, og en arkiveret app, hvis version har en forseglet accepttest-rapport, afvises — så ejerens egen sletning er den praktiske vej. Der findes p.t. ingen selvbetjenings-brugerflade til det; sletningen sker via AgentBase' API
Webhook-modtagelser	Indhold efter organisationens valgte periode; selve registreringen efter mindst 184 dage	Indholdet (modtaget forespørgsel, svar og afsenderens IP-adresse) slettes efter opbevaringsperioden; registreringen af modtagelsen slettes helt efter den længste af organisationens periode og 184 dage
Chatbeskeder	Organisationens valgte periode, pr. besked	Enkeltbeskeder ældre end perioden slettes fra chatsamtaler (også aktive); nyere beskeder i samme samtale bevares
Mellemresultater (cache)	184 dage	Fast platformregel — påvirkes ikke af organisationens valgte periode
Byggeklodsers hukommelse mellem kørsler (fx "sidst sete" markører)	Så længe flowet findes	Små driftsmarkører (maks. 16 KB pr. værdi, maks. 50 nøgler pr. byggeklods), der gør det muligt kun at behandle nye elementer. Slettes sammen med flowet og kan nulstilles pr. flow eller pr. byggeklods af brugere med mindst Udvikler-rollen; nulstilling logges i auditloggen. Indeholder ingen kobling til en bruger. Testkørsler i kvalitetskontrollen læser og skriver aldrig denne hukommelse. Se opbevarings- og sletteaftalen umiddelbart efter tabellen
Udløbne links og invitationer	30 dage efter udløb eller brug	Login-links og links til nulstilling af adgangskode slettes 30 dage efter udløb/brug; invitationer slettes 30 dage efter udløb, og tilbagekaldte/opbrugte invitationer fjernes løbende
Versionshistorik for agents	Planlagt	Automatisk oprydning af versionshistorik er planlagt, men endnu ikke aktiv. Frosne versions-øjebliksbilleder, der indgår som evidens i kvalitetskontrollen, bevares (jf. afsnit 5)
Strukturerede applikationslogs	6 måneder	Kan eksporteres til kundens eget SIEM for langtidsopbevaring og uafhængig retention
Auditlog (administrative handlinger)	Bevares	Ændring af opbevaringsperioden og rydning af kørselshistorik logges i databasen og berøres ikke af oprydningen

Når den automatiske oprydning er aktiveret, har sletningen virkning i den aktive database ved næste kørsel af oprydningsjobbet (jobbet kører mindst én gang i timen). Sletningen slår igennem i backups i takt med backup-rotationen (p.t. 2 måneder — der tages backup dagligt, og en backup slettes efter 2 måneder).

Idriftsætter er ansvarlig for at fastlægge en opbevaringsperiode, der opfylder fx GDPR's princip om opbevaringsbegrænsning og eventuelle sektorspecifikke krav. Vælges en periode længere end standarden, er det den dataansvarliges ansvar at kunne begrunde opbevaringen. Logs kan desuden eksporteres i JSON-format (via LOG_JSON=true) og integreres med eksterne SIEM-/observabilitetsværktøjer, hvor uafhængig langtidsretention kan håndhæves.

Byggeklodsers hukommelse mellem kørsler — opbevaring og sletning

En byggeklods, der er bygget til kun at behandle nye elementer (fx et RSS-feed eller en postkasse), gemmer en lille driftsmarkør mellem kørsler: hvor langt den nåede sidst. Aftalen for de data er kort:

• Hvad det er. Nøgle/værdi-par, der hører til det sted i flowet, byggeklodsen står — maks. 16 KB pr. værdi og maks. 50 nøgler pr. byggeklods. Typisk et tidsstempel, en liste af allerede sete id'er eller et fortsæt-her-link fra en ekstern tjeneste.
• Ingen kobling til en person. Rækkerne har ingen brugerkolonne. Hukommelsen hører til flowet, ikke til den, der tilfældigvis startede kørslen, så en sletteanmodning fra en registreret person har intet at finde her.
• Ingen udløbsdato. Der findes ingen alder, hvor en markør bliver forældet — en markør fra sidste år er stadig det rigtige sted at fortsætte fra. Hukommelsen indgår derfor ikke i den automatiske, tidsbaserede oprydning og påvirkes ikke af organisationens valgte opbevaringsperiode.
• Den dør med flowet. Slettes flowet, slettes hukommelsen i samme databasehandling (fremmednøgle med kaskadesletning). Det er den eneste automatiske sletning.
• Den praktiske sletteknap. Brugere med mindst Udvikler-rollen kan nulstille hukommelsen for hele flowet eller for en enkelt byggeklods. Handlingen er øjeblikkelig og logges i auditloggen. Det er den vej, en sletning sker, uden at flowet nedlægges. Bemærk, at en nulstillet vagtpost behandler alt forfra én gang.
• Rydning af kørselshistorik rører den ikke. Hukommelsen er ikke kørselsdata, og "Ryd kørselshistorik" lader den med vilje stå.
• Ét forbehold, sagt lige ud. Et arkiveret flow kan ikke slettes, så længe det indgår som evidens i kvalitetskontrollen. Et sådant flow beholder sin hukommelse, indtil nogen nulstiller den manuelt.

8. Gennemsigtighed og brugerinformation

I overensstemmelse med art. 13 og art. 50:

• Hver app viser tydeligt, hvilke inputs den forventer, og hvilket output den producerer.
• Når en app indeholder LLM-noder, vises dette i nodepalet og dokumentation, så idriftsætter er bevidst om AI-elementet.
• Idriftsætter har pligt til at informere slutbrugere om, at de interagerer med et AI-system, hvor det er relevant efter art. 50 (fx chatbots, AI-genereret indhold).
• Denne dokumentation samt introduktionen og rolleoversigten er tilgængelig som brugervejledning.

9. Kvalitetsstyring

Udbyderen anvender følgende kvalitetsstyringspraksis (jf. art. 17):

• Versionsstyret kildekode med pull request-review for alle ændringer.
• Automatiserede test i CI (enheds-, integrations- og end-to-end-test).
• Type- og linterkrav håndhævet i CI.
• Releaseproces med semantisk versionering og changelog.
• Hændelseshåndtering ved fejl, herunder dokumentation og reproducerbar fejlsøgning via kørselshistorik.
• Dokumentation som kode: Brugerdokumentation, systembeskrivelse og arkitektur-dokumenter ligger i samme repository som koden og opdateres som del af samme ændringsproces.

10. Overensstemmelse og opdatering

• Denne systembeskrivelse opdateres ved væsentlige ændringer i platformens funktionalitet, datahåndtering, sikkerhedsforhold eller risikobillede.
• Større ændringer dokumenteres i changelog og frigives som ny version.

11. Kontakt

Spørgsmål til denne systembeskrivelse, ønsker om yderligere dokumentation eller henvendelser om sikkerhedshændelser kan rettes til:

syv.ai E-mail: mads@syv.ai

12. Revisionshistorik

Version	Dato	Ændring	Ansvarlig
1.0	2026-04-30	Første udgave af systembeskrivelsen.	syv.ai
1.1	2026-04-30	Tilføjet dokumentkontrol (version, ejer, reviewfrekvens), neutral klassifikationsformulering og opbevaringsperioder for logs.	syv.ai
1.2	2026-04-30	Justeret afsnit 7.1 så det afspejler den faktiske implementering: ingen automatisk tidsbaseret sletning; data opbevares indtil eksplicit sletning.	syv.ai
1.3	2026-05-01	Afsnit 7.1 opdateret til at angive en standardopbevaringsperiode på 6 måneder for kørselslogs, uploadede dokumenter og brugerdata, der kan konfigureres kortere eller længere efter aftale med syv.ai (i overensstemmelse med Databehandleraftalens Bilag C.4).	syv.ai
1.4	2026-08-19	Afsnit 7.1 opdateret: Opbevaringsperioden konfigureres nu af organisationens administrator direkte i AgentBase (Administration → Opbevaring, 7–3653 dage, standard 184 dage), og indholdet af ældre kørsler slettes automatisk og løbende, mens registreringen bevares. Tilføjet detaljerede sletteregler (webhook-modtagelser, chatbeskeder, cache, udløbne links og invitationer), sletningens virkningstidspunkt i database og backups, samt præcisering af auditlog- og login-logning i afsnit 7.	syv.ai
1.5	2026-09-05	Rettet efter gennemgang mod koden: leverandørlisten udvidet (Mistral leverer også en sprogmodel; Google, syv.ai og Lettermint tilføjet), egne API-nøgler beskrevet i §3.2, Superadmin tilføjet i rolletabellen, nodetabellen i §2.3 skrevet om til de faktiske kategorier og danske navne, §3.1 udvidet med de øvrige datakategorier og præciseret for dokumenter, publiceringsgarantien i §2.4 og §5 nuanceret (forsegling gælder Galleriet), §6.2 præciseret om nodefejl, §4.1 præciseret om grænser og API-nøgler, §7 reduceret til det auditloggen faktisk indeholder, og §7.1 opdateret med den korrekte menusti samt forbehold om, at den automatiske sletning skal aktiveres på platformen.	syv.ai
1.6	2026-09-07	Afsnit 1.4, 1.5 og 2.1 opdateret: Eleven Labs Inc. tilføjet som ekstern afhængighed for billedgenerering (Billedgenerering-noden og chat-værktøjet "Generér billede"), med art. 50-note om mærkning af syntetiske billeder.	syv.ai
1.7	2026-09-09	Afsnit 3.1 og 7.1 udvidet med datakategorien appens hukommelse: den vedvarende tilstand, en publiceret app kan gemme for sine slutbrugere (kladder, sager). Kategorien er kundeadministreret og omfattes ikke af den automatiske oprydning; afsnit 7.1 beskriver, hvordan data faktisk slettes, og at der endnu ikke findes en selvbetjenings-brugerflade til det.	syv.ai
1.8	2026-09-10	Afsnit 7.1: tilføjet række for byggeklodsers hukommelse mellem kørsler (node_state).	syv.ai
1.9	2026-09-10	Afsnit 7.1: tilføjet opbevarings- og sletteaftale for byggeklodsers hukommelse mellem kørsler (ingen brugerkobling, ingen udløbsdato, kaskadesletning med flowet, nulstilling som den praktiske slettevej, og forbeholdet om arkiverede flows).	syv.ai