Hvor gemmes jeres AI-mødereferater — og hvem har adgang?

Hvor ligger AI-mødereferater, som agenter genererer?

Mødereferater gemmes typisk i leverandørens sky-infrastruktur sammen med data fra alle andres kunder, medmindre du aktivt har valgt en løsning med egen instans og egen database.

Når en AI-agent laver mødereferater og noter ud fra jeres tekst og dokumenter, gemmes materialet som udgangspunkt i leverandørens egen sky-infrastruktur, sammen med data fra alle andres kunder på samme platform, medmindre I aktivt har valgt en løsning med egen instans og egen database. Det afgørende er derfor ikke om referaterne "er i skyen" — det er de stort set altid et sted — men hvem der ejer databasen, hvem der teknisk kan tilgå den, og om data bruges til andet end at levere jeres egen funktion. Det er tre forskellige spørgsmål, og de kræver hver sit svar fra leverandøren.

Hvad denne artikel handler om — og hvad den ikke gør

Denne artikel handler om skriftlige mødereferater og noter: tekst, der er skrevet, indtastet i et dokument, eller sammenfattet af en AI-agent ud fra jeres egne noter, mails eller dokumenter i chat- og indbakke-værktøjer. Det er den skriftlige del af arbejdsgangen, der er i fokus: AI'en modtager tekst, strukturerer den, og gemmer resultatet et sted. Netop derfor er spørgsmålet om lagringssted og adgang så centralt — det er den del af kæden, I selv har mest indflydelse på at vælge rigtigt fra starten.

Hvorfor spørgsmålet overhovedet er relevant

Mødereferater er ikke bare et praktisk dokument — de er ofte blandt de mest følsomme tekster i en virksomhed. Et referat fra et kundemøde kan indeholde priser, forhandlingsposition og personoplysninger om kunden. Et referat fra et internt strategimøde kan indeholde ansættelsesplaner, økonomital og ting, der aldrig var tænkt til at forlade lokalet. Når en AI-agent begynder at samle, strukturere og gemme den slags tekst automatisk, flytter I reelt jeres mest følsomme skriftlige kommunikation ind i endnu et system — og det system har sine egne regler for opbevaring og adgang, som I sjældent har forhandlet selv.

Det gør spørgsmålet "hvor ligger det henne?" til andet end teknisk nysgerrighed. Det er et spørgsmål om, hvem der reelt har kontrol over jeres virksomheds interne viden.

De tre modeller for datalagring

Der findes i praksis tre forskellige måder, en AI-leverandør kan gemme jeres mødedata på. De ligner hinanden udadtil — "det ligger i skyen" — men de er meget forskellige i, hvor meget kontrol I beholder.

1. Delt sky (multi-tenant)

Den mest almindelige model. Jeres data ligger i samme database-infrastruktur som alle andre kunders data, adskilt logisk via kontonøgler og rettighedslag i softwaren — ikke fysisk i separate databaser. Det er billigere at drive for leverandøren, og det er derfor den model, de fleste standardværktøjer bruger. Adskillelsen er god nok til normal drift, men den betyder også, at en fejl i leverandørens adgangsstyring i teorien kan eksponere data på tværs af kunder — det er sket for store softwareleverandører før, uafhængigt af AI.

2. Egen instans, delt infrastruktur

En mellemmodel, hvor I får jeres egen database, men den kører stadig på leverandørens delte servere og under leverandørens overordnede administrative adgang. I har bedre logisk adskillelse end i multi-tenant-modellen, men leverandørens support- og drifts-personale kan stadig have teknisk adgang til den underliggende infrastruktur.

3. Egen instans og egen database (selvstændig eller self-hosted)

Den model, hvor virksomheden har sin egen instans og egen database pr. kunde — og hvor det i nogle tilfælde også er muligt at self-hoste selve platformen på egen infrastruktur. Her er dataejerskabet tydeligst: det er jeres database, og adgang styres af jeres egne aftaler og rettigheder, ikke af en delt konfiguration hos leverandøren. Agent360 er bygget efter denne model — egen instans og egen database pr. kunde, med mulighed for self-host, og med kode der bliver open source (fair source) efter to år, så arkitekturen ikke er en sort boks.

