Introduzione
AI agentico modifica il perimetro della due diligence perché il software può passare dalla produzione di informazioni all'avvio di azioni. Un agente può predisporre un pagamento, creare un utente, modificare l'infrastruttura cloud, comunicare con un cliente, impegnare scorte, approvare un rimborso, presentare una comunicazione o preparare una conclusione regolamentata. Lo stesso modello può essere a basso rischio in un flusso di ricerca in sola lettura e critico per l'operazione quando è collegato a credenziali e strumenti di produzione. Il team di acquisizione deve quindi svolgere due diligence su autorità e conseguenze a livello di flusso di lavoro.
Il panorama attuale degli standard è in evoluzione. NIST ha lanciato a febbraio 2026 una AI Agent Standards Initiative e ha separatamente proposto attività sull'identità e sull'autorizzazione di software e agenti AI [7-10]. I materiali pubblicati identificano l'identificazione, l'autorizzazione, l'audit, il non ripudio e i controlli contro il prompt injection come questioni pratiche. OWASP descrive l'agentività eccessiva come una combinazione di funzionalità, permessi o autonomia in eccesso e raccomanda il privilegio minimo, l'autorizzazione a valle e l'approvazione umana per le azioni ad alto impatto [17-19]. Queste fonti definiscono utili domande di controllo. Non stabiliscono che un target abbia implementato i controlli né che una particolare allocazione di responsabilità sia giuridicamente efficace.
La supervisione umana deve anche operare nei fatti. L'articolo 14 dell'AI Act dell'Unione europea impone che determinati sistemi ad alto rischio siano progettati per una supervisione efficace, inclusa la capacità di ignorare, sovrascrivere, invertire o interrompere gli output ove appropriato [23-24]. Un pulsante di approvazione mostrato non dimostra che un revisore abbia compreso l'azione, disponesse di informazioni sufficienti, avesse l'autorità appropriata o potesse impedirne l'esecuzione. La due diligence sull'operazione deve testare l'intero percorso dalla richiesta alla conseguenza e al rimedio.
Il presente articolo fornisce tale percorso. Tratta la responsabilità come un'esposizione economica che richiede consulenza legale, e i permessi come un sistema tecnico e organizzativo che richiede evidenze di sicurezza. Collega poi entrambi a prezzo, protezione dell'operazione e integrazione. Il framework è progettato per acquirenti strategici, sponsor di private equity, consigli di amministrazione, team di transazione e finanziatori che valutano un'attività di agenti AI o un target abilitato da AI.
1 Definire la decisione di acquisizione e il perimetro di responsabilità
Il primo documento dovrebbe indicare perché l'acquirente sta acquisendo l'attività e quale capacità agentica è inclusa nel valore. La tesi può dipendere dalla distribuzione della clientela, da dati proprietari sui flussi di lavoro, da un costo del servizio inferiore, da un team specializzato, dall'automazione delle operazioni dell'acquirente o dalla proprietà di un livello di controllo. Ogni tesi crea diverse questioni di responsabilità e integrazione. Un prodotto acquisito per l'implementazione interna può esporre direttamente l'acquirente a conseguenze nei confronti di dipendenti, clienti e autorità di regolamentazione che erano limitate quando il target operava come fornitore.
Il perimetro dovrebbe identificare ogni entità giuridica, prodotto, agente, flusso di lavoro, ambiente, configurazione del cliente, modello, connettore, strumento, credenziale, account di servizio, motore di policy, servizio di approvazione, archivio dati e processo di gestione degli incidenti. Dovrebbe distinguere i componenti di proprietà del target dalle identità controllate dal cliente, dal software open source, dai modelli di terzi e dalle piattaforme dei partner. Una dimostrazione può mostrare un'azione senza mostrare quale autorità sia stata utilizzata o se tale autorità si trasferisca al closing.
L'acquirente dovrebbe elencare le azioni con conseguenze prima di esaminare l'architettura generica. Conseguenza include il movimento di denaro, la creazione o l'estinzione di diritti, la divulgazione di informazioni, le modifiche ai sistemi di produzione, le dichiarazioni a clienti o autorità di regolamentazione, le decisioni in materia di occupazione, gli effetti sulla sicurezza e la pubblicazione irreversibile. L'elenco diventa il registro organizzativo per la due diligence legale, di sicurezza, finanziaria, operativa e assicurativa.
Le passività dovrebbero essere separate in obblighi osservati, pretese avanzate, obbligazioni possibili e rischio operativo prospettico. Lo IAS 37 definisce i principi per gli accantonamenti e le passività potenziali, mentre l'IFRS 3 disciplina le passività assunte in un'aggregazione aziendale [1-3]. La conclusione contabile è specifica per l'operazione. La documentazione di due diligence dovrebbe conservare fatti, intervalli, incertezza e consulenti responsabili anziché sostituire un punteggio tecnico all'analisi legale o contabile.
2 Mappare la catena principale-agente-autorità
Ogni azione in produzione dovrebbe essere tracciabile attraverso una catena principale-agente-autorità. Il principale è la persona o l'organizzazione il cui obiettivo viene perseguito. L'agente è l'istanza software che opera all'interno di un flusso di lavoro definito. L'autorità è l'insieme delimitato di azioni che il principale o un'altra parte autorizzata ha delegato. La catena comprende inoltre l'identità utilizzata, la politica applicata, lo strumento selezionato, i parametri forniti, l'approvazione ricevuta, la risposta di esecuzione e le evidenze conservate.
Il target dovrebbe dimostrare come viene rappresentata l'autorità di un utente. Un agente che agisce per un dipendente tramite lo scope OAuth di quel dipendente differisce da un agente che utilizza un account di servizio privilegiato condiviso. L'account condiviso può essere operativamente comodo ma indebolisce l'attribuzione, la segregazione e la revoca. L'acquirente dovrebbe verificare se l'autorità delegata resta limitata da utente, finalità, risorsa, tempo, valore e tipo di azione.
L'autorità può andare persa nell'orchestrazione. Un agente coordinatore può delegare ad agenti specializzati che chiamano strumenti tramite un'altra piattaforma. Il sistema finale può registrare solo l'ultima chiamata allo strumento. La due diligence dovrebbe ricostruire l'intera catena di delega e verificare che un componente a valle non possa ottenere un'autorità maggiore rispetto al principale di origine. Il controllo dovrebbe essere applicato da un sistema attendibile, non soltanto da istruzioni interpretate da un modello.
Il non ripudio è importante quando l'azione genera una contestazione. La documentazione dovrebbe indicare quale identità autenticata ha richiesto il lavoro, quale agente e versione hanno operato, quali evidenze sono state presentate, quale persona ha approvato, quale azione esatta è stata eseguita e se la documentazione può essere alterata. L'attuale lavoro del NIST sull'identità degli agenti evidenzia audit e non ripudio come aree su cui concentrare l'attenzione in fase di implementazione [8-10]. L'acquirente dovrebbe ispezionare l'implementazione del target e verificare record rappresentativi.
3 Costruire il grafo dei permessi in produzione
Un inventario dei permessi è insufficiente quando elenca account senza collegarli alle azioni. Il grafo dei permessi in produzione dovrebbe collegare principali, agenti, strumenti, risorse, funzioni, ambienti e regole di approvazione. Dovrebbe mostrare sia i permessi espliciti sia l'accesso effettivo ereditato tramite gruppi, ruoli, token, piattaforme e integrazioni con i clienti. Privilegi temporanei, ruoli di emergenza e connettori dormienti appartengono allo stesso grafo.
Le autorizzazioni dovrebbero essere classificate per operazione: scoprire, leggere, creare, modificare, eliminare, approvare, eseguire, esportare, impersonare, delegare e amministrare. Il grafo dovrebbe distinguere la produzione dal test e gli ambienti interni da quelli dei clienti. Dovrebbe inoltre identificare se una credenziale può essere utilizzata al di fuori del percorso previsto per l'agente. Uno strumento descritto in modo restrittivo può comunque essere eseguito con un account dotato di ampi permessi su database, cloud o sistemi di messaggistica.
L'acquirente dovrebbe confrontare i permessi richiesti ed effettivi. Il permesso richiesto deriva dall'attività definita e dalla promessa al cliente. Il permesso effettivo è ciò che l'identità e il sistema sottostante consentono realmente. La differenza è l'eccesso di permessi. L'eccesso dovrebbe essere quantificato in base alle risorse raggiungibili, ai tipi di azione e alle potenziali conseguenze. Un target può ridurre le opzioni di interfaccia pur mantenendo un'ampia autorità a valle, lasciando invariato il raggio d'impatto.
Le evidenze dovrebbero includere le esportazioni correnti del provider di identità, i ruoli cloud e applicativi, le definizioni degli strumenti, le configurazioni dei connettori, policy-as-code, la durata dei token, gli archivi dei segreti, le regole di approvazione e i test di revoca. Gli screenshot e i documenti di policy forniscono contesto. Le esportazioni leggibili da macchina e l'esecuzione osservata forniscono evidenze più solide dello stato di produzione.
4 Classificare le azioni per conseguenze e reversibilità
La classificazione delle azioni determina quali controlli e risposte da adottare nell'operazione sono proporzionati. Una matrice utile assegna un punteggio a conseguenze finanziarie, effetti legali, sensibilità delle informazioni, interruzioni operative, visibilità esterna, popolazione interessata e reversibilità. Il punteggio dovrebbe basarsi sul risultato plausibile dell'azione, incluse le azioni concatenate, anziché sull'apparente semplicità della chiamata allo strumento.
La reversibilità richiede più di un comando opposto. Un record eliminato può essere ripristinato mentre una divulgazione esterna non può essere richiamata. Un pagamento può talvolta essere stornato dopo il trasferimento dei fondi, soggetto a ritardi e rischio di recupero. Un messaggio al cliente può essere corretto mentre l'affidamento contrattuale o il danno reputazionale permane. La classificazione dovrebbe pertanto distinguere azioni tecnicamente reversibili, operativamente recuperabili, finanziariamente recuperabili ed effettivamente irreversibili.
La velocità delle azioni influisce sull'esposizione. Una decisione debole eseguita una volta sotto revisione differisce dalla stessa debolezza eseguita su migliaia di account prima del rilevamento. Limiti su valore, volume, frequenza e popolazione di clienti possono circoscrivere la perdita. L'acquirente dovrebbe verificare se i limiti si applicano al punto di applicazione della policy e se un agente può suddividere l'attività su più chiamate per eluderli.
La classificazione dovrebbe orientare l'approvazione, la registrazione, il monitoraggio, il recupero e l'analisi assicurativa. La raccolta di evidenze in sola lettura può operare sotto controlli automatizzati. La preparazione di un'azione con conseguenze può richiedere validazione. L'esecuzione di un'azione irreversibile o visibile all'esterno può richiedere una persona autorizzata indipendente. I requisiti legali effettivi dipendono dal flusso di lavoro e dalla giurisdizione.
5 Testare l'applicazione della policy al di fuori del modello
Le istruzioni in linguaggio naturale possono guidare un agente. Non dovrebbero essere l'unico meccanismo che autorizza un'azione con conseguenze. L'acquirente dovrebbe identificare il punto di applicazione della policy che convalida ogni richiesta dello strumento rispetto a identità, risorsa, azione, contesto e limiti. La mediazione completa significa che ogni richiesta pertinente viene verificata, comprese le ripetizioni e le chiamate effettuate tramite agenti secondari o credenziali in cache.
Le linee guida di OWASP sull'agentività eccessiva raccomandano di limitare funzionalità, permessi e autonomia e di applicare l'autorizzazione nei sistemi a valle [17]. Il team di acquisizione dovrebbe testare questi controlli tramite scenari avversariali e ordinari. Dovrebbe tentare risorse non consentite, parametri modificati, prompt injection indiretta, autorità scaduta, istruzioni in conflitto, chiamate ripetute e richieste che superano i limiti di valore o di volume.
Anche la modifica delle policy ha conseguenze. Il target dovrebbe mostrare chi può modificare gli schemi degli strumenti, le azioni consentite, le soglie di approvazione, i prompt di sistema, il routing del modello e i ruoli degli account di servizio. Le modifiche dovrebbero seguire segregazione, revisione, test, rilascio e rollback. Uno sviluppatore che può modificare sia la logica dell'agente sia la policy di produzione potrebbe essere in grado di aggirare un controllo di approvazione nominale.
L'acquirente dovrebbe conservare evidenze di test che colleghino la versione della policy alla versione di produzione. Un controllo di laboratorio è utile solo se lo stesso percorso di applicazione opera per il lavoro destinato ai clienti. Le eccezioni, gli accessi di emergenza e le sovrascritture manuali dovrebbero avere autorità definita, durata limitata, registrazione rafforzata e revisione retrospettiva.
6 Distinguere raccomandazione, preparazione, approvazione ed esecuzione
I team addetti alle operazioni dovrebbero evitare una classificazione binaria tra umano o autonomo. Un flusso di lavoro può osservare le evidenze, raccomandare un'azione, preparare un'operazione, richiedere approvazione, eseguire un'operazione approvata e verificare il risultato. Componenti diversi possono essere responsabili di ciascuna fase. La mappa di due diligence dovrebbe identificare dove l'informazione diventa una decisione e dove una decisione diventa un cambiamento nel mondo reale.
Una raccomandazione può comunque generare responsabilità quando viene presentata come definitiva, sulla quale si fa affidamento in modo sistematico o generata da dati non autorizzati. La preparazione può creare rischio quando compila un pagamento, un contratto o una configurazione che i revisori approvano abitualmente. L'approvazione può essere debole quando il revisore vede solo un riepilogo. L'esecuzione può discostarsi dall'azione approvata se i parametri o lo stato cambiano dopo l'approvazione.
L'acquirente dovrebbe verificare il vincolo tra approvazione ed esecuzione. Il record di approvazione dovrebbe identificare l'azione esatta, la risorsa, l'importo, la controparte, la policy e la scadenza. Le modifiche sostanziali dovrebbero invalidare l'approvazione. L'esecuzione dovrebbe rifiutare approvazioni scadute, alterate o riprodotte. Il sistema dovrebbe conservare sia gli stati proposti sia quelli eseguiti e riconciliare le differenze.
Questa separazione informa anche la valutazione. Un prodotto che prepara in modo affidabile il lavoro sotto l'autorità umana può generare valore sostanziale senza esecuzione autonoma. Le previsioni del management non dovrebbero presumere che eliminare l'approvazione aumenti il valore quando clienti, autorità di regolamentazione o assicuratori richiedono responsabilità. Il modello economico dovrebbe includere il costo e la capacità di elaborazione del modello di controllo effettivamente accettato dai clienti.
7 Valutare se l'override umano è efficace
L'etichetta human-in-the-loop dovrebbe essere scomposta in capacità, informazioni, autorità, tempistica, indipendenza e carico di lavoro. Il revisore necessita di informazioni sufficienti per comprendere l'azione e le sue conseguenze. Il revisore deve avere l'autorità effettiva di rifiutarla, modificarla o interromperla. L'intervento deve avvenire prima di un'esecuzione irreversibile o con sufficiente anticipo per contenere il danno.
Il design dell'interfaccia è importante. La schermata di approvazione dovrebbe distinguere le spiegazioni generate dal modello dalle evidenze di origine, mostrare i parametri chiave ed evidenziare le eccezioni alle policy. Dovrebbe evitare impostazioni predefinite manipolatorie e aggregazioni ambigue. L'affaticamento da approvazione può trasformare un controllo nominale in una conferma di routine. L'obiettivo dovrebbe misurare volume delle revisioni, tempo, rifiuti, modifiche, escalation e risultati a valle.
L'indipendenza dipende dall'azione. Un utente può approvare un flusso di lavoro ordinario, mentre un'azione finanziaria, di sicurezza o regolamentata richiede un ruolo diverso. La segregazione dei compiti dovrebbe essere implementata nell'identità e nelle policy, non solo documentata. L'agente non dovrebbe poter selezionare il proprio revisore, sopprimere evidenze scomode o riscrivere la richiesta di approvazione dopo una decisione umana.
I meccanismi di override e arresto dovrebbero essere testati in condizioni di carico e di guasto. L'acquirente dovrebbe osservare la revoca delle credenziali di un agente, l'interruzione delle azioni in coda, il contenimento del lavoro in corso e il ripristino sicuro. L'articolo 14 del Regolamento AI dell'UE individua il monitoraggio, l'interpretazione, l'override, l'inversione e l'interruzione come capacità di vigilanza rilevanti per determinati sistemi ad alto rischio [23]. L'applicabilità richiede un'analisi legale; i test operativi restano utili in tutte le operazioni.
8 Ricostruire incidenti, quasi incidenti e interventi nascosti
La due diligence sugli incidenti dovrebbe includere azioni non autorizzate, permessi eccessivi, prompt injection, esposizione dei dati, decisioni errate, approvazioni fallite, riproduzione, uso improprio degli strumenti, costi fuori controllo, reclami dei clienti e aggiramento dei controlli. I quasi incidenti e i ripristini manuali sono preziosi perché mostrano dove il sistema ha quasi creato una conseguenza o ha dipeso da interventi non documentati.
L'acquirente dovrebbe riconciliare diversi registri: ticket di sicurezza, supporto clienti, crediti di servizio, problemi di ingegneria, fallimenti nella valutazione dei modelli, log cloud, avvisi assicurativi, rivendicazioni legali, rimborsi e reportistica al consiglio. Un unico registro può omettere eventi classificati come qualità del prodotto, successo del cliente o errore operativo. Identificatori comuni e l'analisi della cronologia possono rivelare eventi correlati.
Per ciascun evento, la due diligence dovrebbe identificare la condizione scatenante, i permessi utilizzati, il momento di rilevamento, l'ambito interessato, il contenimento, il ripristino, la comunicazione al cliente, il costo, la valutazione legale e la validazione delle misure correttive. Le etichette di causa radice dovrebbero distinguere comportamento del modello, dati, orchestrazione, strumento, identità, policy, interfaccia, revisione umana e processo organizzativo.
L'intervento nascosto influisce sia sul rischio sia sull'economia. Gli specialisti possono monitorare gli agenti in modo continuativo, correggere azioni e tranquillizzare i clienti senza comparire nelle metriche di prodotto. L'acquirente dovrebbe campionare i flussi di lavoro dalla richiesta al risultato finale e riconciliare il tempo umano con i sistemi di retribuzione e supporto. Un modello di acquisizione che elimina questa manodopera prima che i controlli siano riprogettati può aumentare la responsabilità sovrastimando al contempo le sinergie.
9 Quantificare l'esposizione attraverso coorti di azioni
L'esposizione attesa dovrebbe essere stimata per coorte di azioni anziché tramite un'unica probabilità a livello aziendale. Le coorti possono essere definite per flusso di lavoro, classe di azione, cliente, giurisdizione, livello di autorizzazione, struttura di approvazione, versione del modello e ambiente. Ogni coorte dovrebbe disporre di misure osservate relative a volume, eccezioni, tentativi non autorizzati, override, annullamenti, incidenti e ripristino.
Un modello semplificato di perdita attesa moltiplica il volume delle azioni per la probabilità e la conseguenza dell'evento, quindi aggiunge i costi di rilevamento, risposta, per il cliente, legali, normativi e di remediation. Gli scenari di coda richiedono un trattamento separato perché la frequenza storica può essere bassa e l'impatto concentrato. La correlazione è importante quando una policy, una credenziale, un modello o un connettore condivisi influiscono simultaneamente su molti clienti.
Le ipotesi del management dovrebbero essere esplicite e tenute separate dalle evidenze osservate. L'assenza di contestazioni non dimostra una bassa probabilità quando lo storico di implementazione è breve, le autorizzazioni sono state ampliate di recente o gli incidenti non sono stati registrati. I benchmark esterni possono orientare la progettazione degli scenari ma raramente corrispondono al flusso di lavoro, ai controlli e all'allocazione contrattuale del target.
Il modello dovrebbe mostrare l'esposizione lorda, le ipotesi assicurative, i massimali contrattuali, i diritti di indennizzo, la recuperabilità e l'esposizione residua. La recuperabilità dovrebbe essere verificata con riguardo a esclusioni, limiti, notifica, ritenzione, merito creditizio della controparte e tempistiche. La decisione di acquisizione dovrebbe restare solida anche se il recupero è ritardato o contestato.
10 Esaminare i contratti con i clienti e l'allocazione delle responsabilità
I contratti con i clienti dovrebbero essere mappati rispetto al flusso di lavoro effettivo. Le clausole rilevanti includono descrizione del servizio, uso consentito, istruzioni del cliente, approvazione, ruoli sui dati, modifiche al modello e ai subresponsabili del trattamento, sicurezza, audit, notifica degli incidenti, garanzie, esclusioni di responsabilità, livelli di servizio, indennizzi, massimali di responsabilità, assicurazione, risoluzione e transizione. L'acquirente dovrebbe confrontare le eccezioni negoziate tra i clienti.
La responsabilità può essere suddivisa tra fornitore, cliente, fornitore del modello, piattaforma cloud, partner di integrazione e utente finale. Una clausola che stabilisce che il cliente resta responsabile delle decisioni può avere valore pratico limitato se il prodotto esegue azioni senza un controllo effettivo del cliente o se il processo di vendita ha prospettato un esito gestito. I consulenti legali dovrebbero valutare l'azionabilità e la condotta in ciascuna giurisdizione.
Il team di due diligence dovrebbe riconciliare le autorizzazioni contrattuali con quelle tecniche. Se il contratto autorizza un accesso in sola lettura mentre le credenziali di produzione consentono modifiche, il divario è critico per l'operazione. Se i clienti richiedono un'approvazione prima delle modifiche al modello, la target dovrebbe dimostrare come vengono gestite le versioni e le notifiche. Controlli specifici del cliente non documentati possono ritardare l'integrazione.
La qualità dei ricavi è legata all'allocazione delle responsabilità. Il pricing basato sui risultati può aumentare la disponibilità a pagare trasferendo il rischio operativo al fornitore. Gli impegni minimi possono sostenere la liquidità mentre i clienti si riservano ampi diritti di recesso o crediti di servizio. Il modello dovrebbe includere i costi di erogazione e controllo richiesti dall'impegno effettivo.
11 Valutare i percorsi normativi e giurisdizionali
L'AI agentica può intersecarsi con norme di settore, consumeristiche, del lavoro, finanziarie, sulla privacy, sulla cybersecurity, di prodotto, sulla concorrenza e professionali. Il team dell'operazione dovrebbe mappare ogni flusso di lavoro rilevante rispetto all'entità giuridica che lo fornisce, all'ubicazione del cliente, alla persona interessata, all'ubicazione dei dati e al tipo di decisione. Un prodotto globale può avere obblighi e allocazioni di rischio diversi a seconda delle implementazioni.
L'AI Act dell'UE istituisce un quadro basato sul rischio e include requisiti di supervisione umana per i sistemi ad alto rischio [23-24]. Le autorità di protezione dei dati pubblicano orientamenti sul processo decisionale automatizzato, sulla responsabilità e sulla governance dei dati [25-26]. I requisiti federali e statali statunitensi continuano a svilupparsi, mentre i regolatori di settore possono applicare le leggi esistenti ai comportamenti abilitati da AI. L'articolo non fornisce una conclusione giuridica sull'applicabilità.
L'acquirente dovrebbe richiedere l'inventario legale del target, le analisi di classificazione, le valutazioni d'impatto, la corrispondenza con i regolatori, le dichiarazioni dei clienti e il processo di monitoraggio delle modifiche. Dovrebbe verificare se l'inventario è collegato al prodotto e alle giurisdizioni attuali. Una policy generica può essere obsoleta quando cambiano i flussi di lavoro, le autorizzazioni o le popolazioni di clienti.
Il cambiamento normativo rientra nella valutazione e nell'integrazione. Il lavoro di conformità può richiedere nuovi ruoli di approvazione, controlli sui dati, documentazione, test, comunicazioni ai clienti o limitazioni del prodotto. Il modello dell'operazione dovrebbe includere effetti su costi, tempi e ricavi. Le condizioni di closing possono essere appropriate laddove l'esercizio lecito o il trasferimento dipendano da un consenso rilevante o da un rimedio.
12 Verificare privacy dei dati, proprietà intellettuale e riservatezza
Le autorizzazioni ad agire spesso implicano autorizzazioni ad accedere ai dati. L'acquirente dovrebbe mappare fonti dei dati, finalità, base giuridica, istruzioni del cliente, conservazione, trasferimento, uso del modello ed eliminazione per ciascun flusso di lavoro. La memoria dell'agente, le tracce e l'osservabilità possono replicare informazioni sensibili al di fuori del sistema principale. I risultati degli strumenti possono introdurre dati da una fonte a cui l'utente non era autorizzato ad accedere.
Il registro dei diritti dovrebbe coprire codice, prompt, policy, schemi degli strumenti, design dei workflow, set di valutazione, configurazioni dei clienti, dati di addestramento e feedback, documentazione, brevetti, marchi e segreti commerciali. Dovrebbe identificare creatore, cessione, licenza, restrizione, sublicenza, cambio di controllo e risoluzione. L'accesso ai dati dei clienti necessario per fornire un servizio non crea automaticamente un'attività trasferibile.
Il rischio di riservatezza si estende alle azioni. Un agente può inviare informazioni, popolare un sistema esterno o divulgare il ragionamento tramite un'interfaccia di approvazione. L'acquirente dovrebbe testare liste consentite di destinazione, prevenzione della perdita di dati, oscuramento, segregazione dei clienti e registrazione. Dovrebbe verificare che i controlli si applichino ai nuovi tentativi, agli agenti secondari e agli strumenti di supporto.
IFRS 3 e IAS 38 forniscono requisiti contabili rilevanti per le attività immateriali identificabili in un'aggregazione aziendale [1,4]. L'allocazione del prezzo di acquisto non risolve la questione se l'acquirente abbia l'autorità operativa per utilizzare i dati dei clienti o la tecnologia di terzi. L'analisi legale e tecnica del trasferimento dovrebbe precedere le ipotesi di valutazione.
13 Valutare modelli di terzi, strumenti e protocolli degli agenti
I prodotti agentici dipendono comunemente da fornitori di modelli, cloud, sistemi di identità, applicazioni aziendali, servizi dati e connettori. L'acquirente dovrebbe censire ogni dipendenza, accordo, ambito di autorizzazione, livello di servizio, prezzo, trattamento dei dati, diritto di audit, controllo delle modifiche, continuità, indennità e risoluzione. Una dipendenza materiale può trovarsi dietro uno strumento o un protocollo invece di comparire nell'architettura principale del target.
L'interoperabilità dei protocolli può aumentare la distribuzione e ampliare anche la superficie delle autorizzazioni. L'acquirente dovrebbe identificare come i server e gli strumenti vengono scoperti, autenticati, descritti e considerati affidabili. I metadati degli strumenti possono influenzare la selezione del modello. Gli aggiornamenti a un connettore o a uno schema possono modificare il comportamento effettivo senza un cambio di modello. Dovrebbero essere esaminati registri, firma, liste consentite, blocco delle versioni e test.
I termini del fornitore possono attribuire la responsabilità al target anche quando il guasto ha origine in un servizio di terzi. Il target potrebbe quindi dover corrispondere a un cliente più di quanto possa recuperare. Il modello della transazione dovrebbe mostrare la catena di tetti massimi, esclusioni e assicurazioni. La concentrazione dovrebbe includere dipendenze comuni da modelli, cloud, identità e connettori tra i clienti.
Le dichiarazioni di portabilità richiedono un test simile alla produzione. Sostituire un modello o uno strumento può modificare comportamento, latenza, costo, valutazione e approvazione del cliente. L'acquirente dovrebbe misurare la transizione e qualsiasi periodo di funzionalità limitata. Un diagramma multi-fornitore senza sostituzione testata è una prova debole di resilienza.
14 Esaminare sicurezza, prompt injection e rischio di confused deputy
Un agente può diventare un confused deputy quando usa un'autorità legittima per perseguire un obiettivo non autorizzato. L'iniezione indiretta di prompt, l'output manipolato degli strumenti, la memoria compromessa o un agente pari malevolo possono influenzare le azioni. La conseguenza dipende dalle autorizzazioni effettive e dall'applicazione delle policy. La revisione di sicurezza dovrebbe quindi collegare il percorso di attacco all'azione aziendale e al ripristino.
L'acquirente dovrebbe esaminare modelli di minaccia, risultati dei red team, test di sicurezza, scansione delle dipendenze, gestione dei segreti, isolamento, monitoraggio e risposta agli incidenti. Dovrebbe testare input provenienti da documenti dei clienti, messaggi, siti web e output degli strumenti. Dovrebbe anche verificare se il contenuto dell'approvazione può essere manipolato affinché un revisore autorizzi un'azione diversa da quella eseguita.
Il privilegio minimo riduce il danno potenziale. Identità separate per agente, utente e servizio possono migliorare l'attribuzione se progettate correttamente. Credenziali a breve scadenza, restrizioni sulle risorse, limiti alle transazioni, controlli sulle destinazioni e verifica indipendente possono limitare l'esposizione. La registrazione dovrebbe conservare contesto sufficiente per ricostruire l'evento senza creare un archivio non controllato di dati riservati.
MITRE ATLAS e OWASP forniscono tassonomie di minacce e controlli che possono strutturare i test [17-21]. Il rischio del target dovrebbe essere valutato attraverso il suo flusso di lavoro, la sua architettura e gli impegni verso i clienti. Superare una checklist generica non può dimostrare che le azioni di produzione siano autorizzate e recuperabili.
15 Collegare la responsabilità alla valutazione e al prezzo di acquisto
I metodi di valutazione tradizionali restano rilevanti, inclusi il flusso di cassa attualizzato, gli approcci di mercato, le transazioni precedenti e gli approcci basati sui costi [5-6]. La responsabilità connessa ad agenti autonomi influisce sugli input attraverso la sostenibilità dei ricavi, il contributo, il costo del controllo, l'assicurazione, il capitale circolante, la remediation, la fidelizzazione dei clienti, i tempi di integrazione e l'esposizione di coda. L'acquirente dovrebbe evitare di applicare un multiplo di forte crescita prima di ricostruire queste voci.
La previsione standalone dovrebbe includere il modello di controllo operativo che clienti e autorità di regolamentazione accetteranno. La revisione umana, le operazioni di sicurezza, la valutazione, il supporto legale e la preparazione agli incidenti sono costi di erogazione. Rimuoverli come sinergie immediate può sovrastimare il valore. Controlli aggiuntivi possono migliorare la conversione e la fidelizzazione, ma tale beneficio dovrebbe essere supportato da evidenze e modellato separatamente.
Il prospetto delle responsabilità dovrebbe distinguere obblighi noti, specifiche materie potenziali, remediation dei controlli e rischio operativo futuro. Le voci note possono influire sul debito netto o sul capitale circolante a seconda dell'accordo e della contabilizzazione. Le materie incerte possono influenzare il prezzo, l'escrow, l'indennizzo o l'assicurazione. Il rischio prospettico può influire sul piano industriale e sull'integrazione anziché creare una responsabilità alla data di acquisizione.
Il valore dovrebbe essere sbloccato in base allo stato delle evidenze. Un target con autorizzazioni delimitate, controlli umani testati, registri completi delle azioni, prestazioni stabili in materia di incidenti e contratti allineati supporta una previsione più solida rispetto a uno basato su dichiarazioni di policy. Il modello ponderato per probabilità dovrebbe mostrare come ciascun controllo irrisolto modifica cassa, tempi e rischio di ribasso.
16 Progettare dichiarazioni, indennizzi, escrow e assicurazione
I documenti di transazione possono allocare il rischio identificato quando le definizioni riflettono la realtà tecnica. Le dichiarazioni possono riguardare poteri, istruzioni dei clienti, uso dei dati, proprietà intellettuale, sicurezza, incidenti, conformità normativa, modifiche rilevanti a modelli o strumenti, registri di valutazione e assicurazione. I prospetti di disclosure dovrebbero identificare eccezioni a livello di flusso di lavoro e di cliente.
Indennizzi specifici possono coprire reclami noti o esposizioni definite. L'escrow o la trattenuta possono supportare la recuperabilità. L'assicurazione per garanzie e indennizzi può trasferire selezionati rischi di dichiarazione soggetti a esclusioni, ritenzione e sottoscrizione. Le polizze cyber, errori e omissioni tecnologici, responsabilità civile professionale e altre polizze dovrebbero essere riesaminate con riferimento a entità assicurata, periodo, evento innescante, esclusioni, limiti, sublimiti e notifica.
L'assicurazione non dovrebbe essere modellata al valore nominale. La copertura per errore algoritmico, azione autonoma, sanzione regolamentare, responsabilità contrattuale o circostanza nota può essere limitata o esclusa. L'acquirente dovrebbe riesaminare con i consulenti il testo della polizza, le proposte del broker, lo storico dei sinistri e il trattamento del cambio di controllo. L'esposizione residua permane dopo limiti, ritenzione e ritardo di incasso.
Il team della transazione dovrebbe allineare la protezione legale alle coorti di azioni. Una garanzia ampia può essere difficile da provare e recuperare. Una dichiarazione definita legata all'esportazione delle autorizzazioni di produzione, ai registri degli incidenti e alle eccezioni dei clienti può essere più verificabile. La redazione e l'esecutività richiedono consulenza legale transazionale.
17 Utilizzare condizioni di closing e covenant per rimediare alle lacune nei controlli
Le condizioni di closing dovrebbero concentrarsi sulle questioni necessarie per trasferire e gestire l'attività acquisita. Esempi includono la revoca delle credenziali orfane, la riduzione dell'eccesso di autorizzazioni critiche, l'implementazione del vincolo di approvazione, la conservazione dei log, l'assegnazione della proprietà intellettuale, l'ottenimento dei consensi rilevanti di clienti o fornitori e la risoluzione di un incidente grave. Le evidenze e i test di accettazione dovrebbero essere definiti prima della firma, ove possibile.
Le attività di gravità inferiore possono essere gestite tramite covenant pre-closing, piani di integrazione e budget specifici. Il venditore dovrebbe mantenere i controlli nell'ordinario corso degli affari e notificare modifiche rilevanti a modelli, strumenti, autorizzazioni, incidenti e obblighi verso i clienti. L'acquirente dovrebbe evitare di assumere il controllo operativo prima del closing in modo tale da creare problemi legali o di concorrenza.
Il corrispettivo differito può essere collegato a evidenze operative durevoli. Le misure possono includere la chiusura di rilievi critici, la fidelizzazione verificata dei clienti, il contributo rettificato al netto del costo del controllo, la portabilità testata e il completamento dei traguardi di integrazione concordati. Gli incentivi non dovrebbero premiare un maggiore volume autonomo senza accettazione, sicurezza e cassa.
Il fascicolo della transazione dovrebbe mostrare quale lacuna influisce su decisione, prezzo, struttura, tempistiche o integrazione. Un lungo elenco privo di materialità può ritardare l'operazione senza risolvere i percorsi a maggiore impatto. La governance dovrebbe assegnare a ciascuna condizione un responsabile, uno standard probatorio e una scadenza.
18 Costruire quattro casi ipotetici di acquisizione
L'agente per i pagamenti di tesoreria prepara ed esegue, entro limiti definiti, i pagamenti ai fornitori. Le sue principali esposizioni sono il potere di pagamento, il cambio del beneficiario, i limiti di valore, la segregazione, il replay e il ripristino. L'agente per i contratti con i clienti redige e invia modifiche nell'ambito di modelli approvati. Le sue esposizioni includono il potere apparente, gli impegni non autorizzati, la divulgazione, il controllo delle versioni e l'affidamento del cliente.
L'agente per l'amministrazione cloud diagnostica incidenti e modifica l'infrastruttura. Le sue esposizioni includono l'escalation dei privilegi, la configurazione di sicurezza, l'interruzione del servizio, l'accesso ai dati e le modifiche a cascata. L'agente per i sinistri regolamentati raccoglie prove e raccomanda o esegue parti di un processo di gestione dei sinistri. Le sue esposizioni includono esiti iniqui, pagamenti errati, spiegazione, ricorso, conservazione dei registri e obblighi di settore.
Ogni caso utilizza ipotesi gestionali ipotetiche per mostrare come funziona il framework. Le ipotesi non descrivono una società o un mercato denominato. Un'acquisizione reale richiede contratti, esportazioni delle autorizzazioni di produzione, registrazioni delle approvazioni, tracce delle azioni, incidenti, sinistri, assicurazione, registri finanziari e analisi legale.
I casi dimostrano anche che l'autonomia non è l'unico fattore trainante. L'agente per i contratti può avere un volume di azioni inferiore e conseguenze legali elevate. L'agente cloud può operare con controlli rigorosi sulle modifiche pur mantenendo un ampio raggio d'impatto tecnico. L'agente per i sinistri può richiedere una decisione umana anche quando la preparazione delle prove è altamente automatizzata. Il prezzo dovrebbe seguire il modello di rischio ed economico verificato.
19 Economia illustrativa delle esposizioni e degli interventi correttivi
Il caso ipotetico di tesoreria presume 1,2 milioni di azioni annue, una bassa probabilità di azioni non autorizzate e una conseguenza media elevata, producendo una perdita annua attesa e un costo di risposta pari a USD 4.8 million. Il caso contratti presume 420.000 azioni e USD 3.6 million. Il caso cloud presume 750.000 azioni e USD 7.2 million. Il caso sinistri presume 2,4 milioni di azioni e USD 5.4 million. Tali importi sono illustrazioni gestionali.
I quattro casi presumono inoltre USD 22 million di interventi correttivi una tantum su identità, applicazione delle policy, vincolo delle approvazioni, logging, test, attività per i clienti e modifica dei processi operativi. Il costo incrementale ricorrente dei controlli è ipotizzato pari a USD 9 million. Il business plan dovrebbe individuare quale importo protegge i ricavi esistenti, consente la crescita o riduce le perdite.
Un modello separato di passività ponderato per probabilità assegna USD 29.4 million di esposizione lorda attesa tra un evento di pagamento, un impegno contrattuale, un'interruzione cloud, una divulgazione di dati e un evento con esito regolamentato. Esclude il recupero assicurativo e indennitario perché nell'illustrazione la recuperabilità è incerta. Il numero è uno strumento decisionale, non una stima contabile.
L'analisi di sensibilità dovrebbe variare volume di azioni, probabilità dell'evento, conseguenza, tempo di rilevamento, recupero, concentrazione della clientela, assicurazione ed efficacia dei controlli. Il guasto correlato merita un caso specifico. Una modifica condivisa delle policy può esporre molti clienti anche quando la cronologia dei singoli flussi di lavoro appare solida.
20 Pianificare i primi cento giorni intorno alla continuità dell'autorità
Il primo obiettivo è la continuità dell'autorità responsabile. L'acquirente dovrebbe preservare identità di produzione, policy, approvazioni, log, impegni verso i clienti e risposta agli incidenti mentre stabilisce la titolarità. Dovrebbe identificare credenziali critiche, persone, fornitori e controlli specifici per i clienti prima di cambiare piattaforme.
L'integrazione dovrebbe procedere per coorte di azioni. I flussi di lavoro in sola lettura possono spesso essere trasferiti prima. L'esecuzione ad elevate conseguenze dovrebbe attendere identità, policy, vincolo delle approvazioni, monitoraggio e ripristino testati nell'ambiente dell'acquirente. Ogni migrazione richiede una baseline, un piano di modifica, test, rollback e, ove necessario, una decisione del cliente o del regolatore.
L'acquirente dovrebbe evitare modifiche simultanee a modello, prompt, strumento, identità e approvazione. Una sequenziazione controllata aiuta a identificare la causa del cambiamento delle prestazioni o dei controlli. Le prove del target dovrebbero rimanere accessibili per finalità di earn-out, garanzia, clienti e regolamentari dopo il consolidamento dei sistemi.
Il reporting delle sinergie dovrebbe includere azioni accettate, revisione umana, eccezioni, incidenti, contributo rettificato e liquidità. Un costo del lavoro inferiore non è una sinergia realizzata se aumentano il costo delle eccezioni, la perdita di clienti o l'esposizione residua. Il consiglio di amministrazione dovrebbe ricevere una dashboard sintetica su autorità e passività collegata alla tesi di acquisizione.
21 Governance dell'autorità degli agenti dopo il closing
La governance successiva al closing dovrebbe assegnare un responsabile di business, un responsabile tecnico, un responsabile della sicurezza, un responsabile legale o della conformità e un ruolo di assurance indipendente per ciascun flusso di lavoro rilevante. Il comitato operativo dovrebbe approvare la tassonomia delle azioni, la propensione al rischio, i limiti di autorità, le eccezioni per i clienti e le modifiche rilevanti. Le decisioni con conseguenze rilevanti dovrebbero mantenere una responsabilità umana chiaramente attribuita quando richiesto da legge, policy o mandato del cliente.
Le metriche dovrebbero includere permessi effettivi, eccedenza di permessi, volume di approvazioni, rifiuti e modifiche, tentativi non autorizzati, fallimenti delle policy, annullamenti, incidenti, rilevamento e ripristino, reclami dei clienti, crediti di servizio, esposizione residua e costo dei controlli. Le misure dovrebbero essere segmentate per flusso di lavoro e cliente. Un tasso aggregato di incidenti basso può mascherare una coorte concentrata ad alte conseguenze.
La governance delle modifiche dovrebbe coprire modelli, strumenti, prompt, policy, identità, soglie, dati e configurazione del cliente. Le evidenze di rilascio dovrebbero dimostrare test rispetto a scenari ordinari, di confine e avversariali. Le modifiche critiche dovrebbero attivare la revisione da parte del cliente, dell'assicuratore o della regolamentazione ove richiesto da contratto o legge.
L'assurance indipendente dovrebbe testare il sistema in produzione, non solo le policy. La revisione interna, specialisti esterni o funzioni di controllo possono campionare le catene di autorità, riprodurre le decisioni e verificare i rimedi. Le constatazioni dovrebbero essere collegate all'allocazione del capitale, all'ambito del prodotto e agli impegni verso i clienti.
22 Costruire il record di autorità del comitato investimenti
Il documento per il comitato investimenti dovrebbe tradurre le constatazioni tecniche in una decisione su valore, protezione e responsabilità operativa. Dovrebbe identificare i dieci o meno percorsi d'azione con conseguenze rilevanti che determinano la maggiore esposizione plausibile, le evidenze di produzione esaminate per ciascun percorso, le lacune irrisolte e la persona responsabile di accettare il rischio residuo. Un lungo catalogo di osservazioni minori sulla configurazione può oscurare le questioni dell'acquisizione che modificano il prezzo o la capacità di operare.
Per ciascun percorso rilevante, il record dovrebbe indicare il mandante, lo scopo delegato, l'identità effettiva, il permesso, il punto di applicazione, il controllo umano, il volume delle azioni, la conseguenza plausibile, il metodo di rilevamento, il percorso di ripristino e l'allocazione al cliente. Dovrebbe distinguere le evidenze di produzione osservate dalle dichiarazioni della direzione e dalle ipotesi di scenario. Il comitato può quindi vedere se un'esposizione è già presente, contingente a un evento incerto, creata dall'integrazione successiva al closing o dipendente da un miglioramento pianificato dei controlli.
Il documento dovrebbe riconciliare la prospettiva di responsabilità con il modello finanziario. Organico dei controlli, assicurazione, rimedi per i clienti, attività tecnologica e ritardo di integrazione dovrebbero figurare nel flusso di cassa previsto, ove applicabile. Richieste specifiche, accantonamenti o questioni potenziali dovrebbero essere esaminate con consulenti contabili e legali. Rettifiche di prezzo, escrow, indennizzi e corrispettivi potenziali non dovrebbero essere considerati sostituti dei controlli operativi necessari per servire i clienti dopo il closing.
Le alternative decisionali dovrebbero essere esplicite. L'acquirente può procedere al prezzo proposto dopo la verifica, rettificare il valore, escludere un flusso di lavoro o un'entità, ritardare il closing finché una condizione non è soddisfatta, scaglionare l'implementazione, richiedere ulteriore protezione dal venditore o rifiutare la transazione. Ciascuna alternativa dovrebbe indicare le evidenze che cambierebbero la decisione e la scadenza per ottenerle. Questa struttura impedisce che un red flag irrisolto diventi un'ipotesi non registrata.
Il comitato dovrebbe anche approvare il modello di autorità successivo al closing. Dovrebbe nominare il dirigente responsabile del business agentico, i funzionari che mantengono l'autorità decisionale su decisioni con conseguenze rilevanti, i responsabili dei controlli tecnici e di sicurezza, il percorso di assurance e le circostanze che richiedono l'escalation al consiglio di amministrazione. Il budget e la sequenza dei primi cento giorni dovrebbero corrispondere alla propensione al rischio approvata e agli impegni verso i clienti.
Infine, il record decisionale dovrebbe conservare i dissensi e le condizioni. Un revisore può accettare la tesi commerciale pur richiedendo un livello di autorità inferiore finché non si accumulano ulteriori evidenze. Un altro può considerare un consenso del cliente, una dipendenza da modelli di terzi o un'esclusione assicurativa come una questione di closing. La registrazione di queste posizioni migliora la responsabilità e offre al team di integrazione un confine chiaro per il rilascio delle capacità autonome.
Un calendario di rilascio delle evidenze può convertire le condizioni in attività successive alla firma misurabili. Ogni voce dovrebbe specificare il record di base, la popolazione di test, la soglia di superamento, il revisore indipendente, la risposta al fallimento e la conseguenza per prezzo, tempistiche o implementazione. Le evidenze dovrebbero essere conservate in un repository controllato con identificatori stabili, affinché comitato, consulenti della transazione, assicuratori e team di integrazione facciano riferimento allo stesso risultato. Quando un test fallisce, la risposta dovrebbe affrontare la coorte di azioni interessata e gli impegni verso i clienti, anziché limitarsi a chiudere un ticket. Il calendario dovrebbe far decadere le ipotesi che restano non supportate e richiedere una nuova approvazione prima che l'autorità si ampli. Questa disciplina collega la decisione di investimento alla condotta operativa dopo il cambio di proprietà.
La revisione trimestrale dovrebbe confrontare l'esposizione residua con il caso di acquisizione approvato e documentare ogni scostamento rilevante, responsabile, rimedio e scadenza.
Conclusione
Un'acquisizione di agenti AI non può essere compresa solo attraverso la capacità dei modelli e i ricavi software. L'acquirente sta acquisendo un sistema di autorità le cui identità, permessi, strumenti, approvazioni e azioni possono creare valore e responsabilità. Il record di due diligence deve quindi dimostrare chi può causare quale conseguenza, sotto l'autorità di chi, con quali evidenze e rimedi.
Il framework proposto converte tale domanda in attività transazionale. Definisce il perimetro, ricostruisce la catena principale-agente, costruisce il grafo delle autorizzazioni, classifica le azioni con conseguenze rilevanti, verifica l'applicazione e l'override umano, quantifica l'esposizione per coorte di azioni e collega i risultati alla valutazione e alla protezione dell'operazione. Tratta standard e regolamenti vigenti come fonti di domande e controlli, richiedendo al contempo evidenze specifiche del target.
Il caso di acquisizione più solido è supportato da poteri delimitati, applicazione a valle, controllo umano significativo, registrazioni complete delle azioni, contratti con i clienti allineati, recupero testato e un modello operativo post-closing con costi quantificati. Dove le evidenze restano immature, l'acquirente può ridurre il valore assunto, richiedere interventi correttivi, scaglionare l'integrazione o allocare il rischio tramite la struttura dell'operazione. La decisione di investimento dovrebbe registrare l'esposizione residua e la persona responsabile di accettarla.
Data room delle evidenze su autorità e autorizzazioni
Fornire la mappa principale-agente di produzione, identità, account di servizio, gruppi, ruoli, token, segreti, definizioni degli strumenti, policy-as-code, esportazioni delle autorizzazioni, ambiti dei clienti, privilegi temporanei, accesso break-glass, test di revoca e cronologia delle modifiche. Riconciliare le autorizzazioni richieste ed effettive e identificare il surplus di autorizzazioni per azione con conseguenze rilevanti.
Dossier sul controllo umano e sulle azioni
Fornire tassonomia delle azioni, regole di approvazione, ruoli dei revisori, schermate dell'interfaccia, legame tra approvazione ed esecuzione, scadenza, prevenzione del replay, test di override e di arresto, metriche di revisione, disaccordo, escalation, annullamento e evidenze di recupero. Includere tracce firmate rappresentative dalla richiesta allo stato finale.
Fascicolo su contratti di responsabilità e assicurazioni
Fornire accordi con clienti e fornitori, eccezioni negoziate, reclami, richieste di risarcimento, accantonamenti, passività potenziali, polizze assicurative, comunicazioni al broker, notifiche, recuperi e analisi legali. Mappare le autorizzazioni tecniche e la condotta operativa sull'autorità contrattuale e sull'allocazione della responsabilità.
Fascicolo di controllo dell'operazione e dell'integrazione
Fornire rettifiche di valutazione, scenari di esposizione, budget per interventi correttivi, dichiarazioni, informative, manleve, escrow, condizioni di closing, covenant, corrispettivo potenziale, piano dei primi cento giorni, consensi dei clienti, responsabili dei controlli e reporting al consiglio. Preservare le evidenze necessarie per verificare ogni rilascio di valore.
Catena proposta di due diligence dell'operazione; ogni azione materiale in produzione dovrebbe essere attribuibile e riproducibile.
Classificazione proposta; le celle più scure richiedono un recupero più solido dell'approvazione indipendente e una protezione dell'operazione più forte.
Ipotesi della direzione in USD milioni; i valori escludono il recupero dell'indennità assicurativa, il trattamento fiscale e quello del prezzo di acquisto.
Ipotesi della direzione in USD milioni; l'esposizione lorda totale attesa è USD 29.4 million prima dei recuperi.
Sequenza proposta; i tempi dovrebbero seguire i requisiti del cliente in materia legale, normativa, di sicurezza e di integrazione.
| Componente | Evidenza richiesta | Questione della transazione | Inadempimento del mandante |
|---|---|---|---|
| Legittimazione | delega e limiti dello scopo del mandante | chi ha autorizzato l'azione | potere implicito senza prova |
| Identità e autorizzazioni | esportazioni di produzione, ruoli, token e policy | cosa può effettivamente fare l'agente | eccesso di autorizzazioni o privilegio condiviso |
| Controllo umano | approvazione, registrazione, interfaccia, tempistica e indipendenza | una persona può prevenire o riparare il danno | approvazione rituale o bias di automazione |
| Conseguenza | volume, gravità e reversibilità della coorte di azioni | quale valore o passività può derivarne | il successo tecnico nasconde effetti legali o finanziari |
| Rimedio | rilevamento, contenimento, recupero, contratto e assicurazione | chi sostiene il costo e con quale rapidità | recupero ipotizzato senza esigibilità |
Struttura di due diligence proposta; le conclusioni richiedono una revisione legale, contabile, tecnica e commerciale specifica per il target.
| Livello | Capacità dell'agente | Ruolo umano | Evidenza minima |
|---|---|---|---|
| Osservare | individuare e leggere le evidenze approvate | definisce finalità e accesso | fonte, ambito, identità e traccia di audit |
| Raccomandare | analizzare e proporre | interpreta e decide | griglia di valutazione, fonti, alternative e disaccordo |
| Preparare | compilare una transazione o una modifica | convalida l'azione completa | parametri esatti, segregazione e scadenza |
| Esecuzione limitata | agire entro limiti vincolanti | approva le policy e monitora | applicazione a valle, traccia firmata e rollback |
| Decisione con conseguenze | determinare diritti, denaro, sicurezza o un esito regolamentato | mantiene l'autorità responsabile ove richiesto | registro delle decisioni, competenza, ricorso e garanzia |
Scala di controllo proposta; leggi, politiche e requisiti del cliente specifici del flusso di lavoro disciplinano l'autorità effettiva.
| Dimensione | Test di due diligence | Indicatore di fallimento | Risposta dell'operazione |
|---|---|---|---|
| Informazioni | il revisore vede prove, azione e conseguenza | il riepilogo nasconde parametri o incertezza | ridisegnare l'interfaccia e controllare il rilascio |
| Legittimazione | il revisore può rifiutare, modificare, interrompere ed escalare | il revisore non ha il ruolo o l'autorizzazione di sistema | riassegnare l'autorità e applicare la segregazione |
| Tempistica | la decisione avviene prima dell'esecuzione irreversibile | l'approvazione è retrospettiva | bloccare l'esecuzione o aggiungere una preautorizzazione limitata |
| Indipendenza | il revisore è separato laddove la conseguenza lo richiede | l'agente seleziona o influenza il revisore | instradamento indipendente e controlli sui conflitti |
| Carico di lavoro | il volume di revisione consente un'attenzione significativa | approvazione quasi universale o latenza estrema | riprogettazione di organico e campionamento per livelli di rischio |
| Vincolante | l'azione approvata coincide con l'azione eseguita | approvazione obsoleta, alterata o riprodotta | scadenza del binding crittografico e riconciliazione |
Un passaggio di approvazione visibile non è sufficiente se ogni dimensione non opera in produzione.
| Flusso di lavoro | Azioni annuali in milioni | Esposizione attesa e costo di risposta USD milioni | Dipendenza dal controllo primario |
|---|---|---|---|
| Agente di pagamento della tesoreria | 1.20 | 4.8 | validazione del beneficiario, limiti di importo e segregazione |
| Agente per i contratti con i clienti | 0.42 | 3.6 | linguaggio approvato, autorità apparente e controllo delle versioni |
| Agente di amministrazione cloud | 0.75 | 7.2 | privilegio minimo, approvazione delle modifiche e rollback |
| Agente per i sinistri regolamentati | 2.40 | 5.4 | spiegazione della decisione umana, ricorso e conservazione dei registri |
Ipotesi del management; i dati non costituiscono osservazioni, previsioni, stime contabili o conclusioni di valutazione.
| Filone di lavoro | Costo una tantum | Costo annuale ricorrente | Evidenza di completamento |
|---|---|---|---|
| Ridisegno di identità e autorizzazioni | 5.0 | 1.5 | Test di privilegio minimo e revoca sul grafo di produzione |
| Applicazione delle policy e vincolo delle approvazioni | 4.5 | 1.2 | scenari bloccati, approvazione firmata e rifiuto del replay |
| Valutazione del logging e operazioni sugli incidenti | 4.0 | 2.0 | Esercizio completo di rilevamento e ripristino delle tracce |
| Correzione del contratto e della configurazione del cliente | 3.5 | 1.3 | Autorità concordata e allineamento tecnico |
| Programma di sicurezza, conformità normativa e assurance | 3.0 | 2.0 | Rilievi sui controlli testati e chiusura |
| Integrazione e cambiamento del modello operativo | 2.0 | 1.0 | Accettazione e governance della migrazione per coorte |
| Totale | 22.0 | 9.0 | Registro delle evidenze approvato dal consiglio di amministrazione |
Ipotesi del management in USD milioni; il perimetro effettivo richiede evidenze verificate su architettura, clienti e aspetti legali.
| Evento | Conseguenza lorda | Probabilità | Esposizione ponderata |
|---|---|---|---|
| Diversione dei pagamenti | 55 | 10% | 5.5 |
| Impegno contrattuale non autorizzato | 32 | 15% | 4.8 |
| Interruzione del servizio cloud | 48 | 12% | 5.76 |
| Divulgazione di dati riservati | 70 | 12% | 8.4 |
| Esito regolamentato errato | 38 | 13% | 4.94 |
| Totale | 29.4 |
Ipotesi del management in USD milioni; l'esposizione lorda attesa è USD 29.4 million prima del recupero dell'indennizzo assicurativo, delle imposte o del trattamento del prezzo di acquisto.
| Stato delle evidenze | Rilievo | Possibile risposta all'operazione | Misura post-closing |
|---|---|---|---|
| Potere verificato | identità, autorizzazioni e approvazioni con perimetro definito | valore della base di supporto e dell'integrazione pianificata | autorizzazioni in eccesso ed eccezioni alle policy |
| Lacuna sanabile | debolezza di controllo con correzione e costo definiti | rettifica del prezzo, covenant, budget o milestone | test di chiusura ed esposizione residua |
| Esposizione nota | evento identificato, reclamo o eccezione del cliente | informativa, indennizzo specifico, escrow o assicurazione | reclamo, liquidità e recupero |
| Rischio di coda incerto | storico limitato o conseguenze elevate correlate | sconto di scenario, trattenuta o implementazione limitata | indicatori anticipatori di incidenti e garanzia |
| Ostacolo al trasferimento | mancanza di autorità, diritto, consenso o controllo critico | condizione di chiusura, perimetro rinviato o no-go | trasferimento verificato e accettazione operativa |
Quadro proposto; gli strumenti concreti richiedono una consulenza aggiornata in materia legale, fiscale, contabile, normativa, assicurativa e finanziaria.
Fonti
- Fondazione IFRS. IFRS 3 Aggregazioni aziendali. Leggi la fonte primaria
- IFRS Foundation. IAS 37 Accantonamenti, passività e attività potenziali. Leggi la fonte primaria
- IFRS Foundation. Contabilizzazione del corrispettivo potenziale nelle aggregazioni aziendali. Leggi la fonte primaria
- IFRS Foundation. IAS 38 Attività immateriali. Leggi la fonte primaria
- IFRS Foundation. IFRS 13 Valutazione del fair value. Leggi la fonte primaria
- Consiglio internazionale degli standard di valutazione. Standard internazionali di valutazione. Leggi la fonte primaria
- National Institute of Standards and Technology. AI Iniziativa per gli standard degli agenti. Aggiornato al 14 agosto 2026. Leggi la fonte primaria
- National Institute of Standards and Technology. Annuncio dell'iniziativa per gli standard degli agenti AI. 17 febbraio 2026. Leggi la fonte primaria
- National Institute of Standards and Technology. Accelerare l'adozione dell'identità e dell'autorizzazione per software e agenti AI. 2026. Leggi la fonte primaria
- National Institute of Standards and Technology. Nuovo documento concettuale sull'identità e l'autorità degli agenti software. 5 febbraio 2026. Leggi la fonte primaria
- National Institute of Standards and Technology. Quadro di gestione dei rischi dell'intelligenza artificiale. Leggi la fonte primaria
- National Institute of Standards and Technology. Profilo AI generativo NIST AI 600-1. Leggi la fonte primaria
- National Institute of Standards and Technology. Quadro sulla sicurezza informatica 2.0. Leggi la fonte primaria
- National Institute of Standards and Technology. Linee guida sull'identità digitale. Leggi la fonte primaria
- National Institute of Standards and Technology. Architettura Zero Trust SP 800-207. Leggi la fonte primaria
- Cybersecurity and Infrastructure Security Agency. Sicurezza fin dalla progettazione. Leggi la fonte primaria
- OWASP Foundation. LLM06 2025 Autonomia eccessiva. Leggi la fonte primaria
- OWASP Foundation. Scheda pratica sulla sicurezza degli agenti AI. Leggi la fonte primaria
- OWASP Foundation. Minacce e mitigazioni degli agenti AI. Leggi la fonte primaria
- OWASP Foundation. Standard di verifica della sicurezza degli agenti AI. Leggi la fonte primaria
- MITRE. ATLAS: panorama delle minacce avversarie per i sistemi AI. Leggi la fonte primaria
- MITRE. Quadro sicuro per AI. Leggi la fonte primaria
- Unione europea. Regolamento UE 2024 1689 sull'intelligenza artificiale, articolo 14. Leggi la fonte primaria
- Commissione europea. Quadro normativo e attuazione del AI Act. Leggi la fonte primaria
- Ufficio del Commissario per l'informazione del Regno Unito. Linee guida su AI e protezione dei dati. Leggi la fonte primaria
- Comitato europeo per la protezione dei dati. Linee guida su processi decisionali automatizzati e profilazione. Leggi la fonte primaria
- Organizzazione internazionale per la normazione. Sistemi di gestione dell'intelligenza artificiale ISO IEC 42001. Leggi la fonte primaria
- Organizzazione internazionale per la normazione. Gestione dei rischi dell'intelligenza artificiale ISO IEC 23894. Leggi la fonte primaria
- Organizzazione internazionale per la normazione. Sistemi di gestione della sicurezza delle informazioni ISO IEC 27001. Leggi la fonte primaria
- Organizzazione internazionale per la normazione. Gestione dei rischi per la sicurezza delle informazioni ISO IEC 27005. Leggi la fonte primaria
- OCSE. Principi OCSE in materia di AI. Leggi la fonte primaria
- OCSE. Quadro per la classificazione dei sistemi AI. Leggi la fonte primaria
- Organizzazione mondiale per la proprietà intellettuale. Intelligenza artificiale e proprietà intellettuale. Leggi la fonte primaria
- Commissione federale per il commercio degli Stati Uniti. Controlla le tue dichiarazioni su AI. Leggi la fonte primaria
- Commissione per i titoli e gli scambi degli Stati Uniti. Avviso agli investitori su intelligenza artificiale e frodi negli investimenti. Leggi la fonte primaria
- OpenAI. Tracciamento dell'Agents SDK. Leggi la fonte primaria
- OpenAI. Valutare i flussi di lavoro degli agenti. Leggi la fonte primaria
- OpenAI. Valutazione delle tracce per gli agenti. Leggi la fonte primaria
- Anthropic. Politica di scalabilità responsabile. Leggi la fonte primaria
- Google Cloud. Pattern di progettazione per sistemi agentici AI. Leggi la fonte primaria
- Microsoft. Architettura agentica AI e AI responsabile. Leggi la fonte primaria
- Linux Foundation. Fondazione per l'AI agentica. Leggi la fonte primaria
- Cloud Security Alliance. Matrice dei controlli AI. Leggi la fonte primaria
- Center for Internet Security. Controlli di sicurezza critici CIS. Leggi la fonte primaria
- Internet Engineering Task Force. Pratica corrente ottimale per la sicurezza di OAuth 2.0. Leggi la fonte primaria
- Internet Engineering Task Force. Pratiche correnti ottimali per JSON Web Token. Leggi la fonte primaria
- OpenID Foundation. Profilo di sicurezza API di livello finanziario. Leggi la fonte primaria
- National Institute of Standards and Technology. Ritorno al futuro: perché l'AI agentica necessita di una solida base di identità. 27 agosto 2026. Leggi la fonte primaria
- Model Evaluation and Threat Research. Orizzonti temporali di completamento delle attività dei modelli AI di frontiera. Leggi la fonte primaria
- MLCommons. Benchmark di sicurezza AI. Leggi la fonte primaria
