Konsekvensanalyse vedrørende databeskyttelse (DPIA) — skabelon for anvendelser bygget på AgentBase

Felt	Værdi
Dokumenttitel	DPIA-skabelon for anvendelser bygget på AgentBase
Skabelonversion	1.0
Senest opdateret	2026-05-01
Skabelonejer	syv.ai (kontakt: mads@syv.ai)
Reviewfrekvens af skabelonen	Mindst én gang årligt og ved væsentlige ændringer i platformen, underleverandører eller risikobillede
Tilhørende dokumenter	Systembeskrivelse for AgentBase, Databehandleraftale (udleveres separat), Liste over underleverandører (udleveres separat)

Denne skabelon understøtter den dataansvarlige (idriftsætter / kunde) i at udarbejde en konsekvensanalyse vedrørende databeskyttelse (DPIA) efter art. 35 i forordning (EU) 2016/679 (GDPR), når der bygges en konkret anvendelse på AgentBase. Skabelonen er udarbejdet af syv.ai som databehandler og indeholder den platform-specifikke information, en dataansvarlig DPO/jurist har brug for, så den ikke skal indhentes fra bunden.

Sådan bruger du skabelonen

• Afsnit markeret [PRÆ-UDFYLDT] indeholder oplysninger om AgentBase som platform. Disse er udfyldt af syv.ai og bør kun ændres, hvis konfigurationen i den konkrete anvendelse afviger fra standard.
• Afsnit markeret [UDFYLDES AF DEN DATAANSVARLIGE] kræver oplysninger, som kun den dataansvarlige har: formålet med behandlingen, behandlingsgrundlaget, de specifikke datatyper i anvendelsen, og risikovurderingen for den konkrete sammenhæng.
• Afsnit markeret [DELVIST PRÆ-UDFYLDT] indeholder en platform-baseline, som den dataansvarlige skal supplere med oplysninger fra det konkrete use case.
• Skabelonen er ikke en erstatning for juridisk rådgivning. Datatilsynets vejledninger og sektorspecifik regulering (fx forvaltningsloven, hvidvaskloven, sundhedsloven) skal konsulteres parallelt.
• En DPIA er kun obligatorisk, når behandlingen "sandsynligvis indebærer en høj risiko for fysiske personers rettigheder og frihedsrettigheder" (art. 35, stk. 1). Datatilsynet har offentliggjort en liste over behandlingstyper, hvor DPIA altid skal udarbejdes.

Dokumentkontrol for den konkrete DPIA

[UDFYLDES AF DEN DATAANSVARLIGE]

Felt	Værdi
Anvendelsens navn	(fx "Forberedelse af sygedagpengeopfølgning")
Dataansvarlig	(fx "Eksempel Kommune, CVR XXXXXXXX")
DPIA-version	1.0
Udarbejdet af	(navn, rolle)
Reviewet af DPO	(navn, dato)
Godkendt af	(navn, rolle, dato)
Næste planlagte revision	(dato)

1. Beskrivelse af behandlingen

1.1 Formål med behandlingen

[UDFYLDES AF DEN DATAANSVARLIGE]

Beskriv kort og konkret, hvad anvendelsen skal opnå. Undgå generiske formuleringer som "effektivisering" — vær specifik om hvilke arbejdsgange der understøttes, hvilke beslutninger der træffes (eller forberedes), og hvem der bruger output.

Eksempel: "Anvendelsen forbereder førstegangsvurdering af sygedagpengesager ved at sammenstille opfølgningsskema, journalnoter og tidligere afgørelser til et udkast til indkaldelsesbrev. Sagsbehandleren reviewer og signerer."

1.2 Behandlingens art, omfang og kontekst

[DELVIST PRÆ-UDFYLDT]

AgentBase eksekverer behandlingen som en orienteret acyklisk graf (DAG) af noder. Hver node udfører en specifik operation (LLM-kald, OCR, dokumentopslag, anonymisering, HTTP-kald, etc.). Behandlingens art for den konkrete anvendelse er bestemt af de noder, der indgår i agentens graf.

