AI agenti od pilota do produkcije: načrt nadzorovane uvedbe

Pilot naj odgovori na vnaprej določena vprašanja

Pilot AI agenta je uspešen, ko podjetje dobi dovolj dokazov za naslednjo odločitev. Ne zadostuje dober prikaz. Preveriti morate kakovost opravljenega dela, človeški vložek, obravnavo izjem in sposobnost ekipe, da proces vzdržuje tudi po uvedbi.

Pred začetkom napišite, kaj želite izvedeti. Ali agent pri podprti skupini izdelkov pripravi uporaben osnutek? Koliko popravkov ostane? Kje manjkajo podatki? Ali odobritve pridejo do prave osebe? To so odločitvena vprašanja, ki jih lahko povežete z merili iz procesnega briefa.

Pri hipotetičnem distributerju ne preverjamo, ali AI zna napisati ponudbo v splošnem smislu. Preverjamo dogovorjeno nalogo v dejanskem delovnem okolju. Uspeh pri preprostem katalogu ne pomeni, da je rešitev pripravljena za posebne cenovne dogovore ali drugačen prodajni program.

Določite tudi, kdo presodi rezultat pilota in katere odločitve so mogoče: razširitev, nadaljnji omejen preizkus, sprememba naloge ali ustavitev. Če je edini pričakovani zaključek »gremo v produkcijo«, je pilot postal predstavitev vnaprej sprejete odločitve.

Začnite z zgodovinskimi primeri in znanim izhodom

Pred stikom z živim delom uporabite primere, pri katerih poznate pravilen rezultat. Vključite običajne naloge in primere, ki zahtevajo dopolnitev, predajo ali zavrnitev. Primeri naj pokrijejo dejanski obseg prve uvedbe, ne le vhodov, ki jih prototip že dobro rešuje.

Ločite nabor za razvoj od nabora za končni pregled. Če navodila prilagajate na istih primerih, na katerih pozneje razglasite uspeh, lahko precenite pripravljenost. Dodajte nove primere in ohranite evidenco sprememb, da boste vedeli, kaj se je med različicama izboljšalo.

Anthropic pri evalvacijah agentov opozarja, da presoja zajema več korakov in spremembe v okolju. V začetnem preizkusu zato preverite tudi stanje osnutka, pravilno predajo in odziv na napako, ne samo besedila končnega odgovora.

Shadow mode loči opazovanje od dejanskega izvajanja

V načinu vzporednega opazovanja agent obdeluje primer in pripravi predlog, ustaljeni proces pa še naprej določa poslovni izhod. Namen je primerjava vedenja v realnejših pogojih. Agentov predlog v tej fazi ne sme neopazno postati dejanska sprememba v poslovnem sistemu.

To omejitev uredite v izvedbi, ne samo z oznako »test«. Ločite testne osnutke, onemogočite operacije zunaj dogovorjenega obsega in določite, kdo lahko vidi rezultate. Če oba procesa ustvarjata dejanske ponudbe ali spreminjata isti primer, opazovanje ni več ločeno od izvajanja.

Primerjajte priporočilo s končnim rezultatom dela človeka in preglejte razlike. Razlog nestrinjanja je lahko napačna presoja agenta, slab podatkovni vir ali pomanjkljivo zapisano pravilo. Razlike naj vodijo v konkretne spremembe, ne le v skupno oceno zadovoljstva.

Omejeni pilot naj ima jasne meje

Za živi pilot izberite opredeljeno skupino primerov, uporabnikov in operacij. Na primer: ena podprta skupina izdelkov, imenovani prodajniki in samo priprava osnutkov. Izbiro dokumentirajte, da boste kasneje vedeli, za kateri obseg rezultat dejansko velja.

Google SRE pri postopnem uvajanju opisuje omejeno izpostavitev spremembi in spremljanje ustreznih signalov. Za agentni poslovni proces to uporabite kot načelo nadzorovane širitve. Tehnični uspeh manjše skupine pa sam po sebi še ne dokazuje poslovnega učinka na celotno podjetje.

Pilot mora vključiti tudi dovolj raznolike primere. Če vanj pošljete samo najbolj urejene zahteve, ne boste izvedeli, kako deluje predaja ob nepopolnem vhodu. Obseg omejite, vendar ohranite reprezentativnost znotraj te omejitve.

Merite sprejeto delo in preostali človeški vložek

Primarna enota naj bo rešena naloga po dogovorjenih merilih. Spremljajte delež sprejetih izhodov, čas aktivnega pregleda, popravke in odprte izjeme. Število klicev ali pripravljenih dokumentov lahko raste tudi takrat, ko operativa porabi več časa za popravljanje.

Za operativni izračun stroška vključite izvajanje modela, orodja, infrastrukturo ter pregled in popravke. Vsoto delite s številom sprejetih nalog v istem obsegu in obdobju. Tak izračun podpira primerjavo različic, vendar ni sam po sebi dokaz prihranka ali dodatnega prihodka.

Ločite bruto prihranek časa na nalogi od dejansko sproščene kapacitete ekipe. Če pet krajših opravil ustvari pet novih prekinitev za pregledovalca, se lahko korist zmanjša. Preverite tudi, ali so zaposleni sproščeni čas lahko uporabili za drugo dogovorjeno delo.

Določite pogoje širitve in pogoje ustavitve

Meje naj izhajajo iz pomembnosti procesa in sprejemljivega načina dela. Potrebujete ločene pogoje za kakovost, tehnično zanesljivost in operativno obremenitev. Univerzalna stopnja pravilnosti ne pove dovolj: napačna šifra izdelka ima drugačne posledice kot manj eleganten stavek.

