Cine deține decizia când un agent deleagă?
Predarea unei sarcini nu golește scaunul
Un agent delegă o sarcină. Un alt agent adună materiale, compară înregistrări, apelează un instrument sau pregătește o recomandare. Un al treilea agent verifică rezultatul. Munca se mută dintr-un loc în altul, iar această mișcare poate fi utilă. Poate crea însă și o problemă de management foarte veche, într-o formă nouă: toată lumea a făcut ceva, dar nimeni nu poate spune cine avea dreptul să ia decizia.
Răspunsul tentant este agentul care a făcut ultimul apel. Este însă, de obicei, și cel mai puțin util răspuns. O componentă software poate selecta o rută, poate cere mai multă muncă și poate trimite o instrucțiune către un sistem conectat. Niciuna dintre aceste acțiuni nu stabilește cine a acceptat scopul, cine a stabilit limitele, cine ar fi putut refuza acțiunea sau cine trebuia anunțat când s-au schimbat condițiile. Stabilește doar că un program a făcut parte din lanț.
Această distincție devine clară atunci când un flux de lucru are consecințe. Un răspuns sugerat poate deveni o comunicare cu clientul. O clasificare poate deveni motivul pentru care un caz este plasat într-o anumită coadă. O comparație poate deveni o recomandare de cumpărare. O instrucțiune de plată redactată poate deveni o plată. Fiecare pas poate fi competent din punct de vedere tehnic și totuși incomplet din punct de vedere organizațional. Sistemul a făcut munca delegării fără să facă munca autorității.
Nu este nevoie să inventăm un eșec dramatic pentru a vedea problema. Să luăm un flux de lucru deliberat ipotetic. Un agent de triaj primește o întrebare, cere unui agent de cercetare să inspecteze materialul relevant, trimite rezultatul unui recenzor și apoi pregătește o acțiune pentru un sistem de gestionare a cazurilor. Agentul de cercetare nu este autorizat să acționeze. Recenzorul nu este autorizat să facă efectiv rezultatul cazului. Agentul de triaj are o acreditare de instrument. Organizația nu a specificat dacă acea acreditare îi permite să angajeze rezultatul. Fluxul de lucru poate părea ordonat pe un tablou de bord. A ajuns totuși la cea mai importantă întrebare fără răspuns.
Delegarea nu înseamnă dispariția responsabilității. Este responsabilitate făcută mai greu de văzut. Un design operațional bun o face din nou mai ușor de văzut. Spune care este decizia inițială, ce poate fi delegat, ce condiții călătoresc cu sarcina, cine poate aproba o acțiune ireversibilă sau cu consecințe, ce înregistrare rămâne după predare și cum poate o persoană sau un sistem să intervină atunci când ruta nu mai este sigură. Tehnologia nu este rugată să posede agenție morală. Este rugată să lase agenția organizației intactă.
Acesta este sensul practic al responsabilității într-un flux de lucru cu mai mulți agenți. Nu este o linie decorativă într-o politică și nu este o vânătoare retrospectivă a celui mai apropiat angajat atunci când ceva merge prost. Este o proprietate a rutei înainte ca munca să înceapă. Persoana potrivită poate inspecta ce a fost propus, poate înțelege de ce a fost propus, poate exercita autoritatea care i-a fost atribuită și poate lăsa în urmă o înregistrare care poate fi contestată ulterior.
Regulile emergente ale Europei privind IA sunt utile aici, pentru că sunt mai puțin interesate de un om teatral la capătul unui flux decât de condițiile în care supravegherea poate funcționa efectiv. Prevederile privind supravegherea umană din AI Act se aplică sistemelor cu risc ridicat, nu fiecărei utilizări a unui agent. Această limită contează. Dar întrebările operaționale din act se transferă bine: poate o persoană fizică desemnată să înțeleagă capacitățile și limitele relevante, să monitorizeze anomalii și performanțe neașteptate, să evite dependența excesivă, să interpreteze rezultatul, să îl ignore sau să îl inverseze și să întrerupă sistemul într-o stare sigură? Un flux de lucru cu mulți agenți nu face aceste întrebări mai mici. Multiplică locurile în care răspunsul se poate pierde.
Delegarea este un lanț, nu o ceață
Oamenii deleagă constant. Un manager îi cere unui coleg să pregătească o notă. O echipă de achiziții îi cere unui expert să verifice o clauză contractuală. Un clinician cere unui laborator un rezultat. Persoana care primește sarcina capătă un rol definit în lucrare; nu moștenește automat toată autoritatea deținută de cel care a cerut. Organizațiile bune fac această distincție banală prin fișe de post, limite de aprobare, proceduri, separarea sarcinilor și evidențe. O fac pentru că abilitatea și permisiunea sunt lucruri diferite.
Sistemele de agenți tind să estompeze această distincție, pentru că un agent poate descrie, planifica și executa într-o singură suprafață conversațională. Un model poate fi capabil să genereze un plan convingător pentru a contacta un furnizor. Un wrapper de instrumente poate fi tehnic capabil să trimită mesajul. Un strat de orchestrare poate fi capabil să apeleze acel wrapper fără pauză. Aceste fapte descriu abilitatea. Nu decid dacă mesajul ar trebui trimis, dacă destinatarul propus este în domeniul de aplicare, dacă informația este adecvată pentru divulgare sau cine ar trebui să accepte consecința dacă acțiunea propusă este greșită.
Ajută să separăm cinci întrebări care sunt adesea împachetate împreună. Cine a dat sarcinii scopul ei? Cine poate efectua munca pregătitoare? Cine poate delega o subsarcină? Cine poate decide că o acțiune propusă este acceptabilă? Cine poate face acea acțiune efectivă în lumea exterioară? Uneori un singur rol uman deține în mod legitim mai multe dintre aceste răspunsuri. Uneori ele trebuie separate. Ideea nu este să creăm o ceremonie elaborată pentru o notă cu risc scăzut. Ideea este să evităm tratarea tăcută a unei abilități tehnice ca pe un transfer de autoritate instituțională.
O delegare ar trebui, așadar, să poarte mai mult decât o instrucțiune. Ar trebui să poarte un mandat. Mandatul identifică obiectivul, contextul delimitat, intrările permise, rezultatul așteptat, acțiunile care rămân interzise, bugetul sau limita de timp acolo unde este relevant, condițiile care impun escaladarea și persoana sau rolul responsabil pentru rezultat. Agentul care primește poate face apoi muncă utilă într-un plic vizibil. Poate cere altui agent o analiză. Nu poate extinde plicul doar pentru că un pas următor plauzibil îi vine în minte.
Acesta nu este un argument pentru a transforma fiecare interacțiune într-o ședință de aprobare. Este un argument pentru alegerea punctului în care organizația dorește ca o decizie să aibă loc. Un sistem poate redacta o explicație fără ca un om să privească fiecare propoziție atunci când scopul, publicul, limita sursei și regulile de publicare sunt deja fixate. Un sistem nu ar trebui să dobândească puterea de a schimba dreptul unui client doar pentru că aceeași componentă are acces la baza de date relevantă. Diferența este consecința, nu inteligența modelului.
Consecința respectivă este adesea distribuită. O sarcină poate fi inofensivă la o etapă și cu consecințe la următoarea. Citirea unui fișier poate fi o rutină. Combinarea lui cu o altă sursă poate schimba sensibilitatea materialului. Pregătirea unei recomandări poate fi o rutină. Apăsarea unui buton care creează un rezultat juridic, financiar sau de serviciu poate să nu fie. Un design de guvernanță care întreabă doar dacă un agent este autonom ratează această schimbare de stare. Întrebarea utilă este mai restrânsă: autonom pentru ce, pentru cine, în ce condiții și cu a cui autoritate?
Există un instinct olandez modest care merită păstrat aici. Dacă un proces are nevoie de o duzină de semnături, ștampile și o organigramă laminată pentru a stabili cine poate apăsa un buton, poate că nu este un triumf al guvernanței. Dar aranjamentul opus, în care o acreditare de instrument este tratată ca o soluție constituțională, nu este nici el un triumf. Scopul este o cale proporționată care face clară autoritatea cu consecințe, fără a monta o mică operă în jurul fiecărei acțiuni de rutină.
Supravegherea europeană este o cerință operațională
Regulamentul privind IA oferă cea mai clară expresie juridică a acestei idei pentru sistemele de IA cu risc ridicat. Articolul 14 impune ca acestea să fie proiectate și dezvoltate astfel încât persoanele fizice să le poată supraveghea eficient în timpul utilizării. Scopul declarat este de a preveni sau minimiza riscurile pentru sănătate, siguranță și drepturile fundamentale, acolo unde aceste riscuri pot rămâne în ciuda altor cerințe. Măsurile trebuie să fie proporționale cu riscul, autonomia și contextul de utilizare. Acesta este un standard deliberat operațional. Nu spune că o persoană din organizație este, în general, interesată de IA.
Dispoziția merge mai departe decât o instrucțiune generică de a menține un om în circuit. În funcție de ceea ce este adecvat și proporțional, persoana desemnată pentru supraveghere trebuie să fie capabilă să înțeleagă capacitățile și limitările relevante, să monitorizeze funcționarea și să detecteze anomalii, disfuncționalități sau performanțe neașteptate, să rămână conștientă de părtinirea de automatizare, să interpreteze rezultatele, să decidă să nu folosească un rezultat sau să îl ignore, să îl anuleze sau să îl inverseze și să intervină sau să întrerupă sistemul într-o stare sigură. Legea nu transformă acestea într-o listă universală de verificare pentru fiecare sistem de agenți. Dar arată de ce o ștampilă de aprobare la finalul procesului este un model slab de supraveghere.
Acum adăugați delegarea. Dacă un agent înmânează o sarcină altui agent, rolul de supraveghere trebuie să poată vedea mai mult decât fraza finală produsă de ultimul model. Are nevoie de suficient context pentru a înțelege care agent a propus subsarcina, ce surse sau instrumente au fost folosite, dacă a fost întâlnită o limită de politică, dacă un rezultat a fost modificat de un recenzent și dacă un agent ulterior a extins domeniul de aplicare. În caz contrar, omul poate vedea un rezultat, dar nu și traseul care l-a produs. Acest lucru poate fi suficient pentru o schiță cu consecințe reduse. Nu este o bază convingătoare pentru acceptarea unei decizii cu consecințe.
Articolul 26 face punctul organizațional și mai clar pentru furnizorii de sisteme cu risc ridicat. Acesta prevede că furnizorii trebuie să atribuie supravegherea umană unor persoane fizice cu competența, pregătirea, autoritatea și sprijinul necesare. Aceste cuvinte aparțin împreună. Competența fără autoritate creează un spectator bine informat. Autoritatea fără competență creează un proprietar formal care nu poate contesta sistemul. Ambele fără sprijin creează o persoană de la care se așteaptă să intervină într-un proces pe care nu îl poate vedea, într-un ritm pe care nu îl poate atinge, folosind informații pe care nu le poate interpreta.
În cazul activității multi-agent, suportul include forma interfeței și a înregistrării. Un operator nu are nevoie de fiecare token generat de un model sau de fiecare reîncercare internă. Are nevoie de acțiunea propusă, de scopul denumit, de dovezile materiale, de politica și limita aplicabile, de modificările făcute de la ultimul punct de revizuire, de efectul preconizat, de posibila cale de revenire și de motivul pentru care cazul a fost escaladat. Aceasta este mai puțin o chestiune de a face un tablou de bord să pară liniștitor și mai mult de a reduce șansa ca o persoană să aprobe un răspuns pentru că sistemul a făcut alternativa obositoare de găsit.
Convenția-cadru a Consiliului Europei privind inteligența artificială și drepturile omului, democrația și statul de drept stabilește legătura instituțională mai largă. Scopul său este de a asigura că activitățile din ciclul de viață al sistemelor de IA sunt conforme cu drepturile omului, democrația și statul de drept. Articolele 8 și 9 cer transparență și supraveghere adaptate contextelor și riscurilor specifice, precum și responsabilitate și răspundere pentru efectele negative. Convenția nu prescrie un model de orchestrare a agenților. Ea oferă totuși o corecție utilă ideii că un lanț de componente software poate dizolva responsabilitățile autorității publice sau ale actorului privat care îl utilizează.
Această perspectivă mai largă contează pentru că o decizie delegată poate afecta mai mult decât performanța tehnică. Poate afecta capacitatea unei persoane de a înțelege o decizie, de a o contesta, de a obține o cale de atac sau pur și simplu de a ști care organizație este responsabilă. Un flux de lucru poate fi alcătuit din componente de la mai mulți furnizori, modele de la mai mulți furnizori, instrumente operate de o altă echipă și un serviciu livrat în cadrul unui contract public. Faptul că lanțul este distribuit tehnic nu face impactul asupra individului mai puțin real. În practică, face o alocare clară a rolurilor și mai importantă.
Protecția datelor oferă același avertisment dintr-o direcție diferită. Lucrările Comitetului European pentru Protecția Datelor privind modelele de IA subliniază că analiza de protecție a datelor rămâne contextuală: organizațiile trebuie să își determine rolul, să identifice prelucrarea implicată și să aplice obligațiile relevante, mai degrabă decât să trateze eticheta de model de IA ca pe o scutire de la responsabilitatea obișnuită. Când un flux de lucru multi-agent atinge date personale, delegarea nu ar trebui să ascundă cine determină scopurile și mijloacele prelucrării, ce agent sau instrument primește ce date și dacă următorul transfer este necesar pentru sarcină. O sub-sarcină este tot un pas de prelucrare. A o numi delegare nu o face să dispară.
Nimic din toate acestea nu produce un răspuns magic pentru fiecare caz dificil. Obligațiile legale depind de utilizare, de actori, de date și de sector. Un articol nu poate clasifica un anumit sistem. Dar poate enunța un principiu disciplinat: dacă un flux de lucru distribuie munca, ar trebui să o distribuie într-un mod care păstrează capacitatea de a identifica autoritatea, de a interveni la timp, de a explica traseul și de a răspunde persoanelor afectate de rezultat.
Persoana din buclă are nevoie de o buclă reală
Supravegherea umană este ușor redusă la un ecran cu un buton de aprobare. Acel ecran poate fi util. Poate fi și un obiect ceremonial. Întrebarea este dacă persoana care îl folosește are o alegere semnificativă. O alegere nu este semnificativă doar pentru că interfața afișează două butoane. Depinde de faptul dacă persoana are suficient timp, informații, competență și permisiune instituțională pentru a decide altfel.
Timpul este partea cel mai puțin spectaculoasă a designului și adesea cea mai decisivă. Dacă sistemul trimite sute de propuneri într-o perioadă în care un singur recenzor ar putea examina în mod rezonabil doar o fracțiune, organizația a creat o coadă, nu o supraveghere. Dacă propunerea expiră înainte ca recenzorul să poată obține contextul, sistemul a făcut din viteză factorul efectiv de decizie. Dacă o echipă este recompensată doar pentru volumul de lucru procesat, i s-a dat o instrucțiune tăcută despre ce buton să apese. Software-ul nu poate remedia aceste aranjamente adăugând un scor de încredere într-o altă nuanță de verde.
Informația trebuie să fie proporțională, nu exhaustivă. Un recenzor căruia i se oferă doar o concluzie nu o poate contesta. Un recenzor căruia i se oferă o transcriere brută a fiecărei interacțiuni a agentului, de obicei, nu o poate contesta nici el. Mijlocul utilizabil este un pachet de decizie. Acesta identifică ce acțiune este propusă, de ce se încadrează în scopul declarat, ce dovezi materiale o susțin, ce incertitudine rămâne, ce politică sau regulă este relevantă, care este efectul propus și ce s-ar întâmpla dacă acțiunea nu este aprobată. Pachetul ar trebui să ofere linkuri către dovezi mai detaliate, dar nu ar trebui să ceară o expediție arheologică pentru cazul obișnuit.
Competența înseamnă mai mult decât un curs generic despre AI. Pentru sarcina la îndemână, recenzorul trebuie să înțeleagă tipul de rezultat, limitările cunoscute care ar putea conta, modul în care fluxul de lucru este menit să funcționeze și semnele care impun escaladarea. O persoană care poate recunoaște o factură de furnizor defectuoasă poate fi bine plasată pentru a revizui o propunere legată de facturi. Aceeași persoană poate să nu fie bine plasată pentru a evalua acoperirea lingvistică a unui model sau o implicație privind protecția datelor. Atribuirea supravegherii este, prin urmare, și o decizie de personal.
Permisiunea instituțională este testul pe care multe designuri îl pică în tăcere. Recenzorul trebuie să poată refuza, întrerupe sau schimba ruta propusă fără a fi tratat ca sursa unei defecțiuni de sistem. Are nevoie de acces la o persoană sau un rol care poate decide ce se întâmplă mai departe. Are nevoie de o modalitate de a înregistra că problema a fost escaladată. Iar sistemul are nevoie de o stare sigură în care lucrul poate aștepta fără a fi comis accidental de o reîncercare, un timeout sau un alt agent care interpretează instrucțiunea originală ca o treabă neterminată.
Ingineria siguranței a tratat de mult timp performanța umană ca parte a sistemului, nu ca un ultim strat de lac. Health and Safety Executive din Regatul Unit descrie factorii umani ca fiind sarcina, individul și organizația împreună și avertizează împotriva luării lor în considerare în mod izolat. Acesta este un cadru sensibil pentru supravegherea agenților. Un recenzor nu este un dop uman abstract modelat pentru a umple un gol de software. Persoana respectivă îndeplinește o sarcină particulară, cu informații și instrumente particulare, într-o organizație particulară, cu presiuni și limite particulare. Calitatea controlului depinde de toate acestea.
Din acest motiv, un design bun de tip human-in-the-loop începe înainte ca butonul să apară. Definește ce decizii necesită o poartă umană, cine va ține poarta, ce dovezi va primi, cât timp permite sarcina, ce se întâmplă când persoana este absentă și dacă poarta are autoritate asupra acțiunii în sine sau doar asupra unei explicații a acțiunii. Dacă organizația nu poate răspunde la aceste întrebări într-o marți liniștită, nu va deveni mai clar când apare un caz cu consecințe mari. Nici nu ar trebui să aibă nevoie de o criză imaginară pentru a observa acest lucru.
O singură sarcină, mai multe tipuri de autoritate
Un model compact de autoritate poate face un flux de lucru al unui agent mai ușor de operat. Nu trebuie să fie grandios. Începe cu diferența dintre citire, propunere, delegare, angajare și oprire. Un rol cu drept de citire poate inspecta materialul necesar pentru o sarcină. Un rol cu drept de propunere poate pregăti o acțiune posibilă. Un rol cu drept de delegare poate atribui o muncă limitată altui actor. Un rol cu drept de angajare poate face efectivă o acțiune cu consecințe. Un rol cu drept de oprire poate întrerupe sau opri un traseu atunci când condițiile sale nu mai sunt îndeplinite.
Acestea nu sunt simple grade ierarhice. Un responsabil cu conformitatea poate opri un flux de lucru, dar nu poate angaja un rezultat pentru un client. Un agent specializat poate propune un traseu, dar nu poate delega muncă nouă în afara domeniului său. Un manager poate fi responsabil pentru scopul unui serviciu, dar nu și persoana autorizată să elibereze o anumită plată. Proprietatea utilă nu este o ierarhie de dragul ei. Este faptul că sistemul poate evalua dacă un anumit actor are autoritatea relevantă pentru o anumită acțiune în contextul curent.
Contextul face mare parte din muncă. Aceeași acțiune propusă poate fi obișnuită într-o circumstanță și cu consecințe în alta. Trimiterea unui șablon deja aprobat la o adresă internă cunoscută poate fi în cadrul unui mandat obișnuit de comunicare. Trimiterea unui mesaj nou redactat, cu date personale, către un destinatar nou este diferită. O rambursare sub un prag definit poate fi delegată unui proces bine testat. O modificare a unui drept, o ștergere de date sau o angajare externă pot necesita o decizie umană nominală. Politica ar trebui să exprime această distincție înainte ca modelul să fie rugat să planifice în jurul ei.
Există, de asemenea, o diferență importantă între o confirmare de primire și o aprobare. O confirmare de primire înregistrează că cineva a văzut un mesaj. O aprobare înregistrează că o persoană autorizată a acceptat o acțiune definită, cu contextul relevant, într-un punct definit al traseului. Într-un sistem conversațional, acestea pot părea similare. Înregistrarea nu ar trebui să fie. Dacă un examinator ulterior nu poate spune ce acțiune a fost aprobată și ce efect era așteptat, organizația a înregistrat o conversație, nu a capturat o decizie.
Delegarea în sine are nevoie de limite. Un agent care primește sarcina de a compara trei propuneri existente poate fi autorizat să ceară unui agent de cercetare să extragă termenii relevanți. Nu ar trebui să trateze această permisiune ca pe o invitație de a contacta furnizori, de a achiziționa date noi sau de a reformula obiectivul achiziției. Granița poate fi exprimată în politică, în domeniul de aplicare al instrumentelor, într-un contract de sarcină structurat sau în toate trei. Ceea ce contează este că este suficient de aplicabilă pentru a constrânge traseul, nu doar pentru a descrie comportamentul dorit după fapt.
Adâncimea de delegare este un alt tip de limită care merită numit. O persoană poate da unui agent o sarcină și poate totuși să aibă o imagine clară asupra primului transfer de responsabilitate. După mai multe transferuri succesive, scopul inițial poate fi prezent din punct de vedere tehnic în metadate, dar practic invizibil. Organizațiile pot stabili o adâncime maximă de delegare pentru o categorie de activități, pot cere o revizuire la o anumită adâncime sau pot interzice unui delegat să creeze alți delegați fără o nouă verificare. Acestea sunt opțiuni de proiectare, nu cerințe universale. Ele sunt cele mai utile acolo unde un lanț mai lung face dificil de identificat care actor a introdus o nouă ipoteză sau a modificat domeniul efectiv de aplicare.
Autoritatea asupra instrumentelor trebuie, de asemenea, separată de autoritatea modelului. Un model poate alege un instrument pe baza unui plan. Integrarea instrumentului ar trebui totuși să verifice dacă acțiunea solicitată, ținta, categoria de date, limita de resurse și starea fluxului de lucru permit apelul. Aceasta nu este o neîncredere în model într-un sens moral. Este proiectare obișnuită a granițelor. Un plan bine format poate fi totuși nepotrivit pentru cazul curent, iar un plan prost format nu ar trebui să devină real doar pentru că a ajuns la o acreditare cu acces larg.
Același lucru este valabil și pentru recuperare. O reîncercare nu este întotdeauna inofensivă. Reîncercarea unei cereri de citire a unui document public este diferită de reîncercarea unei cereri care trimite un mesaj sau efectuează o plată. Când o sarcină delegată eșuează, un flux de lucru are nevoie de o alegere explicită între reîncercare, redirecționare, escaladare, pauză și eșec controlat. Tratarea lor ca un singur gestionar generic de erori este modul în care o decizie operațională este luată în tăcere de setările implicite. Mediul de rulare al agentului poate pune opțiunile la dispoziție. Organizația trebuie să decidă ce opțiune se aplică fiecărei categorii de acțiuni.
Eșecul este adesea o decizie lipsă
Când oamenii aud despre eșec, își imaginează adesea un agent care produce o afirmație falsă sau un instrument care expiră. Ambele pot conta. Eșecurile mai relevante în munca delegată sunt frecvent mai discrete. Sarcina a fost atribuită fără un proprietar clar. Propunerea a depășit o graniță pe care nimeni nu o modelase. Revizorul putea vedea concluzia, dar nu și dovezile. O reîncercare a continuat după o pauză. O persoană a observat o problemă, dar nu avea autoritatea de a opri acțiunea. S-a luat o decizie, dar înregistrarea a păstrat doar rezultatul final, nu și condiția care îl făcea acceptabil.
Acestea nu sunt afirmații despre un incident anume. Sunt moduri de eșec derivate din structura delegării în sine. Ele pot fi găsite și în procesele umane. În software, însă, ele pot circula cu viteza automatizării și pot fi repetate foarte consecvent. Această consecvență nu este un motiv de disperare. Este un motiv să tratăm proiectarea fluxului de lucru ca parte a controlului, mai degrabă decât să presupunem că testarea acurateții unei singure componente a modelului rezolvă problema.
Luați în considerare un alt design explicit ipotetic. Unui agent i se cere să pregătească un rezumat al unui caz. Acesta deleagă extragerea documentelor unei componente și normalizarea limbajului alteia. O a treia componentă vede un câmp incomplet și folosește o sursă de cunoștințe conectată pentru a umple golul. Rezumatul final se citește fluent. Dacă fluxul de lucru nu a înregistrat câmpul lipsă, sursa folosită pentru a-l umple, încrederea sau incertitudinea asociată și faptul că sarcina inițială permitea doar rezumarea, un revizor nu poate spune dacă aprobă un rezumat sau o afirmație factuală nou creată. Problema nu este că ultima propoziție sună ciudat. Problema este că sensul sarcinii s-a schimbat în interiorul rutei.
Un răspuns sănătos nu înseamnă să interzici delegarea. Înseamnă să pui punctele de schimbare în evidență. O sursă nouă, un instrument nou, o categorie nouă de date, o clasă nouă de acțiuni, o schimbare materială a nivelului de încredere, un control eșuat, un lanț de delegare mai lung decât cel permis sau o propunere de a traversa o graniță externă pot deveni fiecare un motiv pentru a scoate activitatea la suprafață pentru revizuire. Declanșatoarele exacte vor diferi în funcție de context. Principiul este stabil: o schimbare care ar conta pentru proprietarul responsabil nu ar trebui să rămână invizibilă doar pentru că a avut loc între componente.
Acesta este un loc în care gândirea bazată pe cazul de siguranță este utilă. Un caz de siguranță nu este o promisiune că nimic nu poate merge prost. Este un argument structurat despre de ce un sistem este acceptabil pentru un scop definit în condiții definite, cu dovezi, ipoteze, controale și riscuri reziduale vizibile. Aplicat cu atenție unui flux de lucru cu agenți, asta înseamnă că afirmația nu este că agenții sunt în general siguri. Afirmația este mai restrânsă: această rută poate fi folosită pentru acest scop, cu aceste limite, pentru că există aceste controale și aranjamente de supraveghere, și trebuie reconsiderată atunci când ipotezele declarate nu mai sunt valabile.
Fluxul de lucru este apoi mai ușor de contestat. Un operator poate întreba dacă clasa de acțiuni a fost atribuită corect. Un proprietar de risc poate întreba dacă revizuitorul mai are suficient timp. Un inginer poate întreba dacă o reîncercare ar putea crea un efect duplicat. Un specialist în protecția datelor poate întreba dacă subtask-ul rămâne necesar și proporțional. O persoană afectată de un rezultat poate, acolo unde cadrul aplicabil o cere, să primească o cale de a contesta decizia. Aceste întrebări nu sunt birocrație adăugată după munca tehnică interesantă. Ele sunt munca de a face sistemul tehnic răspunzător într-o organizație.
Metricile ar trebui să urmeze aceeași disciplină. Numărarea numărului de sarcini delegate ne spune ceva despre volum, nu despre operarea responsabilă. Măsuri mai utile pot include rata la care un flux de lucru escaladează pentru că o graniță s-a schimbat, timpul în care o decizie așteaptă la o poartă, proporția acțiunilor cu consecințe care au un pachet complet de decizie, numărul de inversări reușite sau numărul de cazuri în care o verificare de politică a refuzat un apel de instrument. Astfel de măsurători au nevoie totuși de o definiție și un context. Nu ar trebui niciodată inventate pentru o broșură. Dar proiectarea evidențelor astfel încât să poată fi măsurate este un semn că responsabilitatea este tratată ca o proprietate operațională.
Evidența este locul unde supraviețuiește responsabilitatea
Un sistem multi-agent produce un tip ciudat de istoric. Are mesaje, apeluri de instrumente, ieșiri intermediare, verificări de politică, versiuni de model, informații de sincronizare, reîncercări, atribuiri schimbate și poate aprobări umane. Păstrarea fiecărui octet pentru totdeauna nu este nici necesară, nici adesea adecvată. Păstrarea doar a răspunsului final este de obicei prea puțin. Evidența trebuie să păstreze deciziile și dovezile care explică modul în care fluxul de lucru a trecut de la o cerere la un rezultat.
Pentru o acțiune cu consecințe, acea evidență ar trebui în mod normal să permită unui revizuitor să reconstituie câteva fapte de bază. Care a fost obiectivul? Ce politică sau mandat a făcut munca permisibilă? Cine sau ce a primit fiecare atribuire? Ce a fost propus la fiecare poartă cu consecințe? Ce informații au fost folosite pentru a susține propunerea? Ce limite, avertismente sau eșecuri au fost întâlnite? Cine a avut autoritatea de a aproba, opri sau inversa acțiunea? Ce acțiune a devenit efectivă și ce s-a întâmplat după aceea? Acestea nu sunt întrebări exotice. Ele sunt întrebările pe care o organizație le pune atunci când vrea să știe dacă o decizie a fost decizia ei.
Înregistrarea ar trebui să distingă un fapt operațional de o explicație produsă ulterior. Dacă un sistem afirmă că un revizor a aprobat o acțiune, evenimentul ar trebui să consemneze identitatea sau rolul revizorului, acțiunea care i-a fost prezentată, contextul relevant și momentul în care aprobarea s-a legat de acea acțiune. Dacă sistemul afirmă că un model a selectat un delegat, înregistrarea ar trebui să păstreze regula de selecție, candidații sau criteriile la nivelul adecvat utilizării și atribuirea rezultată. O narațiune ulterioară poate ajuta un cititor, dar nu ar trebui să înlocuiască evenimentul care a avut loc.
Versionarea contează aici. Rezultatul unui agent poate fi regenerat. O politică poate fi actualizată. Schema unui instrument se poate schimba. Un endpoint de model poate fi înlocuit. Dacă o decizie depinde de o anumită versiune a unui prompt, a unei politici, a unui model, a unei surse de cunoștințe sau a unei integrări, înregistrarea are nevoie de o referință stabilă la acea versiune. În caz contrar, reluarea devine o performanță: reproduce ceea ce organizația se întâmplă să aibă acum și numește rezultatul o explicație a ceea ce s-a întâmplat atunci.
Reversibilitatea merită o atenție egală. Regulamentul privind IA se referă în mod expres, în contextul supravegherii pentru riscuri ridicate, la capacitatea de a ignora, de a suprascrie sau de a inversa un rezultat și de a întrerupe un sistem astfel încât acesta să ajungă într-o stare sigură. Într-un traseu multi-agent, starea sigură nu este neapărat un proces de model oprit. Poate însemna că nu este trimisă nicio comunicare externă, că o acțiune din coadă este reținută, că un sistem din aval nu este actualizat, că acreditările temporare nu mai sunt utilizabile pentru sarcină și că dovezile necesare pentru a decide ce se întâmplă mai departe sunt păstrate. Aceasta este o inferență operațională din cerința de supraveghere, nu o citare a legii. Este, de asemenea, un test de proiectare util.
Sigur nu înseamnă înghețat pentru totdeauna. Un flux de lucru oprit are nevoie de o cale controlată de reluare. Cineva trebuie să decidă dacă să modifice sarcina, să renunțe la propunere, să ruleze din nou o parte limitată a lucrării, să folosească un alt instrument, să caute dovezi suplimentare sau să abandoneze traseul. O înregistrare curată face această alegere mai ușoară, deoarece îi spune următoarei persoane ce se știe, ce s-a încercat, de ce s-a oprit lucrul și ce efecte au avut loc și care nu. Fără această înregistrare, recuperarea devine o altă delegare nestructurată, asumată de obicei sub o presiune mai mare decât prima.
De aceea, păstrarea și accesul au nevoie de propriile decizii. Nu orice actor ar trebui să poată citi fiecare urmă. O înregistrare poate conține date personale, material sensibil din punct de vedere comercial sau detalii relevante pentru securitate. Dar accesul controlat nu este același lucru cu lipsa înregistrării. Accentul pus de Convenția Consiliului Europei pe transparență, supraveghere, responsabilitate și răspundere este un memento util că granița ar trebui proiectată, nu presupusă. O organizație poate păstra un traseu responsabil, limitând în același timp accesul la detaliile de care un anumit revizor are nevoie în mod real.
Ce ar trebui să facă vizibil un contract de delegare
Un contract de delegare poate fi o structură de date, o schemă de flux de lucru, un pachet de aprobare semnat sau o combinație a acestora. Forma sa contează mai puțin decât conținutul. Ar trebui să îi spună actorului care primește ce are voie să facă, ce nu are voie să facă și cum va fi judecată lucrarea. Când aceste constrângeri lipsesc, agenții tind să compenseze cu instrucțiuni din ce în ce mai elaborate. Acest lucru poate îmbunătăți o anumită rulare. Nu creează o graniță organizațională pe care un instrument, un revizor sau un auditor să o poată aplica.
Începeți cu scopul intenționat. Un scop ar trebui să fie suficient de concret pentru a exclude sarcinile apropiate. Compararea termenilor din propunerile furnizate este diferită de găsirea celui mai bun furnizor. Rezumarea documentelor primite este diferită de stabilirea faptelor lipsă. Redactarea unui răspuns pentru revizuire este diferită de comunicarea unei decizii. Contrastul poate părea pretențios până când un agent folosește o instrucțiune largă pentru a face un pas următor rezonabil, dar neautorizat. Atunci este diferența dintre inițiativa utilă și un mandat nelimitat.
Precizați clasele de acțiuni permise și interzise. Un agent poate fi autorizat să citească un dosar de caz, să extragă câmpuri denumite, să compare cu o politică și să pregătească o schiță. I se poate interzice modificarea unui înregistrare sursă, contactarea unei părți externe, selectarea unei noi surse sau efectuarea unei tranzacții. Acestea nu sunt doar instrucțiuni de prompt. Stratul de instrumente și flux de lucru ar trebui să le aplice acolo unde este practic. O politică care nu poate fi verificată în momentul acțiunii este tot utilă ca orientare, dar este mai slabă ca mecanism de control.
Denumiți proprietarul și ruta de escaladare. Proprietarul nu este neapărat persoana care va face clic pe aprobare pentru fiecare acțiune. Este rolul responsabil pentru rezultat și pentru decizia privind ceea ce se întâmplă atunci când ruta ajunge la o întrebare nerezolvată. Ruta de escaladare identifică următoarea autoritate atunci când agentul detectează o încălcare a limitei, dovezi insuficiente, un conflict între surse, o nepotrivire a politicii sau o condiție pe care sistemul nu este autorizat să o rezolve. O coadă fără un proprietar de decizie numit este pur și simplu o întârziere cu o etichetă optimistă.
Atașați o regulă de dovezi. Regula poate preciza care surse sunt autoritare, dacă agentul poate căuta dincolo de ele, cum este reprezentată incertitudinea, ce trebuie citat în propunere și când o sursă conflictuală necesită revizuire. Acest lucru este deosebit de important pentru sistemele care generează proză fluentă. Fluenta poate face o încălcare a limitei să pară o finalizare utilă. O regulă de dovezi face disponibilă întrebarea corectă: fluxul de lucru a rămas în interiorul materialului pe care era autorizat să îl folosească?
Stabiliți o limită de timp, resurse și delegare acolo unde contează. O sarcină care poate continua la nesfârșit poate crea costuri, congestie operațională sau presiune de a comite un rezultat învechit. O sarcină care poate delega în mod repetat poate crea un lanț pe care niciun proprietar nu îl poate inspecta cu ușurință. Un design limitat precizează cât timp rămâne valabilă sarcina, câtă resursă poate consuma, dacă poate crea o subsarcină, ce adâncime maximă este permisă și ce se întâmplă când este atinsă o limită. Răspunsul poate fi pauză automată, escaladare sau eșec controlat. Partea importantă este că este decis înainte de a fi depășită limita.
În cele din urmă, definiți condiția de finalizare. Finalizat nu înseamnă întotdeauna că agentul a produs text. Poate însemna că un recenzor a primit un pachet complet, că o poartă de politică a acceptat o acțiune specifică, că un sistem din aval a confirmat o actualizare reversibilă sau că un proprietar responsabil a ales să nu continue. Condițiile de finalizare mențin fluxul de lucru onest. Ele împiedică agentul să trateze actul de a propune o decizie ca și cum organizația ar fi luat una.
Aceste modele sunt utile indiferent dacă fluxul de lucru conține un singur agent bazat pe model sau o echipă mai mare de componente specializate. Mai mulți agenți nu necesită automat mai mult proces. Ele necesită ca limitele dintre roluri să fie exprimate, nu doar implicate. Costul acelei exprimări este, în general, mult mai mic decât costul încercării de a reconstrui autoritatea după ce mai multe sisteme au schimbat instrucțiuni parțiale și unul dintre ele a atins lumea exterioară.
Delegarea ar trebui să facă organizația mai capabilă, nu mai puțin responsabilă
Sistemele de agenți sunt adesea descrise ca și cum valoarea lor ar consta în eliminarea organizării din muncă. Perspectiva mai interesantă este opusul. Un sistem proiectat cu atenție poate face angajamentele organizaționale mai clare: o sarcină are un proprietar, o delegare are o limită, o acțiune consecventă are o autoritate, o revizuire are dovezi, o oprire are o stare sigură și o înregistrare poate fi redată. Acesta nu este un obstacol în calea automatizării utile. Este ceea ce permite automatizării să preia muncă semnificativă fără a cere oamenilor să aibă încredere într-un lanț invizibil.
Am construit Dweve Nexus în jurul acestei distincții. Documentația locală de produs descrie sarcini durabile, autoritate evaluată în raport cu contextul de execuție înainte de acțiune, structuri explicite de colaborare, inclusiv delegarea, și o evidență scrisă pe măsură ce munca se desfășoară. Afirmația relevantă este în mod deliberat modestă. Acestea sunt proprietăți de proiectare menite să facă un traseu delegat inspectabil. Nu sunt o dovadă că o anumită implementare este legală, sigură sau adecvată și nu elimină necesitatea ca o organizație să își decidă propriul scop, propria autoritate și propria supraveghere umană.
Lecția mai largă nu depinde de un singur produs. Un model poate decide cum să împartă o sarcină. Un agent poate cere altui agent să preia o muncă. Un instrument poate efectua o acțiune. Organizația tot trebuie să decidă unde locuiește autoritatea. Trebuie să o facă înainte ca delegarea să înceapă, nu după ce un rezultat final a fost lustruit într-o formă greu de contestat.
Acesta este răspunsul la titlu. Proprietarul unei decizii nu este agentul care s-a întâmplat să vorbească ultimul. Este persoana sau rolul căruia organizația i-a atribuit autoritatea de a accepta consecința deciziei, cu suficiente informații și putere pentru a o refuza. Delegarea este utilă atunci când îl face pe acea persoană mai capabilă. Devine periculoasă atunci când o face imposibil de găsit.
Surse
- Regulamentul (UE) 2024/1689, Actul privind inteligența artificială, EUR-Lex
- Convenția-cadru a Consiliului Europei privind inteligența artificială și drepturile omului, democrația și statul de drept
- Avizul EDPB 28/2024 privind aspectele de protecție a datelor legate de prelucrarea datelor cu caracter personal în contextul modelelor de IA
- Factori umani: introducere, UK Health and Safety Executive
- Dweve Nexus