Fornisci a un modello linguistico la frase “the bank of the river” (la riva del fiume), e il suo meccanismo di attenzione scansiona ogni altra parola nella frase, valuta quanto sia rilevante ciascuna di esse e lascia che “river” (fiume) allontani “bank” da una dozzina di significati possibili verso esattamente uno: un lembo di terra, non un istituto finanziario. “River” non si limita a stare vicino a “bank”. È il contesto che rende “bank” qualcosa di specifico.
Un agente di IA che lavora all’interno di un’azienda risolve l’ambiguità allo stesso modo, solo su scala molto più ampia. Le sue istruzioni, per quanto scritte con precisione, funzionano come “bank” da sola: generiche finché qualcosa non le disambigua in un’unica azione corretta. Ciò che serve per arrivarci è un obiettivo, il giusto contesto, dati in tempo reale e gli strumenti per agire su tutti e tre: quattro ingredienti che hanno pari peso e non funzionano da soli. Un obiettivo senza strumenti non può essere eseguito. Il contesto senza dati in tempo reale diventa obsoleto. Gli strumenti senza nessuno dei due si limitano a fare la cosa sbagliata più velocemente.
Ma l’ingrediente più difficile da mantenere affidabile nel tempo è il dato come contesto, ovvero un dato che sia aggiornato e descritto abbastanza bene da significare una cosa specifica nell’esatto momento in cui un agente agisce su di esso.
Quando i dati dietro un agente sono errati, nulla sembra errato
Il contesto può tradire un modello in due modi: troppo poco contesto, e il modello tende a indovinare; troppo contesto, non filtrato, e l’informazione rilevante è sepolta. I medesimi due fallimenti si verificano a livello di dati, ed è più difficile notarli perché nulla va in crash.
Un agente che ragiona su un record cliente obsoleto di due giorni e proveniente da tre sistemi diversi non genera un errore. Raggiunge una conclusione errata ma sicura di sé, con lo stesso tono che userebbe per una conclusione corretta. Questo è un errore di affidabilità: i dati non erano abbastanza buoni per agire.
L’altro errore è più silenzioso, e può accadere anche quando i dati sono perfetti. Un agente può avere a disposizione il record più fresco possibile e sbagliare comunque, perché nessuno gli ha detto che “polizza attiva” ha un significato specifico per questa azienda, o che un determinato segmento è fuori portata per una data offerta. È lo stesso divario che separa “banca” da “riva del fiume” prima che qualcosa lo disambigui, e la persona dall’altra parte, un cliente la cui richiesta viene approvata o respinta su quel fraintendimento, ne avverte la differenza anche se l’agente non la avverte mai. Entrambi gli errori non diventano tali finché qualcuno non verifica l’output rispetto alla realtà.
I dati in tempo reale hanno sempre fatto parte del quadro
Niente di tutto questo è una lacuna in una mappa governata di istruzioni e strumenti. Un Context Catalog elenca già dati e metadati tra le cose che traccia, connessi tramite relazioni tipizzate e dirette che lo fanno comportare meno come una directory e più come un knowledge graph, in grado di rispondere a come due cose siano correlate e non solo a dove si trovi ciascuna. I dati non sono mai stati l’ingrediente mancante. Erano inclusi fin dall’inizio, allo stesso modo in cui “fiume” era sempre da qualche parte nella frase prima che il modello imparasse a dargli il giusto peso.
Ciò di cui hanno bisogno i dati, tuttavia, differisce da ciò di cui ha bisogno un endpoint API. La struttura di un endpoint cambia su un ciclo di rilascio; un record cliente può cambiare cinque volte nel minuto necessario a leggere questa frase. Mappare i dati una volta indica a un agente dove risiedono, ma non gli dice se ciò che si trova lì in questo momento sia ancora attuale. Per questo serve un approccio progettato per il modo in cui i dati si comportano realmente: frammentati tra sistemi mai progettati per parlarsi tra loro, affidabili solo se qualcuno può verificare, in tempo reale, da dove provengono e se sono ancora attuali.
Cosa serve davvero per potersi fidare dei dati in tempo reale
Arrivarci richiede tre elementi, qualunque sia il modo in cui un’organizzazione decida di chiamarli:
- Sapere quali dati esistono e chi ne è responsabile, allo stesso modo in cui una cucina ha bisogno che la dispensa sia etichettata prima che qualcuno si metta ai fornelli, così che “cliente” significhi la stessa cosa sia che a chiederlo sia il marketing, il reparto sinistri o un agente.
- Una traccia documentale che mostri da dove proviene ciascun elemento e attraverso cosa è passato, allo stesso modo in cui una catena di fornitura traccia una spedizione fino al suo lotto, in modo che una modifica possa essere valutata prima di essere rilasciata e controllata a posteriori anziché presa sulla fiducia.
- Freschezza del dato indipendente dal fatto che qualcuno si ricordi di aggiornare, la differenza tra un live scoreboard e un giornale obsoleto.
L’approccio Data Fabric di Mia-Platform
Il Data Fabric è un’idea piuttosto affermata nell’architettura dei dati aziendali: unisce i dati da sistemi esistenti di un’organizzazione in un unico livello governato anziché smantellarli e ricominciare da capo. È ciò che dà all’etichetta della dispensa, alla traccia documentale e al live scoreboard una forma operativa anziché lasciarli come analogie. L’obiettivo non è introdurre un nuovo system of record, ma fare in modo che quelli già presenti si comportino come un’unica fonte di contesto affidabile per gli agenti.
Trasformare questi tre requisiti, inventario, provenienza e freschezza, in qualcosa su cui un agente possa fare affidamento richiede alcune capability concrete:
- Un inventario ricercabile di ciò che esiste e di chi ne è l’owner. In pratica, questo si concretizza in un Data Catalog: un registro unificato di dataset, pipeline e modelli estratti da ovunque risiedano i dati aziendali, da Oracle e Postgres fino a MongoDB, Salesforce e SAP HANA, abbinato a un Data Glossary condiviso così che termini come “sinistro” o “polizza” significhino la stessa cosa per ogni team e ogni agente che lo richieda.
- Una traccia documentale per ogni singolo dato. Il Data Lineage, dal livello di tabella fino al livello di sistema di record, mostra da dove i dati hanno avuto origine e attraverso cosa sono passati, in modo che l’impatto di una modifica possa essere valutato prima che venga rilasciata e verificato a posteriori.
- Freschezza che non dipende dal fatto che qualcuno si ricordi di premere aggiorna. È qui che entra in gioco il livello Fast Data: un motore disaccoppia i dati dai sistemi che li hanno prodotti inizialmente e mantiene una vista unica e governata, aggiornata man mano che tali sorgenti cambiano. Non tutto necessita di questo ritmo: un report trimestrale può ancora attendere un batch job, ma un agente di IA che prende decisioni in tempo reale non può farlo.
In un’implementazione come quella utilizzata in Mia-Platform, queste capability sono collegate tra loro in modo che la sincronizzazione tra Data Catalog e Fast Data sia eseguita continuamente. Un Job Runner all’interno del catalogo pianifica scansioni che mantengono i suoi metadati allineati con ciò che Fast Data eroga effettivamente, mentre un Open Lineage Service traccia la provenienza attraverso entrambi. Il risultato è una mappa che descrive dati freschi, accurati e puliti 24 ore su 24.
Da un dato grezzo a una decisione fondata
Disposti da un’estremità all’altra, un approccio data fabric e un Context Catalog governato, quello che il settore più ampio chiama talvolta un enterprise context layer, non sono alternative: sono fasi di un’unica pipeline. Ciò che viaggia al suo interno sono i dati come contesto, acquisendo significato, provenienza e freschezza a ogni passaggio prima che un agente agisca su di essi. Dal punto di vista dell’agente di quella pipeline, il lavoro passa attraverso AI Foundry. Questa è la piattaforma in cui vengono costruiti e supervisionati gli AI Playbook, ovvero i workflow riutilizzabili e governati che un agente esegue.
