Ievads

Uzņēmumiem ieviešot arvien vairāk autonomu AI aģentu – no sarunu asistentiem līdz uzdevumu automatizējošiem “robotiem” – rodas jauns izaicinājums: novērojamība. Šie aģenti pieņem vairākus lēmumus, izsauc API, atjaunina kontekstu un pat darbojas lietotāju vārdā. Tomēr tradicionālie uzraudzības rīki nodrošina tikai šauru skatījumu. Praksē komandas bieži paļaujas uz izkaisītiem žurnāliem vai informācijas paneļiem, kas nebija paredzēti aģenta daudzpakāpju spriešanas fiksēšanai. Nesenā Dynatrace aptaujā atklājās, ka puse no AI virzītiem projektiem apstājas pilotposmā, jo organizācijas “nevar pārvaldīt, validēt vai droši mērogot” savus aģentus (www.itpro.com). Līdzīgi, Microsoft drošības vadītāji brīdina, ka mēs “nevaram aizsargāt to, ko neredzam” – uzsverot, ka AI aģentiem ir nepieciešama “novērojamības kontroles plakne”, pieaugot to adopcijai (www.itpro.com) (www.itpro.com). Šajā rakstā mēs aplūkojam uzraudzības nepilnības autonomiem un pusautonomiem aģentiem (īpaši attiecībā uz rīku lietošanu, atmiņu un lēmumu pieņemšanas ceļiem). Pēc tam mēs piedāvājam specializētu novērojamības un kontroles platformu, kas fiksē pilnīgas izsekošanas, nodrošina politiku izpildi, simulē darbplūsmas un var atsaukt nedrošas darbības. Mēs salīdzinām šo pieeju ar tradicionālajiem APM (lietojumprogrammu veiktspējas uzraudzības) rīkiem, izskaidrojam, kāpēc aģentam specifiska telemetrija ir kritiski svarīga, un izklāstām cenu/integrācijas modeli (piemēram, maksājumus par aģenta minūti ar PagerDuty/Jira integrācijām).

AI aģentu uzraudzības nepilnības

AI aģenti nav tikai vienkārši API izsaukumi; tie ir daudzpakāpju darbplūsmas, kas plāno, iegūst informāciju, izsauc rīkus un sintezē rezultātus neskaidrības apstākļos (www.stackai.com). Šī sarežģītība rada aklos punktus parastajai uzraudzībai:

• Fragmentēta telemetrija: Vairumā vides telemetrija ir nodalīta. Viena sistēma reģistrē gala punkta notikumus, cita rāda tīkla trafiku, trešā satur autentifikācijas datus. TechRadar atzīmē, ka “lielākā daļa AI aģentu paļaujas uz tām pašām fragmentētajām telemetrijas sistēmām, ar kurām analītiķi ir cīnījušies gadiem ilgi” (www.techradar.com). Nesalīdzinot šos signālus, aģentam trūkst konteksta, lai pareizi spriestu. Piemēram, AI var aizdomāties par konta kompromitēšanu tikai tad, ja tas redz gan neparastu pieteikšanos (no žurnāliem), gan aizdomīgu tīkla modeli – bet, ja šie signāli atrodas dažādos rīkos, aģents “vienkārši nezina pietiekami daudz” (www.techradar.com) (www.techradar.com). Īsumā, fragmentēti dati rada redzamības trūkumu: aģenti rīkojas, pamatojoties uz nepilnīgu informāciju, kas noved pie klusām kļūdām (nepareizām darbībām, kas paliek neatklātas).

• Aklie punkti rīku izsaukumos: Aģenti bieži izsauc ārējos rīkus vai API (piemēram, datubāzes, zināšanu bāzes, tīmekļa pakalpojumus). Tradicionālā uzraudzība varētu reģistrēt tikai to, ka noticis HTTP pieprasījums, taču aģentiem pielāgotai novērojamībai ir jāreģistrē kurš rīks tika izvēlēts un kāpēc. Novērojamības platformai ir jāfiksē precīzs pieprasījums vai konteksts, kas noveda pie šīs rīka izvēles, nodotie argumenti un pilnīga izvade vai kļūdas atbilde (www.braintrust.dev). Bez tā aģents varētu ievadīt nepareizus parametrus vai nepareizi interpretēt rīka atbildi, un problēma paliktu slēpta. Piemēram, Braintrust novērojamības rokasgrāmatā uzsvērts, ka katrs rīka izsaukums ir jāizseko ar tā ievadi un izvadi, lai inženieri varētu “atklāt halucinētus parametrus, trūkstošos laukus vai nepareizu formatējumu” (www.braintrust.dev).