[UDFYLDES AF DEN DATAANSVARLIGE]

Beskriv konkret:

• Hvilke nodetyper anvendes (henvis til Systembeskrivelsen, afsnit 2.3)?
• Hvilke eksterne systemer kaldes (CVR-opslag, fagsystemer, e-mail)?
• Hvilke LLM-modeller anvendes, og hvor er de hostet?
• Hvor mange behandlinger forventes pr. dag/måned?
• Er behandlingen automatiseret beslutningstagning i medfør af art. 22?

Vigtigt om art. 22: AgentBase er designet til at understøtte beslutningsstøtte med menneskeligt tilsyn, ikke fuldautomatiske afgørelser. Hvis den konkrete anvendelse træffer afgørelser uden meningsfuld menneskelig involvering, udløses art. 22 og særlige krav. Beskriv eksplicit, hvor og hvordan menneskeligt tilsyn udøves (jf. afsnit 2.4 nedenfor).

1.3 Datakategorier

[DELVIST PRÆ-UDFYLDT]

Følgende datakategorier kan teknisk set håndteres af AgentBase som platform. Hvilke der faktisk indgår i den konkrete anvendelse afhænger af agentens udformning.

Datakategori	Hvor opbevares den i AgentBase	Bemærkning
Brugerkonti for medarbejdere (e-mail, hashed password, rolle)	PostgreSQL hos hosting-partner	Krævet for adgang til platformen
Inputdata til kørsler (uploadede dokumenter, formularinput)	PostgreSQL/objekt-storage	Bestemmes af den konkrete anvendelse
Outputdata (resultater af kørsler)	PostgreSQL	Bestemmes af den konkrete anvendelse
Kørselslogs (input, output, fejl, tidsstempler)	PostgreSQL	Bevares som standard i 6 måneder, kan konfigureres efter aftale med syv.ai, jf. Systembeskrivelsen, afsnit 7.1
API-nøgler og hemmeligheder	PostgreSQL (krypteret)	Anvendes til integration mod eksterne systemer

[UDFYLDES AF DEN DATAANSVARLIGE]

Specificer for den konkrete anvendelse:

• Hvilke konkrete datatyper indgår? (fx CPR-numre, helbredsoplysninger, økonomiske oplysninger, retslige oplysninger, oplysninger om sociale forhold, oplysninger om strafbare forhold)
• Indgår særlige kategorier af personoplysninger (art. 9) eller oplysninger om strafbare forhold (art. 10)?
• Indgår oplysninger om sårbare grupper (børn, syge, ansøgere om sociale ydelser)?

1.4 Berørte personer

[UDFYLDES AF DEN DATAANSVARLIGE]

Beskriv hvilke kategorier af registrerede der er omfattet, og estimat over antallet:

• (fx "Borgere bosiddende i kommunen, ca. 75.000")
• (fx "Sygedagpengemodtagere i et givet kvartal, ca. 1.200")
• (fx "Medarbejdere med adgang til anvendelsen, ca. 35")

1.5 Behandlingsgrundlag

[UDFYLDES AF DEN DATAANSVARLIGE]

Angiv det lovlige grundlag for behandlingen efter art. 6 og — hvis relevant — art. 9 og art. 10. For offentlige myndigheder vil grundlaget typisk være art. 6, stk. 1, litra e (myndighedsudøvelse) sammenholdt med en specifik retsregel (fx forvaltningsloven, lov om sygedagpenge, lov om aktiv beskæftigelsesindsats).

For private virksomheder kan grundlaget være retlig forpligtelse (litra c), kontrakt (litra b), legitim interesse (litra f) eller samtykke (litra a). Angiv også, om der indhentes et særligt grundlag efter art. 9 (fx art. 9, stk. 2, litra b, h eller g) ved særlige kategorier.

1.6 Roller efter GDPR

[PRÆ-UDFYLDT]

Rolle	Aktør
Dataansvarlig	Den dataansvarlige (kunden)
Databehandler	syv.ai (CVR XXXXXXXX)
Underdatabehandlere	Se afsnit 1.7 nedenfor