Ingen af de tre modeller er automatisk "ulovlig" eller "farlig" — det afgørende er, at I ved, hvilken I har valgt, og at den passer til, hvor følsomt jeres mødeindhold reelt er.

Hvad "adgang" faktisk betyder i praksis

"Hvem har adgang" er ikke ét spørgsmål — det er mindst fire:

Jeres egne brugere. Kan enhver medarbejder med login se alle mødereferater, eller er der roller og rettighedsstyring, så et referat fra en lønforhandling kun er synligt for de relevante personer? Mange værktøjer er bygget til bred deling internt som udgangspunkt, og det er ikke altid det, I ønsker.

Leverandørens driftspersonale. Kan leverandørens ansatte teknisk tilgå indholdet — for eksempel til support, fejlretning eller kvalitetssikring af AI-modellen? Det er lovligt og almindeligt, men det bør stå klart i databehandleraftalen, hvornår og hvorfor det sker.

Underleverandører. De færreste AI-værktøjer er bygget fra bunden af én virksomhed. Der ligger ofte en sprogmodel-leverandør, en cloud-udbyder og måske en tredje part til søgning eller lagring i kæden. Hvert led er en potentiel adgangsvej, og det skal fremgå af databehandleraftalen, hvem underleverandørerne er.

Andre kunder på platformen. Kun relevant ved delt sky-modeller — men det er her adskillelsen mellem kunder er vigtigst at få bekræftet, ikke bare antaget.

Bruges jeres mødereferater til at træne modellen?

Et separat spørgsmål fra opbevaring er, om indholdet af jeres referater bruges til at forbedre eller genoptræne den underliggende AI-model. Det er ikke det samme som opbevaring — data kan ligge sikkert isoleret og stadig blive brugt til træning, hvis leverandørens vilkår tillader det. Dette bør stå eksplicit i aftalen, ikke antages. Hvis leverandøren ikke klart kan svare på, om jeres data indgår i træningsdata for fremtidige modelversioner, er det et spørgsmål, der skal afklares skriftligt, før I lægger følsomt mødeindhold ind i systemet.

Mange leverandører skelner i deres vilkår mellem "at levere funktionen til dig" og "at forbedre produktet generelt". Den første kategori er nødvendig for, at værktøjet overhovedet virker — AI-agenten skal læse referatet for at kunne strukturere det. Den anden kategori er valgfri og handler om, hvorvidt jeres konkrete tekst bruges til at gøre modellen bedre for alle kunder, inklusive konkurrenter til jer. Nogle leverandører giver mulighed for at fravælge det sidste; andre gør det ikke, eller gør det kun for bestemte abonnementsniveauer. Det er værd at læse den del af vilkårene direkte i stedet for at antage, at "vi bruger ikke jeres data" gælder begge kategorier.

Hvad der sker, når I opsiger aftalen

Et punkt, der ofte overses i starten af et samarbejde, er, hvad der sker med mødereferaterne, den dag I skifter leverandør eller stopper med at bruge værktøjet. Tre spørgsmål er relevante her:

Kan I få data eksporteret i et brugbart format, så referaterne ikke bare forsvinder eller bliver ulæselige i et proprietært system? Bliver data faktisk slettet hos leverandøren efter opsigelse, eller ligger det i en backup-rotation i månedsvis bagefter? Og gælder sletningen også de kopier, der måtte være brugt til analyse eller modelforbedring undervejs?

Svarene bør stå i databehandleraftalen eller i de generelle vilkår, ikke kun loves mundtligt af en sælger. Er I i en brancher med skærpede opbevaringskrav — eksempelvis revision, jura eller sundhed — er det særligt vigtigt at få afklaret, om jeres egne opbevaringspligter kan opfyldes inden for leverandørens rammer, eller om det kræver en anden model, som egen database eller self-host.

Hvad I konkret bør spørge jeres leverandør om

Før I lader en AI-agent håndtere mødereferater i stor skala, er der en håndfuld spørgsmål, der er værd at få skriftligt svar på:

• Ligger vores data i en delt database, eller har vi vores egen instans?
• Hvor er serverne fysisk placeret, og overføres data til lande uden for EU/EØS?
• Hvem hos jer (leverandøren) har teknisk adgang til vores data, og hvorfor?
• Hvilke underleverandører indgår i jeres databehandlerkæde?
• Bruges vores indhold til at træne eller forbedre jeres AI-model?
• Kan vi få data slettet fuldstændigt, hvis vi opsiger aftalen — og hvor lang tid tager det?
• Findes der en mulighed for self-host, hvis vores følsomhedsniveau kræver det?

