Chi prende la decisione quando un agente delega?

Chi prende la decisione quando un agente delega?

Un passaggio di consegne non svuota la poltrona

Un agente delega un compito. Un altro agente raccoglie materiale, confronta i registri, chiama uno strumento o prepara una raccomandazione. Un terzo agente verifica il risultato. Il lavoro si sposta, e questo movimento può essere utile. Può anche creare un problema gestionale molto antico in una forma nuova: tutti hanno fatto qualcosa, ma nessuno sa dire chi aveva l'autorità di prendere la decisione.

La risposta allettante è l'agente che ha effettuato l'ultima chiamata. È anche, di solito, la risposta meno utile. Un componente software può selezionare un percorso, richiedere altro lavoro e inviare un'istruzione a un sistema collegato. Nessuna di queste cose stabilisce chi ha accettato lo scopo, chi ha definito i confini, chi avrebbe potuto rifiutare l'azione, o chi doveva essere informato quando le condizioni cambiavano. Stabilisce soltanto che un programma faceva parte della catena.

Questa distinzione diventa netta quando un flusso di lavoro ha delle conseguenze. Una risposta suggerita può diventare una comunicazione con il cliente. Una classificazione può diventare il motivo per cui un caso viene inserito in una particolare coda. Un confronto può diventare una raccomandazione d'acquisto. Un'istruzione di pagamento abbozzata può diventare un pagamento. Ogni passaggio può essere tecnicamente competente e comunque organizzativamente incompleto. Il sistema ha svolto il lavoro della delega senza svolgere il lavoro dell'autorità.

Non c'è bisogno di inventare un fallimento drammatico per vedere il problema. Prendiamo un flusso di lavoro volutamente ipotetico. Un agente di triage riceve una domanda, chiede a un agente di ricerca di esaminare il materiale pertinente, invia il risultato a un revisore e poi prepara un'azione per un sistema di gestione dei casi. L'agente di ricerca non è autorizzato ad agire. Il revisore non è autorizzato a rendere efficace l'esito del caso. L'agente di triage ha una credenziale per lo strumento. L'organizzazione non ha specificato se quella credenziale gli consente di impegnare il risultato. Il flusso di lavoro può sembrare ordinato su una dashboard. Ha comunque raggiunto la domanda più importante senza una risposta.

La delega non è la scomparsa della responsabilità. È una responsabilità resa più difficile da vedere. Una buona progettazione operativa la rende di nuovo più facile. Dice qual è la decisione iniziale, cosa può essere delegato, quali condizioni viaggiano con il compito, chi può approvare un'azione irreversibile o con conseguenze, quale registro rimane dopo il passaggio di consegne e come una persona o un sistema può intervenire quando il percorso non è più sicuro. Alla tecnologia non viene chiesto di possedere un'agency morale. Le viene chiesto di lasciare intatta l'agency dell'organizzazione.

Questo è il significato pratico della responsabilità in un flusso di lavoro multi-agente. Non è una riga decorativa in una policy, e non è una caccia retrospettiva al dipendente più vicino quando qualcosa va storto. È una proprietà del percorso prima che il lavoro inizi. La persona giusta può esaminare ciò che è stato proposto, capire perché è stato proposto, esercitare l'autorità che le è stata assegnata e lasciare dietro di sé un registro che possa essere contestato in seguito.

Le nuove norme europee sull'IA sono utili qui perché sono meno interessate a un essere umano teatrale alla fine di un flusso che alle condizioni in cui la supervisione può effettivamente funzionare. Le disposizioni sull'oversight umano dell'AI Act si applicano ai sistemi ad alto rischio, non a ogni uso di un agente. Questo limite conta. Ma le domande operative dell'Atto viaggiano bene: una persona fisica designata può comprendere le capacità e i limiti pertinenti, monitorare anomalie e prestazioni inattese, evitare un'eccessiva dipendenza, interpretare l'output, ignorarlo o invertirlo e interrompere il sistema portandolo in uno stato sicuro? Un flusso di lavoro con molti agenti non rende queste domande più piccole. Moltiplica i punti in cui la risposta può andare persa.

La delega è una catena, non una nebbia

Le persone delegano di continuo. Un manager chiede a un collega di preparare una nota. Un team acquisti chiede a un esperto di esaminare una clausola contrattuale. Un clinico chiede a un laboratorio un risultato. Chi riceve il compito acquisisce un ruolo definito nel lavoro; non eredita automaticamente ogni autorità di chi ha chiesto. Le buone organizzazioni rendono concreta questa distinzione banale con descrizioni di ruolo, limiti di approvazione, procedure, segregazione dei compiti e registrazioni. Lo fanno perché capacità e permesso sono cose diverse.

