Systembeskrivelse for AgentBase

Felt	Værdi
Dokumenttitel	Systembeskrivelse for AgentBase
Version	1.3
Senest opdateret	2026-05-01
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
Udvikler	Bygger og redigerer agents, administrerer API-nøgler
Anmelder	Godkender eller afviser agents inden publicering
Administrator	Bruger- og teamadministration, fuld systemadgang

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 en tredjepartsudbyder af GPAI-modeller, OpenAI Ireland Ltd. Forpligtelser efter art. 53–55 påhviler udbyderen; AgentBase formidler udelukkende adgang via API. Mistral AI SAS leverer OCR/dokumentudtræk og er ikke en GPAI-model i denne sammenhæng.

1.5 Forsyningskæde og afgrænsning

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

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 (LLM-noder)
• Mistral API (OCR-/dokumentudtræksnoder)

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:

Kategori	Noder
LLM og AI	llm, function_calling, structured_output, transcribe
Dokumenter	document, document_lookup, ocr
Datatransformation	combine, split, diff, template, type_converter, csv_parse, json_node, json_to_excel
Logik	conditional, loop, list_inputs
Integration	http_request, cvr_lookup, email, sql
Anonymisering	anonymization
Egen kode	python_code (sandkasse-eksekvering)

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 godkendelse af en bruger med rollen Anmelder.
• Godkendelsesprocessen er dokumenteret i Anmeldelser.
• 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
Kørselsdata (input, output, fejl, tidsstempler)	Sporbarhed og fejlsøgning	PostgreSQL
Dokumenter uploadet af brugere	Inputmateriale til agents	PostgreSQL/objekt-storage
API-nøgler og hemmeligheder	Integration med eksterne systemer	PostgreSQL (krypteret)

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 eller indsætter egne LLM-/OCR-leverandører via platformens noder.

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 (MAX_AGENT_NODES, MAX_AGENT_EDGES), rate limits, API-nøglehåndtering pr. team
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:

• Anmelderrolle: Agents kan ikke publiceres som apps uden godkendelse fra en bruger med rollen Anmelder.
• 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.

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.
• Fejl i noder fanges og rapporteres pr. node uden at nedlægge hele kørslen.
• 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
Brugerlogin og -logud	Tidsstempel, bruger-id, status	Database
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)
API-kald	Endpoint, bruger, status, varighed	Strukturerede applikationslogs
Administrative handlinger	Brugeraktivering, rolleændring	Database

7.1 Opbevaringsperiode

Som standard opbevares kørselslogs, uploadede dokumenter og brugerdata i 6 måneder, hvorefter de slettes eller anonymiseres. Den dataansvarlige kan konfigurere en kortere eller længere opbevaringsperiode efter aftale med syv.ai.

Datatype	Standardopbevaring	Bemærkning
Versionshistorik for agents	6 måneder efter agenten ikke længere er aktiv	Konfigurerbart efter aftale; slettes ellers af team-administrator
Kørselshistorik (input, output, fejl)	6 måneder	Konfigurerbart efter aftale; kan også slettes pr. kørsel eller pr. agent af team-administrator
Uploadede dokumenter	6 måneder	Konfigurerbart efter aftale med syv.ai
Strukturerede applikationslogs	6 måneder	Konfigurerbart efter aftale; kan eksporteres til kundens eget SIEM for langtidsopbevaring og uafhængig retention
Auditlogs (login, administrative handlinger)	6 måneder	Konfigurerbart efter aftale; understøtter dokumentation af adgang og ændringer

Idriftsætter er ansvarlig for at fastlægge en opbevaringsperiode, der opfylder fx GDPR's princip om opbevaringsbegrænsning og eventuelle sektorspecifikke krav, og for at aftale en eventuel afvigelse fra standardperioden med syv.ai. 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.

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