Millal peaks AI‑agent vajama inimese heakskiitu?

Ei iga sammu puhul. Kui inimene peab heaks kiitma iga lugemise ja iga madala riskiga tööriista väljakutse, hakkab ta kiiresti klõpsama mehaaniliselt. Heakskiit on kasulik seal, kus agendi viga võib käivitada reaalse tagajärje: finantsilise, välise, haldusliku, õigusliku, turvalisusega seotud või raske taastada.

On veel üks oluline punkt: kontrolli tase ei tohiks sõltuda sellest, kui kindel mudel kõlab. Kindel mudel võib siiski eksida. Valime kontrolli põhinedes tegevuse tagajärgel.

Otsustusmudel: viis küsimust enne autonoomia andmist

Iga agendi tegevuse puhul kontrollime viit omadust.

1. Kas toiming muudab olekut?

Lugemine on tavaliselt madalama riskiga kui kirjutamine. Mitte alati — lugemine võib paljastada tundlikke andmeid — kuid lugemise ja kirjutamise eristamine on kasulik lähtepunkt.

2. Kas tagajärg lahkub sisemisest süsteemist?

E‑maili saatmine, postituse avaldamine, reklaami lubamine, dokumendi väljastamine või kliendile vastamine on väliselt nähtavad. Viga muutub kohe suhtlus‑, kulu‑ või maineprobleemiks.

3. Kas toiming tekitab kulu või kohustuse?

Agent võib API‑kõne õigesti täita ja siiski teha vale ärilise otsuse. Eelarve, ostud, maksed, tellimused või ressursi broneerimine vajavad eraldi piiri.

4. Kas muudatus on kergesti tagasi pööratav?

Sildi muutmine ja konto kustutamine ei kuulu samasse klassi. Võta arvesse taastamiskulu, taastamisaega, andmekadu ja mõju teistele kasutajatele.

5. Kas toiming muudab turvalisust või õigusi?

Administraatori juurdepääsu andmine, saladuse pööramine, ressursi avalikustamine või MFA‑poliitika muutmine vajab kontrolli isegi siis, kui tegevus on tehniliselt tagasi pööratav.

Praktikaline autonoomiamaatriks

Tase	Tegevuse omadused	Näited	Vaikimisi otsus
A — autonoomne	ainult lugemine, madal mõju, kitsas ulatus	teenuse olek, kuluaruanne, ülesandeloend	agent võib täita
B — autonoomne auditiga	tagasi pööratav kirjutamine kitsas alal	sildi lisamine, mustandi salvestamine, ülesande loomine	agent võib täita selge loata ja logimisega
C — heakskiit enne mõju	väline tagajärg, finantsmõju või materiaalne muutus	sõnumi saatmine, avaldamine, kampaania lubamine	inimene heaks kiidab konkreetse toimingu
D — tugev kontroll	hävitav, turvalisusega seotud, raske tagasi pöörata	andmete kustutamine, admin‑juurdepääsu muutmine, võtme tühistamine	eraldi ulatus + heakskiit + eelvaade; tihti lisakinnitused

See on operatiivne mudel, mitte õiguslik standard. Konkreetne süsteem peaks tasemed kohandama oma andmete, regulatsioonide, tagajärgede ja taastamismehhanismide järgi.

Heakskiit peab olema seotud konkreetse tagajärjega

Kehv heakskiidu dialoog näeb välja selline:

Agent soovib toimingut teha. Jätkata? Jah / Ei.

Isik ei tea, mida ta autoriseerib.

Parem eelvaade näeb välja selline:

Toiming: KAMPAAINI LUBAMINE
Konto: Brillnet Ads / [inimloetav tunnus]
Kampaania: Otsing — Pulsar GRC
Keskmine päevane eelarve: PLN 80
Sihtkoht: Poola
Muudatus: PAUSETUD → LUBATUD
Tagasipööratav olek: kampaaniat saab uuesti peatada; kogunenud kulutust ei tühistata
Tagajärg: heakskiidu järel võib kampaania alustada kulutamist
Otsuse allikas: ülesanne #...

Ainult siis on “Heakskiida” nupp tähendusrikas. Google Adsis ei ole keskmine päevane eelarve rangelt samapäevane limiit: enamikus kampaaniates on päevane arvelduspiir kaks korda suurem. Eelvaade peaks selgitama seda tagajärge, mitte lubama PLN 80 katuset.

