Toc toc. Chi è? Un nuovo livello di fiducia. Onboarding e AI agent

Ci sono due cose che mi hanno fatto riflettere negli ultimi mesi. In superficie sembrano non avere nulla a che fare l’una con l’altra. Ma guardandole più da vicino, raccontano la stessa storia.

La prima riguarda il cinema. Oggi un film completo può essere prodotto interamente con l’AI: attori che non esistono, volti, voci, micro-espressioni indistinguibili dalla realtà. Tecnicamente, non abbiamo più bisogno di attori in carne e ossa per realizzare un film. Eppure, quando questo avviene su larga scala, gli attori reali, quelli i cui tratti e le cui voci vengono “presi in prestito” dall’AI, dovranno autorizzarne l’uso. L’AI può fare tutto da sola. Ma non senza permesso.

La seconda riguarda i robot. Qualche anno fa li guardavamo inciampare su semplici gradini. Oggi camminano, si muovono, svolgono compiti complessi, a volte oltre ciò che un corpo umano può fare. Può aiutarmi a piegare il bucato a casa? Probabilmente sì, e nessuno gli chiederà un documento di identità. Ma posso mandare un robot a ritirare un pacco all’ufficio postale? A pagare con la mia carta di credito? Ad aprire un conto bancario per mio conto? La risposta, oggi, è no. Non perché la tecnologia non sia in grado di farlo, ma perché manca il pezzo più importante: un livello che dica “questo agente è autorizzato ad agire per conto di quell’essere umano”.

Due scenari molto diversi, lo stesso problema di fondo: l’AI sta diventando sempre più autonoma, ma l’autonomia senza autorizzazione non è fiducia. È rischio.

E nei processi digitali che progettiamo ogni giorno, onboarding di clienti, attivazione di servizi, firma di contratti, questo problema è già arrivato.

Will Smith e Sonny in I, Robot (2004): “Un robot può scrivere una sinfonia? Un robot può trasformare una tela in un capolavoro?” “E tu?”

La scena ribalta il classico test di Turing: non è l’essere umano a giudicare la macchina, ma la macchina a mettere in luce i limiti di chi la sta giudicando. Pretendere che la creatività artistica sia la prova decisiva dell’umanità è un criterio che escluderebbe la maggior parte degli esseri umani stessi: la definizione si rivela arbitraria nel momento stesso in cui viene usata per escludere qualcuno.

È il motivo di Frankenstein reinterpretato in chiave contemporanea: la creatura che mette a nudo l’ipocrisia del suo creatore, mostrando una coscienza morale più limpida di quella di chi l’ha costruita. E il richiamo a Blade Runner è inconfondibile: anche lì erano le macchine a costringere i loro interrogatori a chiedersi se la differenza tra umano e artificiale fosse ontologica oppure semplicemente una convenzione conveniente.

Il vero ribaltamento è che la domanda “cosa ti rende umano?” smette di essere retorica. Diventa scomoda, perché non esiste una risposta che regga davvero.

Chi c’è davvero dall’altra parte del tuo onboarding?

Quando abbiamo progettato i nostri flussi di onboarding, qualche anno fa, avevamo in mente una sola figura: una persona reale dall’altra parte dello schermo che inseriva i propri dati. Nel peggiore dei casi, una persona disonesta che impersonava qualcun altro. Tutto ciò che è venuto dopo, KYC, video-identificazione, controlli documentali, è stato costruito attorno a quel modello mentale.

Oggi, dietro una richiesta di onboarding, possono esserci almeno quattro attori molto diversi:

• Un essere umano legittimo, il caso classico per cui il KYC è nato.
• Un essere umano fraudolento, che usa documenti rubati, impersonificazione, social engineering.
• Un agente AI legittimo, che opera per conto di una persona reale, sempre più comune e destinato a esplodere.
• Un agente AI fraudolento, che concatena attacchi autonomi, deepfake, identità sintetiche, spoofing del dispositivo, a una velocità e a un costo che nessun essere umano può eguagliare.

Il problema è che il KYC tradizionale, progettato per i primi due casi, non riesce a distinguere il terzo dal quarto. E non può farlo per una ragione semplice: non è mai stato pensato per riconoscere un’intelligenza artificiale, tantomeno per decidere se quell’intelligenza sia autorizzata ad agire.

“Il KYC è stato progettato per un mondo in cui dall’altra parte c’era sempre un essere umano. Quel mondo non esiste più.”

Dal KYC al KYA: cosa cambia (e perché il livello si alza)

