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

Felt	Værdi
Dokumenttitel	DPIA-skabelon for anvendelser bygget på AgentBase
Skabelonversion	1.5
Senest opdateret	2026-11-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, Liste over underdatabehandlere

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 (dokumentarkivet gemmer kun den udtrukne tekst; filer, der indgår i en kørsel, gemmes i kørslens data)	Bestemmes af den konkrete anvendelse
Outputdata (resultater af kørsler)	PostgreSQL	Bestemmes af den konkrete anvendelse
Kørselslogs (input, output, fejl, tidsstempler)	PostgreSQL	Indholdet slettes automatisk efter organisationens valgte opbevaringsperiode (konfigureres i AgentBase under Administration → Organisation → Generelt → Dataopbevaring; standard 184 dage). Kørsler, der indgår som evidens i kvalitetskontrollen (tests og bedømmelser), undtages, så længe de indgår som evidens, 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 ApS, Rosenvængets Allé 11, 1. sal, 2100 København Ø (CVR 44671247)
Underdatabehandlere	Se afsnit 1.7 nedenfor

Reguleringen af forholdet sker i Databehandleraftalen på Datatilsynets standardkontrakt-grundlag; den indgås før produktionssætning.

1.7 Underdatabehandlere

[PRÆ-UDFYLDT]

AgentBase anvender følgende underdatabehandlere, jf. Databehandleraftalens Bilag B.1. Den løbende ajourførte liste med registreringsnummer, adresse og DPA-status findes på Underdatabehandlere.

Underdatabehandler	Formål	Geografisk placering
Hetzner Online GmbH	Hosting og drift af AgentBase-applikation, database og lagring	Tyskland (EU)
OpenAI Ireland Ltd.	LLM-inference (sprogmodel-kald), Zero Data Retention	EU/EØS
Mistral AI SAS	LLM-inference (sprogmodel, herunder standardmodellen i Anonymiser tekst) samt OCR og dokumentudtræk fra uploadede dokumenter	Frankrig (EU)
Lettermint B.V.	Afsendelse af e-mails (transaktionelle og via email-noden)	Nederlandene/Frankrig (EU/EØS)
Eleven Labs Inc. (indtil 22. oktober 2026 midlertidigt erstattet af OpenAI på platformens egen adgang)	Billedgenerering (Billedgenerering-noden og chat-værktøjet "Generér billede") — kun hvis anvendelsen bruger det	USA (tredjeland, EU-U.S. Data Privacy Framework); Zero Data Retention, ingen træning
Pydantic Services Inc. (Logfire)	Driftstelemetri for platformen, når den er slået til: applikationslogs, sporing af API-kald (uden parameterværdier) og modelkald (uden prompt-indhold), fejl; for den indbyggede Chat også samtalens tekst. Udløses ikke af anvendelsens byggeklodser	Oplyst af leverandøren, verificeres (Logfire udbydes i en EU- og en US-region); se Underdatabehandlere §2.6

[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' standardkæde er EU-baseret (Hetzner Online GmbH i Tyskland, OpenAI Ireland Ltd. i EU/EØS-region under Zero Data Retention, Mistral AI SAS i Frankrig, Lettermint B.V. i Nederlandene/Frankrig). Billedgenerering er en tredjelandsoverførsel: anvender flowet Billedgenerering-noden, eller kalder brugere chat-værktøjet "Generér billede", sendes tekstbeskrivelsen og eventuelle referencebilleder til Eleven Labs Inc. i USA. Overførselsgrundlaget er EU-U.S. Data Privacy Framework (ElevenLabs er aktiv deltager, certificeret 9. februar 2026) med standardkontraktbestemmelser i ElevenLabs' DPA som fallback; behandling sker i USA, EU eller Singapore, og billedmodellen leveres af ElevenLabs' underdatabehandler OpenAI. Detaljer i Underdatabehandlere. Anvender flowet ikke billedgenerering, sker der ingen tredjelandsoverførsel i AgentBase' egen behandlingskæde.

[UDFYLDES AF DEN DATAANSVARLIGE]

Angiv, om anvendelsen bruger billedgenerering. Hvis ja: vurdér, om referencebilleder kan indeholde personoplysninger (fx fotos af personer), og om de i så fald bør anonymiseres eller udelades.

[UDFYLDES AF DEN DATAANSVARLIGE for egne integrationer]

Hvis den konkrete anvendelse anvender noderne http_request eller sql til at kalde eksterne systemer, idriftsætter selv vælger, eller hvis organisationen har koblet egne modeladgange på under Administration → Organisation → Integrationer (egne AI-nøgler, egen Azure OpenAI-ressource eller egen LLM-server), er det idriftsætterens ansvar at vurdere, om disse kald medfører tredjelandsoverførsler. En Azure-ressource kan ligge i en vilkårlig region, og en egen LLM-server kan stå på en vilkårlig offentlig vært:

• 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]

