Milloin tekoälyagentin on vaadittava ihmisen hyväksyntä?

Ei jokaisessa vaiheessa. Jos henkilön on hyväksyttävä jokainen luku- ja jokainen matalariskinen työkalukutsu, hän alkaa nopeasti klikkaamaan mekaanisesti. Hyväksyntä on hyödyllistä silloin, kun agentin virhe voi aiheuttaa todellisen seurauksen: taloudellisen, ulkoisen, hallinnollisen, oikeudellisen, turvallisuuteen liittyvän tai vaikeasti peruutettavan.

Toinen tärkeä seikka: hallinnan taso ei saa riippua siitä, kuinka itsevarmalta malli vaikuttaa. Itsevarma malli voi silti olla väärässä. Valitsemme hallinnan perustuen toiminnon seurauksiin.

Päätösmalli: viisi kysymystä ennen autonomian myöntämistä

Jokaiselle agentin toiminnolle tarkistamme viisi ominaisuutta.

1. Muuttaako operaatio tilaa?

Luku on yleensä matalariskinen kuin kirjoitus. Ei aina – luku voi paljastaa arkaluonteista dataa – mutta luku‑ ja kirjoitusoperaatioiden erottaminen on hyödyllinen lähtökohta.

2. Jääkö seuraus järjestelmän ulkopuolelle?

Sähköpostin lähettäminen, julkaisun tekeminen, mainoksen käynnistäminen, asiakirjan laatiminen tai asiakkaan vastaaminen on ulkoisesti näkyvää. Virhe muuttuu välittömästi suhde‑, kustannus‑ tai maineongelmaksi.

3. Luoako operaatio kustannuksia tai sitoumuksia?

Agentti voi suorittaa API‑kutsun oikein, mutta tehdä silti väärän liiketoimintapäätöksen. Budjetti, ostot, maksut, tilaukset tai resurssivaraukset tarvitsevat erillisen rajan.

4. Voiko muutoksen perua helposti?

Tunnisteen muuttaminen ja tilin poistaminen eivät ole samassa luokassa. Tarkastele palautuskustannuksia, palautusaikaa, tietojen menetystä ja vaikutusta muihin käyttäjiin.

5. Muuttaako operaatio turvallisuutta tai oikeuksia?

Järjestelmänvalvojan oikeuksien myöntäminen, salaisuuden kierrättäminen, resurssin julkistaminen tai MFA‑politiikan muuttaminen ansaitsee hallinnan, vaikka toiminto olisi teknisesti peruutettavissa.

Käytännön autonomiamatriisi

Taso	Toiminnon ominaisuudet	Esimerkkejä	Oletuspäätös
A — autonominen	vain luku, alhainen vaikutus, tiukasti rajattu	palvelun tila, kustannusraportti, tehtävälista	agentti voi suorittaa
B — autonominen auditoinnin kanssa	peruutettavissa oleva kirjoitus rajoitetulla alueella	lisää tunniste, tallenna luonnos, luo tehtävä	agentti voi suorittaa eksplisiittisellä luvalla ja lokituksella
C — hyväksyntä ennen vaikutusta	ulkoinen seuraus, taloudellinen vaikutus tai merkittävä muutos	lähetä viesti, julkaise, käynnistä kampanja	ihminen hyväksyy tietyn toiminnon
D — vahva kontrolli	tuhoava, turvallisuuteen liittyvä, vaikea peruuttaa	poista dataa, muuta admin‑oikeuksia, peruuta avain	erillinen raja + hyväksyntä + esikatselu; usein lisävahvistus

Tämä on operatiivinen malli, ei oikeudellinen standardi. Jokaisen järjestelmän tulisi soveltaa tasoja omiin tietoihinsa, sääntelyyn, seurauksiin ja palautumismekanismeihin.

Hyväksynnän on sidottava tiettyyn seuraukseen

Heikko hyväksyntäikkuna näyttää tältä:

Agentti haluaa suorittaa toiminnon. Jatketaanko? Kyllä / Ei.

Henkilö ei tiedä, mitä hän oikeuttaa.

Parempi esikatselu näyttää enemmän tältä:

Toiminto: KAMPANJAN AKTIVOINTI
Tili: Brillnet Ads / [luettavissa oleva tunniste]
Kampanja: Haku — Pulsar GRC
Keskimääräinen päivittäinen budjetti: PLN 80
Kohde: Puola
Muutostapa: PAUSED → ENABLED
Peruutettavissa oleva tila: kampanja voidaan taas pysäyttää; kertyneitä kuluja ei peruuteta
Seuraus: hyväksynnän jälkeen kampanja voi alkaa tuottaa kuluja
Päätöslähde: tehtävä #...

Vasta silloin “Hyväksy”-painike saa merkityksensä. Google Adsissa keskimääräinen päivittäinen budjetti ei ole tiukka saman päivän raja: useimmissa kampanjoissa päivittäinen laskutusraja on kaksinkertainen. Esikatselun tulisi selittää tämä seuraus eikä lupauksena PLN 80‑kattoa.

Hyväksyntä ei saa muuttua yleiseksi läpikuluksi tuleville muutoksille

Oletetaan, että henkilö hyväksyy:

lähetä tämä viesti 12 vastaanottajalle

Jos agentti muuttaa sisällön tai vastaanottajalistan 1 200:een vastaanottajaan hyväksynnän jälkeen, alkuperäinen hyväksyntä ei enää päde.

Käytännöllinen sääntö on:

Hyväksyntä on sidottu tiettyyn normalisoituun operaatioon. Materiaalinen muutos sen parametreihin mitätöi hyväksynnän ja vaatii uuden.

Toteutus voi sitoa hyväksyntä‑ID:n operaatio‑parametrien hash‑arvoon, resurssiversioon tai muuhun vakaaan esitykseen siitä, mitä on oikeasti hyväksytty.

Malli ei saa itse päättää, milloin hyväksyntä voidaan ohittaa

Mallia voidaan pyytää arvioimaan riskiä. Se voi olla hyödyllinen yksi signaali, mutta ei ainoa hallintakeino.

Jos politiikka on:

kun malli katsoo toiminnon riskialttiiksi, se kysyy ihmiseltä

niin malli myös hallitsee mekanismia, jonka tarkoitus on rajoittaa sen omien virheiden vaikutuksia.

Vahvempi suunnittelu on:

1. Malli valitsee työkalun ja parametrit.
2. Portti luokittelee toiminnon eksplisiittisen politiikan perusteella.
3. Politiikkamoottori määrittää, vaaditaanko hyväksyntä.
4. Henkilö hyväksyy, kun se on pakollista.
5. Vasta sen jälkeen suoritus tapahtuu.

Mallin voi antaa selityksen. Lopullinen luokittelu tulee järjestelmän politiikasta.

Esimerkki omasta automaatiostamme: kampanjan valmistelu ei ole sama kuin kulujen aloitus

Sisäisessä Brillnet Ads MCP:ssä erottelemme kampanjan valmistelun tai muokkaamisen kyvyn kulujen aktivoinnista.

Uusi kampanja on oletuksena PAUSED, jos muuta tilaa ei erikseen anneta. Konfiguraation tallentaminen ei ole suostumusta kulujen aloitukseen. Operatiivisen vaikutuksen käynnistäminen vaatii erillisen “operate”-oikeuden ja vahvistuksen pyynnössä. Vain vahvistuskenttä ei todista, että henkilö on tarkastellut toimintaa; se vaatii yllä kuvatun itsenäisen hyväksyntämekanismin.

Tämä pieni erottelu tuottaa hyödyllisen tuloksen:

• agentti voi suorittaa suurimman osan valmistelutyöstä;
• henkilön ei tarvitse syöttää jokaista kenttää manuaalisesti;
• budjetti ei käynnisty pelkästään sen takia, että malli katsoo konfiguraation valmiiksi.

Sama malli soveltuu muihin työnkulkuihin:

Valmistelu	Vaikutus, joka vaatii erillisen päätöksen
sähköpostiluonnos	lähetä se
roolin ehdotus	myönnä pääsy
migraatiosuunnitelma	toteuta migraatio
poistettavien tiedostojen lista	poista ne
ehdotettu hintamuutos	julkaise uusi hinta
valmisteltu maksu	valtuuta maksu

Milloin hyväksyntä voi olla tarpeeton

Kaikki automaatio ei tarvitse olla puoliksi automaattista.

Ihmisen hyväksyntä lisää usein vähän arvoa, kun kaikki seuraavat ehdot täyttyvät:

• toiminto on vain luku‑ tai alhaisen vaikutuksen tasolla;
• agentti toimii kapeassa, ennalta hyväksytyssä rajassa;
• tulosta ei julkaista automaattisesti;
• virhe on helppo havaita ja korjata;
• ei ole kulua tai ulkoista sitoumusta;
• oikeuksia ja turvallisuusasetuksia ei muuteta;
• toiminto jättää riittävän auditointitiedon tuloksen rekonstruoimiseksi.

Esimerkki: agentti hakee kampanjan tilan päivittäin ja laatii sisäisen raportin. Ihmisen vaatiminen hyväksymään jokainen luku ei lisää turvallisuutta suhteessa operatiivisiin kustannuksiin.

Milloin suosittelemme vähintään hyväksyntää

Projekteissamme en myönnä autonomista suoritusta ilman erillistä analyysiä seuraaville toiminnoille:

• asiakas‑ tai julkinen viestintä;
• kulujen aloitus tai lisäys;
• datan poistaminen tai ylikirjoittaminen ilman helppoa palautuspolkua;
• oikeuksien myöntäminen, laajentaminen tai peruuttaminen;
• salaisuuksien, turvallisuusasetusten tai MFA:n muokkaus;
• organisaation puolesta oikeudellisten ehtojen hyväksyminen;
• epäselvästi tunnistetun resurssin käyttö;
• toisen järjestelmän käynnistäminen, joka voi itse suorittaa korkean vaikutuksen toimintoja.

Tämä ei tarkoita, että ihmisen hyväksyntä olisi aina ainoa hallintakeino. Kriittisissä toiminnoissa sen tulisi olla yksi useista kerroksista.

Varo hyväksyntäuupumusta

Jos järjestelmä pyytää hyväksyntää 80 kertaa päivässä, käyttäjät lakkaavat lukemasta kehotteita. Hyväksyntä muuttuu työntekijän CAPTCHA‑testiksi.

Tämä viittaa yleensä yhteen kolmesta suunnitteluongelmasta:

1. riskiluokittelu on liian laaja;
2. työnkulku ei ryhmittele loogisesti liittyviä muutoksia;
3. agentilla on liian vähän turvallista autonomiaa matalariskisissä tilanteissa, joten kaikki eskaloituu.

Vastaus ei ole varoitusten piilottaminen, vaan parempien rajojen suunnittelu.

Hyödyllisen hyväksyntämekanismin ominaisuudet

Näytä diff, ei koko objekti

Konfiguraatioissa näytä ennen → jälkeen ja muuttuneet kentät. Älä pakota tarkistajaa vertailemaan kahta ruutua manuaalisesti.

Ilmoita seuraus

“Tallenna muutos” on heikompi kuin “Aktivoi kampanja — se voi alkaa tuottaa kuluja keskimääräisellä päivittäisellä budjetilla PLN 80”.

Määritä laajuus ja voimassaoloaika

Vanhan hyväksynnän ei tule jatkaa toiminnon valtuuttamista, kun konteksti muuttuu.

Hylkää merkittävästi muuttunut operaatio