Google SRE pri načrtovanju ciljev zanesljivosti povezuje kazalnike s pričakovano ravnjo storitve. Pri agentih mora ekipa zato povedati, kaj za uporabnika pomeni uporabna storitev. Primer je zanesljivo dostopen osnutek s pravilnim stanjem, ne le uspešen odgovor vmesnega API-ja.

Širite po eni pomembni dimenziji naenkrat, kadar je to izvedljivo: nova skupina izdelkov, več uporabnikov ali več samostojnih operacij. Če vse spremenite hkrati, boste ob poslabšanju težje ugotovili vzrok. Pred vsako širitvijo preverite tudi zmogljivost vrste za odobritve.

Povrnitev stare različice ni enaka razveljavitvi dejanj

Načrt ustavitve pove, kako prenehate sprejemati nove primere, kaj storite z odprtimi in kdo prevzame ročno delo. Prejšnjo različico sistema lahko ponovno vključite, vendar s tem ne izbrišete že ustvarjenih ponudb ali drugih zunanjih učinkov.

Zato ločite tehnično povrnitev od poslovnega popravka. Za že izvedena dejanja potrebujete evidenco prizadetih primerov in postopek uskladitve. Če popravilo zahteva človeka, mora biti ta odgovornost dodeljena pred pilotom, ne šele ob prvem zapletu.

Izvedite vajo ustavitve na testnih primerih. Preverite, ali operativa najde odprte naloge, ali se nove ne kopičijo brez lastnika in ali se po ponovnem zagonu že končana dejanja ne ponovijo. Ta vaja pogosto razkrije vrzeli, ki jih običajni test kakovosti ne zajame.

Produkcijski prevzem vključuje ljudi in dokumentacijo

Operativni prevzem naj obsega kratka navodila za običajne naloge, razlago statusov, ravnanje z napakami in kontakt odgovorne osebe. Sodelavci morajo znati razlikovati med primerom, ki čaka, in primerom, ki je zaključen. To je pogoj za vsakodnevno uporabo.

Zabeležite različice modela, navodil, orodij in podatkovnih pravil, ki sestavljajo uvedbo. Ko nekaj spremenite, uporabite dogovorjeni nabor preverjanj. Posodobitev modela ni nujno nevtralna sprememba, tudi če se uporabniški vmesnik ne spremeni.

Dogovorite se za reden pregled napak in predlogov izboljšav z operativnim lastnikom. Pogostost določite po obsegu in pomembnosti procesa. Cilj ni stalno spreminjanje, temveč nadzorovano odpravljanje ponavljajočih se vzrokov ob ohranjanju primerljivosti rezultatov.

Primer odločitve po pilotu z mešanimi rezultati

Predpostavimo, da osnutki običajnih ponudb prestanejo pregled, izjeme pa se predajajo prepozno. Povprečni čas priprave se izboljša, starost odprtih nepopolnih primerov pa naraste. Tak rezultat ne podpira neomejene širitve. Pove, da osnovna priprava deluje, način prevzema izjem pa še potrebuje spremembo. Gre za hipotetičen prikaz presoje.

Naslednja odločitev je lahko ohranitev istega obsega in izboljšanje razporejanja predaj. Dodate odgovornega prevzemnika, jasen razlog čakanja in pravilo za opomin, nato ponovite ustrezne primere. Če težavo povzroča manjkajoč podatek, naj sprememba cilja na vhod ali podatkovni vir, ne samodejno na zamenjavo modela.

Zapis odločitve naj vsebuje opažanje, razlago, izbrani ukrep in dokaz, ki ga boste pregledali naslednjič. Ohranite tudi neodločene hipoteze. Manjša količina pregledanih primerov lahko pokaže očiten problem, ne zagotavlja pa zanesljive ocene pogostosti vseh redkih napak. Moč sklepa naj ustreza dejansko zbranim dokazom.

Po popravku primerjajte iste opredelitve meril in dopolnite nabor z novimi primeri. Če bi hkrati spremenili model, obseg naloge in pravilo predaje, bi težko razumeli, kaj je pomagalo. Vodenje pilota je zato tudi vodenje sprememb, ne samo spremljanje nadzorne plošče ali sprejemanje vtisov posameznih uporabnikov.

Kaj pomeni pripravljenost za širšo uporabo

Rešitev je pripravljena za naslednji obseg, ko ima preverjene naloge, delujoče integracije, uporabne predaje in vzdrževalca, ki razume njeno stanje. To ni trditev, da ne bo napak. Pomeni, da podjetje zna napako zaznati, omejiti in obravnavati brez izgube nadzora nad delom.

NUMEDIA vpeljavo AI agentov obravnava kot povezavo poslovnega procesa, podatkov, razvoja in operativnega dela. Celotna serija daje osnovo za tak projekt: zasnovo toka, procesni brief, pogodbe integracij, človeške predaje in način uvajanja.

Za prvi pogovor pripravite eno nalogo, nekaj reprezentativnih primerov in odgovorno osebo. Na tej osnovi lahko oblikujemo izvedljiv pilot ter pojasnimo, kaj je treba urediti pred njim. Jasno določena naloga je bolj uporabno izhodišče kot seznam agentov brez skupnega poslovnega rezultata.

Viri in metodologija

1. Canarying releases (Google SRE, dostop 2026-10-19)
2. Implementing SLOs (Google SRE, dostop 2026-10-19)
3. Demystifying evals for AI agents (Anthropic, dostop 2026-10-19)

Pogosta vprašanja