I sistemi di agenti tendono a offuscare questa distinzione perché un agente può descrivere, pianificare ed eseguire in un'unica superficie conversazionale. Un modello può essere in grado di generare un piano convincente per contattare un fornitore. Un wrapper di strumenti può essere tecnicamente in grado di inviare il messaggio. Un livello di orchestrazione può essere in grado di chiamare quel wrapper senza una pausa. Questi fatti descrivono la capacità. Non decidono se il messaggio debba essere inviato, se il destinatario proposto sia in ambito, se l'informazione sia appropriata da divulgare, o chi debba accettare la conseguenza se l'azione proposta è sbagliata.

Aiuta separare cinque domande che spesso vengono accorpate. Chi ha dato lo scopo al compito? Chi può svolgere il lavoro preparatorio? Chi può delegare un sottocompito? Chi può decidere che un'azione proposta sia accettabile? Chi può rendere efficace quell'azione nel mondo esterno? A volte un unico ruolo umano detiene legittimamente più di una di queste risposte. A volte devono essere separate. Il punto non è creare una cerimonia elaborata per una nota a basso rischio. Il punto è evitare di trattare silenziosamente una capacità tecnica come un trasferimento di autorità istituzionale.

Una delega dovrebbe quindi portare più di un'istruzione. Dovrebbe portare un mandato. Il mandato identifica l'obiettivo, il contesto delimitato, gli input consentiti, l'output atteso, le azioni che restano vietate, il budget o il limite di tempo dove rilevante, le condizioni che richiedono escalation, e la persona o il ruolo responsabile del risultato. L'agente ricevente può quindi svolgere lavoro utile dentro un perimetro visibile. Può chiedere a un altro agente un'analisi. Non può espandere il perimetro solo perché gli viene in mente un passo successivo plausibile.

Questo non è un argomento per trasformare ogni interazione in una riunione di approvazione. È un argomento per scegliere il punto in cui l'organizzazione desidera che una decisione avvenga. Un sistema può redigere una spiegazione senza che un umano guardi ogni frase quando scopo, pubblico, confine delle fonti e regole di pubblicazione sono già fissati. Un sistema non dovrebbe acquisire il potere di modificare il diritto di un cliente solo perché lo stesso componente ha accesso al database pertinente. La differenza è la conseguenza, non l'intelligenza del modello.

Questa conseguenza è spesso distribuita. Un compito può essere innocuo in una fase e avere conseguenze in quella successiva. Leggere un file può essere un'operazione di routine. Combinarlo con un'altra fonte può cambiare la sensibilità del materiale. Preparare una raccomandazione può essere un'operazione di routine. Premere un pulsante che crea un esito legale, finanziario o di servizio può non esserlo. Una progettazione della governance che chiede solo se un agente è autonomo non coglie questo cambiamento di stato. La domanda utile è più circoscritta: autonomo per fare cosa, per chi, a quali condizioni e con l'autorità di chi?

C'è un modesto istinto olandese che vale la pena conservare qui. Se un processo richiede una dozzina di firme, timbri e un diagramma di flusso plastificato per stabilire chi possa premere un pulsante, potrebbe non essere un trionfo della governance. Ma la disposizione opposta, in cui una credenziale di uno strumento viene trattata come un accordo costituzionale, non è nemmeno quella un trionfo. L'obiettivo è un percorso proporzionato che renda chiara l'autorità per le azioni con conseguenze senza allestire una piccola opera attorno a ogni azione di routine.

La supervisione europea è un requisito operativo

L'AI Act offre l'espressione giuridica più chiara di questa idea per i sistemi di IA ad alto rischio. L'articolo 14 richiede che siano progettati e sviluppati in modo che le persone fisiche possano supervisionarli efficacemente durante l'uso. Lo scopo dichiarato è prevenire o ridurre al minimo i rischi per la salute, la sicurezza e i diritti fondamentali laddove tali rischi possano permanere nonostante altri requisiti. Le misure devono essere commisurate al rischio, all'autonomia e al contesto d'uso. Questo è uno standard deliberatamente operativo. Non dice che una persona da qualche parte nell'organizzazione sia generalmente interessata all'IA.

La disposizione va oltre una generica istruzione di mantenere un essere umano nel circuito. A seconda di ciò che è appropriato e proporzionato, la persona assegnata alla supervisione deve essere messa in grado di comprendere le capacità e i limiti pertinenti, monitorare il funzionamento e rilevare anomalie, disfunzioni o prestazioni inattese, restare consapevole del bias di automazione, interpretare gli output, decidere di non utilizzare un output o di ignorarlo, sovrascriverlo o annullarlo, e intervenire o interrompere il sistema portandolo in uno stato sicuro. La legge non trasforma questi elementi in un elenco di controllo universale per ogni sistema di agenti. Mostra però perché un timbro di approvazione a fine processo sia un modello povero di supervisione.

Ora aggiungiamo la delega. Se un agente affida un compito a un altro agente, il ruolo di supervisione deve poter vedere più della frase finale prodotta dall'ultimo modello. Serve abbastanza contesto per capire quale agente ha proposto il sotto-compito, quali fonti o strumenti sono stati usati, se è stato raggiunto un limite di policy, se un revisore ha modificato un risultato e se un agente successivo ha ampliato l'ambito. Altrimenti l'essere umano può vedere un output, ma non il percorso che lo ha prodotto. Questo può bastare per una bozza a basso impatto. Non è una base convincente per accettare una decisione con conseguenze.