• Nepārredzamas atmiņas operācijas: Daudzi aģenti izmanto atmiņas vai datu iegūšanas sistēmas (piemēram, lietotāja profilu, RAG zināšanu krātuvi). Šis dinamiskais konteksts var izraisīt kļūdas, kuras nav iespējams noteikt bez reģistrēšanas, “ko aģents lasa un raksta” (www.braintrust.dev). Piemēram, ja aģents iegūst novecojušu atmiņas ierakstu vai nepareiza lietotāja datus, atbilde var klusi kļūt nepareiza. Novērojamībai ir jāreģistrē iegūšanas vaicājumi, atgrieztie vienumi, atbilstības rādītāji un aktualitātes metadati, lai nepareizu izvadi varētu izsekot līdz novecojušai vai nepareizi mērķētai atmiņas lasīšanai (www.braintrust.dev). Līdzīgi, katrai atmiņas rakstīšanas darbībai ir jābūt reģistrētai (kas tika saglabāts, ar kādu atslēgu), lai atklātu kumulatīvas kļūdas vai datu noplūdes (piemēram, viena lietotāja informācija parādās cita sesijā) (www.braintrust.dev).

• Neredzamas lēmumu trajektorijas: Atšķirībā no tīmekļa pieprasījuma ar skaidru “ievadi kodu, saņem atbildi” plūsmu, aģenti parasti izpilda plāno-darbojies-novēro ciklu. Tie ģenerē plānu, veic darbību (piemēram, “meklēt zināšanu bāzē”), novēro rezultātu un pēc tam nolemj pārplānot vai turpināt. Vienkārši žurnāli nevar atklāt šo zarojošo ceļu. Novērojamība prasa katra soļa fiksēšanu secīgi, ar aģenta “iemeslu” katrai darbībai. Bez tā mēs varētu redzēt tikai galīgo rezultātu un domāt, ka viss ir kārtībā – pat ja aģents pusceļā novirzījās no uzdevuma vai iestrēga. Piemēram, Braintrust izceļ “plāna novirzi” (aģents klusi maina mērķus) un “bezgalīgas cilpas” kā kļūdu veidus, ko var atklāt tikai soļu līmeņa izsekošana (www.braintrust.dev). Pareiza izsekošana reģistrē katru apakš-aģenta izsaukumu, zarojošo lēmumu un cilpas ilgumu, skaidri parādot, vai aģents atbildēja uz nepareizu jautājumu vai atkārtoja soļus bez progresa.

• Klusas kvalitātes kļūmes: Daudzas aģenta kļūmes neizraisa HTTP kļūdas vai avārijas. Tā vietā aģents var halucinēt datus, pārkāpt lietotāja norādījumus vai novirzīties no politikas. Parastie monitori (piemēram, Datadog vai New Relic) pārbauda tikai latentumu vai kļūdu rādītājus (www.techradar.com)), tāpēc sistēma ziņotu “viss ir zaļš”, pat ja atbilde būtu faktiski nepareiza. StackAI skaidro, ka tradicionālie APM rīki pieņem deterministisku programmatūru – taču aģenti pārkāpj šos noteikumus (www.stackai.com). Piemēram, uzvednes maiņa vai modeļa jaunināšana varētu smalki pazemināt atbildes kvalitāti, neizraisot acīmredzamu brīdinājumu (www.stackai.com). Tāpēc novērojamībai ir jāiekļauj semantiskās pārbaudes: piemēram, halucināciju rādītāju vai politikas pārkāpumu incidentu izsekošana. Rezumējot, parastie monitori parāda, ka aģents atbildēja laikā, bet tikai aģentam specifiska telemetrija var parādīt, vai atbilde bija pareiza, atbilstoša vai droša.

• Pārvaldības un drošības riski: AI aģenti ievieš jaunus atbilstības izaicinājumus (uzvedņu injekcijas, privātuma noplūdes, neatļautas darbības). Bez pielāgotas telemetrijas šie riski ir neredzami. StackAI atzīmē, ka novērojamība un pārvaldība saplūst: “jūs nevarat nodrošināt politikas izpildi, ja to nevarat atklāt” (www.stackai.com). Piemēram, ja klientu atbalsta režīmā esošs aģents sāktu nopludināt personas datus, tikai detalizēti izsekošanas žurnāli varētu atklāt pārkāpuma avotu. Tāpēc mūsu platformai ir jāuzrauga politikas pārkāpumi reāllaikā (piemēram, PII atzīmēšana izvades datos, neatļautu API izsaukumu bloķēšana) un jānodrošina audita pēdas atbilstībai.

