Di seguito è riportata la traduzione in giapponese del discorso di apertura tenuto alla European Identity and Cloud Conference 2026 (EIC 2026), svoltasi a Berlino il 19 maggio. Le slide sono disponibili in formato PDF alla fine di questo documento.

L'era in cui il software non è più solo uno strumento.

Ciao a tutti.

Stiamo entrando in un'era in cui il software non è più semplicemente uno strumento.

Per molto tempo, il software si è limitato a eseguire istruzioni. Elaborava moduli, spostava dati, effettuava calcoli, imponeva flussi di lavoro e connetteva sistemi.

Ma ora il software sta iniziando a comportarsi come un dipendente umano.

Non sono dipendenti umani. Non sono aziende. Non sono colleghi nel senso umano del termine.

Si tratta di un attore digitale che si comporta come un dipendente.

Affidiamo loro missioni e compiti, diamo loro autonomia e forniamo gli strumenti necessari. Ci aspettiamo che si coordinino, prendano decisioni, riferiscano alla dirigenza, deleghino l'autorità e producano risultati concreti.

Quando un software raggiunge tali livelli di funzionalità, le questioni di governance assumono una forma diversa.

La domanda non è più semplicemente: "Il modello è in grado di rispondere correttamente?"

Non si tratta solo di stabilire se l'applicazione può chiamare l'API in modo sicuro.

La domanda da porsi è:

  • Chi ha approvato questo lavoro?
  • Di chi sono le intenzioni qui riflesse?
  • Che tipo di autorità è stata delegata?
  • Cosa è cambiato durante il processo di esecuzione?
  • Chi può fermare tutto questo?
  • E quando si presenteranno le conseguenze, chi ne sarà ritenuto responsabile?
  • Cioè.

Il software come personale e identità

A tal proposito, vorrei iniziare con una semplice proposta:

Quando un software diventa un dipendente, l'identità diventa la pietra angolare della governance.

L'obiettivo di Agentic AI non è solo la sicurezza dei modelli, né la sicurezza delle applicazioni. Al centro di tutto c'è la questione delle autorizzazioni delegate.

La delega di autorità implica sempre questioni di identità, proprietà, controllo, prove, responsabilità e fiducia.

Le applicazioni tradizionali operavano in genere entro i limiti di un'interfaccia definita. L'applicazione riceveva istruzioni, eseguiva funzioni e restituiva risultati.

Tuttavia, gli agenti sono diversi.

Agli agenti vengono assegnati obiettivi generali e loro decidono come raggiungerli. Ciò può comportare la selezione di strumenti, l'utilizzo di API, la creazione di sotto-attività, la collaborazione con altri agenti, l'adattamento alle circostanze e l'azione al di là dei confini organizzativi.

Questo è il motivo"Personale digitale"Quella frase è utile.

Naturalmente, questo non accade perché gli agenti siano umani.

Ricevere un obiettivo generale e poi decidere e mettere in pratica il metodo per raggiungerlo è ciò che tradizionalmente ci aspettiamo dal nostro personale.

Assegniamo loro dei compiti, diamo loro autonomia e ci aspettiamo dei risultati. E in definitiva, qualcuno deve assumersi la responsabilità delle loro azioni, come se fossero nostri subordinati.

Questo schema non si limita alle interazioni tra esseri umani e agenti; sta iniziando a emergere anche tra gli agenti stessi. Gli agenti che ricevono richieste ora dichiarano cosa possono fare, dove possono arrivare, quali competenze possiedono e quali certificazioni sono richieste, e i clienti esaminano queste informazioni prima di assegnare il lavoro.

La funzione che individua i metadati relativi alla parte richiedente è chiamata funzione di individuazione. La funzione di individuazione è utile anche in questo caso.

Tuttavia, nel momento in cui la fonte dei metadati sfugge al suo controllo, sorge spontanea la domanda: "Possiamo davvero fidarci?"

Non è immediatamente chiaro se ciò che dice quell'agente sia vero, né è chiaro chi si celi dietro di lui.

Potrebbe esserci uno stato che sponsorizza il terrorismo dietro tutto questo.

Ma ancor prima di ciò, sorge spontanea la domanda: l'agente con cui ho parlato ieri e l'agente con cui sono attualmente in contatto sono la stessa persona?

Continuità e coerenza dell'identità dell'agente

Passiamo ora al primo problema difficile.

Cosa significa per gli agenti essere "lo stesso agente"?

Per i dipendenti umani, esiste continuità e coerenza (uniformità) nella loro identità. Anche quando le persone imparano, cambiano ruolo e acquisiscono esperienza, rimangono la stessa persona in termini di responsabilità.

Tuttavia, nel caso degli agenti di intelligenza artificiale, tale continuità e coerenza non sono così evidenti.

