Sådan vurderer I en AI-leverandør, før I køber

AI-demoen kender sjældent en dårlig tirsdag.

Den bruger et rent dokument, et tydeligt spørgsmål og en konto med de rigtige rettigheder. Svaret kommer hurtigt. Leverandøren viser den funktion, der virker, og hopper elegant over de to menuer, hvor administratoren senere skal styre adgang og sletning.

Det er ikke nødvendigvis snyd. En demo skal vise en mulighed. Men et indkøb skal vurdere en driftssituation.

Den vigtigste opgave er derfor at gøre sammenligningen konkret, før salgsmøderne begynder.

1. Hvilken arbejdsopgave køber vi til?

“Vi skal have en AI-platform” er ikke et krav. Beskriv opgaven:

Kundeservice skal kunne finde gældende returregler og få et svarudkast med kildehenvisninger. Systemet må ikke sende, ændre ordrer eller behandle betalingsoplysninger.

Tilføj baseline og mål:

• tid pr. sag i dag
• fejl og videresendelser
• acceptable og uacceptable fejl
• hvem der kontrollerer
• hvilke sager der er uden for scope

Leverandøren skal kunne vise løsningen på jeres repræsentative materiale, lovligt og sikkert. Et generelt benchmark siger ikke, om danske fagord, scannede bilag og jeres undtagelser fungerer.

2. Hvad er egentlig AI – og hvad er almindelig software?

Bed leverandøren tegne løsningen:

• hvilken model eller modeltype bruges?
• hvilke dele er leverandørens egne?
• hvor bruges søgning, regler og klassisk automatisering?
• hvilke tredjepartstjenester og underleverandører indgår?
• kan modellen skifte uden at produktnavnet ændres?

Det er ikke for at samle modelnavne. Det er for at forstå afhængigheder, ansvar og hvilke ændringer der kan påvirke resultatet.

3. Hvilke data går hvorhen?

Tegn dataflowet fra brugerens input til sletning:

• prompts, filer, billeder, lyd og metadata
• hentede data fra interne systemer
• modeloutput og feedback
• tekniske logs, sikkerhedslogs og supportkopier
• lagringssteder og overførsler
• underdatabehandlere
• backup og gendannelse

Spørg direkte, om kundedata bruges til træning, evaluering, produktforbedring eller menneskelig gennemgang. “Vi træner ikke på dine data” besvarer ikke nødvendigvis, hvad der logges, hvor længe eller hvem der kan se det ved support.

Få svarene ind i aftalen og den konkrete kontotype.

4. Hvordan styres adgang?

Kontrollér:

• single sign-on og flerfaktorgodkendelse
• roller og mindst mulig adgang
• adskillelse mellem kunder og miljøer
• adgang til samtaler, filer og delte agenter
• gæste- og ekstern adgang
• automatisk lukning ved fratrædelse
• administratorlogs og alarmer

Test deling. Mange datalæk sker ikke i modellen, men gennem et link, en standardgruppe eller en integration med for brede rettigheder.

5. Hvor godt virker det på vores virkelighed?

Bed om en prøve med et aftalt testsæt:

• normale sager
• svære undtagelser
• manglende og modstridende information
• dansk og eventuelt andre relevante sprog
• dårlige scanninger og tabeller
• forsøg på prompt injection
• sager, hvor systemet skal afstå

Definér bedømmelsen før testen. Mål kildekorrekthed, faglig kvalitet, afslag, tidsforbrug og menneskelige rettelser. Leverandøren bør oplyse model, indstillinger og dato, så testen kan gentages.

Spørg også, hvordan kvalitet overvåges efter lancering. En engangstest er ikke drift.

6. Hvilke fejl kender leverandøren allerede?

En troværdig leverandør kan tale om begrænsninger uden at gemme sig bag “AI kan begå fejl”.

Bed om:

• kendte fejlkategorier
• anvendelser produktet frarådes til
• dokumenterede hændelser og læring
• red teaming og sikkerhedstest
• hvordan fejl rapporteres og prioriteres
• support- og eskalationstider

Spørg: “Hvad ville få jer til at anbefale, at vi ikke bruger produktet til vores opgave?” Svaret siger meget om leverandørens modenhed.

7. Hvad kan systemet gøre uden et menneske?

Skeln mellem at foreslå og at handle.

Hvis systemet kan sende, købe, slette, publicere eller ændre data, bør I kende:

• tilladte værktøjer og destinationer
• beløbs- og mængdegrænser
• menneskelige godkendelsespunkter
• beskyttelse mod prompt injection
• log over kald og ændringer
• nødstop og tilbagerulning

Bed leverandøren demonstrere en fejl og et stop – ikke kun en succes.

8. Hvilken dokumentation følger med?

AI-forordningen fordeler krav efter systemets risikokategori og parternes roller. Bed leverandøren forklare sin vurdering, tilsigtede formål og den dokumentation, I skal bruge som kunde eller idriftsætter.