Rezumējot, esošās APM un žurnālu sistēmas vienkārši neuztver, kā AI aģents domā: domu ķēdi, zarojošo loģiku un dinamisko kontekstu. Tas noved pie aklajiem punktiem rīku izsaukumos, atmiņas lietojumā un lēmumu pieņemšanas trajektorijās. Neizlabojot šīs nepilnības, uzņēmumi riskē ar klusām aģentu kļūmēm, drošības pārkāpumiem un uzticības zaudēšanu.

AI aģentu novērojamības un kontroles platformas izveide

Lai aizpildītu šīs nepilnības, mēs piedāvājam specializētu AI aģentu novērojamības un kontroles platformu. Šis pakalpojums nodrošinātu aģentu instrumentāciju no sākuma līdz beigām, nodrošinātu pārvaldību un atļautu drošu eksperimentēšanu. Galvenās funkcijas ietver:

Pilnīga izsekošana un žurnālēšana

Katrā aģenta izpildē ir jārada izsekošanas ieraksts, kas reģistrē pilnu izpildes grafiku. Iedvesmojoties no sadalīto sistēmu prakses, katra aģenta darbplūsma ir izsekošanas ieraksts, un katra darbība (LLM uzvedne, rīka izsaukums, atmiņas vaicājums, apakš-aģenta nodošana) ir posms šajā izsekošanas ierakstā (www.stackai.com) (www.braintrust.dev). Tas nozīmē, ka inženieris var redzēt precīzu secību: kādu uzvedni aģents redzēja, kā tas sadalīja uzdevumu soļos un ko katrs rīks atgrieza. Piemēram, ja aģents vaicā dokumentu krātuvei, izsekošanas ieraksts reģistrē vaicājumu un iegūto saturu; ja tas pēc tam pārformulē vaicājumu, tas ir jauns posms. Sesijas identifikatori saista vairāku pagriezienu sarunas vai ilgstošus uzdevumus. Izmantojot standarta protokolus, piemēram, OpenTelemetry, šie izsekošanas dati var ieplūst esošajos APM aizmugursistēmās. Kā norādīts vienā ceļvedī, “šīs primitīvās funkcijas arvien labāk sader ar esošajiem novērojamības modeļiem” (www.stackai.com). Praksē tas ļauj korelēt aģenta uzvedību ar pamatā esošo infrastruktūru: CPU pīķus, tīkla I/O vai datubāzes izsaukumus var aplūkot kopā ar aģenta spriešanas soļiem.

Tā vietā, lai reģistrētu neapstrādātu tekstu brīvā formā, platforma glabā strukturētus posmus. Piemēram, posms varētu reģistrēt: Rīks: emailSender, Ievade: JSON datu bloks, Izvade: panākumi vai kļūda, Latentums: 200ms. Ieliekot posmus (piemēram, rīku izsaukumus zem vecāka LLM izsaukuma), inženieri var iedziļināties, kur tika tērēts laiks vai kurš solis izraisīja kļūmi. Svarīgi ir tas, ka visas lietotāja ievades, sistēmas instrukcijas un atmiņas lasījumi kļūst par izsekošanas datiem. Šī strukturētā žurnālēšana aizstāj nogurdinošo “printēšanas atkļūdošanu” un ļauj meklēt un filtrēt žurnālus (piemēram, parādīt visus izpildes gadījumus, kuros aģents izmantoja rīku financialAPI).

Reāllaika politikas izpilde