Se il modello cambia, si tratta comunque dello stesso agente?

Se il messaggio di sistema cambia, si tratta dello stesso agente?

Se la memoria viene ripristinata, unita o condivisa, si tratta ancora dello stesso agente?

Cosa succede quando cambia la toolchain? Cosa succede quando il fornitore cambia la sua policy? Cosa succede quando cambia l'ambiente di runtime? Cosa succede quando un subagente viene sostituito? Cosa succede quando una missione viene passata da un esecutore a un altro? Cos'è esattamente questo "esso" di cui ci fidiamo?

E chi è il "proprietario" responsabile di queste azioni?

Ciò solleva quindi la seguente questione:

Chi è il proprietario o il controllore di fatto dell'agente?

Ogni agente che agisce con autorità necessita di un responsabile a cui rispondere.

Ho questo"Proprietario definitivo del bot (UBO)"と 呼 ん で い ま す.

UBO.

Questa espressione è intenzionale. Nell'ambito delle normative antiriciclaggio, il concetto di Titolare Effettivo dell'Attività (UBO, Ultimate Business Owner) è fondamentale. L'UBO a cui mi riferisco è proprio questo. L'importanza dell'UBO risiede nel fatto che la responsabilità non deve essere elusa da un'entità giuridica fittizia. È necessario comprendere di cosa si tratta prima di affidare qualsiasi incarico. 

Altrimenti, l'intera rete di agenti impiegati sarebbe esposta a rischi inaccettabili. Ciò è necessario per mitigare i rischi della catena di approvvigionamento. 

missione

Un altro aspetto che vorrei introdurre in questa presentazione è la nostra "missione". 

Questo è diverso da un "prompt". Un "prompt" è un'istruzione.

È anche diverso da una sessione. Una sessione è,Questo è un luogo dove gli agenti possono continuare il loro lavoro.La missione è diversa da quella.

Una missione è un mandato controllato conferito a un individuo o a un gruppo per raggiungere un obiettivo specifico; è il motivo per cui un agente è autorizzato a continuare a operare. Ciò include obiettivi, vincoli, autorità, risorse, tempistiche, politiche applicabili, requisiti probatori e un quadro di riferimento per la responsabilità delle azioni di una o più entità.

Missioni, agenti e sessioni sono concetti indipendenti e non vanno confusi. Una missione può durare più a lungo di un agente, oppure può terminare prima che un agente abbia completato il suo compito. Se una sessione è ancora in corso quando una missione termina, potrebbe essere opportuno terminare anche la sessione. 

Le azioni e le sessioni degli agenti sono vincolate dalla missione. Gli agenti devono agire solo per portare a termine la missione. 

Una missione deve avere un ambito chiaramente definito, essere verificabile, poter essere sospesa ed essere giustificata.

Altrimenti, i sistemi basati su agenti non solo eseguirebbero compiti, ma trasferirebbero anche autorizzazioni senza una registrazione affidabile della provenienza di tali autorizzazioni.

Gli esseri umani assegnano le missioni agli agenti. 

Gli agenti formulano i compiti e decidono le azioni da intraprendere nell'ambito dei poteri discrezionali delegati. 

Poiché gli agenti sono quasi sempre incapaci di assumersi la responsabilità, spesso diventa necessario coinvolgere gli esseri umani nel processo per ottenere l'approvazione. 

La supervisione umana è importante. 

Il giudizio umano è talvolta essenziale in azioni di grande impatto, procedimenti legali, decisioni regolamentate, trasferimenti finanziari, comunicazioni esterne o divulgazioni irreversibili.

Il problema della scala

Tuttavia, se proviamo a fare tutto in questo modo, ci troveremo ad affrontare problemi di scala. 

Un singolo lavoratore può gestire decine o addirittura centinaia di agenti. Per un'organizzazione, questo potrebbe significare migliaia di agenti.

Gli esseri umani non possono approvare in modo significativo ogni singolo passaggio. Anzi, ci sono persino studi che suggeriscono che, anche quando si ha a che fare con un solo agente, le conferme dopo il terzo tentativo per ogni compito diventano puramente nominali.

Se 100 agenti richiedessero l'approvazione uno dopo l'altro a una sola persona, l'approvazione diventerebbe inevitabilmente una questione di inerzia.

A questa scala, non si può affidare la direzione esclusivamente alla revisione umana. Il "controllo umano" non è necessariamente una forma di governance efficace.

Le approvazioni effettuate sotto pressione temporale e con informazioni incomplete non sono vere decisioni. Il Codice Claude si è già espresso in merito a questa situazione.

Si tratta di "elaborazione automatizzata" mascherata da giudizio umano.

Abbiamo bisogno dell'aiuto di un agente di intelligenza artificiale, un agente di supervisione che si schieri dalla parte del mandante, del delegante.

