Sådan vurderer du en AI-leverandør: due diligence-spørgsmål om GDPR, EU AI Act, sikkerhed og dataflow

Valget af en AI-leverandør er ikke længere et rent indkøbsspørgsmål. Det er en beslutning med direkte betydning for jura, informationssikkerhed, drift, omdømme og ledelsesansvar. Når en leverandør får adgang til data, processer eller beslutningsstøtte, bliver kvaliteten af deres kontroller hurtigt til kvaliteten af jeres egen risikostyring.

Derfor er due diligence på AI-området mere krævende end ved klassiske softwareaftaler. En god leverandør skal ikke bare levere funktionalitet. Den skal også kunne dokumentere databehandling, sikkerhedsniveau, rollefordeling, modelstyring og efterlevelse af både GDPR og EU AI Act.

Efter den første screening er det ofte nyttigt at vurdere leverandøren ud fra fire spor:

• GDPR og databeskyttelse
• EU AI Act og risikoklassificering
• tekniske sikkerhedskontroller
• dokumenteret dataflow og underleverandører

Hvorfor vurdering af AI-leverandør kræver mere end en standardscreening

Mange organisationer starter med pris, funktioner og implementeringstid. Det er forståeligt, men utilstrækkeligt. AI-systemer arbejder ofte med store datamængder, probabilistiske output og komplekse værdikæder, hvor flere underleverandører, cloudmiljøer og modeller indgår samtidigt. Det gør sporbarhed og ansvar vanskeligere end i traditionel softwaredrift.

En moden vurdering begynder derfor med et enkelt spørgsmål: Hvilken rolle får løsningen i jeres forretning? Hvis AI bruges til intern tekstproduktion, er risikobilledet ét. Hvis den bruges til HR-screening, kundesegmentering, sagsprioritering eller beslutningsstøtte, er billedet et helt andet. Risikoen stiger ikke kun med datamængden, men med konsekvensen af fejl.

Det er heller ikke nok, at leverandøren lover compliance i salgsdialogen. De relevante spørgsmål handler om dokumentation, processer og kontrolmiljø. Kan leverandøren vise, hvordan kravene faktisk håndteres i praksis?

GDPR-krav ved valg af AI-leverandør

GDPR er det første filter. Ikke fordi det alene kan bære hele vurderingen, men fordi det sætter rammen for lovlighed, formålsbegrænsning, dataminimering, sikkerhed og ansvar. En AI-leverandør bør kunne forklare præcist, hvilke personoplysninger der behandles, til hvilke formål, hvor længe de opbevares, og om data bruges til modeltræning, kvalitetssikring eller produktforbedring.

Et centralt punkt er rollefordelingen. Er leverandøren databehandler, selvstændig dataansvarlig eller noget blandet afhængigt af behandlingen? Mange problemer opstår netop her. Hvis rollerne er uklare, bliver ansvaret for registreredes rettigheder, sletning, underleverandører og sikkerhed hurtigt uklart med dem.

Dataminimering er særligt vigtigt i AI-løsninger. Inputfelter, prompts, vedhæftede dokumenter, logfiler og metadata kan tilsammen danne en meget større datamængde end forventet. En leverandør med høj modenhed kan redegøre for, hvilke data der er nødvendige, hvilke der er valgfrie, og hvordan unødige data undgås allerede i designet.

Det samme gælder formålsbegrænsning. Data, der indsendes til drift af en løsning, bør ikke uden videre genbruges til træning af nye modeller. Her bør der være klare standardindstillinger, tydelig kontrakttekst og dokumenterede muligheder for fravalg.

Når I vurderer en leverandør op mod GDPR, er disse spørgsmål ofte de mest afslørende:

• Rollefordeling: Hvilke behandlinger udfører I som databehandler, og hvilke udfører I som selvstændig dataansvarlig?
• Databehandleraftale: Har I en DPA, der beskriver formål, datakategorier, sikkerhedsforanstaltninger, sletning og brug af underdatabehandlere?
• Data til modeltræning: Anvendes kundedata, prompts eller output til træning, finjustering eller evaluering af modeller?
• Registreredes rettigheder: Hvordan understøtter I indsigt, sletning, berigtigelse, portabilitet og indsigelse inden for gældende frister?
• Privacy by design: Hvordan er dataminimering, adgangsstyring og standardindstillinger bygget ind i løsningen?
• DPIA-støtte: Kan I bidrage med dokumentation, der gør det muligt at gennemføre en databeskyttelseskonsekvensanalyse?