Platforma darbojas arī kā kontroles plakne pārvaldībai. Tā nepārtraukti pārbauda aģenta telemetriju, salīdzinot to ar drošības un biznesa politikām. Piemēram, ja aģents mēģina izpildīt neatļautu darbplūsmu (piemēram, piekļūt personāla algām, kad tam nevajadzētu), politikas dzinējs var nekavējoties iejaukties. Noteikumus var definēt uz izsekošanas datiem: piemēram, “Brīdināt, ja izvade satur kredītkartes numuru modeļus” vai “Bloķēt jebkuru datubāzes ierakstu ārpus klientu atbalsta darba laika no 9:00 līdz 17:00”. Tā kā “jūs nevarat nodrošināt politikas izpildi, ja to nevarat atklāt” (www.stackai.com), šie novērojamības dati padara izpildi iespējamu. Praksē pārkāpumi var izraisīt automatizētu ierobežošanu: platforma var apturēt aģentu, eskalēt brīdinājumu vai atsaukt visas tā veiktās izmaiņas. Iebūvēts “aģenta apturēšanas slēdzis” ļauj administratoriem apturēt vai ierobežot nepareizi funkcionējošus aģentus (atkārtojot padomu, ka vadībai jāzina “Kas ir apturēšanas slēdzis?” (www.techradar.com)). Piemēram, ja ļaunprātīgas programmatūras skenera aģents kļūst nekontrolējams, tiklīdz telemetrija atzīmē anomālo uzvedību, sistēma var nekavējoties izolēt tā atļaujas un brīdināt dežurējošo inženieri.

Politikas izpilde attiecas arī uz privātuma un drošības pārbaudēm. Sistēma varētu palaist automatizētus PII detektorus visos izejošajos ziņojumos vai izmantot “LLM kā tiesneša” moduli, lai meklētu halucinācijas vai politikas novirzes. Jebkurš drošības pārkāpums tiek reģistrēts kā incidents. Iekļaujot šīs pārbaudes novērojamības slānī, uzņēmumi papildus veiktspējas metrikai iegūst arī reāllaika drošības informācijas paneli.

Bezsaistes simulācija un “smilškastes” testēšana

Pirms jebkādu nozīmīgu izmaiņu ieviešanas ir vērts simulēt scenārijus. Mūsu platforma ietver smilškastes vidi, lai atkārtoti atskaņotu vai imitētu aģentu darbplūsmas. Komandas var aģentam piešķirt testu gadījumu kopumu (atspoguļojot biežus lietotāju pieprasījumus vai robežgadījumus) un vākt izsekošanas žurnālus izmēģinājuma veidā. Šī bezsaistes novērtēšana nodrošina, ka jaunas uzvednes vai modeļu jauninājumi nepārkāpj politikas vai nesamazina kvalitāti (www.braintrust.dev). Piemēram, pirms finanšu aģentam piešķirt jaunas API privilēģijas, inženieri varētu simulēt mēneša beigu slēgšanas uzdevumus, lai pārliecinātos, ka tas ievēro apstiprināšanas plūsmas. Sistēma var arī atklāt regresijas: ja atjaunināta aģenta versija pēkšņi nepareizi konfigurē rīkus, testu izsekošanas ieraksti atklāj kļūdu, pirms tā nonāk ražošanā.

Būtībā tas ir kā haosa inženierija AI jomā: apzināta aģenta pakļaušana draudu scenārijiem vai nepareiziem datiem, lai redzētu, vai tas nenovirzās no kursa. TechRadar iesaka uzņēmumiem “novērtēt gatavību ar smilškastes novērtējumiem… lai lēmumu pieņemšana tiktu pārbaudīta un atgūšanas laiki būtu saprotami” (www.techradar.com). Platforma var automatizēt šīs pārbaudes pēc grafika, reģistrējot katru izpildi. Tas palīdz savlaicīgi atklāt slēptās kļūmes (piemēram, novecojušu konteksta indeksēšanu). Integrējot novērtēšanu izstrādes plūsmā, komandas panāk atgriezenisko saiti: ražošanas kļūdas kļūst par jauniem testu gadījumiem, un katrai laidienu versijai ir jāiziet bezsaistes pārbaude.

Izpildes kontrole un atcelšana

Pat ar profilaksi var rasties kļūdas. Mūsu platforma nodrošina labošanas rīkus. Pirmkārt, reāllaika “apturēšanas” komanda var nekavējoties apturēt aģenta darbības. Ilgstošiem vai asinhroniem uzdevumiem sistēma var izsaukt atcelšanas punktus, ja tiek pārkāpta politika (piemēram, pārtraukt darījumu, ja aģents mēģina izņemt līdzekļus bez apstiprinājuma). Otrkārt, tā kā visas darbības tiek izsekotas, platforma var atkārtot vai atcelt efektus. Piemēram, ja aģents kļūdaini nosūtīja e-pastu klientiem vai atjaunināja CRM, operatori var izmantot žurnālus, lai rekonstruētu stāvokli pirms izmaiņām. Kombinācijā ar nemainīgiem audita žurnāliem tas ļauj atsaukt datubāzes transakcijas vai failu sistēmas izmaiņas, ko veicis aģents. TechRadar uzsver šī nepieciešamību: “organizācijām ir jāpārvērtē… atcelšanas ceļi katrā AI ieviešanā” (www.techradar.com). Praksē platforma varētu saglabāt stāvokli pirms izpildes vai integrēties ar versiju datu krātuvēm, nodrošinot, ka neveiksmīgas aģenta darbības var atcelt kā kļūdainu programmatūras izvietošanu.