L'articolo 26 rende il punto organizzativo ancora più chiaro per i deployer di sistemi ad alto rischio. Stabilisce che i deployer assegnino la supervisione umana a persone fisiche con le necessarie competenze, formazione, autorità e supporto. Queste parole stanno insieme. La competenza senza autorità crea uno spettatore ben informato. L'autorità senza competenza crea un proprietario formale che non può mettere in discussione il sistema. Entrambe senza supporto creano una persona a cui si chiede di intervenire in un processo che non può vedere, a un ritmo che non può sostenere, usando informazioni che non può interpretare.

Nel lavoro multi-agente, il supporto comprende la forma dell'interfaccia e della registrazione. Un operatore non ha bisogno di ogni token generato da un modello o di ogni nuovo tentativo interno. Ha invece bisogno dell'azione proposta, dello scopo dichiarato, delle prove materiali, della policy e del limite applicabili, delle modifiche apportate dall'ultimo punto di revisione, dell'effetto previsto, dell'eventuale percorso di annullamento e del motivo per cui il caso è stato inoltrato a un livello superiore. Non si tratta tanto di rendere rassicurante una dashboard quanto di ridurre la probabilità che una persona approvi una risposta perché il sistema ha reso estenuante trovare l'alternativa.

La Convenzione quadro del Consiglio d'Europa sull'intelligenza artificiale e i diritti umani, la democrazia e lo Stato di diritto stabilisce il collegamento istituzionale più ampio. Il suo scopo è garantire che le attività nel ciclo di vita dei sistemi di IA siano coerenti con i diritti umani, la democrazia e lo Stato di diritto. Gli articoli 8 e 9 richiedono trasparenza e supervisione adattate a contesti e rischi specifici, nonché responsabilità e rendiconto per gli impatti negativi. La Convenzione non prescrive un modello di orchestrazione degli agenti. Costituisce però un utile correttivo all'idea che una catena di componenti software possa dissolvere le responsabilità dell'autorità pubblica o dell'attore privato che la utilizza.

Questa visione più ampia è importante perché una decisione delegata può incidere su più della sola performance tecnica. Può incidere sulla capacità di una persona di comprendere una decisione, contestarla, ottenere un risarcimento o semplicemente sapere quale organizzazione è responsabile. Un flusso di lavoro può essere composto da componenti di più fornitori, modelli di più provider, strumenti gestiti da un altro team e un servizio erogato nell'ambito di un contratto pubblico. Il fatto che la catena sia tecnicamente distribuita non rende meno reale l'impatto sull'individuo. In pratica, rende più importante una chiara attribuzione dei ruoli.

La protezione dei dati lancia lo stesso avvertimento da una direzione diversa. Il lavoro del Comitato europeo per la protezione dei dati sui modelli di IA sottolinea che l'analisi della protezione dei dati rimane contestuale: le organizzazioni devono determinare il proprio ruolo, identificare il trattamento coinvolto e applicare gli obblighi pertinenti, piuttosto che trattare l'etichetta "modello di IA" come un'esenzione dalla normale responsabilità. Quando un flusso di lavoro multi-agente tocca dati personali, la delega non dovrebbe oscurare chi determina le finalità e i mezzi del trattamento, quale agente o strumento riceve quali dati e se il successivo passaggio di consegne sia necessario per l'attività. Una sotto-attività è comunque un passaggio di trattamento. Chiamarla delega non la fa sparire.

Niente di tutto ciò fornisce una risposta magica a ogni caso difficile. Gli obblighi legali dipendono dall'uso, dagli attori, dai dati e dal settore. Un articolo non può classificare un sistema specifico. Ma può enunciare un principio disciplinato: se un flusso di lavoro distribuisce il lavoro, dovrebbe distribuirlo in modo da preservare la capacità di identificare l'autorità, intervenire in tempo, rendere conto del percorso e rispondere alle persone colpite dall'esito.

La persona nel ciclo deve avere un ciclo reale

La supervisione umana è facilmente ridotta a uno schermo con un pulsante di approvazione. Quel pulsante può essere utile. Può anche essere un oggetto cerimoniale. La questione è se la persona che lo utilizza abbia una scelta significativa. Una scelta non è significativa solo perché l'interfaccia mostra due pulsanti. Dipende dal fatto che la persona abbia abbastanza tempo, informazioni, competenze e permesso istituzionale per decidere diversamente.