Reguleringen af forholdet sker i Databehandleraftale på Datatilsynets standardkontrakt-grundlag. Databehandleraftalen udleveres separat og indgås før produktionssætning.

1.7 Underdatabehandlere

[PRÆ-UDFYLDT — opdateres separat]

AgentBase anvender følgende kategorier af underdatabehandlere. Den fuldstændige og ajourførte liste — med navn, geografisk placering, behandlingsformål og DPA-status — udleveres som bilag til Databehandleraftalen.

Kategori	Formål	Geografisk placering (standardkonfiguration)
Hosting-leverandør	Drift af AgentBase backend, frontend, database	EU/Danmark (konkretiseres pr. konfiguration)
LLM-udbyder	Udførelse af sprogmodel-kald	OpenAI Ireland Ltd., EU/EØS-region
OCR-leverandør	Udtræk af tekst fra dokumenter	Mistral AI SAS, EU/Frankrig
E-mail-leverandør	Levering af e-mails fra email-noden	Konkretiseres pr. konfiguration
Fejl-/observabilitetsværktøj	Overvågning af platformens drift	Konkretiseres pr. konfiguration

[UDFYLDES AF DEN DATAANSVARLIGE — eller bekræftes]

Verificer, at signerede databehandleraftaler foreligger med hver navngiven underdatabehandler inden produktionssætning.

1.8 Tredjelandsoverførsler

[PRÆ-UDFYLDT]

AgentBase' underdatabehandlere er alle EU-baserede (Hetzner Online GmbH i Tyskland, OpenAI Ireland Ltd. i EU/EØS-region under Zero Data Retention, Mistral AI SAS i Frankrig). Der sker ikke tredjelandsoverførsler i AgentBase' egen behandlingskæde, og platformen understøtter ikke alternative LLM- eller OCR-leverandører.

[UDFYLDES AF DEN DATAANSVARLIGE — for egne integrationer]

Hvis den konkrete anvendelse anvender noderne http_request, email, cvr_lookup eller sql til at kalde eksterne systemer, idriftsætter selv vælger, er det idriftsætterens ansvar at vurdere, om disse kald medfører tredjelandsoverførsler:

• Sker der tredjelandsoverførsler via idriftsætterens egne integrationer? Ja/Nej.
• Hvis ja: Hvilket overførselsgrundlag anvendes (Kommissionens standardkontraktbestemmelser efter Schrems II, godkendelsesafgørelser, eller andet)?
• Er supplerende foranstaltninger nødvendige (jf. Det Europæiske Databeskyttelsesråds anbefalinger 01/2020)?

1.9 Opbevaringsperiode

[DELVIST PRÆ-UDFYLDT]

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

[UDFYLDES AF DEN DATAANSVARLIGE]

Bekræft, om standardopbevaringsperioden på 6 måneder anvendes for den konkrete anvendelse, eller specificér den aftalte afvigelse pr. datatype. Vurdér, om perioden opfylder GDPR's princip om opbevaringsbegrænsning (art. 5, stk. 1, litra e) og eventuelle sektorspecifikke krav (fx arkivlovens regler for offentlige myndigheder, bogføringslovens 5-årsregel, hvidvaskloven). Beskriv, hvordan retention håndhæves operationelt — via standardperioden, en aftalt afvigelse med syv.ai, eller eksport til ekstern SIEM-/arkivløsning med uafhængig retention.

2. Nødvendighed og proportionalitet

2.1 Vurdering af nødvendighed

[UDFYLDES AF DEN DATAANSVARLIGE]

Argumentér for, at behandlingen er nødvendig for at opfylde formålet, og at formålet ikke kan opnås på en mindre indgribende måde. Overvej eksplicit:

• Kan formålet opnås uden personoplysninger?
• Kan formålet opnås med færre personoplysninger?
• Kan formålet opnås uden brug af automatiseret behandling?
• Hvis svaret er "nej": dokumentér hvorfor.

2.2 Dataminimering

[DELVIST PRÆ-UDFYLDT]

AgentBase tilbyder følgende værktøjer til dataminimering:

• anonymization-noden kan fjerne CPR-numre, navne og andre direkte personhenførbare oplysninger inden videresendelse til ekstern model. Anvendelsen er konfigurerbar pr. flow.
• structured_output-noden muliggør, at modeloutput valideres mod et skema, så kun de relevante felter videreføres.
• Filtrering før eksterne kald: ved at placere filtrerings-, anonymiserings- eller udvælgelsesnoder før eksterne kald kan det dokumenteres, at kun nødvendige oplysninger forlader platformen.

[UDFYLDES AF DEN DATAANSVARLIGE]

Beskriv, hvordan dataminimering håndhæves i den konkrete anvendelse. Giv konkrete eksempler — fx "CPR-nummer anonymiseres før LLM-kald i node X" — og dokumentér, at flowet er testet på et kontrolleret datasæt.

2.3 Information til de registrerede

[DELVIST PRÆ-UDFYLDT]

AgentBase giver ikke selv direkte information til registrerede; informationspligten påhviler den dataansvarlige (art. 13 og 14). Platformen understøtter informationspligten ved:

• At gøre formularer til apps konfigurerbare, så informationspligt-tekst og samtykker kan indlejres.
• At dokumentere kørsler og brugte modeller, hvilket understøtter besvarelse af indsigtsanmodninger.

[UDFYLDES AF DEN DATAANSVARLIGE]

Beskriv, hvordan de registrerede informeres om behandlingen. Vedlæg den konkrete privatlivspolitik eller informationsskrivelse som bilag. Hvis behandlingen omfatter automatiserede individuelle afgørelser, skal informationen indeholde meningsfulde oplysninger om logikken samt konsekvenserne (art. 13, stk. 2, litra f).

2.4 De registreredes rettigheder

[PRÆ-UDFYLDT]

AgentBase understøtter den dataansvarliges håndtering af de registreredes rettigheder via:

Rettighed	Platformfunktion
Indsigt (art. 15)	Kørselshistorikken kan eksporteres i struktureret form og udleveres som del af et indsigtssvar
Berigtigelse (art. 16)	Inputdata kan rettes og kørsler genkøres på opdateret grundlag
Sletning (art. 17)	Kørsler, dokumenter og brugere kan slettes manuelt af en bruger med passende rolle
Begrænsning (art. 18)	Apps kan deaktiveres af administrator, så ny behandling stopper
Dataportabilitet (art. 20)	Kørsler kan eksporteres i JSON-format
Indsigelse (art. 21)	Den dataansvarlige håndterer indsigelser organisatorisk; AgentBase understøtter med stop-funktion og audit
Ikke at være underlagt automatiseret afgørelse (art. 22)	Anmelder-rolle og manuel godkendelse i flowet sikrer menneskeligt tilsyn

[UDFYLDES AF DEN DATAANSVARLIGE]

Beskriv den organisatoriske proces, der sikrer rettidig besvarelse af anmodninger fra registrerede (typisk én måned), inklusive eskaleringspunkter og ansvarlige roller.

3. Risikoanalyse

3.1 Identificerede risici på platformniveau

[PRÆ-UDFYLDT]

Risiko	Sandsynlighed (uden foranstaltninger)	Konsekvens for den registrerede	Mitigation på platformniveau
Uautoriseret adgang til kørselsdata	Lav	Høj (fortrolighedsbrud)	RBAC, JWT-tokens, team-isolation, kryptering at-rest og in-transit
Datalækage til ekstern LLM/OCR	Middel	Høj (særligt ved særlige kategorier)	Anonymiseringsnode, EU-baserede underdatabehandlere, Zero Data Retention hos OpenAI, ingen træning hos Mistral, dokumenteret dataflow
Hallucination eller fejl i modeloutput, der lægges til grund for afgørelse	Middel	Høj (urigtig afgørelse)	Strukturerede outputs, evalueringsmodul, anmelder-godkendelse, menneskeligt tilsyn på flowniveau
Tab af sporbarhed	Lav	Middel (manglende dokumentationsgrundlag)	Komplet kørselslogning, versionshistorik for agents, eksport til SIEM
Eksekvering af ondsindet brugerkode (python_code-node)	Lav	Middel	Sandkasse-eksekvering med begrænset netværks- og filsystemadgang
Tjenesteafbrydelse	Lav	Lav til middel afhængigt af kritikalitet	Hosting-leverandørens SLA, fejlhåndtering pr. node uden samlet kørselsnedbrud

