Procesni brief za AI agenta: od delovnega postopka do meril sprejema

Zakaj opis delovnega mesta ni dovolj

Procesni brief spremeni idejo o AI agentu v jasno izvedbeno nalogo. Pove, kateri primer agent rešuje, katere podatke uporablja, česa ne odloča in po čem bo podjetje presodilo, ali je rešitev primerna za vsakodnevno delo.

»Potrebujemo AI prodajnega asistenta« opisuje vlogo, ne naloge. Različni sodelavci si pod tem predstavljajo raziskavo kupcev, pripravo ponudb, vpis podatkov ali spremljanje poslov. Brez ožjega dogovora lahko razvoj pripravi tehnično dober izdelek, ki ne odpravi nobenega konkretnega zastoja.

Brief naj zato obravnava eno ponovljivo enoto dela. Pri hipotetičnem distributerju iz serije je to priprava osnutka ponudbe iz popolnega povpraševanja za podprto skupino izdelkov. Obravnava reklamacij, pogajanja o posebnih cenah in naročanje pri dobaviteljih za prvo različico niso vključeni.

Takšna omejitev ni končni obseg vaše AI strategije. Je pogoj, da lahko razvoj, prodaja in vodstvo presojajo isto stvar. Ko naloga uspešno deluje, imate podlago za širitev. Če jo takoj razširite na celoten oddelek, postane težko ugotoviti, katero pravilo ali povezava povzroča problem.

Opišite današnji proces z dejanskimi primeri

Zberite reprezentativne primere opravljenega dela: običajne, nepopolne in takšne, pri katerih sodelavec uporabi posebno presojo. Zapišite zaporedje korakov in mesta čakanja. Izberite primere, za katere poznate izhod, da lahko kasneje preverite, kaj je agent naredil drugače.

Ločite aktivno delo od celotnega časa do zaključka. Sodelavec lahko za pripravo osnutka porabi malo časa, primer pa večino dneva čaka na podatek iz drugega oddelka. Avtomatizacija pisanja ne odpravi tega čakanja. Brief mora pokazati, kateri del procesa dejansko želite spremeniti.

OpenAI v vodiču o izbiri in širitvi AI primerov uporabe povezuje izbiro naloge s poslovnim kontekstom in pripravo. Za vaš projekt je praktična posledica preprosta: odgovorna oseba mora opisati delo in kakovosten rezultat, preden začne ekipa izbirati tehnično rešitev.

Določite vhodne pogoje in dovoljene izhode

Vhodni pogoji povedo, kdaj je primer primeren za avtomatizirano pot. Na primer: prepoznana stranka, podprta skupina izdelkov, zahtevana količina in znana ciljna država dostave. Če obvezni podatek manjka, proces zahteva dopolnitev. Model naj ga ne nadomesti z verjetno domnevo.

Izhod opišite kot konkreten artefakt. Osnutek ponudbe vsebuje identifikator stranke, šifre izdelkov, količine, uporabljeno cenovno podlago in odprta vprašanja. Predloga izhoda uskladi pričakovanja ljudi ter omogoča strojno preverjanje obveznih polj.

Predvidite tudi izhode, ki niso osnutek: dodatno vprašanje, predaja produktnemu strokovnjaku ali tehnična izjema. Za vsak izhod določite, kdo prevzame delo. Agent, ki pravilno prepozna neprimeren primer in ga preda, lahko izpolni brief bolje kot agent, ki za vsako ceno izdela odgovor.

Ločite poslovno pravilo, presojo in podatkovno dejstvo

Poslovno pravilo je na primer, kdo sme odobriti poseben popust. Podatkovno dejstvo je trenutna cena iz potrjenega sistema. Presoja pa je razumevanje, kateri izdelek verjetno ustreza neurejenemu opisu kupca. Če te kategorije pomešate, model nehote postane nadomestilo za manjkajoč poslovni dogovor.

Ob vsakem podatku določite vir in odgovorno osebo. Zapis v stari preglednici ni samodejno enakovreden veljavnemu ceniku. Če se viri ne ujemajo, naj brief določi, kateri ima prednost ali kdaj se primer preda. Tega spora ne rešujte z daljšim promptom.

Koristna vaja je označevanje vsakega koraka z eno od treh oznak: pravilo, podatek ali interpretacija. Tako ekipa hitro vidi, kje AI sploh potrebujete. Hkrati odkrije opravila, ki jih je smiselno rešiti s preprostim preverjanjem, izračunom ali urejeno podatkovno povezavo.

Merila sprejema naj opisujejo vedenje na primeru

Merilo »odgovor mora biti kakovosten« ni dovolj natančno. Boljši zapis je: kadar zahtevani izdelek ni podprt, sistem ne pripravi navidezno potrjene ponudbe in navede razlog predaje. Takšno merilo lahko preverite na konkretnem vhodu ter o njem smiselno razpravljate.

Pripravite preglednico z vhodom, pričakovanim vedenjem, nesprejemljivim izhodom in načinom presoje. Pri nekaterih poljih je odločitev avtomatska, pri ustreznosti izdelka pa bo sprva potreben strokovnjak. Vnaprej določite tudi, kako boste obravnavali nestrinjanje med ocenjevalci.