Il tempo è la parte meno affascinante del progetto e spesso la più decisiva. Se il sistema invia centinaia di proposte in un periodo in cui un singolo revisore potrebbe ragionevolmente esaminarne solo una frazione, l'organizzazione ha creato una coda, non una supervisione. Se la proposta scade prima che il revisore possa ottenere il contesto, il sistema ha reso la velocità il decisore effettivo. Se un team viene premiato solo per il volume di lavoro completato, ha ricevuto un'istruzione implicita su quale pulsante premere. Il software non può risolvere questi accordi aggiungendo un punteggio di confidenza in una diversa tonalità di verde.

Le informazioni devono essere proporzionate, non esaustive. Un revisore a cui viene data solo una conclusione non può contestarla. Un revisore a cui viene dato il trascritto grezzo di ogni interazione tra agenti di solito non può contestarlo nemmeno lui. Il punto intermedio utilizzabile è un pacchetto decisionale. Identifica quale azione viene proposta, perché rientra nello scopo dichiarato, quali prove materiali la supportano, quale incertezza rimane, quale politica o regola è pertinente, quale sarebbe l'effetto proposto e cosa accadrebbe se l'azione non venisse approvata. Il pacchetto dovrebbe collegarsi a prove più approfondite, ma non dovrebbe richiedere una spedizione archeologica per il caso ordinario.

La competenza significa più di un corso generico sull'IA. Per il compito in questione, il revisore deve comprendere il tipo di output, i limiti noti che potrebbero essere rilevanti, il modo in cui il flusso di lavoro è pensato per comportarsi e i segnali che richiedono un'escalation. Una persona che sa riconoscere una fattura del fornitore errata può essere nella posizione giusta per rivedere una proposta relativa alle fatture. La stessa persona potrebbe non essere nella posizione giusta per valutare la copertura linguistica di un modello o un'implicazione sulla protezione dei dati. Assegnare la supervisione è quindi anche una decisione di personale.

Il permesso istituzionale è il test che molti progetti falliscono silenziosamente. Il revisore deve poter rifiutare, mettere in pausa o modificare il percorso proposto senza essere trattato come la fonte di un guasto del sistema. Ha bisogno di accesso a una persona o a un ruolo che possa decidere cosa succede dopo. Ha bisogno di un modo per registrare che la questione è stata portata a un livello superiore. E il sistema ha bisogno di uno stato sicuro in cui il lavoro possa attendere senza essere accidentalmente commesso da un nuovo tentativo, da un timeout o da un altro agente che interpreta l'istruzione originale come un'attività incompiuta.

L'ingegneria della sicurezza ha da tempo trattato le prestazioni umane come parte del sistema, piuttosto che come uno strato finale di vernice. L'Health and Safety Executive del Regno Unito descrive i fattori umani come il compito, l'individuo e l'organizzazione insieme, e mette in guardia dal considerarli in isolamento. Questa è una cornice sensata per la supervisione degli agenti. Un revisore non è un tappo umano astratto per una lacuna del software. Sta svolgendo un compito specifico, con informazioni e strumenti specifici, all'interno di un'organizzazione specifica con pressioni e limiti specifici. La qualità del controllo dipende da tutto questo.

Per questo motivo, una buona progettazione human-in-the-loop inizia prima che il pulsante appaia. Definisce quali decisioni necessitano di un gate umano, chi gestirà il gate, quali prove riceverà, quanto tempo consente il compito, cosa succede quando la persona è assente e se il gate ha autorità sull'azione stessa o solo su una spiegazione dell'azione. Se l'organizzazione non può rispondere a queste domande in un tranquillo martedì, non diventerà più chiaro quando arriverà un caso ad alta conseguenza. Né dovrebbe aver bisogno di una crisi immaginaria per accorgersene.

Un compito, diversi tipi di autorità

Un modello di autorità compatto può rendere più facile gestire un flusso di lavoro di un agente. Non deve essere per forza complesso. Si comincia dalla differenza tra leggere, proporre, delegare, impegnarsi e fermarsi. Un ruolo autorizzato alla lettura può ispezionare il materiale necessario per un compito. Un ruolo autorizzato alla proposta può preparare un'azione possibile. Un ruolo autorizzato alla delega può assegnare attività delimitate a un altro attore. Un ruolo autorizzato all'impegno può rendere effettiva un'azione consequenziale. Un ruolo autorizzato all'arresto può sospendere o fermare un percorso quando le sue condizioni non sono più soddisfatte.

Questi non sono semplicemente gradi. Un revisore della conformità può essere in grado di fermare un flusso di lavoro ma non di impegnarsi su un risultato per il cliente. Un agente specializzato può essere in grado di proporre un percorso ma non di delegare nuovo lavoro al di fuori del proprio dominio. Un manager può essere responsabile dello scopo di un servizio ma non essere la persona autorizzata a rilasciare un pagamento specifico. La proprietà utile non è una gerarchia fine a se stessa. È che il sistema possa valutare se un determinato attore ha l'autorità pertinente per una determinata azione nel contesto attuale.

