Sådan vælger du en leverandør til AI-implementering: tjekliste med 20 spørgsmål og aftalevilkår (AI Act, GDPR, IP, acceptkriterier)

Forskellen mellem en AI-implementering, der giver målbare resultater, og et projekt, der ender med en præsentation, ligger sjældent i teknologien. Den ligger i, hvordan partneren arbejder med data, hvordan resultatet måles, og hvad I underskriver i kontrakten. Denne tekst er en liste over spørgsmål til de første møder med leverandøren og en liste over bestemmelser, der bør stå i kontrakten, før projektet starter.

Dette er ikke juridisk rådgivning; kontraktklausuler bør drøftes med en jurist, især for højrisikosystemer efter AI Act.

Vigtigste pointer

• Start med problemet, ikke modellen. En god partner spørger først til proces, data og forventet resultat og først derefter til teknologistakken.
• Data afgør resultatet. Spørg til dataaudit, adgang, rettigheder og hvor data vil blive behandlet.
• En AI-kontrakt adskiller sig fra en softwarekontrakt. Den skal omfatte roller efter AI Act, databehandling efter GDPR, ejerskab til kode, prompts, konfigurationer og modelvægte, acceptkriterier baseret på metrikker samt omkostninger ved modelbrug.
• Accept er statistik, ikke en knap. Acceptkriterier defineres på et testdatasæt med kvalitetsgrænser, svartid og pris pr. forespørgsel.
• Planlæg exit. Dokumentation, overdragelse og udskiftelighed af modellen er bestemmelser, der beskytter virksomheden efter samarbejdets afslutning.

Hvad er en AI-implementering i virksomheden

En AI-implementering er at bygge og idriftsætte et system, der bruger maskinlæringsmodeller eller sprogmodeller (LLM) i virksomhedens processer: en assistent til medarbejdere eller kunder, en agent der udfører opgaver i systemer, en RAG-vidensbase eller en prædiktiv model. I de fleste forretningsprojekter bygger man ikke egne modeller fra bunden; man bruger færdige modeller via API eller open-weight modeller og kobler dem til virksomhedens data og systemer. Derfor tæller partnerens kompetencer først og fremmest i integration, data, sikkerhed og effektmåling.

Tre søjler i vurderingen af en partner

Teknologi og data

Før du spørger om pris, så undersøg, hvordan virksomheden arbejder med data: laver den audit af kilder, hvordan klargøres data, hvordan videreføres rettigheder fra kildesystemer til AI, hvordan vælges model (omkostning, kvalitet, behandlingssted), og om den kan udskiftes uden ombygning. En partner, der straks foreslår at træne en egen model, bør kunne begrunde, hvorfor en færdig model med RAG ikke er nok.

Forretning og måling

En implementering uden en discovery-fase (hvad måler vi, hvad er udgangspunktet, hvad anser vi for succes) ender med funktioner, som ingen bruger. En god partner foreslår et pilotprojekt på én proces og reelle data med måling før og efter.

Jura og sikkerhed

AI Act træder i kraft trinvist fra 2024 (forbud og AI-kompetencer fra februar 2025, gennemsigtighed fra august 2026, højrisikosystemer fra december 2027). GDPR gælder fuldt ud. Partneren bør vide, i hvilken rolle den optræder (leverandør eller anvender efter AI Act, databehandler efter GDPR), og hvad det betyder for kontrakten.

Advarselssignaler og god praksis

Tjekliste: 20 spørgsmål til en AI-implementeringspartner

Erfaring

1. Kan I vise et AI-system i produktion hos en kunde – med tal? Søg case studies med metrikker (tid, omkostning, omsætning), ikke beskrivelser.
2. Hvilke problemer opstod i tidligere implementeringer, og hvordan løste I dem? Svaret viser, om partneren taler om risici, før de opstår.
3. Har I erfaring i vores branche? Data i fintech, sundhed eller produktion har andre krav til sikkerhed og compliance.
4. Har I overtaget systemer efter andre leverandører og integreret AI i legacy-systemer? De fleste virksomheder bygger ikke fra bunden.

Data og arkitektur

1. Hvordan ser jeres dataaudit ud før implementeringen? Kilder, kvalitet, huller, rettigheder.
2. Hvordan vælger I modellen, og tillader arkitekturen, at den kan udskiftes? Spørgsmål om afhængighed af én leverandør.
3. Hvordan begrænser I hallucinationer? RAG på verificerede kilder, kildehenvisninger, kvalitetstests af svar, afvisning ved manglende data.
4. Hvordan viderefører I rettigheder fra kildesystemer til AI? Brugeren må kun se det, vedkommende har adgang til.
5. Hvordan tester I et system, hvis svar er ikke-deterministiske? Testdatasæt, metrikker, regressionstests efter hver ændring af model eller prompt.
6. Hvem og hvordan overvåger kvaliteten efter idriftsættelse? Logs, metrikker, alarmer, plan for finetuning eller modelskifte.