For en fuldstændig liste over platform-niveau-risici og mitigationer, se Systembeskrivelsen, afsnit 4.1 og afsnit 6.

3.2 Use case-specifikke risici

[UDFYLDES AF DEN DATAANSVARLIGE]

Identificér risici, der er specifikke for den konkrete anvendelse, ud over platform-niveau. Eksempler:

• Risiko for diskrimination, hvis modellen reflekterer biased træningsdata for en bestemt borgergruppe.
• Risiko for "automation bias" hos sagsbehandlere, der godkender AI-udkast uden tilstrækkelig kritisk gennemgang.
• Risiko for forkert klassificering, der fører til urimelig sagsbehandling.
• Risiko for genidentifikation af pseudonymiserede personer via kontekstuelle oplysninger.

For hver risiko, vurdér sandsynlighed (Lav/Middel/Høj) og konsekvens (Lav/Middel/Høj) for den registreredes rettigheder og frihedsrettigheder.

3.3 Risikomatrix

[UDFYLDES AF DEN DATAANSVARLIGE]

#	Risiko	Sandsynlighed	Konsekvens	Samlet risikoniveau	Risikoejer
R1	(beskrivelse)	(L/M/H)	(L/M/H)	(L/M/H)	(rolle)
R2	(beskrivelse)	(L/M/H)	(L/M/H)	(L/M/H)	(rolle)
...

4. Foranstaltninger

4.1 Tekniske foranstaltninger på platformniveau

[PRÆ-UDFYLDT]

• Autentifikation via JWT-tokens med konfigurerbar levetid; adgangskoder hashes med moderne adaptiv algoritme.
• Rollebaseret adgangskontrol med fire roller (Bruger, Udvikler, Anmelder, Administrator).
• TLS for al kommunikation mellem klient og server i produktion.
• API-nøgler og hemmeligheder krypteres at-rest i databasen.
• Inputvalidering på alle systemgrænser via Pydantic.
• Statisk analyse, typecheck og automatiseret test ved hver kodeændring i CI/CD.
• Afhængigheder opdateres automatisk via Dependabot.
• Fejlhåndtering pr. node forhindrer enkelt-fejl i at nedlægge hele kørslen.
• Konfigurerbare grænser for antal noder/kanter pr. agent forhindrer ressourceudtømmelse.

For den fulde tekniske beskrivelse henvises til Systembeskrivelsen, afsnit 6.

4.2 Organisatoriske foranstaltninger på platformniveau

[PRÆ-UDFYLDT]

• Versionsstyret kildekode med pull request-review.
• Dokumenteret hændelseshåndteringsproces hos syv.ai.
• Dokumenteret release- og changelog-proces.
• Dokumentation som kode — systembeskrivelse og DPIA-skabelon ligger i samme repository som koden.
• Databehandleraftale på Datatilsynets standardgrundlag.

4.3 Konfigurationsanbefalinger pr. risiko

[PRÆ-UDFYLDT]

Risiko	Anbefalet konfiguration
Tredjelandsoverførsel	AgentBase' underdatabehandlere er EU-baserede (se Underdatabehandlere). Idriftsætterens egne integrationsnoder (http_request, email m.fl.) skal valideres separat, hvis de behandler personoplysninger.
Datalækage til model	Indsæt anonymization-node før alle LLM-kald, der modtager personoplysninger. Test på et kontrolleret datasæt.
Automation bias	Anvend Anmelder-rolle for kritiske flows. Indsæt obligatorisk godkendelsestrin i flowet før resultatet videreføres.
Hallucination	Anvend structured_output med skema og validering. Definér evalueringssæt og kør dem som del af versions-godkendelse.
Tab af sporbarhed	Aktiver eksport af logs til kundens SIEM via LOG_JSON=true.