Questo agente valuta le prove e i segnali di rischio, filtra le informazioni irrilevanti e comunica al cliente, se necessario, le informazioni pertinenti. Inoltre, deve schierarsi dalla parte della persona o dell'organizzazione che ha originariamente delegato il lavoro. Deve essere leale al cliente, non a un sistema che cerca di portare a termine il compito.

L'agente di esecuzione deve inviare report strutturati all'agente di monitoraggio quando manifesta l'"intenzione" di eseguire un'azione e durante l'esecuzione. Eccezioni. Modifiche. Risultati.

La segnalazione di eventi di tipo Shared Signals potrebbe far parte di questo sistema nervoso. Ma disponiamo di standard concreti per implementare una segnalazione strutturata di questo tipo?

あ り ま せ ん.

E il segnale non è un interruttore di spegnimento.

Questa è solo una parte del livello di segnalazione. Abbiamo bisogno anche di un piano di controllo.

Il piano di controllo deve essere in grado di intervenire. Deve essere in grado di mettere in pausa le missioni, limitare i privilegi, disabilitare gli strumenti, bloccare la delega, revocare le credenziali, isolare la memoria, inoltrare la richiesta a personale umano o terminare la missione stessa.

Esistono protocolli standard per questi casi? No.

Il sistema Agentic AI è un sistema di transazioni distribuito.

Esiste un altro modo per comprendere il sistema agentivo.
Ecco come va visto: come un sistema di oggetti distribuito e un sistema di transazioni distribuito.

La missione ha inizio. L'agente richiama strumenti. Chiama API. Delega ai sub-agenti. Riscrive lo stato. Invia messaggi. E può produrre risultati esternamente.

È noto da tempo che l'elaborazione di transazioni a lungo termine è complessa nei sistemi distribuiti convenzionali. Il modello Saga considera le transazioni a lungo termine come un'unica unità, ma divisibile in sotto-transazioni.

L'IA agenteica si trova ad affrontare lo stesso problema, ma in modo ancora più complesso.

Il coordinatore può essere parzialmente non deterministico. L'esecutore può dipendere dal modello. Il passo successivo può dipendere dal contesto.

Pertanto, i compiti, gli strumenti e le competenze di ciascun sub-agente devono tutti dichiarare la semantica delle proprie conseguenze.

È possibile annullarlo? È previsto un risarcimento? Si possono compiere progressi verso la guarigione? O è irreversibile?

L'invio di bozze interne può essere revocato. La cancellazione di appuntamenti può essere risarcita. Le correzioni ai flussi di lavoro possono essere annullate. Tuttavia, la divulgazione di dati riservati è irreversibile.

Non si può gestire una missione senza sapere quali parti possono ancora essere riavvolte.

L'IA agentica trasforma le transazioni distribuite in processi decisionali distribuiti.

E tale giudizio deve essere circoscritto, osservabile e intercettabile.

Pubblicità dei metadati tramite schede agente

Ora i riflettori sono puntati sulle carte degli agenti.

La scheda agente è una descrizione di sé stesso, che include nome, provider, endpoint, capacità, competenze, metodo di autenticazione e requisiti di interazione. E un giorno, potrebbe persino essere in grado di rappresentare caratteristiche transazionali, come ad esempio se una transazione può essere annullata o meno.

Questi elementi sono importanti per la scoperta, la dichiarazione delle funzionalità, l'individuazione degli endpoint e la selezione del protocollo. Tuttavia, è fondamentale avere una comprensione precisa di cosa risolvono e cosa non risolvono.

La scheda dell'agente potrebbe indicare cosa quell'agente dichiara di essere in grado di fare. Tuttavia, ciò di per sé non indica cosa l'agente sia effettivamente in grado di fare.

  • Non dimostrerò di essere adatto a questa missione.
  • Inoltre, ciò non dimostra che il tempo di esecuzione sia affidabile.
  • Inoltre, non verifica il modello, il prompt, la memoria o le versioni dei criteri.
  • Neanche Ultimate-Bot-Owner lo dimostra. E,
  • La parte che si affida a questo agente non garantisce che ci si possa fidare di lui in questa transazione.

Le tessere di agente autodichiarate sono insufficienti dal punto di vista della governance.

Anche una carta d'identità dell'agente firmata rappresenta solo un passo avanti. La firma ci dice semplicemente che una persona chiave ha firmato un documento.

Il verificatore deve inoltre stabilire se il firmatario, la chiave, l'emittente e il quadro di fiducia siano idonei a tale scopo.

  • L'identificazione non implica fiducia.
  • La scoperta non costituisce autorità.
  • I metadati non sostituiscono la responsabilità.

Modello SPIFFE/SPIRE

I modelli SPIFFE e SPIRE sono utili quando si prendono in considerazione questi aspetti.