Sikkerhed og jura

1. Hvor vil vores data fysisk blive behandlet, og af hvilke enheder? Modelleverandørens cloud, kundens cloud, kundens infrastruktur; liste over underdatabehandlere.
2. Kan virksomhedens data blive brugt til at træne leverandørens modeller? Forventet svar: nej, baseret på en kommerciel aftale med modelleverandøren.
3. Hvordan sikrer I overholdelse af GDPR? Databehandleraftale, dataminimering, konsekvensanalyse (DPIA), hvis påkrævet, retten til sletning af data.
4. I hvilken rolle efter AI Act er I, og hvilken er vi? Leverandør eller anvender; risikokategori; hvad det betyder for dokumentation og tilsyn.
5. Hvilke beskyttelser bruger I for data i prompts og svar? Filtre for følsomme data, logning, adgangskontrol, sikkerhedstests (inkl. prompt injection).

Samarbejde og omkostninger

1. Hvordan definerer I pilotprojektet, og hvad bliver resultatet? Omfang, data, metrikker, beslutning om skalering.
2. Hvordan opdeler I prissætningen? Bygning, brug af modeller (ved estimeret antal forespørgsler), drift og videreudvikling. Én samlet pris uden opdeling er et advarselssignal.
3. Hvilke forretningsmetriker følger vi? Tidsbesparelse, serviceomkostning, konvertering, omsætning; målt før og efter.
4. Hvem konkret arbejder på projektet og i hvilken model? Dedikeret team, udvidelse af vores team, projekt med fast scope; adgang til arkitekt.
5. Hvad modtager vi til slut, og hvordan foregår overdragelsen? Kode, dokumentation, prompts, konfigurationer, testdatasæt; mulighed for drift hos et andet team.

Kontraktens elementer for en AI-implementering

1. Roller og ansvar efter AI Act

• Angivelse af, hvem der er systemleverandør (udvikler og bringer i omsætning), og hvem der er anvender (bruger i egen virksomhed). Hvis systemet bygges på bestilling under kundens brand, kan kunden være leverandør; kontrakten bør nævne dette eksplicit.
• Risikoklassificering af systemet i kontrakten eller bilag; ved høj risiko: hvem er ansvarlig for teknisk dokumentation, logning, menneskeligt tilsyn og overensstemmelsesvurdering.
• Gennemsigtighed: systemet informerer brugeren om, at de interagerer med AI, og genereret indhold mærkes i overensstemmelse med art. 50.
• AI-kompetencer (art. 4): træning af kundens team er en del af leverancen, ikke et tilkøb.
• Indberetning af hændelser: procedure og frister for at informere kunden om systemfejl og sikkerhedshændelser.

2. GDPR og data

• Databehandleraftale (art. 28 GDPR) med partneren og liste over underdatabehandlere (inkl. modellleverandører) med ret til at gøre indsigelse mod ændringer.
• Behandlingssted og regioner (EU/EØS), regler for overførsel uden for EØS.
• Forbud mod at træne leverandørens modeller på kundens data, bekræftet i kommerciel aftale med modelleverandøren.
• Dataminimering og anonymisering før afsendelse til modellen; filtre for følsomme data.
• Sletning af data: arkitekturen (RAG i stedet for træning på personoplysninger) skal muliggøre sletning af en persons data uden at genopbygge modellen; log-retention (for højrisikosystemer min. 6 måneder efter AI Act).
• Konsekvensanalyse (DPIA) og, ved høj risiko for bestemte anvendere, vurdering af konsekvenser for grundlæggende rettigheder (art. 27 AI Act): hvem udarbejder den.

3. Intellektuelle rettigheder

• Overdragelse af de økonomiske ophavsrettigheder (ikke licens) til kode, dataskripts, dokumentation, prompts, konfigurationer, test- og evalueringssæt på alle udnyttelsesområder ved betaling for etape.
• Modelvægte: hvis partneren finetuner en model, overgår rettighederne til vægte og træningsdata til kunden i det omfang, grundmodellens licens tillader. Eksterne leverandørers modeller (OpenAI, Anthropic, Google) kan ikke „købes”; kontrakten bør skelne klart her.
• Open source-komponenter og open-weight modeller: liste med licenser og bekræftelse af overensstemmelse med kommerciel anvendelse.
• AI-genereret indhold: ophavsret beskytter menneskeskabte værker; kontrakten bør regulere rettigheder til output og ansvar for brugen uden at love beskyttelse, som loven ikke giver.
• Partnerens knowhow: hvis partneren bidrager med egne komponenter eller produkter (fx en færdig vidensbase), licens til dem med ret til videre brug efter kontraktens ophør.