Heakskiit ei tohi muutuda üldiseks loa andmiseks tulevastele muudatustele

Oletame, et isik heaks kiidab:

saada see sõnum 12‑le adressaadile

Kui agent muudab sisu või adressaadide loendit 1 200‑ks pärast heakskiitu, ei kehti algne heakskiit enam.

Praktiline reegel on:

Heakskiit on seotud konkreetse normaliseeritud toiminguga. Olulised muutused parameetrites tühistavad heakskiidu ja nõuavad uut.

Rakendus võib siduda heakskiidu ID‑ga toimingu parameetrite räsi, ressursi versiooni või muu stabiilse esindusega, mis tegelikult heaks kiideti.

Mudel ei tohi ise otsustada, kas heakskiitu võib vahele jätta

Mudelile võib anda ülesande hinnata risk. See võib olla üks signaal. See ei tohiks olla ainsaks kontrolliks.

Kui poliitika on:

kui mudel peab toimingu riskantseks, küsib see inimeselt

siis mudel kontrollib ka mehhanismi, mis on mõeldud oma vigade mõju piiramist.

Tugevam disain on:

1. Mudel valib tööriista ja parameetrid.
2. Värav klassifitseerib toimingu selge poliitika alusel.
3. Poliitikamootor otsustab, kas heakskiit on vajalik.
4. Inimene heaks kiidab, kui nõutud.
5. Alles siis toimub täitmine.

Mudel võib anda selgituse. Lõplik klassifikatsioon tuleb süsteemi poliitikast.

Näide meie enda automatiseerimisest: kampaania ettevalmistamine ei ole sama mis kulude alustamine

Meie sisemises Brillnet Ads MCP‑s eraldame võimekuse kampaania ettevalmistamiseks või muutmiseks kulude aktiveerimisest.

Uus kampaania on vaikimisi PAUSETUD, kui ei ole antud muud olekut. Konfiguratsiooni salvestamine ei ole nõusolek kulude alustamiseks. Operatiivse efekti lubamine nõuab eraldi “operate” õigust ja kinnitust päringus. Ainult kinnituse väli ei tõesta, et isik on toimingu üle vaadanud. See tõendus vajab eespool kirjeldatud sõltumatut heakskiidu mehhanismi.

See väike eristus annab kasuliku tulemuse:

• agent saab lõpetada enamik ettevalmistustööd;
• isik ei pea käsitsi sisestama kõiki välju;
• eelarve ei alga lihtsalt seetõttu, et mudel otsustas, et konfiguratsioon on valmis.

Sama muster kehtib teiste töövoogude puhul:

Ettevalmistus	Efekt, mis nõuab eraldi otsust
e‑maili mustand	saatmine
kasutajarolli ettepanek	juurdepääsu andmine
migratsiooniplaan	migratsiooni käivitamine
failide loetelu eemaldamiseks	kustutamine
hinnamuudatuse ettepanek	uue hinna avaldamine
ettevalmistatud makse	makse autoriseerimine

Millal heakskiit võib olla mittevajalike

Ei iga automatiseerimine vaja olla poolautomaatselt.

Inimese heakskiit lisab vähe väärtust, kui kehtivad kõik järgnevad tingimused:

• toiming on ainult lugemine või madala mõjuga;
• agent töötab kitsas, eelnevalt heaks kiidetud ulatuses;
• väljund ei ole automaatselt avaldatud;
• viga on lihtne avastada ja parandada;
• kulutusi ega välist kohustust ei teki;
• õigused ja turvaseaded ei muutu;
• toiming jätab piisava auditi jälje, et tulemus taastada.

Näide: agent toob iga päev kampaania staatuse ja koostab sisemise aruande. Inimese nõudmine heaks kiita iga lugemine ei suurenda turvalisust proportsionaalselt operatiivsete kuludega.

Millal soovitame heakskiitu minimaalse nõudena

Meie projektides ei annaks ma autonoomset täitmist ilma eraldi analüüsita toimingutele, mis:

• saadavad kliendi‑ või avaliku suhtluse;
• alustavad või suurendavad kulutusi;
• kustutavad või kirjutavad üle andmeid ilma lihtsa taastamisteedeta;
• annavad, laiendavad või tühistavad õigusi;
• muudavad saladusi, turvakonfiguratsiooni või MFA‑d;
• aktsepteerivad õiguslikke tingimusi organisatsiooni nimel;
• toimivad ebamääraselt tuvastatud ressursil;
• käivitavad teise süsteemi, mis omakorda võib teha kõrge mõjuga toiminguid.