Il contesto fa gran parte del lavoro. La stessa azione proposta può essere ordinaria in una circostanza e consequenziale in un'altra. Inviare un modello già approvato a un indirizzo interno noto può rientrare in un mandato di comunicazione di routine. Inviare un messaggio appena redatto con dati personali a un nuovo destinatario è diverso. Un rimborso entro una soglia definita può essere delegato a un processo ben collaudato. Una modifica a un diritto, una cancellazione di dati o un impegno esterno possono richiedere una decisione umana nominata. La policy dovrebbe esprimere questa distinzione prima che al modello venga chiesto di pianificare di conseguenza.

C'è anche una differenza importante tra un'approvazione e un'accettazione. Un'accettazione registra che qualcuno ha visto un messaggio. Un'approvazione registra che una persona autorizzata ha accettato un'azione definita, con il contesto pertinente, in un punto definito del percorso. In un sistema conversazionale queste possono sembrare simili. Il registro non dovrebbe esserlo. Se un revisore successivo non riesce a capire quale azione è stata approvata e quale effetto era atteso, l'organizzazione ha registrato una conversazione piuttosto che catturato una decisione.

La delega stessa ha bisogno di limiti. Un agente che riceve un compito di confrontare tre proposte esistenti può essere autorizzato a chiedere a un agente di ricerca di estrarre termini pertinenti. Non dovrebbe trattare questo permesso come un invito a contattare i fornitori, acquisire nuovi dati o riformulare l'obiettivo di approvvigionamento. Il confine può essere espresso nella policy, nell'ambito degli strumenti, in un contratto di attività strutturato o in tutti e tre. Ciò che conta è che sia abbastanza applicabile da vincolare il percorso piuttosto che limitarsi a descrivere il comportamento desiderato a posteriori.

La profondità di delega è un altro limite che vale la pena nominare. Un essere umano può affidare un compito a un agente e mantenere comunque una visione chiara del suo primo passaggio di consegne. Dopo diversi passaggi di consegne annidati, lo scopo originale può essere tecnicamente presente nei metadati ma di fatto invisibile. Le organizzazioni possono impostare una profondità massima di delega per una classe di lavoro, richiedere una revisione a una determinata profondità o vietare a un delegato di creare ulteriori delegati senza un nuovo controllo. Queste sono scelte progettuali, non requisiti universali. Sono più utili laddove una catena più lunga rende difficile capire quale attore ha introdotto una nuova ipotesi o ha modificato l'ambito effettivo.

L'autorità sugli strumenti deve inoltre essere separata dall'autorità del modello. Un modello potrebbe scegliere uno strumento in base a un piano. L'integrazione dello strumento deve comunque verificare se l'azione richiesta, il bersaglio, la categoria di dati, il limite di risorse e lo stato del flusso di lavoro consentono la chiamata. Non si tratta di sfiducia nei confronti del modello in senso morale. È ordinaria progettazione dei confini. Un piano ben formato può comunque essere inappropriato per il caso corrente, e un piano mal formato non dovrebbe diventare reale solo perché ha raggiunto una credenziale con accesso ampio.

Lo stesso vale per il recupero. Un nuovo tentativo non è sempre innocuo. Ripetere una richiesta per leggere un documento pubblico è diverso dal ripetere una richiesta che invia un messaggio o addebita un importo. Quando un compito delegato fallisce, un flusso di lavoro necessita di una scelta esplicita tra nuovo tentativo, reindirizzamento, escalation, pausa e fallimento controllato. Trattarli come un unico gestore di errori generico è il modo in cui una decisione operativa viene presa silenziosamente dalle impostazioni predefinite. Il runtime dell'agente può rendere disponibili le opzioni. L'organizzazione deve decidere quale opzione si applica a quale classe di azione.

Il fallimento è spesso una decisione mancante

Quando le persone sentono parlare di fallimento, spesso immaginano un agente che produce un'affermazione falsa o uno strumento che va in timeout. Entrambe le cose possono contare. I fallimenti più rivelatori nel lavoro delegato sono spesso più silenziosi. Il compito è stato assegnato senza un proprietario chiaro. La proposta ha superato un confine che nessuno aveva modellato. Il revisore poteva vedere la conclusione ma non le prove. Un nuovo tentativo è continuato dopo una pausa. Un essere umano ha notato un problema ma non aveva l'autorità per fermare l'azione. Una decisione è stata presa, ma il registro ha conservato solo l'output finale e non la condizione che lo rendeva accettabile.

Queste non sono affermazioni su un incidente specifico. Sono modalità di fallimento derivate dalla struttura stessa della delega. Si possono trovare anche nei processi umani. Nel software, tuttavia, possono viaggiare alla velocità dell'automazione ed essere ripetute in modo molto coerente. Questa coerenza non è un motivo per disperare. È un motivo per trattare la progettazione del flusso di lavoro come parte del controllo, piuttosto che presumere che i test di accuratezza di un singolo componente del modello risolvano la questione.