Integrācija ar incidentu reaģēšanu un biļešu sistēmām

Novērojamība ir tikai puse no cīņas; inženieri ir efektīvi jābrīdina. Platforma tiks integrēta ar moderniem incidentu pārvaldības un sadarbības rīkiem. Piemēram, tā var nosūtīt kritiskus aģenta brīdinājumus uz PagerDuty, izveidojot dežurējoša personāla incidentu, kad notiek nopietns politikas pārkāpums. Tā var publicēt kopsavilkumus Slack vai Microsoft Teams kanālos (PagerDuty atzīmē, ka viņu pašu sistēmai ir “uzlabotas Slack un Microsoft Teams integrācijas”, lai reaģētāji saglabātu fokusu (www.pagerduty.com))). Integrācija ar biļešu sistēmām ir arī būtiska: kad tiek aktivizēts brīdinājums, platforma var automātiski izveidot Jira vai ServiceNow biļeti, kas iepriekš aizpildīta ar izsekošanas ID, skarto sarunu un politikas detaļām. Tas nodrošina, ka aģenta incidenti nonāk tajās pašās triāžas darbplūsmās kā citi pārtraukumi. PagerDuty arī izceļ savas vairāk nekā 700 rīku integrācijas (Datadog, Grafana utt.), lai sasaistītu novērojamību un reaģēšanu (www.pagerduty.com). Līdzīgi, mūsu platforma piedāvātu savienotājus ar žurnāliem (piemēram, Splunk), metriku (Prometheus) un CI/CD sistēmām, lai katrs telemetrijas elements iekļautos esošajos informācijas paneļos un diagrammās.

Tradicionālā APM pret aģenta telemetriju

Kā tas salīdzināms ar mantoto Lietojumprogrammu veiktspējas uzraudzības (APM) risinājumu? Īsumā, tradicionālā APM (Datadog, New Relic, Dynatrace utt.) izceļas ar infrastruktūras un koda līmeņa metriku, taču tā uz aģentiem skatās kā uz melnajām kastēm. Piemēram, Datadog var “automātiski ievadīt, parsēt un analizēt žurnālus no visas jūsu sistēmas” un tā APM modulis “izseko pieprasījumus sadalītajās sistēmās” (www.techradar.com)). Līdzīgi, tā tīkla uzraudzība sniedz vispārēju pārskatu par serveriem, CPU, atmiņu un tīkla plūsmām (www.techradar.com). Šie rīki brīdinās, ja aģents patērē pārāk daudz CPU vai izmet izņēmumu. Bet neviens no tiem neuztver, ko aģents domā. Tie nereģistrēs faktisko uzvednes tekstu (privātuma noteikumu dēļ) vai LLM izsaukumu secību. Tie nezinās, vai tā radītā atbilde balstījās uz nepareizu atmiņu vai vai tā pārkāpa kādu biznesa noteikumu. No viņu viedokļa “viss izskatās zaļš”, kad API izsaukums atgriež 200 OK (www.stackai.com).

Praksē varētu mēģināt pielāgot APM aģentiem (piemēram, marķējot katru tērzēšanas pieprasījumu un meklējot žurnālos). Bet bez aģentam specifiskiem posmiem nepilnības saglabājas. APM pieņem deterministiskas darbplūsmas: kļūmes gadījumā mēs atkļūdojam koda ceļus. Taču ar AI aģentiem kļūmes ir klusās (nepareiza atbilde) vai semantiskās (politikas pārkāpums), nevis izņēmumu mešana. StackAI novēro, ka aģenti “pārkāpj daudzus [APM] pieņēmumus” – piemēram, aģentam nav kļūdas koda, ja tas vienkārši halucinē (www.stackai.com). Turklāt daudzpakāpju aģentu ķēdes aptver daudzas komponentes (modeļus, indeksus, rīkus); ja jūs uzraugāt tikai galīgo tīmekļa pieprasījumu, jūs zaudējat visu kontekstu par to, kā aģents tur nonāca. Visbeidzot, APM rīki parasti ignorē AI specifiskās izmaksas (piemēram, marķieru lietojumu) un kvalitātes signālus.