SPIFFE e SPIRE non sono specifiche standard per la governance degli agenti. Tuttavia, forniscono modelli da cui possiamo trarre insegnamento.

Un carico di lavoro non dovrebbe limitarsi a dichiarare la propria identità; dovrebbe essere autenticato prima di poterla identificare.

Tuttavia, per Agentic AI, l'identità del carico di lavoro è solo il punto di partenza.

La dichiarazione può aiutare a rispondere alla domanda: "Cosa si sta facendo?"

Tuttavia, l'attestazione non può rispondere alle seguenti domande.

  • Di chi è la missione che viene portata a termine?
  • Che tipo di autorità è stata delegata?
  • Quale modello o suggerimento è stato utilizzato?
  • Quale politica è stata applicata?
  • È possibile ottenere un risarcimento per tale azione?
  • Chi è il beneficiario finale (UBO)?

Pertanto, oltre alla prova del carico di lavoro, sono richiesti la prova della missione, la prova dell'autorizzazione, la semantica delle transazioni e i report di monitoraggio.

Creazione di strutture di fiducia attraverso la federazione

È qui che entra in gioco il concetto di "federazione".

La scheda dell'agente indica cosa viene richiesto.

L'attestazione fornisce informazioni su ciò che viene fatto.

Le federazioni possono aiutarti a determinare di quali affermazioni o attestazioni fidarti.

La federazione OpenID definisce come le entità che desiderano interagire tra loro stabiliscono rapporti di fiducia tramite terze parti fidate chiamate "ancore di fiducia". Supporta più livelli di autorità e una singola entità può appartenere a più federazioni. Fornisce inoltre i componenti tecnici dell'infrastruttura di fiducia per la creazione di reti di fiducia dinamiche e decentralizzate.

La federazione ci consente di verificare se la chiave di firma appartiene a un'entità all'interno di un framework di fiducia da noi approvato, se esiste una catena di fiducia valida, se vengono applicate le politiche sui metadati e se il marchio di fiducia è significativo per questa parte dipendente.

Questo è estremamente importante nella gestione degli agenti.

Un mondo in cui ogni parte deve decidere manualmente se accettare o rifiutare ogni agente, fornitore, registro, emittente di attestazioni e titolare effettivo non è auspicabile.

Sono necessarie una catena di fiducia e delle politiche sui metadati. È indispensabile un meccanismo per determinare quali rivendicazioni accettare prima di esercitare qualsiasi autorità. A tal fine, un meccanismo di federazione risulta molto utile.

L'importanza dell'utilizzo degli standard

Esistono già molti componenti utili per raggiungere questi obiettivi. Le sole specifiche relative a OpenID includono quelle elencate qui. 

  • OpenID Connect
  • OpenID4VCI/VP
  • AuthZEN
  • Federazione OpenID
  • Framework OpenID per segnali ed eventi condivisi
  • ecc.

Molte di queste sono state verificate matematicamente e formalmente da una prospettiva di sicurezza. 

Certo, tutto ciò da solo non basta. Tuttavia, dovremmo riutilizzare ciò che è riutilizzabile e costruire solo ciò che è veramente necessario. 

Sfide in materia di responsabilità e attuariali

Infine, vorrei porre la domanda a cui la governance inevitabilmente giunge.

Chi sopporterà la perdita?

Quando un agente divulga dati, indirizza erroneamente i pagamenti, manipola i flussi di lavoro, invia istruzioni errate o innesca una reazione a catena dannosa, di chi è la responsabilità ultima?

Anche da questa prospettiva, Ultimate-Bot-Owner diventa importante.

Ed è qui che le prove diventano cruciali. Senza prove, la responsabilità si indebolisce. L'individuazione della causa diventa mera speculazione e l'assicurazione si riduce a una mera congettura.

Attualmente, le basi attuariali per la valutazione dei rischi associati all'IA agentica sono ancora in una fase iniziale. Tuttavia, ciò non significa che dovremmo aspettare. È giunto il momento di costruire l'infrastruttura di misurazione.

L'assicurazione non si riduce solo agli slogan. Servono dati sul grado di esposizione al rischio, la frequenza degli eventi, la gravità dei danni, l'efficacia della gestione, i nessi causali e le perdite.

Il software sta diventando un dipendente.

La governance in queste materie sta diventando necessaria. 

Esistono specifiche standard che possono essere utilizzate. 

Tuttavia, la semplice creazione di un'infrastruttura di agenti ben governata non è sufficiente. Ci sono molte lacune da colmare. 

Per la community di Identerati, il nostro percorso verso la creazione di un ecosistema di agenti affidabile è appena iniziato. 

Lavoriamo tutti insieme e iniziamo a realizzarlo subito.

Diapositive (PDF)

Quando il software diventa personale-08-EN