Si consideri un altro progetto esplicitamente ipotetico. A un agente viene chiesto di preparare un riepilogo di un caso. Delega l'estrazione dei documenti a un componente e la normalizzazione linguistica a un altro. Un terzo componente vede un campo incompleto e usa una fonte di conoscenza collegata per colmare la lacuna. Il riepilogo finale si legge in modo scorrevole. Se il flusso di lavoro non ha registrato il campo mancante, la fonte usata per colmarlo, la fiducia o l'incertezza che l'accompagnava e il fatto che il compito originale consentisse solo il riepilogo, un revisore non può dire se sta approvando un riepilogo o un'affermazione fattuale di nuova creazione. Il problema non è che l'ultima frase suoni strana. Il problema è che il significato del compito è cambiato all'interno del percorso.

Una risposta sensata non è vietare la delega. È mettere i punti di cambiamento nel registro. Una nuova fonte, un nuovo strumento, una nuova categoria di dati, una nuova classe di azioni, un cambiamento materiale nella confidenza, un controllo fallito, una catena di delega più lunga del consentito o una proposta di attraversare un confine esterno possono tutti diventare un motivo per portare il lavoro in revisione. I trigger esatti varieranno a seconda del contesto. Il principio è stabile: un cambiamento che avrebbe importanza per il proprietario responsabile non dovrebbe rimanere invisibile solo perché è avvenuto tra componenti.

Questo è un punto in cui il pensiero del safety case è utile. Un safety case non è una promessa che nulla possa andare storto. È un argomento strutturato sul perché un sistema sia accettabile per uno scopo definito in condizioni definite, con evidenze, assunzioni, controlli e rischi residui resi visibili. Applicato con cura a un flusso di lavoro agente, ciò significa che l'affermazione non è che gli agenti siano generalmente sicuri. L'affermazione è più ristretta: questa via può essere usata per questo scopo, con questi limiti, perché esistono questi controlli e queste disposizioni di supervisione, e deve essere riconsiderata quando le assunzioni dichiarate non valgono più.

Il flusso di lavoro è quindi più facile da contestare. Un operatore può chiedere se la classe di azioni sia stata assegnata correttamente. Un proprietario del rischio può chiedere se il revisore abbia ancora abbastanza tempo. Un ingegnere può chiedere se un nuovo tentativo possa creare un effetto duplicato. Uno specialista di protezione dei dati può chiedere se il sotto-compito rimanga necessario e proporzionato. Una persona colpita da un esito può, dove il quadro applicabile lo richiede, ricevere una via per contestare la decisione. Quelle domande non sono burocrazia aggiunta dopo il lavoro tecnico interessante. Sono il lavoro di rendere il sistema tecnico responsabile all'interno di un'organizzazione.

Le metriche dovrebbero seguire la stessa disciplina. Contare il numero di attività delegate ci dice qualcosa sul volume, non sull'operato responsabile. Misure più utili possono includere il tasso con cui un flusso di lavoro scala perché un confine è cambiato, il tempo che una decisione attende a un gate, la proporzione di azioni consequenziali con un pacchetto decisionale completo, il numero di inversioni riuscite o il numero di casi in cui un controllo delle policy ha rifiutato una chiamata a uno strumento. Tali misurazioni richiedono comunque una definizione e un contesto. Non dovrebbero mai essere inventate per un opuscolo. Ma progettare i registri in modo che possano essere misurati è un segno che la responsabilità viene trattata come una proprietà operativa.

Il registro è dove sopravvive la responsabilità

Un sistema multi-agente produce un tipo di storia scomodo. Ha messaggi, chiamate a strumenti, output intermedi, controlli delle policy, versioni del modello, informazioni sui tempi, nuovi tentativi, assegnazioni modificate e forse approvazioni umane. Conservare ogni byte per sempre non è né necessario né spesso appropriato. Conservare solo la risposta finale di solito è troppo poco. Il registro deve preservare le decisioni e le evidenze che spiegano come il flusso di lavoro sia passato da una richiesta a un esito.

Per un'azione consequenziale, quel registro dovrebbe normalmente permettere a un revisore di ricostruire alcuni fatti di base. Qual era l'obiettivo? Quale policy o mandato rendeva il lavoro ammissibile? Chi o cosa ha ricevuto ogni assegnazione? Cosa è stato proposto a ogni gate consequenziale? Quali informazioni sono state usate per sostenere la proposta? Quali limiti, avvisi o fallimenti sono stati incontrati? Chi deteneva l'autorità di approvare, fermare o invertire l'azione? Quale azione è diventata effettiva e cosa è successo dopo? Queste non sono domande esotiche. Sono le domande che un'organizzazione pone quando vuole sapere se una decisione era la sua decisione.

Il registro deve distinguere un fatto operativo da una spiegazione prodotta in un secondo momento. Se un sistema dichiara che un revisore ha approvato un'azione, l'evento deve registrare l'identità o il ruolo del revisore, l'azione che gli è stata mostrata, il contesto pertinente e il momento in cui l'approvazione si è vincolata a quell'azione. Se il sistema dichiara che un modello ha selezionato un delegato, il registro deve conservare la regola di selezione, i candidati o i criteri al livello appropriato per l'uso, e l'assegnazione risultante. Una narrazione successiva può aiutare il lettore, ma non deve sostituire l'evento che si è verificato.