Know Your Customer non basta più. La domanda cambia: chi sta agendo, per conto di chi, con quale legittimità? È un cambio di paradigma che potremmo chiamare KYA – Know Your Agent, e porta con sé conseguenze molto concrete:

• Cambia ciò che verifichi: non solo l’identità di una persona, ma la legittimità della catena di delega “essere umano → agente”.
• Il modello di minaccia si amplia: oltre alle minacce classiche, documenti falsi, presentation attack, deepfake, ora affrontiamo attacchi agentici, bot autonomi che orchestrano la frode end-to-end.
• L’ancora della fiducia si sposta: dal documento di identità all’intero contesto che circonda l’interazione.

Quest’ultimo punto, a mio avviso, è il più importante e il più sottovalutato. Vale la pena soffermarcisi un momento.

La fiducia prima viveva nel documento. Ora vive nella catena.

Per due decenni, l’onboarding è stato costruito attorno a un’idea apparentemente semplice: fidarsi del documento. Verificare che il documento sia autentico, confrontare il volto sul documento con il volto davanti alla videocamera, incrociare i dati con un database antifrode. È un modello profondamente orientato all’essere umano dall’altra parte: ogni controllo presuppone una persona davanti alla telecamera, in possesso delle proprie credenziali. Gli strati biometrici e quelli basati su eID, wallet compresi, erano estensioni naturali della stessa logica: più possiamo dimostrare chi è il titolare, più possiamo fidarci della transazione.

Quella logica funzionava perché dall’altra parte c’era sempre un essere umano, in possesso di una credenziale fisica o qualificata. Se togli quell’assunto, l’intera ancora della fiducia collassa su qualcosa di troppo limitato.

In un mondo KYA, l’ancora della fiducia deve ampliarsi, drasticamente. Il documento di identità può ancora essere un pezzo del puzzle, ma non è più il puzzle. La fiducia deve essere costruita a partire da un insieme molto più ampio di segnali:

• Segnali del dispositivo
• Indicatori comportamentali
• Impronta digitale
• Intelligence documentale e AML

Dietro ciascuna di queste etichette si nasconde una costellazione di dati: fingerprint hardware e parametri di rete del dispositivo usato; il ritmo con cui vengono compilati i campi, il modo in cui si muove il cursore, i pattern di copia-incolla; le tracce digitali lasciate online, anzianità e reputazione dell’email, validazione del numero di telefono, presenza social; e naturalmente i controlli documentali e gli screening su cui abbiamo sempre fatto affidamento. Nessuno di questi segnali è decisivo da solo. Insieme, però, disegnano un ritratto dell’interazione che nessun singolo documento potrebbe mai offrire: centinaia di segnali raccolti silenziosamente, valutati dall’AI in tempo reale, alimentando un motore di regole adattivo che decide, per questo utente in questo contesto, se consentire, approfondire o bloccare.

E quando entra in gioco un agente, si aggiunge un quinto pilastro:

• Catena di delega: chi ha autorizzato l’agente ad agire, con quale ambito operativo e in che modo quell’autorizzazione può essere verificata end-to-end.

Il modello mentale deve ribaltarsi. La fiducia non è più una proprietà del documento che sto tenendo in mano. È una proprietà della catena di evidenze che riesco a costruire attorno all’interazione. Il documento è un anello. Il dispositivo è un altro. Il comportamento è un altro ancora. La delega, quando c’è un agente coinvolto, è un ulteriore anello. Nessuno di essi, preso singolarmente, è sufficiente. Insieme, sono molto più resilienti di quanto il documento da solo non sia mai stato.

Non si tratta di sostituire il KYC. Si tratta di estenderlo, accettando che l’assunto fondante, “dall’altra parte c’è un essere umano con una credenziale verificabile”, non è più sempre valido.

Una sfida che esiste già oggi, non nel futuro

Quando parlo di KYA nelle conversazioni, a volte percepisco una reazione del tipo “interessante, ma sembra fantascienza”. I dati raccontano una storia diversa.

• 442 miliardi di dollari: perdite globali stimate dovute alle frodi finanziarie nel 2025, secondo l’ultimo Global Financial Fraud Threat Assessment di Interpol.
• 4,5 volte più redditizio: le frodi guidate dall’AI generano oggi circa quattro volte e mezzo il rendimento delle frodi tradizionali, a parità di sforzo.
• Il 35% delle organizzazioni ha subito incidenti legati ai deepfake nell’ultimo anno.
• Il 61% delle aziende ha agenti AI in produzione, e Gartner riporta che il 59% di questi opera al di fuori del perimetro della supervisione formale di sicurezza.