Et kort “ja, vi er GDPR-compliant” er ikke et svar. Bed om dokumenter, skærmbilleder, procesbeskrivelser og konkrete eksempler på sletning, logudtræk og underleverandørstyring.

Dokumentation og certificeringer som bevis for modenhed

Certificeringer er ikke det samme som fuld compliance, men de er nyttige signaler om struktur og kontrol. De bør læses som dokumentation for et styringsniveau, ikke som en garanti.

Det afgørende er ikke blot, om et certifikat findes, men hvad det dækker. Gælder det hele platformen, kun et afgrænset produkt, eller udvalgte datacentre? Er revisionen aktuel? Kan leverandøren dele summary reports, scope og kontrolbeskrivelser?

EU AI Act og risikoklassificering hos AI-leverandører

EU AI Act ændrer samtalen markant. Nu skal en leverandør ikke kun tale om funktioner og datasikkerhed, men også om risikoklasse, dokumentation, transparens, menneskeligt tilsyn og overvågning efter idriftsættelse.

Det første spørgsmål bør derfor være, hvordan leverandøren har klassificeret sin løsning. Er systemet minimal risiko, begrænset risiko eller højrisiko? Hvis løsningen anvendes i områder som ansættelse, uddannelse, adgang til ydelser, kritisk infrastruktur eller biometriske formål, skal vurderingen være langt mere grundig. Her er det ikke nok med en generel produktbeskrivelse. Leverandøren bør kunne vise den konkrete analyse bag klassificeringen.

For højrisiko-systemer bør I forvente teknisk dokumentation, risikostyringsproces, logning, data governance, krav til menneskeligt tilsyn og plan for løbende overvågning. Det er her, mange leverandører skiller sig ud. De stærkeste kan forklare både begrænsninger, fejlscenarier og afbødende kontroller uden at tale udenom.

Transparens er også en væsentlig del af vurderingen. Hvis brugere interagerer direkte med AI, skal det være tydeligt. Hvis indhold er syntetisk genereret, skal mærkning og oplysning tænkes ind. En leverandør, der tager dette alvorligt, har normalt gennemtænkte brugerflows, tydelig dokumentation og standardtekster til kunder og slutbrugere.

Typiske røde flag i denne del af processen er:

• uklar risikoklassificering
• ingen skriftlig vurdering op mod AI Act
• fravær af teknisk dokumentation
• ingen plan for post-market overvågning
• overdrevne påstande om nøjagtighed eller bias-frihed

Informationssikkerhed og sikkerhedskontroller hos AI-leverandøren

Sikkerhedsvurderingen bør gå dybere end “data er krypteret”. Det er en start, ikke en slutning. Et troværdigt sikkerhedssetup omfatter adgangsstyring, netværksisolering, logging, patch management, sårbarhedsscanning, hændelsesberedskab og test af både infrastruktur og modeladfærd.

MFA, rollebaseret adgang og princippet om mindst privilegium bør være standard. Kryptering skal gælde både i transit og ved lagring. Samtidig bør leverandøren kunne forklare, hvem der internt kan få adgang til kundedata, under hvilke vilkår, og hvordan al adgang registreres. Hvis support eller udvikling kan tilgå produktionsdata, skal der være stærke kontroller omkring det.

På AI-området er klassisk it-sikkerhed heller ikke tilstrækkelig alene. Modeller kan påvirkes af ondsindede input, prompt injection, datalæk via output, utilstrækkelig isolation mellem kunder eller svage integrationspunkter. Derfor er det positivt, når leverandøren arbejder med red teaming, adversarial tests og løbende validering af modelopførsel.

Efter en indledende sikkerhedsbeskrivelse bør I bede om konkrete svar på kontrolmiljøet:

• Adgangsstyring: Er MFA, RBAC og godkendelsesflows indført for både medarbejdere og administratorer?
• Kryptering: Hvordan beskyttes data i transit og i hvile, og hvilke nøgler eller nøglestyringsprincipper anvendes?
• Penetrationstest: Hvor ofte testes løsningen, af hvem, og hvad er processen for opfølgning på fund?
• Patch management: Hvor hurtigt håndteres kritiske sårbarheder i operativsystemer, biblioteker og afhængigheder?
• Hændelsesrespons: Hvilke tidsfrister gælder for notifikation ved sikkerhedshændelser, og findes der en dokumenteret incident response-plan?
• Audit logs: Kan kunden få adgang til revisionsspor, så hændelser og dataadgang kan efterprøves?

Den leverandør, der kan svare konkret og roligt på disse spørgsmål, er ofte også den leverandør, som arbejder struktureret internt.

Dataflow, underleverandører og tredjelandsoverførsler

Dataflow er ofte det område, hvor risici skjuler sig. En løsning kan se enkel ud i brugergrænsefladen og samtidig sende data gennem flere lag af API’er, cloudtjenester, modeller, logsystemer og supportværktøjer. Uden dokumenteret dataflow bliver det svært at vurdere både GDPR, sikkerhed og kontraktmæssig kontrol.

Bed derfor om et dataflow-diagram eller en tilsvarende oversigt. I bør kunne se, hvor data indsamles, hvilke komponenter de passerer, hvor de lagres, hvem der kan tilgå dem, og hvornår de slettes. Det gælder også backup, testmiljøer, telemetry, logging og fejlretning.

Placeringen af data er et særskilt spørgsmål. Hvis leverandøren lover EU-datalagring, skal det kunne efterprøves. Hvis support eller drift involverer medarbejdere uden for EU, skal det fremgå tydeligt. Underleverandørlisten er her helt central, fordi den viser, om løsningen i praksis er afhængig af globale cloudaktører, eksterne modeller eller tredjeparter med adgang til data.

Ved internationale overførsler bør leverandøren kunne forklare det juridiske grundlag klart. SCC’er kan være relevante, men de er ikke magiske. De skal følges af faktiske vurderinger af risiko, adgangsforhold og beskyttelsesniveau.

Praktisk due diligence-model til vurdering af AI-leverandør

En effektiv proces er at kombinere juridisk, teknisk og forretningsmæssig vurdering i én model. Det giver bedre beslutninger end sekventielle siloer, hvor indkøb, it, jura og forretning arbejder hver for sig.

Start med brugsscenariet. Fortsæt med datatyper, integrationspunkter og risikoniveau. Først derefter giver det mening at gå i detaljen med kontraktvilkår og sikkerhedsbeviser. På den måde vurderer I leverandøren i forhold til den reelle anvendelse, ikke kun i forhold til et standardspørgeskema.

I praksis er det ofte nyttigt at samle due diligence i tre niveauer:

1. Basisscreening af rolle, data, hosting og sikkerhedsminimum
2. Udvidet vurdering af GDPR, AI Act, teknisk dokumentation og underleverandører
3. Endelig godkendelse med kontraktkrav, auditmuligheder og plan for løbende kontrol

Den model gør også dialogen med leverandøren bedre. Gode leverandører foretrækker som regel præcise spørgsmål frem for brede krav om “fuld compliance”.

Kontraktkrav og løbende leverandøropfølgning

Selv en stærk due diligence mister værdi, hvis kontrakten er vag. Krav om databehandleraftale, underleverandørgodkendelse, notifikation ved hændelser, sletning ved ophør, auditrettigheder og ændringsstyring bør være klare og operationelle.

Det er også klogt at aftale, hvad der sker ved væsentlige ændringer i modellen eller leverancens arkitektur. Hvis leverandøren skifter modeludbyder, åbner nye supportlokationer eller ændrer praksis for træningsdata, bør det udløse varsel og ny vurdering.

Løbende kontrol er ikke mistillid. Det er sund governance. En årlig revurdering, opfølgning på nye underleverandører, status på certificeringer og gennemgang af hændelser giver et langt stærkere beslutningsgrundlag over tid end den indledende onboarding alene.

Når AI indgår i centrale arbejdsgange, er den bedste leverandør sjældent den med de største løfter. Det er den, der kan dokumentere sit arbejde, forklare sine begrænsninger og indgå i et professionelt samarbejde om ansvar, sikkerhed og gennemsigtighed.