Il versionamento è importante in questo contesto. L'output di un agente può essere rigenerato. Una policy può essere aggiornata. Uno schema di strumento può cambiare. Un endpoint di modello può essere sostituito. Se una decisione dipende da una versione specifica di un prompt, di una policy, di un modello, di una fonte di conoscenza o di un'integrazione, il registro deve contenere un riferimento stabile a quella versione. Altrimenti la riproduzione diventa una messa in scena: riproduce ciò che l'organizzazione possiede in quel momento e definisce il risultato una spiegazione di ciò che è accaduto allora.

La reversibilità merita altrettanta attenzione. L'AI Act fa espresso riferimento, nel contesto della supervisione ad alto rischio, alla capacità di ignorare, annullare o invertire un output e di interrompere un sistema affinché si fermi in uno stato sicuro. In un percorso multi-agente, lo stato sicuro non è necessariamente un processo di modello arrestato. Può significare che non viene inviata alcuna comunicazione esterna, che un'azione in coda viene trattenuta, che un sistema a valle non viene aggiornato, che le credenziali temporanee non sono più utilizzabili per l'attività e che le prove necessarie per decidere cosa fare dopo vengono conservate. Questa è un'interpretazione operativa del requisito di supervisione, non una citazione della legge. È anche un utile test di progettazione.

Sicuro non significa congelato per sempre. Un flusso di lavoro interrotto necessita di un percorso di ripresa controllato. Qualcuno deve decidere se modificare l'attività, scartare la proposta, rieseguire una parte limitata del lavoro, usare uno strumento diverso, cercare ulteriori prove o abbandonare il percorso. Un registro pulito rende questa scelta più semplice perché comunica alla persona successiva cosa è noto, cosa è stato tentato, perché il lavoro si è fermato e quali effetti si sono verificati e quali no. Senza quel registro, il recupero diventa un'altra delega non strutturata, di solito intrapresa sotto maggiore pressione della prima.

Per questo la conservazione e l'accesso richiedono decisioni proprie. Non tutti gli attori dovrebbero poter leggere ogni traccia. Un registro può contenere dati personali, materiale commercialmente sensibile o dettagli rilevanti per la sicurezza. Ma l'accesso controllato non equivale all'assenza di registro. L'enfasi della Convenzione del Consiglio d'Europa su trasparenza, supervisione, responsabilità e rendiconto è un utile promemoria del fatto che il confine dovrebbe essere progettato piuttosto che dato per scontato. Un'organizzazione può preservare un percorso responsabile limitando l'accesso ai dettagli di cui un determinato revisore ha realmente bisogno.

Cosa dovrebbe rendere visibile un contratto di delega

Un contratto di delega può essere una struttura dati, uno schema di flusso di lavoro, un pacchetto di approvazione firmato o una combinazione di questi. La sua forma conta meno del suo contenuto. Deve comunicare all'attore ricevente cosa gli è consentito fare, cosa non gli è consentito fare e come verrà giudicato il lavoro. Quando questi vincoli sono assenti, gli agenti tendono a compensare con istruzioni sempre più elaborate. Questo può migliorare una singola esecuzione. Non crea un confine organizzativo che uno strumento, un revisore o un revisore contabile possa far rispettare.

Inizia con lo scopo previsto. Uno scopo deve essere abbastanza concreto da escludere attività simili. Confrontare i termini nelle proposte fornite è diverso da trovare il miglior fornitore. Riassumere i documenti ricevuti è diverso da accertare i fatti mancanti. Abbozzare una risposta per la revisione è diverso da comunicare una decisione. Il contrasto può sembrare pedante finché un agente non usa un'istruzione ampia per compiere un passo successivo ragionevole ma non autorizzato. Allora è la differenza tra un'iniziativa utile e un mandato senza limiti.

Indicare le classi di azioni consentite e vietate. A un agente può essere consentito di leggere un fascicolo del caso, estrarre campi nominati, confrontare con una policy e preparare una bozza. Può essergli vietato di modificare un record di origine, contattare una parte esterna, selezionare una nuova fonte o eseguire una transazione. Queste non sono semplici istruzioni nel prompt. Il livello di strumenti e flusso di lavoro dovrebbe applicarle dove praticabile. Una policy che non può essere verificata al momento dell'azione è comunque utile come guida, ma è più debole come controllo.

Indicare il proprietario e il percorso di escalation. Il proprietario non è necessariamente la persona che cliccherà su approva per ogni azione. È il ruolo responsabile dell'esito e della decisione su cosa accade quando il percorso arriva a una questione irrisolta. Il percorso di escalation identifica l'autorità successiva quando l'agente rileva una violazione dei confini, prove insufficienti, un conflitto tra fonti, una mancata corrispondenza con la policy o una condizione che il sistema non è autorizzato a risolvere. Una coda senza un proprietario decisionale nominato è semplicemente un ritardo con un'etichetta ottimistica.