Svarene bør stå i eller følge af databehandleraftalen (DPA). Er svarene vage eller mundtlige, er det i sig selv et signal om, at arkitekturen ikke er bygget til at give klare svar.

Hvad AI'en IKKE skal

AI-agenten skal ikke være den, der afgør, om jeres datahåndtering er compliant — det er en juridisk vurdering, som skal ligge hos jer eller jeres rådgiver, ikke hos softwaren. AI'en skal heller ikke automatisk dele mødereferater bredt internt, blot fordi det er teknisk muligt — adgang bør stadig følge samme rolle- og behovsprincip, som gjaldt før AI kom ind i billedet. Og AI'en skal ikke bruges som en sort boks: er I ikke i stand til at få et klart svar på, hvor data ligger, og hvem der har adgang, er det et tegn på, at værktøjet ikke er modent nok til følsomt mødeindhold — uanset hvor gode referaterne ser ud til at være.

Sådan passer det ind i en bredere AI-strategi

Spørgsmålet om datalagring hænger sammen med det bredere spørgsmål om, hvad en AI-agent til virksomheden egentlig er, og hvor meget af virksomhedens interne data den får adgang til over tid. Mødereferater er sjældent isolerede — de bliver ofte koblet sammen med CRM-data, kundehistorik og opfølgningsopgaver, og derfor er det relevant at se datalagring i sammenhæng med, hvordan CRM-automatisering og god CRM-data-hygiejne hænger sammen med resten af jeres AI-opsætning. Jo flere systemer der kobles sammen, jo vigtigere bliver det at have overblik over, hvor de underliggende data faktisk befinder sig.

Det gælder især for kundevendte teams, hvor mødereferater ofte er første led i en kæde, der ender med opfølgning, tilbud eller support. Den samme mødenote, der i dag ligger som en fil i et referat-værktøj, bliver i morgen måske grundlag for en opfølgningsmail eller en note på en kundesag i customer success-arbejdet. Hvis I ikke ved, hvor det første led i kæden ligger, og hvem der har adgang til det, mister I også overblikket over resten af kæden — uanset hvor gode de efterfølgende automatiseringer er.

Størrelse betyder noget, men er ikke hele billedet

Det er fristende at tænke, at en stor, kendt leverandør automatisk er et sikrere valg end en mindre, fordi de "har flere ressourcer til sikkerhed". Det kan være rigtigt for den rene tekniske sikkerhed omkring servere og kryptering — men det siger ikke noget om, hvor gennemsigtig arkitekturen er for jer som kunde. En stor, multi-tenant-platform kan have fremragende sikkerhed og stadig være bygget sådan, at I ikke kan få egen database eller self-host, fordi hele forretningsmodellen hviler på delt infrastruktur. Omvendt kan en mindre leverandør, der er bygget om egen instans og egen database fra starten, give jer mere reelt dataejerskab — selv med færre ressourcer i ryggen. Spørgsmålet, I bør stille jer selv, er derfor ikke "hvor stor er leverandøren", men "kan jeg få et klart, skriftligt svar på, hvor mine data er, og hvem der kan se dem — og passer den arkitektur til, hvor følsomt mit mødeindhold er."

Ofte stillede spørgsmål

Kilder og videre læsning

Dette er ikke juridisk rådgivning. For konkrete spørgsmål om databehandling, dataoverførsler og jeres pligter som dataansvarlig, se de officielle vejledninger fra myndighederne, eller kontakt en rådgiver:

• Datatilsynets regler og vejledning: datatilsynet.dk/regler-og-vejledning
• EU's vejledning om databeskyttelse og GDPR for virksomheder: europa.eu — Data protection / GDPR

Status: Kladde færdig, ≥2200 ord, struktur og kilder verificeret nedenfor. Verificerede eksterne URL'er (curl HTTP 200, denne session, 2026-07-22): - https://www.datatilsynet.dk/regler-og-vejledning — 200 - https://europa.eu/youreurope/business/governance-and-sustainability/digital-and-data-compliance/data-protection-gdpr/index_da.htm — 200