Jos parametrit muuttuvat hyväksynnän jälkeen, hyväksynnän on vanhentua.

Jätä itsenäinen tallenne

Auditointitietueen on kerrottava, kuka hyväksyi mitä, milloin ja millä operaatio‑tunnisteella. Sen ei saa perustua pelkkään mallin viestiin “käyttäjä suostui”.

Lisää: AI‑agenttien auditointijäljet

Tarkistuslista yhdelle agentin toiminnolle

Ennen autonomian myöntämistä vastaa:

• Onko toiminto vain luku?
• Muuttaako se liiketoiminnan tilaa?
• Luo se kustannuksia tai sitoumuksia?
• Onko tulos ulkoisesti näkyvä?
• Sisältääkö se henkilökohtaisia tai luottamuksellisia tietoja?
• Muuttaako se rooleja, oikeuksia tai turvallisuusasetuksia?
• Onko se helppo peruuttaa?
• Onko kohde‑resurssi yksiselitteinen?
• Voiko toiminnon yrittää uudelleen kahdesti?
• Voiko järjestelmä näyttää konkreettisen esikatselun ennen suoritusta?
• Onko hyväksyntä sidottu tarkkaan parametreihin?
• Voidaanko lopullinen tila tarkistaa suorituksen jälkeen?

Jos toiminto yhdistää useita korkean riskin ominaisuuksia, yksi “OK” voi olla liian heikko hallintakeino.

Työstetty esimerkki: palveluyritys lähettää asiakasraportin

Käsitellään ehdotettua työnkulkua eikä raportoituja toteutuksia. Agentti hakee hyväksyttyjä tietueita, vertaa määräaikoja ja laatii raportin. Tilin omistaja pysyy vastuussa sisällöstä. Prosessin omistaja määrittelee sallitun datan ja sen, kuka voi valtuuttaa toimituksen.

Luonnoksen valmistelu voi tapahtua ennalta hyväksytyssä rajassa. Ennen lähettämistä näytä asiakas, tarkka vastaanottajan osoite, aihe, viesti ja liitteet sekä lähdedatan versio. Tarkastajan tulee voida tarkastaa asiakirja suoraan. Pelkkä mallin yhteenveto heikentää tarkistusta.

Hyväksyntä kattaa juuri kyseisen paketin. Vastaanottajan lisääminen, liitteen korvaaminen tai merkittävän suosituksen muuttaminen mitätöi sen. Aikaisemmin määritelty sääntö voi sallia oikeinkirjoituksen korjauksen, mutta sen ei tule antaa lupaa muuttaa merkitystä. Prosessin omistaja määrittelee, mitkä muutokset ovat merkittäviä; toteutuskomponentti valvoo rajaa.

Mitä hyväksyntätietueen tulisi sisältää

Liitä hyväksyntä henkilöön, rooliin, tenanttiin, työkaluun, kohde‑resurssiin, dataversioon, parametreihin, voimassaoloaikaan ja tehtävä‑tunnisteeseen. Erota ehdotettu, odottava, hyväksytty, suoritettava ja epävarma tila. Käyttäjän tulee tietää, valmistellaako klikkaus toiminnon vai käynnistääkö sen.

Parametrien hash‑arvo auttaa havaitsemaan korvaamisen. Se ei todista, että henkilö on lukenut esikatselun. Selkeä käyttöliittymä ja valtuutettu tarkastaja ovat edelleen tärkeitä. Henkilö, jolla ei ole oikeutta myöntää järjestelmänvalvojan oikeuksia, ei saa saada niitä agentin hyväksyntäikkunan kautta.

Eräajoissa näytä objektien määrä, merkittävät poikkeukset ja kokonaisvaikutus. Yksi hyväksyntä voi kattaa tarkasti määritellyn erän. Se ei voi kattaa mielivaltaisesti lisättyjä objekteja hyväksynnän jälkeen. Tämä vähentää toistuvia dialogeja menettämättä hallintaa.