Afhængigt af anvendelsen kan I også have brug for:

• databehandleraftale og underleverandørliste
• sikkerhedsdokumentation og revisionserklæringer
• tekniske instruktioner og begrænsninger
• information til berørte personer
• dokumentation for trænings- og testdata på relevant niveau
• hjælp til konsekvensvurderinger
• tilgængeligheds- eller sektorstandarder

Et logo for en certificering er ikke dokumentationen. Bed om scope, dato og eventuelle undtagelser.

9. Hvordan varsles ændringer?

AI-tjenester ændrer sig hurtigt. En leverandør kan opdatere modellen, systemprompten, standardindstillinger, dataplacering eller funktioner.

Aftal:

• hvad der regnes som en væsentlig ændring
• hvor lang varsling I får
• adgang til versionsnoter
• mulighed for at teste før bred udrulning
• mulighed for at fastholde en version i en periode
• ret til at sige nej eller opsige ved væsentlig forringelse

Ellers kan en godkendt løsning ændre risikoprofil uden en ny indkøbsbeslutning.

10. Hvad koster hele arbejdsgangen?

Licensen er kun én post. Medtag:

• implementering og integration
• oprydning i data og rettigheder
• faglig test og juridisk vurdering
• træning og support
• løbende kontrol af output
• vedligeholdelse af prompts, kilder og arbejdsgange
• ekstra forbrug, lager og API-kald
• exit og dataudtræk

Mål gevinsten efter menneskelig kontrol. En løsning, der sparer fem minutters skrivning og kræver seks minutters verificering, har måske andre fordele – men ikke den lovede tidsbesparelse.

11. Hvad sker der ved en hændelse?

Kontrakten og beredskabet bør beskrive:

• hvordan og hvor hurtigt I underrettes
• hvilke oplysninger leverandøren giver
• hvordan data og funktioner kan isoleres
• hvem der kommunikerer til berørte og myndigheder
• hvordan beviser og logs bevares
• hvordan tjenesten genåbnes sikkert

Kør en skrivebordsøvelse. Forestil jer, at systemet har sendt fortrolige oplysninger til en forkert modtager. Kan begge parter handle, eller begynder de med at lede efter en mailadresse?

12. Hvordan kommer vi ud igen?

Exit er et kvalitetskriterium, ikke et pessimistisk bilag.

I skal kunne få:

• egne data og relevante metadata ud i et brugbart format
• prompts, instruktioner, testsæt og konfigurationer
• logs, som lovligt og nødvendigt skal bevares
• dokumentation for sletning hos leverandør og underleverandører
• en overgangsperiode uden urimelig pris
• en manuel arbejdsproces, hvis tjenesten stopper pludseligt

Overvej også afhængigheden af en bestemt models adfærd. En eksport af dokumenter hjælper ikke meget, hvis hele processen kun fungerer med en lukket, ikke-dokumenteret opsætning.

Lav et lille beslutningsnotat

Saml vurderingen på 2–4 sider:

• formål og afgrænsning
• forventet nytte og baseline
• væsentlige risici og kontroller
• roller og ansvar
• leverandørens vigtigste forpligtelser
• resultat af test
• betingelser for pilot og drift
• stopkriterier og næste vurderingsdato

Det gør beslutningen forståelig, når projektgruppen skifter, eller produktet ændrer sig.

NIST’s Generative AI Profile anbefaler løbende vurdering af tredjepartsrisici, kontraktlige krav, hændelsesrapportering og overvågning. NIST’s særskilte due diligence-guide til forsyningskæden understreger samme jordnære pointe: Leverandørkontrol er en proces, ikke et spørgeskema, der arkiveres efter underskrift.

Den bedste leverandør er ikke altid den største model

Til en afgrænset arbejdsopgave kan den bedste løsning være den, der har tydelige kilder, smalle rettigheder, forståelige logs og en leverandør, som siger nej til det forkerte scope.

Køb derfor ikke “AI”. Køb en dokumenteret evne til at hjælpe med en bestemt opgave under bestemte vilkår.

Når kravene er konkrete, bliver salgsmødet bedre for begge parter. Leverandøren ved, hvad der skal bevises. Og I kan vælge ud fra andet end den sætning, der kom hurtigst ud af demoen.

Kilder og videre læsning

• NIST: Generative AI Profile – leverandøruafhængige anbefalinger om tredjepart, kontrakter, test og overvågning.
• NIST: AI Risk Management Framework – ramme for styring, kortlægning, måling og håndtering.
• NIST: Due diligence assessment quick-start guide – officiel guide til leverandørvurdering i forsyningskæden.
• Digitaliseringsstyrelsen: Guide til virksomheder – dansk myndighedsguide til ansvarlig brug af generativ AI.
• EU-Kommissionen: AI Act – regulatory framework – officiel oversigt over roller og risikobaserede krav.