Anthropic pri vrednotenju agentov poudarja razliko med zapisanim odgovorom in končnim stanjem okolja. V briefu to pomeni, da »osnutek je shranjen« preverite z obstojem ustreznega zapisa, ne samo z izjavo agenta. Ta razlika prepreči, da bi navidezno uspešen prikaz postal napačna poslovna evidenca.

Oblikujte izjeme in povratne informacije

Vprašajte sodelavce, kaj jih pri sedanjem procesu najpogosteje prisili v dodatno preverjanje. Odgovori pogosto razkrijejo manjkajoče kategorije, nejasne različice izdelkov in razlike med formalnim pravilom ter prakso. Te izjeme sodijo v brief, ne v opombe, ki jih razvoj vidi šele po uvedbi.

Microsoftov HAX Toolkit je usmerjen v načrtovanje uporabniške izkušnje in pričakovanih napak AI. Pri procesnem briefu to uporabite kot izhodišče za pogovor: kako sodelavec prepozna omejitev, popravi rezultat in brez ponovnega vnosa prevzame primer.

Povratna informacija naj pove, kaj je bilo narobe. »Neustrezen odgovor« ni tako uporabno kot »izbran napačen model« ali »uporabljena neveljavna cena«. Razloge za popravek zbirajte v dogovorjenem naboru in ohranite možnost dodatne razlage. S tem dobite osnovo za naslednjo izboljšavo.

Imenujte lastnika rezultata in skrbnika sprememb

Poslovni lastnik potrdi, kaj šteje kot uporabna rešitev. Podatkovni skrbnik odgovarja za zanesljivost vira. Tehnični skrbnik zagotovi delovanje povezav in izvajanja. Uporabnik pa presoja uporabnost pri vsakodnevnem delu. Ena oseba lahko opravlja več vlog, toda odgovornosti morajo ostati vidne.

Določite, kdo lahko spremeni brief in katera sprememba zahteva ponovno preverjanje. Dodana skupina izdelkov lahko spremeni pravila ujemanja, podatkovno strukturo in vzorec primerov. To ni nujno samo nov odstavek v navodilih. Shranite različico specifikacije skupaj z različico uvedene rešitve.

Tudi izvajalec mora znati povedati, katere predpostavke uporablja njegova ocena obsega. Dostop do podatkov, urejen katalog in razpoložljivost strokovnjaka niso samoumevni. Dober brief pokaže te odvisnosti, da se naročnik in razvoj ne pogovarjata o različnih projektih.

Delovni primer: kratka izpolnjena specifikacija

V brief napišemo: agent pripravi osnutek za obstoječo stranko in podprto skupino izdelkov, kadar so potrebni podatki popolni. Cilj je zmanjšati ponavljajoče se sestavljanje osnutka, pri čemer prodajnik še vedno presodi predlog. To je opis namena pilota, ne napoved zagotovljenega prihranka ali spremembe števila zaposlenih.

Kot vhod navedemo identifikator primera, izvorno zahtevo, potrjeno stranko in zahtevane količine. Za vsak podatek zabeležimo, ali ga dobimo iz vhoda ali z orodjem. Če identiteta stranke ni potrjena, primer ne nadaljuje v zapis osnutka. Takšno pravilo lahko preveri razvoj in razume operativni uporabnik.

Izhod je osnutek s postavkami, podatkovno podlago in odprtimi vprašanji. Merilo sprejema določi, da vse potrjene postavke ustrezajo veljavnim šifram, izračun je ponovljiv in stanje jasno kaže, da dokument še ni poslan. Pri nepopolnem primeru mora izhod navesti manjkajoče polje ter odgovorno vrsto za nadaljevanje.

Na prevzemu nato pregledamo običajen primer, manjkajočo količino, dvoumno stranko, nepodprt izdelek in nedosegljiv cenik. Pri vsakem uporabimo vnaprej zapisano merilo, ne naknadne razlage. Če se prodaja in razvoj ne strinjata o pričakovanem vedenju, je to znak za dopolnitev specifikacije, preden spor preselimo v produkcijo.

Iz briefa naredite odločitev za izvedbo

Pred razvojem mora biti jasno, kaj bomo prikazali na pregledu, kateri primeri morajo uspeti in kdo bo ocenil rezultat. Odprta vprašanja razvrstite na blokade in zadeve, ki jih lahko preveri pilot. Prvih ne skrivajte v pričakovanju, da jih bo rešil bolj zmogljiv model.

Pri NUMEDIA je cilj te faze izvedljiv obseg: ena naloga, odgovorna ekipa, dogovorjeni podatki in preverljiva merila. Tak dokument podpira tudi primerjavo ponudb izvajalcev. Razlika v številu predlaganih agentov je manj pomembna kot razlika v tem, katero odgovornost posamezna rešitev dejansko prevzame.

Ko je brief potrjen, ga uporabite kot skupno referenco pri integraciji in pregledu pilota. Če se izkaže, da je treba spremeniti nalogo, to zapišite. Meril ne prilagajajte za nazaj samo zato, da bi že izdelan prototip izgledal uspešen.

Viri in metodologija

1. Identifying and scaling AI use cases (OpenAI, dostop 2026-10-19)
2. Microsoft HAX Toolkit (Microsoft, dostop 2026-10-19)
3. Demystifying evals for AI agents (Anthropic, dostop 2026-10-19)

Pogosta vprašanja