Šo iemeslu dēļ uzņēmumi, kas veido aģentu sistēmas, arvien vairāk saskata vajadzību pēc specializētas telemetrijas. Kā ziņoja Dynatrace, “Novērojamība… ir būtiska veiksmīgas aģentu AI stratēģijas sastāvdaļa. Komandām ir nepieciešama reāllaika redzamība par to, kā AI aģenti uzvedas, mijiedarbojas un pieņem lēmumus” (www.itpro.com). Piedāvātā platforma nodrošina tieši to slāņveida skatu, ko APM rīki nevar: no augsta līmeņa veselības metrikas līdz aģenta kognitīvajiem soļiem. Būtībā tas paplašina APM zelta signālus (latentums, kļūda, caurlaidība) ar aģentam specifiskiem kvalitātes rādītājiem (pamatotība, pabeigšanas rādītājs, halucināciju biežums) (www.stackai.com) (www.stackai.com).

Cenu modelis

Vienkāršs cenu modelis ir uz lietošanu balstīts. Viena pieeja ir iekasēt maksu par aģenta minūti (laiku, ko aģents aktīvi veic uzdevumus). Piemēram, pakalpojuma cena varētu būt aptuveni $0.05–$0.10 par aģenta minūti, līdzīgi kā mākoņu funkciju rēķini. Tas sedz izsekošanas/posmu datu fiksēšanas un glabāšanas, novērtēšanas pārbaužu veikšanas un žurnālu glabāšanas izmaksas. (Var būt pamata ikmēneša maksa par piekļuvi platformai plus maksa par pārtēriņu.) Papildu datu glabāšana vai žurnālu apjoms varētu tikt rēķināts par GB. Apjoma atlaides vai korporatīvie plāni varētu piedāvāt zemākas likmes par minūti lielām izvietošanām. Tas saskaņo izmaksas ar patēriņu: sporādiski aktīvs robots rada minimālas izmaksas, līdz tas darbojas. Kontekstam, daudzi uzraudzības un bezserveru produkti izmanto detalizētu lietošanas cenu. Mūsu “aģenta minūtes” metrika ir analoga – lietotāji precīzi zina, cik viņi maksā par katru aģenta darbības stundu, veicinot efektīvu lietošanu.

Secinājums

Autonomie AI aģenti sola ievērojamus produktivitātes ieguvumus, bet tikai tad, ja mēs varam redzēt un kontrolēt to darbības. Jaunā AI novērojamības joma risina tieši to: padarīt aģentu “domāšanas procesus” pārredzamus un pārvaldāmus. Instrumentējot rīku izsaukumus, atmiņas piekļuves un lēmumu pieņemšanas soļus kā izsekošanas ierakstus, mēs iegūstam ieskatu neskaidrās kļūmēs un pārvaldības nepilnībās. Speciāli izstrādāta uzraudzības platforma (ar politikas izpildi, simulāciju, atcelšanas iespējām un incidentu reaģēšanas integrāciju) nodrošina, ka aģenti droši darbojas ražošanā. Atšķirībā no mantotajiem APM rīkiem, aģentam specifiska telemetrija uzskata pašu AI sistēmu par pilnvērtīgu pilsoni, nevis tikai tās serverus.

Kā brīdina aptaujas un eksperti, novērojamības trūkums ir šķērslis aģentu AI mērogošanai (www.itpro.com) (www.itpro.com). Izveidojot šeit aprakstīto jauno uzraudzības sistēmu, organizācijas var pārvērst “cerīgu minēšanu” par uzticamu automatizāciju (www.techradar.com). Galvenokārt, šāda pieeja veido uzticību, ka aģenti darbosies, kā paredzēts, un ļauj inovatīvi darboties ar pārliecību. Ja kaut kas noiet greizi, tas vairs nebūs noslēpumains pārkāpums vai halucinācija – izsekošanas žurnāli un kontroles plakne precīzi norādīs kļūmes veidu, nodrošinot ātru mazināšanu un mācīšanos. Autonomo aģentu laikmetā novērojamība nav izvēles iespēja; tā ir drošas, mērogojamas AI pašos pamatos.