Spørg ti virksomheder, hvad en AI-arkitekt laver, og halvdelen svarer med et produktnavn: en cloudplatform, en vektordatabase, en model. Men platformen er det, man bygger på. Arkitekturen er de beslutninger, der afgør, om det byggede gør det, forretningen har brug for, også den dag modellen tager fejl.
Læs jobopslag for AI-arkitekter i et par uger, og et mønster træder frem. Kravene ligner en indkøbsliste: en cloudplatform, et par modelnavne, containere, API'er og en vektordatabase. Alt sammen nyttigt. Men det er driftens værktøjer, altså det, et godt platform- eller DevOps-team sørger for står klar, så der kan arbejdes. Listen svarer på, hvor systemet kører. Den svarer ikke på, hvad systemet skal gøre, og hvad der sker, når det gør det forkert.
Min definition er kortere end indkøbslisten:
AI-arkitektur er at samrette forretningslogikken med generativ AI på en måde, der kan skalere, efterlader et revisionsspor og håndterer fejl med et menneske i løkken.
Jeg tager delene én ad gangen.
Forretningslogikken ejer systemet
En sprogmodel er god til det, der ikke kan skrives som regler: at læse en uformel mail, sammenfatte et langt dokument, foreslå en formulering. Den er dårlig til det, der kan: at regne moms, at overholde en frist, at vide, at en kunde i restance ikke må få kredit.
Den mest almindelige fejl, jeg ser, er at lade modellen gøre begge dele. Prompten vokser med regler som «husk altid at» og «du må aldrig», og hver af dem er et ønske og ikke en garanti. Forretningslogik i en prompt er forretningslogik, ingen kan teste.
Arkitektens første opgave er derfor at trække grænsen mellem regler og skøn. Reglerne skrives som kode, der kører ens hver gang og kan testes. Modellen får skønnet og intet andet, og dens svar går gennem reglerne igen på vej ud.
Et eksempel fra mit eget ansøgningssystem: En model skriver udkast til både ansøgning og CV. Brevet må den skrive frit, for et brev er argumentation og skal formes efter læseren. CV'et må den kun skære i. Hvert punkt, den foreslår, sammenlignes ordret med mit master-CV, og afviger blot én linje, bliver CV'et slet ikke skrevet. Modellen kan altså ikke opfinde en erfaring, jeg ikke har. Prompten beder den godt nok lade være, men det er koden, der sørger for det.
Skalering handler om opmærksomhed
Når der tales om skalering, tænker de fleste på trafik. Det er det letteste af problemerne, og det løser platformen. Det svære er, hvad der sker med kvaliteten, når mængden vokser.
Et system, der behandler ti sager om dagen, kan leve med, at et menneske kigger på dem alle. Ved tusind kan det ikke. Den knappe ressource er ikke regnekraft, men menneskers opmærksomhed. En arkitektur skalerer, når den bruger opmærksomheden dér, hvor den flytter noget: ved de sager, hvor systemet er i tvivl, og ikke ved de mange, hvor alt gik efter bogen.
Det kræver, at systemet ved, hvornår det er i tvivl, og det ved en sprogmodel ikke af sig selv. Et system kan godt. I Splash, som vurderer danske forsider, stiller jeg det samme spørgsmål to gange: én gang med regler, jeg selv har skrevet, og én gang med en model. Hvor de er enige, kan resultatet køre videre. Hvor de er uenige, er der noget, et menneske skal se på.
Revisionssporet skal kunne svare på hvorfor
Når en kunde klager, en revisor spørger, eller en medarbejder bare undrer sig, skal man kunne forklare, hvorfor systemet gjorde, som det gjorde. Ikke kun hvad modellen svarede, men hvad der gik ind, hvilken regel der greb ind, og hvem der godkendte.
En log over prompts og svar er ikke et revisionsspor. Det er et referat af en samtale. Sporet skal følge beslutningerne: hvilken sag, hvilke data, hvilken validering, hvilket udfald, hvem.
I mit system går hver ændring af en sags tilstand gennem ét værktøj, der validerer mod et skema, før noget gemmes. Hver berøring, om det er en mail, et opkald eller et svar, logges med tidsstempel og retning samme sted, som sagens tilstand ligger. Det lyder som bureaukrati. Det var det spor, der afslørede, at en automatisk rykker var ved at rykke mig for noget, jeg allerede havde gjort.
EU's AI-forordning kræver automatisk logning af højrisikosystemer. Men selv uden et lovkrav er sporet den eneste måde, ledelsen kan tage ansvar for noget, den ikke selv så ske.
Fejl skal kunne ses
Det er her, flest projekter går galt, og det sker uden en lyd. En model, der ikke kan svare, svarer alligevel. En integration, der er gået i stykker, melder «ingen nye data», og det ser nøjagtig ud som en stille dag.
Jeg har selv haft en automatisk udgivelse, der lå død i flere dage på grund af ét manglende tegn i koden, og en datakilde, der leverede nul resultater i fire dage, uden at noget sagde fra. Begge dele endte i den samme regel: Automatik, ingen ser output fra, skal have et tjek, som nogen ser.
God fejlhåndtering betyder, at systemet validerer, før det skriver, i stedet for at rydde op bagefter. At en fejl standser processen frem for at blive til en tom værdi, der ligner et svar. Og at et tjek er set sige fra mindst én gang, for et tjek, der kun nogensinde har vist grønt, ved man ikke, om virker.
Mennesket i løkken – men hvor?
Human in the loop bliver ofte forstået som «et menneske godkender alt». Det holder i tre uger. Derefter er godkendelsen et klik, ingen læser, og så har man et gummistempel med en logfil bagved.
Mennesket hører til to steder: hvor systemet ved, at det ikke ved, og foran de handlinger, der ikke kan gøres om.
I mit ansøgningssystem kører en kæde selv alt det, der kun skriver filer på min egen disk: opretter noter, skriver udkast, bygger PDF'er. Går noget galt, kører jeg det bare igen. Kæden standser foran alt, der er en påstand om verden udenfor, som at sende en ansøgning, markere den som sendt eller skrive til en arbejdsgiver. Grænsen har ét kriterium, og det er ikke, hvor svært skridtet er. Det er, om det kan fortrydes.
Fire spørgsmål, før I ansætter eller køber
Spørg ikke først, hvilken platform løsningen kører på. Spørg:
- Hvilke dele er regler, og hvilke er model?
- Hvad sker der, når modellen svarer forkert?
- Kan I bagefter vise mig, hvorfor systemet traf en bestemt beslutning?
- Hvilke handlinger kræver et menneske, og hvorfor netop dem?
Kan nogen svare skarpt på de fire, er platformen et spørgsmål, driften nok skal løse. Kan de ikke, hjælper ingen platform.