L’aspetto più scomodo di questo scenario non sono i numeri in sé, ma quanto sia diventato economico l’attacco. Un anno fa, generare un video deepfake credibile richiedeva tempo, potenza computazionale e denaro. Oggi chiunque abbia un laptop e una registrazione video può produrne uno in pochi minuti, gratuitamente. E il passo successivo è già qui: le identità sintetiche, volti che sembrano completamente reali ma non appartengono a nessuno. Nessuna fuga di dati, nessun furto, nessuna persona reale da verificare. Un vettore di frode che scala con una singola API call.

Tradotto: la superficie di attacco è cresciuta, è automatizzata ed economicamente molto più attraente di prima. Non è uno scenario ipotetico: è il presente.

Mentre i team di sicurezza inseguono questa ondata, i team di business continuano giustamente a concentrarsi sulla domanda che hanno sempre avuto: come evitare di perdere conversioni?

Tre forze, un equilibrio che non puoi spezzare

Ogni piattaforma di onboarding vive in una tensione costante tra tre forze:

1. Ridurre le frodi, chiudendo la porta ad attaccanti sempre più sofisticati e veloci.
2. Aumentare le conversioni, senza perdere utenti legittimi lungo il percorso.
3. Raggiungere il giusto livello di compliance, né troppo permissivo né eccessivamente complesso rispetto al caso d’uso.

Ogni decisione presa su una leva influisce inevitabilmente sulle altre. Aggiungere un controllo riduce le frodi ma rallenta il flusso. Semplificare il flusso aumenta la conversione ma può lasciare esposto un controllo. Una compliance “minima” può risultare una protezione insufficiente per casi ad alto rischio.

L’arrivo degli agenti AI amplifica tutte e tre queste tensioni. Stanno emergendo nuovi “killer” della conversione specifici dei flussi guidati da agenti:

• API non agent-friendly: l’onboarding richiede interazione con la UI e l’agente non sa cosa cliccare.
• Assenza di una trust chain: oggi non esiste uno standard per verificare chi ha autorizzato un agente a fare cosa.
• Assenza di un modello di delega: manca un framework per il passaggio “essere umano → agente” e viceversa, quando è necessaria l’approvazione esplicita dell’umano.
• Assenza di feedback loop: quando qualcosa fallisce, l’agente non riesce a interpretare l’errore e riprovare in modo intelligente.

Quando un agente AI fallisce un flusso di onboarding, non si lamenta sul tuo forum. Non chiama il supporto. Semplicemente se ne va. E con lui se ne va anche la transazione.

MCP: la lingua franca tra agenti AI e trust layer

MCP – Model Context Protocol è uno standard aperto che consente ai modelli e agli agenti AI di scoprire, comprendere e invocare le capacità di un sistema esterno in modo dichiarativo, senza che gli sviluppatori debbano orchestrare manualmente integrazioni REST riga per riga.

È il passaggio che descrivo come il passaggio dall’integrazione imperativa all’orchestrazione dichiarativa:

• Imperativo: dico al sistema esattamente cosa fare, passo dopo passo. Settimane di codice glue, logiche if-else fragili, un ciclo di rilascio per ogni modifica.
• Dichiarativo: dico all’agente cosa voglio ottenere. L’agente scopre le capacità disponibili a runtime, decide come combinarle, gestisce autonomamente errori e retry. Quello che prima richiedeva settimane di integrazione diventa configurazione.

Sulla carta, MCP è un enorme abilitatore per gli agenti. Ma, ed è questo il punto che voglio sottolineare, MCP da solo non basta. Uno standard aperto è una porta. Se dietro quella porta non esiste un trust layer che decide chi entra, cosa può fare e come vengono tracciate le sue azioni, tutto ciò che abbiamo fatto è facilitare gli attaccanti.

| Non solo MCP. MCP con un trust layer.

È questo il principio che abbiamo incorporato nel Namirial OnBoarding MCP Server: lo standard aperto è la forma, ma la sostanza è la garanzia di compliance, identità verificata e audit trail al livello di un Qualified Trust Service Provider europeo.

Concretamente, quando un agente AI si connette al nostro MCP server per orchestrare un flusso di onboarding:

1. Si autentica tramite My Namirial SSO: ogni azione è riconducibile a un’identità aziendale reale, non a una API key condivisa, ma alla stessa identità che l’utente possiede nel portale.
2. Eredita gli entitlement del proprio operatore: l’agente non può fare nulla che il suo operatore umano non possa già fare nella piattaforma. Nessuna escalation di privilegi tramite prompt injection.
3. Riceve automaticamente la configurazione normativa della giurisdizione: le regole KYC italiane sono diverse da quelle tedesche o spagnole. Il server applica automaticamente le regole corrette in base al Paese e al tipo di cliente.
4. Scrive un audit trail conforme all’AI Act: ogni tool call viene registrata con contesto conversazionale, identità dell’agente, timestamp e hashing tamper-evident, pronto per i regulator.

