Kravställning för AI i offentlig sektor
Kravnivån har flyttat. De flesta plattformar möter den nivå som gällde för två år sedan.
Fem mönster som ser rätt ut i en demo och inte håller i drift. Varje fallgrop har ett tekniskt varför och en kravformulering ni kan klistra in i er egen kravspec. Guiden är fri att citera, med eller utan hänvisning till oss.
01 Residens som enda kontroll Att data ligger i EU säger ingenting om vem som får fråga vad.
En plattform kan vara helt EU-hostad och samtidigt låta vem som helst i organisationen ställa frågor mot det mest känsliga materialet, eftersom ingenting i vägen fram till modellen vet vilken sorts uppgifter frågan rör. Residens svarar på var uppgifterna finns, aldrig på vem som får se dem eller vad som får göras med dem. De två frågorna löses av olika mekanismer, och bara den ena syns i en upphandlingsbilaga.
Kräv i stället
Kräv att varje anrop prövas mot ett regelverk innan det når en modell, och att beslutet skrivs till granskningsloggen i samma transaktion som händelsen. Be om ett NEKAT anrop som demonstration, inte ett godkänt — det är bara nekandet som visar att grinden finns.
02 Policy i systemprompten En instruktion är en önskan, inte en spärr.
En regel som ligger i prompten är formulerad till en statistisk modell och delar utrymme med användarens egen text. Den kan förhandlas bort, omtolkas eller helt enkelt tappas när sammanhanget blir långt. Spärren måste ligga utanför modellen, i koden som avgör om anropet ens får göras — annars är kontrollen sannolik i stället för verklig, och sannolik räcker inte när frågan är om ett personnummer får lämna huset.
Kräv i stället
Kräv att regelverket utvärderas i en egen komponent med egen testsvit, och fråga vad som händer när den komponenten är otillgänglig. Rätt svar är att ingenting släpps igenom. Får ni svaret att systemet fortsätter fungera har ni fått veta att skyddet är avstängningsbart.
03 Governance som efterhandslogg En logg som skrivs efter beslutet kan inte neka något.
Spårbarhet och kontroll blandas ofta samman. En logg som skrivs efter att svaret levererats kan visa vad som hände, men den kan inte hindra något — och kan loggen redigeras i efterhand visar den inte ens det. Skillnaden ligger i om beslutet fattas före eller efter att innehållet nått modellen, och om loggposten kan tas bort utan att det syns.
Kräv i stället
Kräv att loggposterna länkas kryptografiskt så att ett borttaget eller ändrat led syns vid kontroll, och att verifieringen kan köras av er, inte bara av leverantören. Kräv att posten skrivs i samma transaktion som beslutet — annars kan händelsen ske utan att spåret finns.
04 Ett gränssnitt ovanpå någon annans modell-API Byter ni modell byter ni i praktiken produkt.
Många plattformar är ett välbyggt användargränssnitt ovanpå en enda leverantörs API. Prompter, verktygsdefinitioner och utvärderingar skrivs mot den leverantörens dialekt, och den kopplingen syns inte i avtalet. Inlåsningen sitter aldrig i licensen, den sitter i integrationen — och den upptäcks först den dag priset ändras eller modellen dras tillbaka.
Kräv i stället
Kräv att modellval är konfiguration, inte kod, och att ett byte inte kräver ändringar i era assistenter. Kräv därtill en exportväg för er data som ni kan starta själva, och be om en tidsuppskattning i timmar. Exit-kostnaden är den enda inlåsningsmätning som går att verifiera innan ni skriver på.
05 Tillgänglighet som efterarbete Ni ärver bristen, inte leverantören.
Tillgänglighetskrav hamnar i avtalet men sällan i produkten. När gränssnittet levereras med för svag kontrast, eller med status som bara kommuniceras med färg, är det er organisation som står som avsändare inför tillsynen. Efterhandsfixar i ett komponentbibliotek som inte designats för kravet blir dyra och ofullständiga, eftersom problemet ofta ligger i färgvalen och komponentformerna snarare än i enskilda sidor.
Kräv i stället
Kräv WCAG 2.1 AA verifierad med två oberoende granskningsmotorer och begär rapporten, inte en självskattning. Kräv att status aldrig kommuniceras med färg som enda bärare, och att kravet gäller varje tema gränssnittet levereras med.
Klarar plattformen ni tittar på de fem frågorna?
Svara som ni tror att det ser ut i dag. Ni får ingen poäng och ingenting lämnar er browser — ni får en lista på de kravformuleringar som saknas.
-
01 Vet plattformen vilken sorts uppgifter en fråga rör innan modellen ser den?
-
02 Ligger reglerna i kod med egna tester, eller i en systemprompt?
-
03 Skrivs granskningsposten i samma transaktion som beslutet, och går den att ändra i efterhand?
-
04 Kan ni byta språkmodell utan att skriva om era assistenter?
-
05 Har ni sett en tillgänglighetsrapport från två oberoende granskningsmotorer?
Ta med listan till er egen kravställning
Vill ni gå igenom den mot en verklig plattform, eller pröva era följdfrågor på någon som byggt den? Hör av er. Ni möter en person, inte ett formulär.