Allegare una regola sulle prove. La regola può stabilire quali fonti sono autorevoli, se l'agente può cercare oltre esse, come viene rappresentata l'incertezza, cosa deve essere citato nella proposta e quando una fonte in conflitto richiede una revisione. Questo è particolarmente importante per i sistemi che generano prosa fluente. La fluidità può far sembrare una violazione dei confini un completamento utile. Una regola sulle prove rende disponibile la domanda corretta: il flusso di lavoro è rimasto all'interno del materiale che era autorizzato a utilizzare?

Impostare un limite di tempo, risorse e delega dove rilevante. Un'attività che può continuare indefinitamente può creare costi, congestione operativa o pressione a impegnare un risultato obsoleto. Un'attività che può delegare ripetutamente può creare una catena che nessun proprietario può facilmente ispezionare. Un design con limiti definiti stabilisce per quanto tempo l'attività rimane valida, quante risorse può consumare, se può creare una sottoattività, quale profondità massima è consentita e cosa accade quando viene raggiunto un limite. La risposta può essere una pausa automatica, un'escalation o un fallimento controllato. La parte importante è che sia decisa prima che il limite venga superato.

Infine, definire la condizione di completamento. Completato non significa sempre che l'agente ha prodotto testo. Può significare che un revisore ha ricevuto un pacchetto completo, che un gate di policy ha accettato un'azione specifica, che un sistema a valle ha confermato un aggiornamento reversibile, o che un proprietario responsabile ha scelto di non procedere. Le condizioni di completamento mantengono onesto il flusso di lavoro. Impediscono a un agente di trattare l'atto di proporre una decisione come se l'organizzazione ne avesse presa una.

Questi modelli sono utili sia che il flusso di lavoro contenga un singolo agente basato su modello sia un team più ampio di componenti specializzati. Più agenti non richiedono automaticamente più processi. Richiedono che i confini tra i ruoli siano espressi piuttosto che impliciti. Il costo di questa espressione è generalmente molto inferiore al costo di tentare di ricostruire l'autorità dopo che diversi sistemi hanno scambiato istruzioni parziali e uno di essi ha toccato il mondo esterno.

La delega dovrebbe rendere l'organizzazione più capace, non meno responsabile

I sistemi agente sono spesso descritti come se il loro valore risiedesse nel rimuovere l'organizzazione dal lavoro. La prospettiva più interessante è l'opposto. Un sistema progettato con cura può rendere più chiari gli impegni organizzativi: un'attività ha un proprietario, una delega ha un confine, un'azione consequenziale ha un'autorità, una revisione ha prove, un arresto ha uno stato sicuro e un record può essere riprodotto. Questo non è un ostacolo all'automazione utile. È ciò che consente all'automazione di assumere un lavoro significativo senza chiedere alle persone di fidarsi di una catena invisibile.

Abbiamo costruito Dweve Nexus attorno a questa distinzione. La sua documentazione di prodotto locale descrive attività durevoli, autorità valutata rispetto al contesto di runtime prima dell'azione, strutture di collaborazione esplicite che includono la delega, e una registrazione scritta mentre il lavoro accade. L'affermazione rilevante è volutamente modesta. Queste sono proprietà di progettazione pensate per rendere ispezionabile un percorso delegato. Non sono una prova che una particolare implementazione sia legittima, sicura o adatta, e non eliminano la necessità per un'organizzazione di decidere il proprio scopo, la propria autorità e la propria supervisione umana.

La lezione più ampia non dipende da un singolo prodotto. Un modello può decidere come dividere un compito. Un agente può chiedere lavoro a un altro agente. Uno strumento può eseguire un'azione. L'organizzazione deve comunque decidere dove risiede l'autorità. Deve farlo prima che la delega inizi, non dopo che un risultato finale è stato rifinito in qualcosa di difficile da mettere in discussione.

Questa è la risposta al titolo. Il proprietario di una decisione non è l'agente che per caso ha parlato per ultimo. È la persona o il ruolo a cui l'organizzazione ha assegnato l'autorità di accettare le conseguenze della decisione, con informazioni e potere sufficienti per rifiutarla. La delega è utile quando rende quella persona più capace. Diventa pericolosa quando la rende impossibile da trovare.

Fonti

• Regolamento (UE) 2024/1689, l'Artificial Intelligence Act, EUR-Lex
• Convenzione quadro del Consiglio d'Europa sull'intelligenza artificiale e i diritti umani, la democrazia e lo stato di diritto
• Parere EDPB 28/2024 sugli aspetti di protezione dei dati relativi al trattamento di dati personali nel contesto dei modelli di IA
• Fattori umani: introduzione, Health and Safety Executive del Regno Unito
• Dweve Nexus