4.4 Yderligere foranstaltninger hos den dataansvarlige

[UDFYLDES AF DEN DATAANSVARLIGE]

Beskriv de yderligere foranstaltninger, den dataansvarlige implementerer, herunder:

• Uddannelse og instruks af medarbejdere, der bruger anvendelsen.
• Procedurer for håndtering af modeloutput, der ikke kan kvalitetsvurderes.
• Procedurer for incident response og brud-anmeldelse til Datatilsynet (art. 33-34).
• Plan for periodisk evaluering af anvendelsens nøjagtighed.

5. Restrisiko og konklusion

[UDFYLDES AF DEN DATAANSVARLIGE]

Efter at platformens og den dataansvarliges foranstaltninger er anvendt, vurdér den tilbageværende risiko for hver identificeret risiko. Konkluder, om restrisikoen er acceptabel.

#	Risiko	Restrisiko (efter foranstaltninger)	Acceptabel?
R1		(L/M/H)	(Ja/Nej + begrundelse)
R2		(L/M/H)	(Ja/Nej + begrundelse)

Samlet konklusion: (Den dataansvarlige skriver en kort konklusion: kan behandlingen igangsættes som beskrevet, eller kræves yderligere foranstaltninger / konsultation af Datatilsynet?)

6. Godkendelse og opfølgning

6.1 Konsultation af Datatilsynet

[UDFYLDES AF DEN DATAANSVARLIGE]

Hvis konsekvensanalysen viser, at behandlingen indebærer en høj risiko, som ikke kan afbødes med rimelige foranstaltninger, skal Datatilsynet konsulteres efter art. 36, før behandlingen påbegyndes.

Vurdering: (Påkrævet / Ikke påkrævet). Begrundelse: (...).

6.2 Godkendelse

[UDFYLDES AF DEN DATAANSVARLIGE]

Felt	Værdi
Godkendt af	(navn, rolle)
Dato
Vilkår eller forbehold	(eventuelle vilkår, der gælder for igangsættelsen)

6.3 Plan for revision

[UDFYLDES AF DEN DATAANSVARLIGE]

Beskriv den planlagte revisionscyklus:

• Hvornår revurderes DPIA'en (typisk minimum årligt)?
• Hvilke ændringer udløser en ekstraordinær revision (ny model, ny datakategori, nyt formål, ny underleverandør, ændret risikobillede)?
• Hvem er ansvarlig for at initiere revisionen?

7. Referencer

• Systembeskrivelse for AgentBase — generel teknisk og organisatorisk beskrivelse af platformen
• Databehandleraftale — udleveres separat af syv.ai
• Liste over underdatabehandlere — udleveres som bilag til Databehandleraftalen
• Datatilsynets vejledning om konsekvensanalyse: datatilsynet.dk (se publikationer om DPIA)
• Det Europæiske Databeskyttelsesråd: anbefalinger 01/2020 om foranstaltninger ved tredjelandsoverførsler
• Forordning (EU) 2016/679 (GDPR), særligt art. 35-36
• Forordning (EU) 2024/1689 (AI-forordningen) — for behandlinger der udgør AI-systemer

8. Revisionshistorik for skabelonen

Version	Dato	Ændring	Ansvarlig
1.0	2026-05-01	Første udgave af DPIA-skabelonen for anvendelser bygget på AgentBase.	syv.ai

---

Bemærk: Denne skabelon er udarbejdet af syv.ai med henblik på at lette dataansvarliges arbejde med konsekvensanalyser. Skabelonen er ikke juridisk rådgivning, og syv.ai påtager sig ikke ansvar for fuldstændigheden eller korrektheden af en konkret DPIA udarbejdet på baggrund af skabelonen. Den dataansvarlige bør indhente intern eller ekstern juridisk rådgivning ved tvivlsspørgsmål, særligt vedrørende behandlingsgrundlag, særlige kategorier af personoplysninger og krav til konsultation af Datatilsynet.