Il risultato pratico per chi integra è che un singolo prompt in linguaggio naturale come “Crea una richiesta di onboarding KYC per un cliente individuale italiano e genera un link di verifica con QR code” viene tradotto in una catena di API call certificate, governate e tracciabili. Quello che dall’esterno appare come una semplice verifica dell’identità è in realtà un percorso adattivo e intelligente step-by-step: la piattaforma decide quali controlli applicare, in quale ordine e quando effettuare escalation, in base al contesto della singola interazione. Lo sviluppatore si concentra sul workflow di business; i controlli eIDAS, AMLR e AI Act vengono applicati server-side, senza dover essere reimplementati per ogni nuovo agente.

C’è un’altra sfumatura importante da sottolineare. Il trust layer non esclude l’integratore dal flusso, ma lavora insieme a lui. Durante il percorso di onboarding, la piattaforma emette eventi a cui il system integrator può reagire: attivando controlli aggiuntivi, mostrando un messaggio personalizzato all’utente o chiedendo di ripetere un passaggio. L’integratore collabora per portare a termine con successo la transazione; ciò che non può fare è indebolire la compliance garantita end-to-end dalla piattaforma.

“Più l’AI diventa capace, più diventa critica la capacità di fidarsi di essa.”

In altre parole: l’agente accelera, ma la fiducia non viene mai delegata.

Cosa significa tutto questo per chi progetta onboarding oggi

Quando parlo con CIO, CISO e Head of Digital, c’è una frase che torna spesso: “Il nostro onboarding funziona da anni, perché dovremmo cambiarlo?”

La mia risposta è semplice. Non dobbiamo cambiare l’onboarding. Dobbiamo cambiare il modo in cui pensiamo all’onboarding. Per anni l’assunto dominante, in tutto il settore, è stato che dall’altra parte esistesse un solo tipo di controparte: un essere umano con una credenziale verificabile. Questo assunto non è più sempre vero. Il pubblico dall’altra parte ora è plurale – umani, agenti, ibridi – e i nostri flussi devono essere in grado di accogliere tutti, con il giusto livello di assurance per ciascuno.

Tre principi guida, maturati sul campo:

• Non è il cliente che deve adattarsi alla piattaforma. È la piattaforma che deve adattarsi al contesto. Modularità, configurabilità, certificazione: la stessa infrastruttura deve poter offrire un’attivazione di servizio a basso attrito e una Firma Elettronica Qualificata ad altissimo livello di assurance, semplicemente tramite configurazione.
• La fiducia è una catena, non un checkpoint. Non può vivere in un singolo passaggio, controllo del documento, liveness, OTP. Deve essere costruita sull’intera interazione – documento, dispositivo, comportamento, impronta digitale, delega – ed essere valutata in tempo reale. Solo una catena può reggere l’impatto degli agenti AI; un singolo checkpoint non potrà mai farlo.
• L’audit è un requisito by design, non un’aggiunta successiva. Con l’AI Act in vigore e i regulator che iniziano a chiedere evidenze delle decisioni guidate dall’AI, registrare chi ha fatto cosa e perché fa parte del prodotto, non è un nice-to-have.

Il punto, in una frase

Possiamo continuare a chiamarlo “onboarding”, ma ciò che stiamo realmente costruendo è qualcosa di più grande: un sistema di fiducia capace di capire, in tempo reale, chi c’è davvero dall’altra parte, un essere umano, un agente, una catena legittima di deleghe oppure un attacco automatizzato, e di concedere a ciascuno il corretto livello di fiducia.

L’AI può fare molte cose per conto nostro. Ma non senza permesso.

Sta a noi, come settore, costruire l’infrastruttura capace di emettere, verificare e soprattutto garantire quel permesso.

Vuoi vedere come si traduce tutto questo nella pratica?

In Namirial abbiamo costruito una piattaforma di onboarding modulare, apertamente componibile da agenti AI tramite il Namirial OnBoarding MCP Server. Se stai progettando il tuo prossimo flusso di onboarding, parliamone: scopri Namirial Onboarding.

E se hai trovato utile questo articolo, condividilo o lascia un commento su LinkedIn. KYA è una conversazione che stiamo iniziando ora, e mi piacerebbe ascoltare molte voci diverse.