See ei tähenda, et inimese heakskiit oleks alati ainus kontroll. Kriitiliste toimingute puhul peaks see olema üks mitmest kihist.

Jälgi heakskiidu väsimust

Kui süsteem küsib heakskiitu 80 korda päevas, lõpetavad kasutajad teavituste lugemise. Heakskiit muutub töötaja CAPTCHA‑ks.

See viitab tavaliselt ühele kolmest disainiprobleemist:

1. riskiklassifikatsioon on liiga lai;
2. töövoog ei rühma loogiliselt seotud muudatusi;
3. agentil on liiga vähe turvalist autonoomiat madala riskiga, seega eskaleeritakse kõik.

Vastus ei ole hoiatuste varjamine. See on paremate piiride kujundamine.

Kasulik heakskiidumehhanism peaks tegema

Näita diffi, mitte kogu objekti

Konfiguratsiooni puhul näita enne → pärast ja muutunud välju. Ära nõua, et ülevaataja võrdleks kahte ekraani käsitsi.

Kirjelda tagajärg

“Salvesta muudatus” on nõrgem kui “Luba kampaania — see võib alustada kulutamist keskmise päevase eelarvega PLN 80”.

Oleulised ulatus ja kehtivusaeg

Vana heakskiit ei tohiks jätkata toimingu autoriseerimist, kui kontekst on muutunud.

Keela oluliselt muudetud toiming

Kui parameetrid muutuvad pärast heakskiitu, peab heakskiit aeguma.

Jäta sõltumatu kirje

Auditkirje peaks näitama, kes, millal, millise toimingu ID alusel heaks kiitis. See ei tohi tugineda ainult mudeli sõnumile “kasutaja nõustus”.

Loe: AI‑agendi auditijäljed

Kontrollnimekiri ühe agendi tegevuse jaoks

Enne autonoomia andmist vasta:

• Kas tegevus on ainult lugemine?
• Kas see muudab ärilist olekut?
• Kas see tekitab kulu või kohustuse?
• Kas tulemus on väliselt nähtav?
• Kas see hõlmab isiku‑ või konfidentsiaalseid andmeid?
• Kas see muudab rolle, õigusi või turvakonfiguratsiooni?
• Kas see on lihtne tagasi pöörata?
• Kas sihtressurss on üheselt tuvastatav?
• Kas toimingu korduv käivitamine võib toimuda kaks korda?
• Kas süsteem suudab enne täitmist näidata konkreetset eelvaadet?
• Kas heakskiit on seotud täpsete parameetritega?
• Kas tulemuslik olek on täitmise järel kontrollitav?

Kui tegevus ühendab mitu kõrge riskiga omadust, võib üks “OK” olla liiga nõrk kontroll.

Läbitöödeldud näide: teenusepakkuja saadab kliendi aruande

Võtame ettepanekulise töövoo, mitte juba kasutuse võetud juurutuse. Agent toob heaks kiidetud kirjed, võrdleb tähtaegu ja koostab aruande. Konto omanik jääb vastutavaks sisu eest. Protsessi omanik määrab lubatud andmed ja kes võib kohalduse kohaletoimetamise heaks kiita.

Mustandi ettevalmistus võib toimuda eelnevalt heaks kiidetud piirides. Enne saatmist näita kliendi, täpset adressaadi, teemat, sõnumit ja manuseid koos lähteandmete versiooniga. Ülevaataja peaks saama dokumenti otse kontrollida. Ainult mudeli kokkuvõtte usaldamine nõrgestab ülevaatust.

Heakskiit katab just seda paketti. Lisades adressaadi, asendades manuse või muutes olulist soovitust, tühistab see heakskiidu. Varem määratletud reegel võib lubada õigekirjavea parandamist, kuid see ei tohi muutuda õiguseks muuta sisu. Protsessi omanik määratleb materiaalsed muudatused; täitmiskomponent jõustab piiri.

Mida peaks heakskiidukirje sisaldama

Seosta heakskiit isiku, rolli, tenant’i, tööriista, sihtressursi, andmete versiooni, parameetrite, aegumise ja ülesande ID‑ga. Eralda “proposed”, “pending”, “approved”, “executing” ja “uncertain” olekud. Operatsioon peab teadma, kas klõps valmistab tegevust või käivitab selle.

