Človeška odobritev agenta lahko postane slepi klik: tako postavite prava vrata

Pri agentu zahtevajte človeško odobritev glede na tveganje konkretnega dejanja: kaj bo spremenil, komu bo kaj poslal, koliko bo plačal ali katere pravice bo dodelil. Pregledovalec naj potrdi določen predlog, izvajalec pa naj pred klicem preveri, da so cilj, vsebina in drugi odločilni parametri še vedno enaki.

Začnite z matriko za branje, pisanje, pošiljanje, plačilo, brisanje in spremembo pravic. Smernice AWS za odobritve agentov priporočajo razvrščanje po tveganju, dovolj konteksta za presojo, ozko omejena in preklicljiva trajnejša dovoljenja ter varen izid, če se rok za odgovor izteče. Če pregledovalec potrjuje vsako malenkost, se odobritev lahko spremeni v rutinski klik.

Matrika: katera dejanja potrebujejo pregled

Naslednja matrika je izhodišče za pravila ekipe, ne univerzalna razvrstitev. Stopnjo pregleda zvišajte glede na občutljivost podatkov, obseg spremembe, možnost povrnitve, zunanjega prejemnika in nenavadno pogostost zahtev. Pravilo naj izvaja preverljiva programska logika. Agentova ocena lahko pojasni okoliščine, ne sme pa sama odločiti, da je odobritev odveč.

• Branje: znotraj že dovoljenega vira praviloma brez sprotnega potrjevanja. Če agent potrebuje občutljive ali nepričakovane podatke, najprej omejite dostop do vira; klik ob vsakem branju ne popravi preširokih pravic.
• Pisanje: omejeno in popravljivo spremembo lahko pregleda en pristojni človek ali jo pokrije ozko dovoljenje. Pri množični spremembi zapisov, produkcijske konfiguracije ali podatkov druge ekipe predvidite strožji pregled.
• Pošiljanje: pred sporočilom zunaj organizacije pokažite prejemnika, vsebino in priloge. Samodejno ustvarjen osnutek obravnavajte ločeno od dejanskega pošiljanja.
• Plačilo: pred izvršitvijo pokažite prejemnika, znesek, valuto, plačilni račun in namen. Pragove ter število pregledovalcev določite glede na lastna pooblastila; sprememba plačilnega podatka zahteva novo presojo.
• Brisanje: pokažite točen vir in obseg, tudi če sistem omogoča obnovitev. Množično ali nepopravljivo brisanje uvrstite v strožjo stopnjo.
• Sprememba pravic: pokažite, kdo dobi ali izgubi dostop, do katerega vira in za koliko časa. Razširitev pravic, posebej skrbniških, presojajte strožje kot njihovo zožitev.

Za vsako vrsto dejanja določite tudi upravičenega pregledovalca in nadomestno pot, če ni dosegljiv. Zahtevo mora prejeti oseba, ki razume njen učinek in jo sme zavrniti. Sicer čakalna vrsta doda zamudo, odločitvi pa malo vrednosti.

Odobritev vežite na predlagani klic

Pred pregledom shranite ime orodja, ciljni vir in parametre, ki določajo učinek dejanja. Pregledovalcu pokažite kratek razumljiv povzetek in omogočite vpogled v celoten predlog. Ob izvedbi primerjajte dejanski klic s shranjeno različico: drug prejemnik, priloga, znesek ali cilj pomeni novo zahtevo, ne popravek že odobrene.

Vodnik OpenAI Agents SDK opisuje prekinitev pred klicem orodja, odločitev o čakajočem klicu in nadaljevanje iz shranjenega stanja. Aplikacija mora ob tem sama preveriti identiteto in pooblastilo pregledovalca ter povezati njegov odgovor s čakajočo zahtevo. Stanje in argumente klica naj hrani na strežniku; odgovor pregledovalca naj vsebuje identifikator odločitve, ne nadomestnih parametrov za izvedbo.

Preverite tudi predpogoje v ciljnem sistemu. Če se je med čakanjem spremenila različica zapisa, stanje naročila ali seznam prejemnikov, lahko isti ukaz učinkuje drugače, kot je pregledovalec pričakoval. Takšno zahtevo ustavite in pripravite nov predlog z aktualnim stanjem.

Zapis naj pojasni odločitev in izvedbo

Komentar za TechRadar Pro opozarja, da lahko potrjevanje postane rutina in da dnevnik končnega dejanja brez vmesnih sprememb ne pojasni, kako je do njega prišlo. Gre za avtorjevo opozorilo, ne za meritev pogostosti takih primerov. Za pregled dogodka mora biti razvidno, kaj je bilo predlagano, kaj je človek videl in kaj se je izvedlo.

Uporabna predloga zapisa vsebuje identifikator agenta in poteka, vrsto operacije, ciljni vir, odločilne parametre ter različico predloga. Dodajte uporabljeno pravilo tveganja, povezavo do relevantnih vhodnih podatkov in vmesnih korakov, identiteto pregledovalca, čas prikaza in odgovora, odločitev z razlogom, rok ter rezultat izvedbe. Zabeležite tudi predajo drugemu pregledovalcu in vsak preklic.

Pri pogojnem primeru pošiljanja bi zapis povezal določenega prejemnika, vsebino in prilogo z odločitvijo določenega pregledovalca ter z dejansko izvedenim klicem. Če se klic razlikuje od potrjenega predloga, mora zapis pokazati zavrnitev izvedbe. Poln kontekst hranite z omejenim dostopom; obvestilo pregledovalcu naj izpostavi podatke, ki jih potrebuje za odločitev.

Po izteku roka dejanje ostane blokirano

Vsaka zahteva naj ima rok veljavnosti. Če odgovor ne prispe pravočasno, obvestite nadomestnega pregledovalca ali ustvarite novo zahtevo, prvotni klic pa naj ostane blokiran. Poznejši klik na poteklo zahtevo ne sme sprožiti izvedbe. Zavrnitev, preklic in iztek časa zabeležite kot različna stanja, da je pozneje jasno, zakaj dejanje ni bilo opravljeno.

Za res rutinsko opravilo lahko odobrite trajnejše dovoljenje, vendar ga omejite na določeno operacijo, obliko parametrov, vir in rok. Zapišite, kdo ga je podelil, ter omogočite takojšen preklic. Sprememba obsega zahteva novo odločitev: dovoljenje za eno vrsto notranjega sporočila ne sme samodejno veljati za vse prihodnje pošiljanje.

Kako zmanjšati utrujenost pregledovalcev

Po uvedbi spremljajte obremenitev posameznega pregledovalca, čas do odločitve, zavrnitve in potekle zahteve. Veliko hitrih odobritev je razlog za pregled prikazanega konteksta in pragov, samo po sebi pa ne dokazuje površnosti. Če se ponavljajo enaki, omejeni in popravljivi posegi, lahko zanje oblikujete ozko preklicljivo dovoljenje. Če se ponavljajo zavrnitve, preverite pravilo ali podatke, iz katerih agent sestavi predlog.