Sådan kravspecificerer I AI i et udbud

Et dansk kommunalt udbud, vi læste for nylig, stiller krav om, at brugerlogs opbevares i seks måneder og derefter slettes, at produktet integrerer med Azure AD for medarbejdere og MitID for borgere, at det stiller et REST-API til rådighed, som sagssystemet kan kalde, og at testmiljøet er adskilt fra produktion. Præcist, testbart og tydeligvis skrevet af en, der har gennemført et udbud før.

AI-kravet i samme dokument er én sætning: produktet skal tilbyde AI-funktionalitet, der overholder AI-forordningens relevante bestemmelser. Systemet understøtter borgere, der søger arbejde.

Den sætning overlader indkøberens mest betydningsfulde beslutning til den, der vinder. Det er, hvad man skriver, når man godt ved, at emnet er vigtigt, og ikke har en skabelon til det. Her er skabelonen.

Stil krav til egenskaber, ikke til arkitektur

Den mest almindelige fejl den anden vej er et krav, der navngiver en teknologi. On-premise-drift, en bestemt model, en navngiven vektordatabase. Hvert af dem træffer arkitekturbeslutningen på vegne af et behov, der aldrig blev skrevet ned, og udelukker leverandører, der kunne have dækket behovet billigere.

Skriv, hvad der skal være sandt om systemet i drift. Lad leverandørerne foreslå hvordan.

Sporbarhed

Kræv, at systemet for ethvert output kan fremvise de kilder, det trak på, den model og version, der genererede det, og identiteten på den bruger eller proces, der bad om det. Kræv en opbevaringsperiode for den registrering, angivet i måneder, på samme måde som logopbevaring allerede er angivet.

Bed om dokumentationen allerede i udbudsfasen: en beskrivelse af, hvad der registreres per forespørgsel, og et eksempel på en registrering.

Adgang og rettigheder

Hvor systemet læser fra eksisterende indhold, skal I kræve, at søgningen respekterer rettighederne i kildesystemerne, og at filtreringen sker før rangeringen frem for efter. Kræv en maksimal forsinkelse for rettighedsændringer, angivet i minutter eller timer.

Dokumentation: en beskrivelse af, hvordan rettigheder når frem til indekset, og hvordan en tilbagekaldelse forplanter sig.

Menneskelig kontrol

Kræv, at en navngiven rolle kan forkaste eller rette et output, at grænsefladen tilbyder den vej frem for kun en visning, og at tilsidesættelser registreres. Hvor systemet kan handle uden opsyn, skal I kræve, at grænsen er konfigurerbar af myndigheden frem for fastlagt af leverandøren.

Dokumentation: en gennemgang af tilsidesættelsesvejen i demonstrationen, ikke et afsnit i besvarelsen.

Evaluering og ændringer

Det er den bestemmelse, næsten ingen skriver, og den, der betyder mest over en femårig kontrakt. Kræv, at leverandøren redegør for, hvordan systemet evalueres, at myndigheden modtager resultaterne med en fastlagt kadence, og at et modelskifte eller en væsentlig adfærdsændring varsles på forhånd med dokumentation for, at evalueringen fortsat består.

Uden den kan det system, I godkendte ved idriftsættelsen, være blevet et andet system i marts, uden at nogen har pligt til at fortælle jer det.

Datahåndtering og exit

• Hvilken jurisdiktion der regulerer adgangen til det indhold, systemet behandler, og om der gælder udenlandske udleveringspligter for leverandøren eller dennes underdatabehandlere
• Om myndighedens indhold bruges til at træne eller forbedre modeller, med standarden sat til nej frem for overladt til leverandørens vilkår
• Hvad der leveres tilbage ved ophør, i hvilket format og inden for hvilken frist, herunder søgeindekset og sporbarhedsregistreringerne frem for kun kildedokumenterne
• Om myndigheden kan skifte til en anden leverandør eller selv drive systemet uden at skulle bygge integrationerne om

Et krav, der navngiver en teknologi, har allerede valgt arkitekturen. Et krav, der navngiver en egenskab, lader arkitekturen stå åben og gør behovet præcist.

Hvor hver bestemmelse hører hjemme

Sporbarhed, adgang, menneskelig kontrol og evaluering hører til i kravspecifikationen, fordi det er egenskaber, løsningen enten har eller mangler, og de bør indgå i tildelingsevalueringen.

Varsling ved modelskifte, evalueringskadence, brug af indhold til træning og exit hører til i kontrakten, fordi de regulerer adfærd over kontraktperioden frem for på leveringstidspunktet. Den opdeling forhindrer også, at kravspecifikationen bliver et juridisk dokument, leverandørerne besvarer med standardformuleringer.

Det vi anbefaler

Erstat den ene AI-forordningssætning med de fem grupper af egenskaber ovenfor, og bed om dokumentation frem for forsikringer. Hver eneste af dem kan efterprøves i udbudsfasen, og en leverandør, der ikke kan beskrive, hvad deres system registrerer per forespørgsel, fortæller jer noget nyttigt.

Bliv ved med også at nævne forordningen. Den sætter rammen. Den kan bare ikke være hele kravet, for den fortæller leverandøren, hvilken lov der gælder, uden at fortælle dem, hvad de skal bygge.

Hvad bør et AI-krav i et offentligt udbud egentlig indeholde?

Egenskaber, systemet i drift skal have: sporbarhed fra output til kilder og modelversion, søgning der respekterer rettighederne i kildesystemerne, en registreret vej til menneskelig tilsidesættelse, en evalueringsordning med varsling før modelskifte, og fastlagte vilkår for datahåndtering og exit. Hver af dem kan efterprøves i udbudsfasen.

Er det nok at kræve overholdelse af AI-forordningen?

Den sætter rammen og bør nævnes, men alene fortæller den en leverandør, hvilken lov der gælder, uden at fortælle dem, hvad de skal bygge. Forpligtelserne, der følger af forordningen, er egenskaber ved et system, så kravspecifikationen skal navngive de egenskaber, for at de kan indgå i tildelingen.

Bør et udbud kræve on-premise-drift?

Som regel ikke. Det navngiver en arkitektur i stedet for et behov. Skriv behovet i stedet: hvilken jurisdiktion der regulerer adgangen, om der gælder udenlandske udleveringspligter, hvordan modelversioner styres, og hvad exitvejen er. Leverandører, der kan opfylde det billigere end ved at flytte hardware, bør have lov at byde.

Hvilke AI-bestemmelser hører til i kontrakten frem for i kravspecifikationen?

Alt, der regulerer adfærd over kontraktperioden: varsling før modelskifte, evalueringskadence og afrapportering, om myndighedens indhold må bruges til træning, og forpligtelser ved ophør. Kravspecifikationen bør bære de egenskaber, der evalueres ved tildelingen.