4. Acceptkriterier

• Testdatasæt aftalt før start (repræsentative forespørgsler og forventede svar), som accept måles på.
• Kvalitetsgrænser tilpasset opgaven: for en vidensbase-assistent fx andel korrekte svar baseret på kilder, andel afvisninger ved manglende data; for klassifikation: præcision og recall; for ekstraktion: felt-nøjagtighed.
• Svartid (fx 95. percentil) og pris pr. forespørgsel ved antaget volumen.
• Sikkerhed: tests for prompt injection og datalæk, adgangskontrol.
• Menneskeligt tilsyn: hvor et menneske godkender resultatet, før det når kunden eller systemet.
• Realismen: AI har en fejlmargin; accept definerer et acceptabelt niveau – ikke 100%.

5. Omkostninger, drift og exit

• Pris opdelt i bygning, brug af modeller (med mekanisme for afregning af leverandørers prisændringer) og drift.
• SLA for tilgængelighed og reaktionstid; kvalitetsmonitorering som en service, ikke en hensigtserklæring.
• Udskiftelighed af modellen som et arkitekturkrav nedfældet i kontrakten.
• Exit-klausul: overdragelse af kode, dokumentation, data og konfigurationer i aftalt format, overgangsperiode, støtte til næste team.
• Fortrolighed og audit: kundens ret til sikkerheds- og compliance-audit hos partneren og underdatabehandlere.

Hvilken type partner leder du efter

Valget afhænger af udgangspunktet: én partner passer til at tilføje AI til kørende systemer (softwarehus specialiseret i AI), en anden til transformationsprogram i en koncern (stor integrator), en tredje til at få styr på data (analysefirma). En oversigt over virksomheder, der implementerer AI i Polen, grupperet efter partnertype, finder du i vores TOP 10-rangliste over virksomheder, der implementerer AI i Polen.

Startup House bygger AI-assistenter, agenter og RAG-vidensbaser for mellemstore og store virksomheder, herunder i regulerede brancher (fintech, sundhed, cybersikkerhed). Løsningerne kører på kundens verificerede data, i kundens cloud, integreret med adgangspolitikker; kundens data træner ikke offentlige modeller. I overensstemmelse med ISO 27001. Eksempel: en kundeportal med indbygget AI for en cybersikkerhedsplatform, der betjener Fortune 500-kunder, forkortede onboarding med 95 %, og overtagelse og modernisering af et logistiksystem for Omnipack sænkede udviklingsomkostningerne med 40 %.

Se også: AI Act: hvad skal en virksomhed, der implementerer AI, gøre · Startup House case studies

FAQ

Eget AI-team eller softwarehus?

At rekruttere et AI-team tager måneder, og den første implementering kræver erfaring med integrationer og sikkerhed. For de fleste virksomheder virker modellen: start med en partner, byg interne kompetencer parallelt (træning, en produktansvarlig på virksomhedens side) og overtag gradvist driften.

Hvad koster en AI-implementering?

Det afhænger af omfanget. Et pilotprojekt for en assistent på én proces og færdige modeller er et projekt på nogle få uger; en implementering i mange afdelinger med integrationer er et projekt over måneder. Prissætningen bør adskille omkostningen til bygning, modelbrug og drift.

Gør AI Act implementeringer sværere?

For de fleste forretningsimplementeringer (minimal risiko) handler forpligtelser om medarbejderkompetencer og gennemsigtighed over for brugere. Højrisikosystemer (rekruttering, kreditvurdering, biometrik) kræver dokumentation, logning og menneskeligt tilsyn med frist fra december 2027. En partner, der forstår dette, designer systemet til at opfylde kravene fra start.

Hvad er de største risici ved en AI-implementering?

Data af lav kvalitet, manglende måling af udgangspunktet, manglende accept i teamet, afhængighed af én modellleverandør og en kontrakt, der ikke regulerer ejerskab til kode, prompts og data.

Hvor lang tid tager implementeringen?

Et pilotprojekt på én proces og reelle data kan bygges på få uger. En produktionsimplementering med integrationer og sikkerhed tager længere og afhænger af antallet af systemer og datakvaliteten.

Kan jeg skifte modellleverandør under eller efter projektet?

Ja, hvis arkitekturen forudsætter det, og kontrakten kræver det. Modeller ændrer sig hver få måneder; et system, hvor modellen er en udskiftelig komponent, kræver ingen ombygning ved leverandørskifte.