Käsittele epävarma suoritus ennen uudelleenyrittämistä

Palveluntarjoaja saattaa suorittaa pyynnön, vaikka sen vastaus ei koskaan saavu agentille. Puuttuva vahvistus ei ole todiste epäonnistumisesta. Uudelleenyrittäminen voi lähettää toisen sähköpostin, luoda kaksoisdokumentin tai aiheuttaa lisäkuluja. Tarkista ensin pyynnön tunniste ja palveluntarjoajan tila.

Jos idempotenssi‑avaimia tuetaan, sidota yksi operaatioon ja käytä sitä uudelleen samassa pyynnössä. Muussa tapauksessa toteuta kaksoiskappaleiden tunnistus tai pyydä operaattoria päättämään tarkistuksen jälkeen. Kirjaa epävarma tulos rehellisesti. Kahdesti klikkaaminen ei ratkaise tuntematonta tulosta.

Hiljaisuus ei ole hyväksyntä

Määritä jokaiselle prosessille varahenkilö ja ilmoituskanava. Vanhentuminen ilman vastausta estää porttitoiminnon. Agentti voi jatkaa muiden valtuutettujen, matalariskisten tehtävien valmistelua; sen ei tule tulkita hiljaisuutta tai liiketoiminnan määräaikaa suostumukseksi.

Määritä hätä‑pysäytys erikseen. Virheellisen työnkulun pysäyttämisen oikeus voi olla kapeampi kuin sen käynnistämisen oikeus. Säilytä suoritustila ja luettelo suoritetuista toiminnoista. Konfiguraation palauttaminen ei voi peruuttaa jo luettua asiakasviestiä.

Tarkista, muuttavatko tarkistukset päätöksiä

Seuraa korjauksia, hylkäyksiä, odotusaikoja ja yrityksiä suorittaa merkittävästi muutettuja parametreja. Vertaa operaatio‑tyyppejä erikseen. Hidas hyväksyntä asiakasviesteille ei saa estää autonomista sisäistä tehtävien valmistelua.

Jos jokainen ehdotus hyväksytään välittömästi viikkojen ajan, tarkista otos prosessin omistajan kanssa. Politiikka voi olla liian laaja, tai esikatselut voivat puuttua olennaisista tiedoista. Korkea hyväksyntämäärä ei ole turvallisuuden todiste.

Huomenna valitse yksi ulkoinen toiminto. Rakenna sen esikatselu, nimeä valtuutettu tarkastaja, määritä voimassaoloaika ja varmista, että vastaanottajan muuttaminen mitätöi hyväksynnän. Vahvista, että hylkäys ei aiheuta ulkoista vaikutusta.

Suosituksia ja lähde­rajoja

OWASP kattaa korkean vaikutuksen toimintojen hallinnan ja hyväksynnän eheyden. Transaktio‑valtuutuksen ohjeistus käsittelee palvelinpuolen tarkistuksia merkittävien transaktiodatan osalta. NIST AI RMF on vapaaehtoinen riskienhallinnan ohjeistus. A–D‑matriisimme on insinöörisuositus, ei oikeudellinen velvoite hyväksyä jokainen AI‑toiminto. Sisäinen Ads MCP -dokumentaatio 28 heinäkuuta 2026 kuvaa viitattua hallintasuunnitelmaa; se ei itsenäisesti todista tuotantokäyttöä asiakkaalle.

Rajaus

Tämä luokittelumalli on insinöörikäytäntö, ei oikeudellinen neuvonta tai virallinen riskianalyysistandardi. Säännellyt, lääketieteelliset, rahoitus‑ tai turvallisuuskriittiset prosessit voivat vaatia tiukempia hallintakeinoja.

Katso myös MCP ja AI‑agentit: turvallisempien työkalujen suunnittelu ja Vähiten oikeudet AI‑agenteille.

Lähteet

• 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.