Min checklista innan ett AI-workflow får gå från prototyp…

En AI-prototyp kan kännas färdig långt innan den är produktionsredo. Den kan svara rätt i tio demos, använda rätt verktyg och ändå sakna det som avgör om jag vågar låta den arbeta på riktigt: definierade felmoder, mätbara gates, begränsade behörigheter och ett sätt att återhämta sig när något går fel. Min produktionschecklista handlar därför mindre om modellens intelligens och mer om systemets förmåga att bära modellens osäkerhet utan att osäkerheten sprids till användaren eller datan.

Börja med felmoderna, inte happy path

Jag skriver först ned de tre till fem fel som skulle vara dyrast: felaktiga fakta, otillåten skrivning, duplicerad automation, fel mottagare eller ett beslut utan evidens. Därefter bygger jag testfall runt dem. En demo visar vad systemet kan göra när allt går rätt; en release gate ska visa vad som händer när något går fel. Det praktiska värdet är spårbarhet: jag vill kunna återvända till beslutet senare och se om systemet fortfarande beter sig som avsett, i stället för att förlita mig på minnet av varför en regel lades till.

Separera modellbeslut från deterministiska regler

State transitions, obligatoriska fält, tillåtna statusar, filnamn, schemavalidering och rättighetskontroller ska inte vara "kom ihåg-regler" i en prompt. Jag låter modellen göra det probabilistiska arbetet och låter kod äga sådant som kan avgöras exakt. Jag testar principen med ett negativt fall, inte bara ett lyckat exempel: om flödet ändå passerar när förutsättningen saknas är kontrollen för svag och behöver flyttas uppströms eller göras deterministisk.

Behörigheter: read-only tills motsatsen är bevisad

Nya agenter börjar med läsrättigheter och förslag. Skrivning, publicering och externa actions öppnas stegvis. Det gör blast radius liten samtidigt som jag samlar riktiga felmoder från användning. Det påverkar också kostnaden: när processen är explicit kan enklare steg köras med enklare verktyg eller modeller, och de dyra bedömningarna reserveras för delarna där osäkerheten faktiskt finns.

Observability före autonomi

Jag vill kunna se vilken input som användes, vilken modell och version som kördes, vilka tools som kallades, vilket beslut som togs och varför ett flöde stoppades. Utan den kedjan går det inte att skilja modellfel från datafel eller orkestreringsfel. Det viktiga är att inte göra regeln bredare än problemet: jag dokumenterar scope och undantag samtidigt som huvudregeln, annars tenderar en lokal lösning att bli global policy av gammal vana.

Evals måste representera verkligt arbete

Jag sparar incidenter och borderline-fall som golden cases. Ett evalset med tjugo verkliga fel kan vara mer värdefullt än hundratals generiska prompts. Varje större ändring körs mot samma fall innan den släpps. I ett agentflöde blir ägarskapet centralt: nästa steg ska inte behöva tolka en lång chattlogg för att förstå vad som är godkänt, utan få ett litet kontrakt med input, evidens, beslut och återstående osäkerhet.

Retries, idempotens och dubbelkörningar

Ett produktionsflöde måste tåla att nätverk, API eller modellanrop fallerar. Retry utan idempotens kan skapa dubbla mejl, dubbla rader eller dubbla publiceringar. Jag separerar därför "försök igen" från "utför action igen". Det här är också där jag skiljer demo från drift: i en demo räcker det ofta att output ser rimligt ut, i drift måste samma resultat gå att förklara, validera och vid behov stoppa utan att en människa läser hela resonemanget.

Human-in-the-loop där felet kostar

Mänskligt godkännande ska ligga före irreversibla eller svårverifierade actions, inte efter varje harmlöst steg. För många approvals skapar klicktrötthet; för få gör att systemet får större handlingsutrymme än evidensen motiverar. En bieffekt är att förbättringar blir enklare att mäta: när samma testfall och artefakter finns kvar kan jag ändra en komponent i taget och se om kvaliteten faktiskt gick upp, eller om jag bara flyttade felet.

Min release gate

Jag kräver definierade felmoder, begränsade permissions, fungerande rollback/fallback, evals, loggning, kostnadsgränser och ett explicit BLOCKED-läge. Om teamet inte kan förklara vad som händer när evidens saknas är systemet inte redo. Jag vill dessutom att en framtida person ska kunna ta över: om metoden bara fungerar när skaparen minns alla muntliga undantag är den inte riktigt produktionsmässig, oavsett hur bra modellen är i dag.

Ett litet exekverbart kontrakt

Jag försöker alltid kondensera metoden till ett kontrakt som går att implementera eller granska. Ett förenklat exempel är:

text

input: declared + versionedevidence: source IDs / first-hand IDsdecision: PASS | REVISE | BLOCKEDowner: explicitnext_state: explicitrelease_condition: measurable

Poängen är inte formatet utan att varje fält måste kunna fyllas utan att modellen hittar på det som saknas. Om evidence är tomt ska nästa steg inte kompensera med bättre prosa. Om owner saknas ska ingen agent implicit ta över ett irreversibelt beslut.

Ett konkret pre-production-test

Innan jag öppnar skrivbehörighet kör jag ett litet "failure rehearsal". Jag matar flödet med en saknad källa, ett schemafel, ett timeout, en dubbel webhook och en input som försöker få agenten att hoppa över sitt state. För varje fall ska utfallet vara förutsägbart: antingen en säker retry, ett BLOCKED-state eller en människa som får ett tydligt beslutsunderlag. Det här är mer värdefullt än att köra ytterligare tio normala exempel, eftersom det testar systemets kontrollplan och inte bara modellens förmåga att svara.

Jag mäter dessutom recovery, inte bara failure rate. Hur snabbt kan vi förstå vad som hände? Går en action att återställa? Kan vi fortsätta från senaste godkända state utan att köra om hela kedjan? Ett system som sällan gör fel men är omöjligt att felsöka kan vara sämre i produktion än ett system som ibland blockerar men lämnar ett tydligt spår.

Checklista jag faktiskt skulle signera

Före release vill jag kunna sätta ja på följande: vi har definierat dyra felmoder; varje extern action har minimal behörighet; retries är idempotenta; källor och first-hand claims är spårbara; evalsetet innehåller verkliga incidents; logs räcker för en post-mortem; kostnad och rate limits har gränser; modellen kan avstå; rollback/fallback är testad; och en människa vet när den förväntas ingripa. Om någon punkt är "vi löser det senare" är det en medveten riskacceptans, inte ett tomt hål i checklistan.

Slutsats

Min releaseprincip är därför ganska konservativ: autonomi är något systemet förtjänar genom observerade felmoder, evals och begränsad blast radius. En prototyp blir produktionsredo när jag kan beskriva inte bara hur den lyckas, utan exakt hur den misslyckas och vad systemet gör då.

Min checklista innan ett AI-workflow får gå från prototyp till produktion