En pilot som fungerar bevisar att tekniken kan lösa problemet. Den säger ingenting om huruvida er organisation kan driva lösningen varje dag i ett år. En pilot kan därför fastna på vägen till produktion fast modellen räcker, bara för att ingen har bestämt vem som äger systemet på måndag morgon när det går fel.
Vi har tagit vårt eget Azure Ops-team genom den övergången, och vi bygger varje nytt agentteam för att klara samma steg.
Varför piloter dör vid produktionsgränsen
En pilot körs under perfekta förhållanden. Den som byggde den sitter bredvid, data är handplockad, och alla vet att det är ett experiment. I produktion kommer riktiga data i full volym, och organisationen räknar med att systemet bara fungerar.
Tre saker brukar fälla övergången.
Ingen tydlig ägare. Piloten ägdes av den som var nyfiken. Produktion behöver någon vars jobb det är att systemet fungerar — som blir uppringd när det inte gör det. Saknas den personen förfaller systemet tyst tills någon stänger av det.
Inga regler för när AI:n får handla själv. I piloten godkände en människa varje steg. Det skalar inte. Utan uttryckliga gränser för vad agenten får göra utan godkännande fastnar ni i ett läge där allt fortfarande kräver en människa. Då har agenten bara blivit ett steg till i processen.
Värdet mättes aldrig. "Det känns som att det sparar tid" överlever inte ett budgetmöte. Om ni inte vet vad piloten faktiskt flyttade i timmar, kronor eller felfrekvens har ni inget argument för att driftsätta den på riktigt.
De fyra besluten
Innan en pilot får gå i produktion ska fyra frågor vara besvarade, och ingen av dem är teknisk.
1. Vem äger systemet i drift? En namngiven person, inte ett team och inte "IT". Den personen sätter takten, tar emot eskaleringar och fattar beslutet att pausa om något ser fel ut, och de andra tre besluten bygger på att den personen finns.
2. Var går gränsen för autonomi? Skriv ner exakt vad agenten får göra utan att fråga, vad den får föreslå men inte verkställa, och vad som alltid går till en människa. I vårt Azure Ops-team har varje agent enbart läsåtkomst — den föreslår åtgärder, men en människa godkänner allt som ändrar en resurs.
3. Vad utlöser eskalering? Ett produktionssystem måste veta när det är osäkert och vem det ska störa då. Bestäm tröskeln innan ni sätter systemet i drift. En agent som aldrig eskalerar är farligare än en som eskalerar för ofta.
4. Hur mäter ni att det fungerar? Välj ett tal ni kan följa varje vecka, till exempel hur stor andel av ärendena som hanteras utan att någon behöver gå in, hur lång tid det tar från larm till åtgärdsförslag eller vad en körd uppgift kostar. Det räcker med ett tal, så länge det ändras när agenten gör skillnad.
Bygg ut på bredden först
När de fyra besluten har svar är frestelsen att göra systemet smartare. Gör det bredare istället. Har ni en agent som sköter en process pålitligt kan ni använda den som mall för nästa process, medan en agent som ska sköta allt på en gång tar er tillbaka till pilotfällan.
Vi bygger våra team med en samordnare och specialister för att ni ska kunna växa genom att kopiera det som redan fungerar. En ny process får en ny specialist, och en ny miljö får en ny instans av samma team. Det gör övergången billig, förutsatt att de fyra besluten redan är fattade.
Vad ni tar med er
Piloten visar att tekniken fungerar, och de fyra besluten avgör om ni kan lita på den i drift.
Om ni har en pilot som fungerar men inte vet hur ni tar den vidare är det precis det samtalet vi helst för. I vår pilot fattas de fyra besluten redan från början, så när tekniken har visat sig hålla vet ni också hur den ska gå i produktion.
Talented AI bygger AI-agentteam för företag och kan sköta dem när de är i drift hos er. Era medarbetare får då tid för det som behöver en människa.