Opbevaringsperioden for kørselsdata konfigureres af den dataansvarliges egen administrator direkte i AgentBase (Administration → Organisation → Generelt → Dataopbevaring), mellem 7 og 3653 dage; standard er 6 måneder (184 dage). Indholdet af ældre kørsler (input, output og fejldetaljer) slettes automatisk og løbende, mens registreringen af kørslen (status, varighed, tidspunkter) bevares af hensyn til fakturering og statistik. Kørsler, der indgår som evidens i kvalitetskontrollen (tests og bedømmelser), undtages fra den automatiske sletning, så længe de indgår som evidens. Dokumenter uploadet som input til en kørsel følger kørselshistorikken; dokumentbiblioteket er kundeadministreret og slettes af organisationen selv. Se Systembeskrivelsen, afsnit 7.1 og Databehandleraftalens Bilag C.4.

[UDFYLDES AF DEN DATAANSVARLIGE]

Angiv den opbevaringsperiode, der er konfigureret i AgentBase for den konkrete anvendelse (standard 184 dage, hvis intet er valgt). 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). Vælges en periode længere end standarden, skal den dataansvarlige kunne begrunde opbevaringen. Beskriv, hvordan retention håndhæves operationelt — via den indbyggede automatiske sletning i AgentBase eller suppleret med 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:

• Anonymiser tekst kan fjerne CPR-numre, navne og andre direkte personhenførbare oplysninger, før teksten går videre til de næste eksterne kald. Byggeklodsen sender selv den originale tekst til en sprogmodel (standard: EU-model hos Mistral) for at finde oplysningerne, så den indskrænker modtagerkredsen uden at fjerne den, jf. Dataflow §8. 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)	En administrator kan selv eksportere organisationens data — herunder kørselshistorikken inden for opbevaringsperioden — som et ZIP-arkiv med JSON-filer (Organisation → Generelt → Dataeksport eller REST-API'et) og udlevere det relevante udsnit 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. En kørsel, der er bedømt i kvalitetskontrollen, kan dog ikke slettes, og "Ryd kørselshistorik" for et flow springer kørsler over, der indgår som test-evidens, fordi de dokumenterer, hvad der faktisk blev kørt
Begrænsning (art. 18)	Apps kan deaktiveres af administrator, så ny behandling stopper
Dataportabilitet (art. 20)	Selvbetjent dataeksport (Organisation → Generelt → Dataeksport eller REST-API'et): brugere, teams, flows og deres versioner, apps, kørsler, dokumenter og auditlog i JSON-format. Hemmeligheder (adgangskoder, API-nøgler, webhook-secrets, variablers værdier) indgår ikke
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)	Menneskelig kvalitetskontrol — bedømmelse og forsegling af en bruger med mindst Anmelder-rollen, udgivelse af en bruger med mindst Udvikler-rollen — samt manuel godkendelse i flowet sikrer menneskeligt tilsyn. Den forseglede rapport dokumenterer ærligt hvem der byggede (sendte versionen til kvalitetskontrol) og hvem der bedømte og forseglede den — herunder hvis det var samme person (solo-aktør-markering) — frem for at love en adskillelse platformen ikke håndhæver teknisk. Hvem der udførte selve udgivelsen, registreres ikke i rapporten

[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 for Bruger, Anmelder og Udvikler (Administrator ser hele organisationen), 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
Tredjelandsoverførsel ved billedgenerering (kun hvis anvendt)	Middel	Middel–Høj (afhænger af, om beskrivelse/referencebilleder indeholder personoplysninger)	Fravalg af Billedgenerering-noden/chat-værktøjet, anonymiseringsnode før kaldet, ingen referencebilleder med personer, EU-U.S. DPF-grundlag, Zero Data Retention og ingen træning hos ElevenLabs
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)	Kørselslogning pr. node inden for den valgte opbevaringsperiode (registreringen af kørslen bevares derefter), versionshistorik for agents, udlevering af applikationslogs i JSON-format efter aftale
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; er en ekstern udbyder utilgængelig, fejler de pågældende noder med en sporbar fejlmeddelelse, men resten af platformen og agents uden disse noder kører videre

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 fem roller: Bruger, Anmelder og Udvikler ser kun data i de teams, de er medlem af; Administrator ser alt indhold i sin egen organisation; Superadministrator er syv.ai's driftsrolle (tildelt ud fra en liste over godkendte e-mailadresser), der arbejder inde i én organisation ad gangen som dens administrator, og hvert skift skrives til auditloggen.
• TLS for al kommunikation mellem klient og server i produktion.
• Disk og backups krypteres hos hosting-leverandøren (AES-256, oplyst af leverandøren); API-nøgler og hemmeligheder krypteres desuden på feltniveau i databasen (Fernet: AES-128-CBC + HMAC-SHA256) med en applikationsadministreret nøgle.
• Login samt bruger-, adgangs- og administrative handlinger skrives til en auditlog; læsning af personoplysninger (visning af en kørsel eller et dokument) logges ikke — et kendt gap, jf. Systembeskrivelsen, afsnit 7.
• 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.
• 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.
• 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 i standardkæden er EU-baserede; billedgenerering er en tredjelandsoverførsel til Eleven Labs Inc., USA (afsnit 1.8, se Underdatabehandlere). Idriftsætterens egne integrationsnoder (http_request, sql) og egne modeladgange (egne AI-nøgler, Azure OpenAI, egen LLM-server) skal valideres separat, hvis de behandler personoplysninger.
Datalækage til model	Indsæt Anonymiser tekst før de LLM-kald, der modtager personoplysninger, og medregn, at byggeklodsen selv er ét kald til sprogmodel-udbyderen. 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	Hent kørselshistorik løbende via REST-API'et, inden opbevaringsperioden udløber, og aftal med syv.ai, hvis applikationslogs (JSON) skal udleveres eller videresendes til jeres eget SIEM.

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 standardkontraktsbestemmelser med bilag A-D
• Liste over underdatabehandlere den løbende ajourførte liste, jf. Databehandleraftalens Bilag B.1
• 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
1.1	2026-08-11	Udfyldt syv.ai's CVR (44671247) og de navngivne underdatabehandlere (Hetzner, OpenAI Ireland, Mistral AI, Lettermint) fra Databehandleraftalens Bilag B.1; tilføjet links til Databehandleraftalen og listen over underdatabehandlere.	syv.ai
1.2	2026-08-19	Afsnit 1.3 og 1.9 opdateret: Opbevaringsperioden for kørselsdata konfigureres nu af den dataansvarliges administrator direkte i AgentBase (Administration → Opbevaring, 7–3653 dage, standard 184 dage) med automatisk, løbende sletning af indholdet.	syv.ai
1.3	2026-09-07	Afsnit 1.7, 1.8 og 5 opdateret: Eleven Labs Inc. (USA) tilføjet som underdatabehandler for billedgenerering; tredjelandsoverførsel og tilhørende risiko beskrevet som betinget af, om anvendelsen bruger billedgenerering.	syv.ai
1.4	2026-09-23	Rettet efter gennemgang mod koden (issue #1045): egne modeladgange og idriftsætterens egne integrationer præciseret (Send Email og CVR Opslag er platformens); Mistral leverer også LLM-inference; underdatabehandlere i standardkæden er EU-baserede, billedgenerering er en tredjelandsoverførsel; ingen separat objekt-storage; en fejlende node stopper kørslen; test-evidens undtages fra sletning; kørselslogning afgrænset af opbevaringsperioden; Anonymiser tekst beskrevet som selv et kald til en sprogmodel.	syv.ai
1.5	2026-11-01	Rulings fra issue #1090 indarbejdet: afsnit 1.7 tilføjet Pydantic Services Inc. (Logfire) som underdatabehandler for driftstelemetri med region til verifikation (issue #1065); afsnit 2 (art. 22) rapporten dokumenterer bygger og forsegler, ikke udgiver; afsnit 3.1 og 4.1 fem roller, Administrator ser hele organisationen, kryptering angivet med de faktiske cifre (AES-256 på disk hos hosting-leverandøren, Fernet på feltniveau), auditloggens omfang og det kendte gap om læsning; afsnit 3.1 og 4.3 LOG_JSON=true/"eksport til SIEM" erstattet af udlevering efter aftale.	syv.ai
1.6	2026-11-01	Afsnit om de registreredes rettigheder: indsigt (art. 15) og dataportabilitet (art. 20) understøttes nu af en selvbetjent dataeksport af hele organisationen (Organisation → Generelt → Dataeksport eller REST-API'et) som et ZIP-arkiv med JSON-filer.	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.