Hvor starter man, når virksomheden skal forberedes på implementering af kunstig intelligens?

Start med at analysere forretningsprocesser, tilgængelige data og medarbejdernes behov. Vælg derefter områder, hvor AI-værktøjer kan give målbare gevinster, og udpeg en ansvarlig for projektet. De næste faser bør omfatte risikovurdering, pilot i et kontrolleret miljø og gradvis udvidelse af brugen af nye teknologier i det daglige arbejde.

Hvad er en AI-politik, og bør alle virksomheder have en?

En AI-politik er et internt dokument, der fastlægger regler for brug af systemer med kunstig intelligens i organisationen. Den bør angive tilladte AI-værktøjer, begrænsninger for indtastning af data, regler for verifikation af resultater samt ansvar for medarbejdere og administratorer. Den kan også regulere valg af leverandører, opdatering af AI-modeller og indrapportering af hændelser. En god AI-politik understøtter regelefterlevelse og sikker implementering af AI-løsninger.

Er et register over AI-systemer obligatorisk i alle organisationer?

Ikke alle organisationer er forpligtet til at føre et formelt register over alle AI-systemer. Et internt register over AI-systemer er dog god risikostyringspraksis. Det bør indeholde systemnavn, formål, leverandør, anvendte data, risikokategori og ansvarlig person. For bestemte højrisikosystemer forudser EU’s AI Act også registreringsforpligtelser. Omfanget afhænger bl.a. af organisationens rolle og systemets anvendelse.

Hvordan gennemfører man en risikovurdering før implementering af et AI-system?

Start risikovurderingen med at fastlægge systemets formål, typer af behandlede data samt mulig påvirkning af fysiske personer og organisationens virksomhed. Analysen bør omfatte informationssikkerhed, AI-resultaters kvalitet, fejlagtige beslutninger, menneskeligt tilsyn og potentielt forbudte praksisser. Det skal også vurderes, om anvendelsen kan klassificeres som uacceptabel risiko eller højrisikosystem efter AI Act. Risikovurdering er ikke et engangsdokument — den bør opdateres, når systemet ændres.

Kræver en AI-implementering en konsekvensanalyse for databeskyttelse?

En konsekvensanalyse for databeskyttelse (DPIA) er påkrævet efter GDPR, når en bestemt type behandling sandsynligvis medfører høj risiko for fysiske personers rettigheder og friheder. Det gælder især nogle former for profilering og automatiske afgørelser. Brugen af kunstig intelligens i sig selv udløser ikke automatisk pligt til DPIA. Konsekvensanalysen erstatter ikke den risikovurdering, AI Act kræver, da de to mekanismer delvist adresserer forskellige risici.

Hvad betyder AI literacy, og hvilke træninger bør medarbejdere gennemføre?

AI literacy er kompetencer, der gør det muligt at bruge systemer med kunstig intelligens bevidst, sikkert og ansvarligt. Træninger bør dække muligheder og begrænsninger ved AI-modeller, beskyttelse af personoplysninger, verifikation af svar samt genkendelse af fejl. Uddannelsesmaterialer bør tilpasses medarbejdernes roller og brugen af AI-værktøjer i dagligdagen. Art. 4 i AI Act forudser tiltag, der sikrer et passende niveau af AI-kompetencer hos leverandører og anvendere.

Hvem er leverandør, og hvem er anvender af et AI-system ifølge AI Act?

Leverandør er den, der udvikler et AI-system eller lader det udvikle og bringer det i omsætning eller tager det i brug under eget navn eller varemærke. Anvenderen bruger AI-systemet som led i sin virksomhed, bortset fra personlig og ikke-professionel brug. Rolledelingen har betydning for dokumentation, tilsyn, sikkerhed og forpligtelser efter EU-retten. I bestemte situationer kan den organisation, der implementerer løsningen, påtage sig leverandørens forpligtelser.

Hvordan fungerer menneskeligt tilsyn med AI, altså human in the loop?

Human in the loop er en model, hvor et menneske deltager i vurdering eller godkendelse af AI’ens resultater. Personen kan kontrollere anbefalinger, rette fejl og træffe endelige beslutninger i situationer, der kræver ekstra kontrol. Det er særligt vigtigt ved automatisering af processer, der påvirker kunder, medarbejdere eller fysiske personer. Tilsynet skal være reelt: medarbejderen skal forstå systemets begrænsninger, kunne anfægte resultatet og have de nødvendige rettigheder til at gribe ind.

Denne tekst er informativ og udgør ikke juridisk rådgivning. Retsstilling: oktober 2026 (AI Act efter Digital Omnibus, forordning 2026/1744).