Parameetriräsi aitab tuvastada asendamist. See ei tõesta, et isik on eelvaadet lugenud. Selge liides ja volitatud ülevaataja on endiselt olulised. Isikul, kellel pole õigust anda administraatori juurdepääsu, ei tohi see õigus läbi agendi heakskiidudialoogi omandada.

Partii puhul näita objektide arvu, olulisi erandeid ja kogu mõju. Üks heakskiit võib katta täpselt määratletud partiid. See ei saa katta suvalisi täiendavaid objekte, mis valitakse pärast heakskiitu. See vähendab korduvaid dialooge, kaotamata kontrolli ulatust.

Käsitle ebakindlat täitmist enne kordust

Teenusepakkuja võib päringu täita, kuigi vastus ei jõua agendini. Puuduv kinnitus ei ole tõend ebaõnnestumisest. Kordus võib saata teise e‑maili, luua duplikaatdokumendi või tekitada lisakulu. Kontrolli esmalt päringu ID‑d ja teenusepakkuja olekut.

Kui toetatakse idempotentsusvõtmeid, seo üks võti toimingu külge ja kasuta seda sama päringu jaoks. Vastasel juhul rakenda duplikaatide tuvastamine või küsi operaatoril otsustada pärast oleku kontrollimist. Kirjuta ebakindel tulemus ausalt. Kahekordne klõps ei lahenda teadmata tulemust.

Vaikimine ei ole heakskiit

Määra iga protsessi jaoks asendaja ja teavituskanal. Aegumine ilma vastuseta blokeerib väravaga seotud toimingu. Agent võib jätkata teiste volitatud, madala riskiga tööde ettevalmistamist; ta ei tohiks vaikimisest või ärilisest tähtaegast järeldada nõusolekut.

Määra eraldi hädaolukorra peatamine. Luba vale töövoo peatamiseks võib olla kitsam kui selle käivitamiseks. Säilita täitmisseisund ja lõpetatud toimingute loend. Konfiguratsiooni taastamine ei saa kutsuda tagasi kliendisõnumit, mis on juba loetud.

Kontrolli, kas ülevaatus muudab otsuseid

Jälgi parandusi, keeldumisi, ooteaega ja katseid täita oluliselt muudetud parameetreid. Võrdle toimingutüüpe eraldi. Aeglane heakskiit kliendisuhtluse puhul ei tohiks takistada autonoomset sisemist ülesannete ettevalmistust.

Kui iga ettepanek heaks kiidetakse kohe nädalateks, vaata protsessi omanikuga valimit. Poliitika võib olla liiga lai või eelvaated võivad olulist infot välja jätta. Kõrge heakskiidukogus ei ole turvalisuse tõend.

Homme vali üks väline toiming. Koosta selle eelvaade, määra volitatud ülevaataja, määra aegumine ja kinnita, et adressaadi muutmine tühistab heakskiidu. Veendu, et keeldumine ei põhjusta välist mõju.

Soovitused ja allikapiirangud

OWASP käsitleb kõrge mõjuga toimingute kontrolli ja heakskiidu terviklikkust. Tehingu autoriseerimise juhised käsitlevad serveripoolset kontrolli oluliste tehinguandmete üle. NIST AI RMF on vabatahtlik riskijuhtimise juhend. Meie A–D maatriks on inseneri soovitus, mitte õiguslik kohustus iga AI‑toimingu heaks kiitmiseks. Sisemine Ads MCP dokumentatsioon, kuupäevaga 28. juuli 2026, kirjeldab viidatud kontrollidisaini; see ei tõesta iseseisvalt tootmist kliendi jaoks.

Piirang

See klassifikatsioonimudel on meie insenerpraktika, mitte õigusnõuanne ega ametlik riskihindamise standard. Reguleeritud, meditsiinilised, finants- või turvalisuskriitilised protsessid võivad nõuda tugevamaid kontrolle.

Vaata ka MCP ja AI‑agendid: turvalisemate tööriistade kujundamine ja Vähimõõdu põhimõte AI‑agentele.

Allikad

• OWASP AI Agent Security Cheat Sheet. Accessed: 2026-10-02.
• OWASP Transaction Authorization Cheat Sheet. Accessed: 2026-10-02.
• NIST AI Risk Management Framework. Accessed: 2026-10-02.
• Google Ads Help — About spending limits. Accessed: 2026-10-02.