Perché fallisce metà dei progetti GenAI: la verità sui dati dietro l’altra metà che sopravvive

Il perché del fallimento dei progetti GenAI non è più una discussione sulla qualità dei modelli. Falliscono perché le organizzazioni trattano i dati come un input da ripulire e non come una prova da certificare. Gartner individua cinque cause ricorrenti: scarsa qualità dei dati, controlli del rischio inadeguati, TCO che esplode, mancanza di valore di business e gestione del cambiamento debole. Due di queste, in realtà, collassano su una sola radice profonda, e quella radice vive nello strato di acquisizione dei dati.

Entro la fine del 2025, almeno la metà di tutti i progetti aziendali di intelligenza artificiale generativa è stata abbandonata dopo la fase di proof of concept. Il dato arriva da Arun Chandrasekaran, Distinguished VP Analyst di Gartner, nella sua analisi del 26 gennaio 2026 intitolata "Why Half of GenAI Projects Fail: Avoid These 5 Common Mistakes". Un secondo studio, "State of AI in Business 2025" del MIT NANDA, porta la percentuale al 95% sui pilot aziendali. NTT Data riferisce che tra il 70 e l'85% degli sforzi di deployment GenAI non raggiunge gli obiettivi. Una ricerca RAND del 2024 stima il tasso di fallimento intorno all'80%.

Questi numeri non si contraddicono fra loro. Misurano stadi diversi dello stesso fenomeno: le imprese stanno investendo miliardi nella GenAI e la maggior parte di quei miliardi non arriva mai in produzione. Quando ogni analista risponde "dati" alla domanda sulla causa, la conversazione si ferma un passo prima del punto utile: quale proprietà dei dati.

La tesi di questo articolo è che la frazione che sopravvive condivide una disciplina sola. Non ha i dati più puliti. Ha dati che riescono a dimostrare se stessi, autenticati al momento dell'acquisizione, tracciabili lungo ogni trasformazione, difendibili davanti a un regolatore. Il cuneo sotto la categoria "AI-ready data" è l'autenticità dei dati alla fonte: origine, integrità, catena di custodia, ammissibilità, verificabili dal momento in cui un fatto entra nel sistema fino a ogni uso a valle. Senza questo strato, la governance corre dietro ai problemi, il RAG recupera quello che trova nel corpus, e il programma di Responsible AI eredita qualunque bugia fosse nell'input.

Quello che segue mappa i cinque errori di Gartner, riformula i due che contano davvero attraverso la lente dell'autenticità dei dati, definisce lo strato mancante e propone un manuale operativo in quattro fasi per la metà che attraverserà il 2026 in piedi.

La mappa dei cinque errori: cosa dice davvero Gartner

L'analisi Gartner individua cinque errori che spiegano la maggior parte dei fallimenti GenAI. La tassonomia è diventata il riferimento citato nelle note degli analisti, nei board deck e nel pool di citazioni delle AI Overview. Conviene restituirla con precisione: qualunque risposta onesta sulla causa dei fallimenti GenAI deve partire da queste cinque voci, perché il pattern di fallimento si ripete su ogni dataset disponibile.

1.1 Mancanza di valore di business

I progetti partono come esperimenti tecnologici e non come soluzioni a un problema definito. I team scelgono il modello prima di scegliere il risultato. Senza obiettivi misurabili su produttività, costo, soddisfazione del cliente o throughput di conformità, il progetto va alla deriva. Gartner raccomanda un quadro rigoroso di prioritizzazione degli use case con criteri di successo quantificati, applicato prima di qualunque scelta del modello.

1.2 Scarsa qualità dei dati

I dati sono incompleti, incoerenti, etichettati male, senza governance, oppure non adatti al retrieval-augmented generation. Secondo Gartner, le organizzazioni con deployment AI di successo investono fino a quattro volte di più nelle loro fondazioni dati rispetto a quelle che falliscono. L'analisi Informatica del 2025 descrive i problemi sui dati come la sorprendente causa primaria di gran parte dei fallimenti AI. NTT Data attribuisce il suo 70-85% di fallimenti alla scarsa igiene dei dati e a una governance debole.

1.3 TCO che esplode

I costi di inferenza, lo scaling dei vector database, il riaddestramento dei modelli, il consumo di token nei prompt e il debito di integrazione si accumulano. Al nono mese di un tipico pilot, l'economia unitaria non sostiene più il razionale economico iniziale. Gartner raccomanda una disciplina di GenAI FinOps fin dal primo giorno: caching dei prompt, model routing, riuso degli output e una telemetria di costo per use case che mostri il ROI in tempo reale.

1.4 Controlli del rischio inadeguati

La Responsible AI viene trattata come un pensiero a posteriori, non come il sistema operativo del deployment. Validazione degli input, monitoraggio degli output, audit trail, controlli di accesso, registrazione per la conformità: vengono aggiunti nell'ultimo sprint prima del lancio, non disegnati nell'architettura. Il risultato è un modello che funziona ma non è difendibile davanti a un regolatore, a un giudice o a un audit interno.

1.5 Gestione del cambiamento debole

Il flusso di lavoro non assorbe il modello. Le persone lo evitano, non si fidano, oppure lo usano per i compiti sbagliati. Gartner indica empathy map e coinvolgimento nei pilot come rimedi standard. Lo studio RAND del 2024 inquadra questo come lo strato di interazione del fallimento AI, distinto dallo strato di processo e da quello tecnico ma altrettanto frequente.

1.6 Nota sui tassi di fallimento concorrenti: come si conciliano 50%, 95%, 70-85% e 80%

I numeri in circolazione non sono in conflitto: misurano fasi diverse dello stesso pipeline. Il 50% di Gartner conta i progetti abbandonati dopo il proof of concept entro fine 2025. Il 95% del MIT NANDA conta i pilot che non sono mai diventati integrazioni enterprise. Il range 70-85% di NTT Data copre i deployment che non raggiungono gli obiettivi dichiarati. L'80% di RAND è una media cross-studio sui progetti AI in generale. Una stima Gartner separata, ripresa da Forbes Tech Council e FullStack, attribuisce circa l'85% di questi fallimenti specificamente a problemi di qualità dei dati. La riconciliazione: man mano che un progetto passa da pilot a deployment, da deployment a produzione e da produzione a ROI sostenuto, l'attrito si somma a ogni cancello. Ogni statistica è corretta per lo stadio che misura.

Due di questi cinque errori, qualità dei dati e controlli del rischio, non sono fallimenti paralleli. Sono lo stesso fallimento raccontato due volte. Le due sezioni successive spiegano perché.

Errore 2 riformulato: "qualità scarsa dei dati" significa in realtà "dati non verificabili"

Il rimedio standard alla scarsa qualità dei dati è costruire una fondazione di AI-ready data. Pipeline di curation, master data management, vector database, knowledge graph, etichettatura automatizzata, deduplicazione, applicazione degli schemi. Tutto necessario. Non sufficiente. Un AI-ready data eredita comunque il gap di fiducia della sua sorgente. Pulito non significa vero. Governato non significa autentico. Il problema "garbage in" dell'era analitica è diventato un problema "garbage from where" nell'era GenAI.

2.1 Il problema "garbage in" è diventato un problema "garbage from where"

In una pipeline ETL tradizionale, lo scenario peggiore di dati cattivi era una colonna numerica corrotta o un join disallineato. In una pipeline generativa, lo scenario peggiore è un documento che sembra legittimo ma è stato falsificato, manipolato o generato da un altro modello a monte. Il retrieval del RAG tratta ogni documento nel vector store con lo stesso peso di confidenza. Un documento KYC fabbricato, una prova manipolata in un fascicolo sinistri, un'attestazione di conformità sintetica: ognuno entra nel set di recupero e viene presentato all'utente con la stessa massa di probabilità del documento autentico.

Perché la scarsa qualità dei dati è la causa numero uno dei fallimenti dei progetti AI? Le analisi convergono su campi mancanti, formati incoerenti, etichettatura debole, assenza di governance. La causa più profonda sta uno strato sotto: l'input non riesce a dimostrare ciò che dichiara di essere. Quando la fonte non è verificabile, ogni rimedio a valle amplifica il gap originario invece di chiuderlo.

2.2 Perché curation, governance e vector database non risolvono la provenance

La data governance definisce la politica: controlli di accesso, lineage all'interno del data warehouse, SLA di qualità, regole di retention. La data provenance documenta la storia: da dove viene un certo record, chi l'ha toccato, cosa è cambiato. L'autenticità dimostra l'identità: il record è ciò che la sorgente dichiara essere, e non è stato manomesso dall'acquisizione in avanti. Sono tre discipline distinte. La maggior parte delle imprese ha investito nella prima, sta iniziando a investire nella seconda e non ha ancora riconosciuto la terza come categoria.

L'impostazione di Informatica spinge la governance a includere metadati che tracciano l'origine. Questo si avvicina più alla provenance che all'autenticità, ma si ferma al perimetro del sistema. Una volta che un documento entra dall'esterno (un upload di partner, una submission cliente, un feed di notizie, un dataset pubblico, uno scraping web), il metadato è quello che il sistema d'origine ha dichiarato. Nessuno prova quella dichiarazione. Il Software Engineering Institute di Carnegie Mellon fa esattamente questo argomento nella sua analisi sul data poisoning nei modelli AI: il caso per i controlli di chain of custody è il caso per trattare i dati di training come la prova digitale viene trattata nella pratica forense da vent'anni.

Qual è la differenza tra data governance e data provenance? La governance definisce politiche, controlli di accesso e regole di ciclo di vita per i dati dell'organizzazione. La provenance documenta l'origine e la storia di trasformazione di un singolo dato. La governance è il sistema. La provenance è la prova. Un programma GenAI robusto ha bisogno di entrambe. Quando l'uso a valle è di natura regolatoria o probatoria, serve un terzo strato: l'autenticità, la proprietà che il dato sia ciò che la sorgente dichiara.

2.3 Cosa richiede davvero un dato "AI-ready": i sei criteri standard più un settimo

La checklist standard per AI-ready data, estratta da IBM, Qlik, Gartner e dal consenso degli analisti, contiene sei proprietà. Un settimo criterio sta emergendo nei settori regolati, ed è quello che separa un AI-ready data da un dato pronto per la GenAI.

Il settimo criterio cambia il significato dei primi sei. Se un record non può dimostrare da dove viene, nessuna delle altre proprietà sopravvive al di fuori del perimetro in cui è stata stabilita. Un fascicolo sinistri pulito, governato e contestualizzato in modo perfetto resta inutile in un giudizio se la fotografia sottostante non può essere collegata a un evento di acquisizione verificabile.

Cosa significa dato pronto per l'AI e in cosa differisce da un dato autenticato? Un AI-ready data è pulito, strutturato, contestualizzato, governato, rappresentativo e conforme. La maggior parte delle checklist si ferma qui. La settima proprietà, la verificabilità alla fonte, è quella che determina se il dato può essere usato in un downstream regolatorio, probatorio o critico per la fiducia. È la proprietà che un AI-ready data eredita dallo strato di acquisizione, non dallo strato di governance.

Come faccio a rendere i miei dati pronti per l'AI? Si parte da un audit guidato dagli use case: ogni input dati viene classificato per esposizione regolatoria, valore probatorio e criticità di fiducia. Per gli use case a bassa esposizione (produttività interna, code completion, drafting generico) basta la governance standard. Per gli use case ad alta esposizione (sinistri, KYC, consenso sanitario, consulenza finanziaria, revisione legale) serve uno strato di autenticità in acquisizione. L'audit fissa l'asticella; l'architettura segue l'asticella.

2.4 Un esempio concreto: la pipeline RAG assicurativa che superava ogni audit

Una compagnia assicurativa europea di medie dimensioni ha costruito un assistente di triage sinistri basato su RAG. Il corpus di retrieval combinava fotografie inviate dai sinistrati, dichiarazioni scritte e referti medici forniti da partner, tutti instradati attraverso uno strato di ingestione governato con schemi documentati ed etichettatura pulita. I dati superavano ogni audit di qualità definito dal team.

In una revisione adjudicativa a valle, tre sinistri su quaranta hanno fatto emergere anomalie: fotografie il cui canale di acquisizione non era ricostruibile, dichiarazioni con marche temporali incoerenti rispetto al log degli upload del partner e referti medici la cui catena di origine si interrompeva su un intermediario. L'assistente aveva eseguito il retrieval in modo corretto. I dati avevano superato la governance. Nulla di tutto questo è risultato rilevante davanti al regolatore, perché la catena di custodia dei record sottostanti era stata persa nel momento dell'acquisizione. La pipeline è stata ricostruita con autenticazione a livello di canale, e l'audit successivo si è chiuso senza rilievi.

La lezione: la prontezza all'AI misurata da qualità e governance non coincide con la prontezza probatoria. Il gap si manifesta nello strato di acquisizione, e i rimedi a valle non riescono a chiuderlo.

Il RAG risolve le allucinazioni se la fonte dei dati non è verificabile? Il retrieval-augmented generation riduce la fabbricazione quando il corpus contiene contenuti affidabili e veri. Non valida il corpus in sé. Se i documenti sorgente nel vector database sono falsificati, manipolati o di origine non verificata, il RAG li recupera e li presenta con la stessa confidenza dei documenti autentici. Ancorare il modello a dati non verificati significa sostituire l'allucinazione con la disinformazione amplificata. Le prove peer-reviewed di un'analisi PMC del 2025 confermano che la qualità del retrieval è limitata dall'affidabilità della fonte. L'autenticità in acquisizione è la precondizione che il RAG presuppone ma non impone.

Qual è la causa profonda delle allucinazioni dell'AI? Le allucinazioni nascono su tre strati: a livello di modello (predizione probabilistica del token successivo senza ancoraggio al mondo), a livello di retrieval (lacune nel corpus o recuperi a bassa rilevanza) e a livello di sorgente (il corpus contiene contenuti falsi o manipolati). I primi due sono ampiamente discussi. Il terzo è sotto-diagnosticato. Quando lo strato sorgente non è verificato, i guardrails di retrieval e i monitor di output rilevano i sintomi, non le cause.

Come si confronta la qualità dei dati con l'autenticità dei dati? La qualità descrive accuratezza, completezza e coerenza dei record dopo che sono entrati nel sistema. L'autenticità descrive la verificabilità dell'origine e dell'integrità nel momento dell'ingresso. La qualità è a valle. L'autenticità è a monte. I programmi sulla qualità riconoscono un campo corrotto; i programmi sull'autenticità impediscono che un record non verificabile venga trattato come autorevole.

Errore 4 riformulato: la Responsible AI è a valle dell'input verificabile

La maggior parte dei quadri di Responsible AI guarda all'output: audit di equità, mitigazione dei bias, strumenti di spiegabilità, filtri anti-allucinazione, monitor di sicurezza. L'assunzione implicita è che l'input sia ciò che qualcuno dice essere. Nel 2026, quella assunzione è la superficie d'attacco. Materiale di training iniettato da deepfake, documenti di conformità sintetici, submission di ingresso clienti manipolate, prove generate da AI: ogni elemento entra nella pipeline attraverso un canale che non verifica la dichiarazione alla porta, e ogni guardrail a valle eredita la bugia.

3.1 I cinque pilastri della Responsible AI e cosa ciascun pilastro assume silenziosamente

Il quadro canonico della Responsible AI poggia su cinque pilastri: equità, trasparenza, accountability, privacy e sicurezza. Ogni pilastro contiene un'assunzione implicita sull'input che raramente viene esplicitata.

L'equità assume che il segnale demografico nel dato di training sia genuino e non plasmato in modo avversario. La trasparenza assume che le fonti dati documentate siano le fonti dati reali. L'accountability assume che l'audit trail cominci all'acquisizione e non all'inferenza. La privacy assume che il record di consenso allegato a un dato rifletta ciò che il soggetto ha effettivamente accettato. La sicurezza assume che l'input ricevuto dal modello sia l'input che il canale dichiara di aver trasmesso.

Quando una di queste assunzioni cade allo strato dati, il pilastro sopra cade in silenzio. Il programma di Responsible AI continua a far girare i suoi pannelli di controllo. Il modello continua a fare buoni punteggi sui benchmark di equità. Lo strumento di mitigazione dei bias continua a segnalare gli output. Nessuno vede che il record a monte era falsificato.

3.2 Audit trail che partono dall'inferenza sono audit trail che finiscono al sintomo

Un log di audit del modello registra ogni inferenza: input, output, latenza, utente, versione del modello. È utile per il monitoraggio dell'output. Non è utile per la difesa della sorgente. Quando la domanda diventa "da dove veniva l'input e chi può provare che non sia stato alterato dall'acquisizione in poi", un log di inferenza restituisce zero.

L'audit trail rilevante parte dall'acquisizione e si propaga lungo ogni trasformazione: ingestione, normalizzazione, vector embedding, retrieval, fine-tuning, inferenza, rendering dell'output. Ogni trasformazione è un passaggio di consegne. Ogni passaggio è documentato. La catena tiene in tribunale, davanti a un regolatore, sotto audit. È lo standard che la comunità della prova digitale usa da due decenni sotto ISO/IEC 27037 e norme contigue.

Come si possono mitigare le allucinazioni dell'AI nello strato sorgente? Combinando tre controlli: autenticare gli input in acquisizione (così il corpus contiene solo record che possono provare la propria origine), documentare ogni trasformazione in un audit trail immutabile (così retrieval e inferenza ereditano la prova) e applicare la validazione dell'input prima che il modello veda il dato (così le submission avversarie vengono respinte alla porta e non filtrate all'uscita).

3.3 La provenance come precondizione: chi, quando, dove, da quale dispositivo, non manomesso da allora

La provenance allo strato di acquisizione risponde a cinque domande per ogni input. Chi l'ha acquisito: un'identità verificata, non una dichiarazione di testo libero. Quando: una marca temporale firmata da un servizio fiduciario qualificato, non l'orologio di sistema. Dove: una coordinata geografica catturata in acquisizione, non una posizione dedotta. Da quale dispositivo: un'impronta del dispositivo e una versione software registrate al momento della cattura. Non manomesso da allora: un hash crittografico dell'artefatto, ancorato in acquisizione, verificabile in ogni momento successivo.

Queste cinque risposte sono ciò che converte un input da "dato che il sistema ha ricevuto" a "prova che il sistema può difendere". Sono anche ciò che gli attuali quadri di Responsible AI omettono dallo strato di input delle loro architetture, perché non erano stati progettati per un mondo dove l'input è avversario.

3.4 EU AI Act, articolo 10 e articolo 12: cosa il regolatore vuole vedere davvero documentato

L'Legge UE sull'AI, Regolamento (UE) 2024/1689, entra in vigore per i sistemi di AI ad alto rischio il 2 agosto 2026. Due articoli pesano in modo particolare sullo strato dati.

L'articolo 10 prescrive che i sistemi di AI ad alto rischio siano sviluppati su dataset di addestramento, validazione e test che rispondano a criteri di qualità, fra cui pertinenza, rappresentatività, assenza di errori e proprietà statistiche appropriate allo scopo. Richiede anche l'esame dei bias che possono incidere su salute, sicurezza o diritti fondamentali. La conseguenza implicita: un'organizzazione deve essere in grado di documentare la provenance e le caratteristiche di ogni dataset usato per addestrare o affinare il sistema.

L'articolo 12 prescrive la registrazione automatica degli eventi durante l'intero ciclo di vita del sistema AI. I log devono consentire l'identificazione delle situazioni che possono creare un rischio e facilitare il monitoraggio post-immissione sul mercato. La conseguenza implicita: l'audit trail deve essere leggibile dalla macchina, esportabile su richiesta e completo dall'acquisizione fino all'inferenza.

L'articolo 53(1)(c) applica un dovere simile di documentazione sulla provenance ai fornitori di modelli AI di uso generale, riguardo ai dati impiegati nell'addestramento.

In Italia il quadro si compone con il Codice dell'Amministrazione Digitale (D.Lgs 82/2005), l'articolo 2712 del Codice Civile sulle riproduzioni meccaniche, il Regolamento eIDAS (UE) 910/2014 e il Regolamento eIDAS 2 (UE) 2024/1183, che ridefinisce i sigilli elettronici qualificati a distanza e fissa la scadenza del 21 maggio 2026 per gli operatori.

Un requisito complementare emerge nel NIST AI Risk Management Framework sotto le funzioni "Manage" e "Map": le organizzazioni devono documentare fonte, lineage e integrità dei dati usati nei sistemi AI. Insieme a ISO/IEC 27050 sull'electronic discovery e all'analisi peer-reviewed di Longpre e colleghi del 2024, il consenso regolatorio e accademico converge sullo stesso punto: autenticità dei dati, consenso e provenance per l'AI sono strutturalmente inadeguati nella pratica attuale e vanno affrontati allo strato architetturale, non come uno strato di conformità sovrapposto.

L'articolo TrueScreen su certificazione dei dati per agenti AI tratta le implicazioni più ampie di governance e responsabilità quando questi doveri si estendono dagli input alle azioni di agenti autonomi.

Come tratta l'AI Act la provenance dei dati per i sistemi ad alto rischio? L'articolo 10 impone dati di training e di test che rispondano a criteri di qualità, fra cui pertinenza, rappresentatività e assenza di errori, con documentazione delle proprietà e dei bias. L'articolo 12 impone la registrazione automatica degli eventi lungo il ciclo di vita del sistema, esportabile per il monitoraggio post-immissione sul mercato. Insieme richiedono una provenance dimostrabile e un registro auditabile di ogni interazione con i dati. L'autenticità in acquisizione produce entrambe le cose: l'origine è documentata, la catena è registrata, il record è difendibile.

Perché i progetti AI falliscono nonostante i programmi di Responsible AI? Quasi tutti i programmi di Responsible AI operano allo strato di output: audit dei bias, metriche di equità, pannelli di spiegabilità, filtri di sicurezza. Lo strato di input viene assunto come governato e affidabile. Quando lo strato di input non riesce a provare la propria origine, i controlli a valle ereditano il gap. Un deployment del 2026 che fallisce davanti a un regolatore tipicamente fallisce allo strato di input, non a quello di modello.

L'articolo su voice cloning e frodi aziendali e l'analisi sull'autenticazione delle immagini aziendali descrivono due superfici d'attacco concrete dove il gap dello strato di input ha già prodotto perdite aziendali documentate.

Lo strato di autenticità dei dati

L'autenticità dei dati è la proprietà di un asset digitale la cui origine, integrità e catena di custodia sono verificabili in modo indipendente dal momento dell'acquisizione lungo ogni uso a valle, incluso l'addestramento AI, il fine-tuning, il retrieval-augmented generation e l'inferenza. A differenza della qualità dei dati, che descrive accuratezza e completezza dopo l'elaborazione, l'autenticità prova che l'input è ciò che la sorgente dichiara essere, prima che qualsiasi pipeline, vector database o strato di governance lo trasformi. Non è una feature di un prodotto dati. È una categoria di infrastruttura, posizionata sotto la governance, sotto la curation, sotto i metadati di provenance, allo strato in cui un fatto entra nell'organizzazione.

4.1 Origine, integrità, custodia, ammissibilità: le quattro proprietà

Quattro proprietà definiscono l'autenticità allo strato dati.

Origine risponde a chi, quando, dove, da quale dispositivo. L'acquirente è identificato, non dichiarato. La marca temporale è ancorata a un servizio fiduciario qualificato. Il contesto geografico e di dispositivo viene catturato al momento dell'acquisizione, non ricostruito a posteriori.

Integrità è la garanzia crittografica che l'artefatto non sia cambiato dall'acquisizione in poi. Un hash SHA-256 viene calcolato in cattura e ancorato. Ogni modifica successiva è rilevabile.

Custodia è la catena documentata dei passaggi di consegne dall'acquisizione fino a ogni trasformazione. Ogni passaggio è registrato. Il registro è immutabile.

Ammissibilità è la proprietà secondo cui la catena tiene davanti a un giudice, a un regolatore o a un audit interno. Si appoggia alle stesse norme legali e tecniche usate per la prova digitale nel contenzioso, fra cui l'articolo 2712 del Codice Civile per l'ordinamento italiano e i Federal Rules of Evidence negli ordinamenti angloamericani. L'analisi TrueScreen sulla Certified Data Room approfondisce questa dimensione.

Queste quattro proprietà non sono miglioramenti della qualità dei dati. Sono ciò che converte un dato da input a prova.

4.2 Dove sta questo strato: prima della pipeline, non dentro

La scelta architetturale decisiva è il posizionamento. L'autenticità sta prima della pipeline, non dentro. Se autentichi in acquisizione, ogni componente a valle eredita la prova. Se autentichi dentro la pipeline (nel data warehouse, nel vector database, allo strato di inferenza), la catena si è già spezzata al punto di ingresso.

Questo posizionamento è ciò che distingue l'autenticità dagli standard di provenance lato contenuto. Lo standard C2PA e i sistemi di content credentials provano a legare la provenance al contenuto stesso attraverso metadati incorporati nel file. L'approccio ha senso per la distribuzione mediatica. È insufficiente per il controllo dell'input aziendale: il metadato sta dentro il contenuto, può essere rimosso e non include l'identità dell'acquirente, la marca temporale qualificata, né la catena ancorata a un servizio fiduciario. L'autenticità in acquisizione produce un record fuori banda che sopravvive a una modifica del contenuto.

4.3 Cosa cambia operativamente

Le conseguenze operative dello spostare l'autenticità in acquisizione sono concrete. Il tempo di discovery scende, perché la sorgente di ogni input è ricostruibile in secondi e non in giorni. Il ciclo di audit si comprime, perché esiste una sola fonte di verità per ogni record invece di una catena ricostruita a posteriori fra sistemi. Il tempo di risposta al regolatore migliora, perché la documentazione richiesta dall'articolo 10 è disponibile al volo e non viene assemblata retrospettivamente. La due diligence sui dati di training diventa trattabile, perché ogni dataset può essere filtrato per attributi di provenance. Il rischio fornitore sui dataset di terzi diventa gestibile, perché il confine della fiducia è esplicito.

TrueScreen certifica queste quattro proprietà al momento dell'acquisizione, così che si propaghino a valle in modo automatico. La certificazione combina acquisizione e metodologia forense, hash crittografici di integrità, marche temporali qualificate e sigilli elettronici qualificati apposti da prestatori di servizi fiduciari qualificati terzi via API. TrueScreen non è un prestatore di servizi fiduciari qualificato: integra sigilli emessi da QTSP qualificati terzi, così il peso legale della certificazione poggia sulla stessa catena che sostiene la prova digitale ammissibile in giudizio in Europa e nel più ampio quadro eIDAS 2. Per le organizzazioni il cui downstream è regolatorio, probatorio o critico per la fiducia, questo strato diventa una precondizione e non un'opzione.

4.4 Perché è una categoria, non una feature

La combinazione di acquisizione con metodologia forense, marca temporale qualificata, hash di integrità, verifica dell'identità dell'acquirente e immutabilità ancorata a un servizio fiduciario qualificato non esiste dentro gli strumenti di data quality, dentro le suite di governance o dentro i prodotti di vector database. È una categoria di infrastruttura adiacente a quegli strumenti, non una feature dentro. L'analogo più vicino è la catena della prova digitale usata nella pratica legale, che è maturata sotto ISO/IEC 27037 e ISO/IEC 27050 e standard contigui.

Il paper di Longpre e colleghi del 2024 sull'autenticità dei dati, il consenso e la provenance per l'AI raggiunge la stessa conclusione architetturale dal versante accademico: gli strumenti correnti sono strutturalmente inadeguati, e il gap richiede uno strato dedicato e non una governance incrementale.

Un manuale operativo per il 50% che sopravvive

La metà che sopravvive nel 2026 condividerà una disciplina in quattro fasi. Identificare gli use case critici per la fiducia. Autenticare in acquisizione. Ereditare e propagare la prova. Difendere e auditare a richiesta. Non è una generica lista di dieci consigli; è un modello di maturità con checkpoint concreti a ogni fase, ed è la risposta operativa alla domanda sul perché i progetti GenAI falliscono su scala anche quando i singoli pilot sembrano riusciti. Il lavoro è sequenziale, i ritorni sono cumulativi, e la fase quattro è dove le organizzazioni esposte al regolatore guadagnano la licenza di operare su scala.

Cos'è l'autenticità dei dati e perché conta per la GenAI? L'autenticità dei dati è la proprietà di un asset digitale la cui origine, integrità e catena di custodia sono verificabili in modo indipendente dal momento dell'acquisizione lungo ogni uso a valle. Per la GenAI conta perché retrieval, fine-tuning e inferenza ereditano il profilo di fiducia dell'input. Senza un input autenticato, ogni output è la migliore congettura che il modello può fare su un corpus non verificato, e nessuno strato di governance può rimediare in modo retroattivo.

Il RAG risolve le allucinazioni se la fonte dei dati non è verificabile? In parte, e solo nella direzione sbagliata. Il RAG riduce le allucinazioni ancorando le risposte ai documenti recuperati, ma non verifica quei documenti. Se il corpus di retrieval contiene un record manipolato, falsificato o sintetico, il RAG lo riporta con piena confidenza come fatto. La mitigazione corretta accoppia il RAG con l'autenticazione del corpus sorgente in acquisizione, così l'ancoraggio del retrieval poggia su input che possono dimostrare la propria origine e integrità.

Qual è la differenza fra data governance e data provenance? La data governance è l'insieme di politiche, ruoli e processi che gestiscono qualità, accesso e ciclo di vita dei dati dentro un'organizzazione. La data provenance è il registro verificabile della provenienza di un dato specifico: da dove viene, quando è stato creato, da chi e come è cambiato. La governance risponde a chi è responsabile. La provenance risponde a cosa è vero. Entrambe sono necessarie; nessuna sostituisce l'altra.

5.1 Fase uno: identificare

Mappare ogni use case GenAI attivo e pianificato lungo tre assi: esposizione regolatoria, valore probatorio, criticità di fiducia. Un chatbot di consulenza finanziaria ha alta esposizione regolatoria (le comunicazioni MiFID II richiedono registrazioni certificate). Un sistema di triage sinistri ha alto valore probatorio (un giudizio può ruotare attorno a una sola immagine). Una televisita ha entrambe le cose, più la criticità di fiducia (il paziente deve poter invocare il record nelle cure successive). Un assistente di code completion non ne ha nessuna. La mappatura determina quali use case hanno bisogno di autenticazione in acquisizione e quali possono operare su dati governati standard.

Output: un inventario di use case con un flag binario di criticità di fiducia, un flag di esposizione al regolatore e un flag di valore probatorio per ciascuno.

5.2 Fase due: autenticare in acquisizione

Per ogni use case critico per la fiducia, si definiscono i metadati minimi di provenance per classe di input: identità dell'acquirente, marca temporale qualificata, geolocalizzazione, impronta del dispositivo, hash di integrità, sigillo qualificato. Si integra uno strumento di acquisizione certificata in ogni canale che alimenta lo use case: cattura mobile, upload web, SFTP partner, submission API, acquisizione lato browser per sorgenti dell'internet pubblico, canali di intake documentale certificati. Le organizzazioni che gestiscono deployment GenAI regolatori, probatori o critici per la fiducia usano TrueScreen per autenticare gli input prima che entrino nella pipeline, lungo i canali mobile, web, browser e programmatici.

Output: un diagramma architetturale a livello di canale con la copertura di autenticazione per ogni classe di input in scope.

Come si garantiscono dati pronti per l'AI negli use case ad alto rischio? Si identificano gli use case con downstream regolatorio, probatorio o critico per la fiducia. Per ciascuno si definiscono i metadati minimi di provenance per classe di input. Si integra l'acquisizione certificata in ogni canale. Si testa la catena end-to-end ricostruendo un singolo record dall'inferenza all'acquisizione. Se la ricostruzione riesce, lo use case è pronto per la GenAI. Se si interrompe a un passaggio di consegne, l'architettura deve chiudere il gap prima del lancio.

5.3 Fase tre: ereditare e propagare

Far passare la prova attraverso la pipeline. Il certificato di acquisizione viaggia con il dato lungo ETL, normalizzazione, vector embedding, log di retrieval, dataset di fine-tuning e output di inferenza. Ogni trasformazione si aggiunge alla catena invece di sostituirla. Il sistema di retrieval mostra la provenance accanto al contenuto, così il modello e l'utente vedono entrambi. Il log di inferenza include la provenance di ogni sorgente recuperata, così la difesa dell'output comincia dalla fonte e non dalla risposta.

È il lavoro di ingegneria che chiude il gap che la maggior parte dei programmi dati ignora: governance e curation operano a livello di dataset, mentre l'autenticità opera a livello di record. La logica di propagazione deve trattare ogni record come portatore della propria catena di custodia.

5.4 Fase quattro: auditare e difendere

Esportare la catena su richiesta. La richiesta del regolatore, l'ordine del giudice, l'audit interno, la disputa col cliente: ognuno richiede la stessa esportazione, nello stesso formato, con lo stesso peso legale. Integrare la catena nella telemetria di costo FinOps, così il costo marginale dell'autenticazione appare nell'economia unitaria di ogni use case. L'errore tre di Gartner (TCO che esplode) vive anche qui: le pipeline autenticate hanno un overhead che deve essere visibile al CFO fin dal primo giorno e non emergere a fine trimestre come una sorpresa.

La catena si integra con un'infrastruttura probatoria più ampia, fra cui le Certified Data Room per archivi documentali pronti al contenzioso, così l'architettura operativa e quella probatoria condividono la stessa fonte di verità.

Come si misura il ROI di un investimento GenAI con overhead di autenticazione? Si calcola il costo marginale dell'autenticazione per use case (strumenti di acquisizione, costo della marca temporale qualificata, archiviazione degli hash di integrità, strumenti di export per l'audit). Lo si confronta con tre categorie di costo evitato: sanzioni del regolatore per documentazione mancante, tempo di risoluzione delle dispute per prove non verificabili, costo di ricostruzione quando un deployment fallisce la revisione di conformità. Negli use case ad alta esposizione, il costo evitato di solito domina già al primo ciclo di audit.

Autovalutazione (cinque domande sì/no):

1. Riesci a identificare, in meno di sessanta secondi, quali fra i tuoi use case GenAI ricadono in un downstream regolatorio, probatorio o critico per la fiducia?
2. Per ciascuno di quegli use case, sai quali canali di input alimentano il modello e quei canali autenticano in acquisizione?
3. Se un regolatore chiedesse oggi la catena di custodia per un singolo record processato dal tuo sistema GenAI ad alta esposizione, riusciresti a produrla senza ricostruzione manuale?
4. Il tuo log di inferenza include la provenance delle sorgenti recuperate per ogni output del modello?
5. Il costo dell'autenticazione è visibile nell'economia unitaria per use case del tuo portfolio AI?

Tre o meno sì: il programma rischia di stare nel 50% che non supererà il 2026. Quattro o cinque: la disciplina c'è; il lavoro residuo è esecutivo.

Caso d'uso

Antiriciclaggio certificato: prove digitali per KYC e adeguata verifica

Scopri come TrueScreen certifica gli input KYC al momento dell'acquisizione con marca temporale qualificata e catena di custodia per i programmi antiriciclaggio.

Scopri di più →

Controargomenti, limiti e quando NON serve

Non tutti gli use case GenAI richiedono input autenticato. Assistenti di produttività interna, code completion, drafting generico di contenuti, sintesi di informazioni pubbliche, strumenti di ideazione: operano a bassa esposizione regolatoria, basso valore probatorio e bassa criticità di fiducia. La governance standard basta. Aggiungere uno strato di autenticità a questi use case è overhead senza ritorno, e la decisione corretta è saltarlo.

L'autenticazione non risolve prompt malfatti, retrieval debole, modelli sottodimensionati o un inquadramento aziendale sbagliato. L'errore uno di Gartner (mancanza di valore di business) resta un problema a sé. Una pipeline con provenance perfetta e una metrica di successo sbagliata fallisce comunque. L'autenticazione è necessaria per una classe di fallimenti, non sufficiente per tutti.

C'è anche un limite su quello che l'autenticità può fare contro la sintesi a valle. Lo studio di Edinburgh sulle impronte AI mostra che gli approcci lato output al rilevamento dei contenuti generati dall'AI incontrano soffitti strutturali: man mano che i modelli generativi migliorano, l'accuratezza del rilevamento si degrada. L'implicazione non è un controargomento all'autenticità; è il suo opposto. Il rilevamento allo strato di output è limitato. L'autenticazione allo strato di input non è limitata dalla qualità del generatore, perché non prova a distinguere reale da sintetico a posteriori. Prova l'origine al momento dell'acquisizione. Più diventa difficile rilevare i contenuti sintetici a valle, più il peso della fiducia si sposta a monte, allo strato di input.

Infine, il costo è reale. La provenance ha un overhead: strumenti di acquisizione, archiviazione degli hash di integrità, costo della marca temporale qualificata, pipeline di export per l'audit. I conti FinOps vanno fatti per use case. Sotto una soglia regolatoria o probatoria, la governance tradizionale è sufficiente e l'autenticazione aggiunge costo senza un ritorno proporzionato. La disciplina è applicarla dove guadagna il suo posto e non altrove.

Dove va a finire tutto questo

Tre segnali da osservare fra il 2026 e il 2027.

I deployment di agentic AI stanno scalando, e Gartner prevede che il 40% dei progetti di agentic AI sarà cancellato entro la fine del 2027. Il gap di autenticità dei dati diventa esistenziale allo strato agentico, perché un agente autonomo che agisce su input non verificato non può difendere le proprie azioni. L'analisi TrueScreen sull'audit trail nella comunicazione agent-to-agent esamina come la provenance si propaga nei sistemi multi-agente.

I corpus di training pubblici si stanno saturando di contenuti sintetici generati da modelli precedenti. La prossima generazione di training erediterà tutto ciò che era non verificato nella generazione precedente, e il ciclo si stringe. L'autenticazione allo strato di acquisizione umana diventa l'unica uscita architetturale dal compounding sintetico-su-sintetico.

Gli audit dell'articolo 10 dell'EU AI Act partono nel Q3 2026 per i sistemi ad alto rischio. La prima ondata di decisioni pubbliche fisserà lo standard operativo su cosa significhi davvero "provenance documentata" nella pratica. Le organizzazioni pronte prima delle prime decisioni non staranno facendo retrofit; staranno operando.

La domanda sul perché i progetti GenAI falliscono non cambierà nel 2027; cambieranno solo le sue conseguenze. Il 50% che attraverserà il 2026 in piedi condividerà una disciplina sola. Non avrà i dati più puliti. Avrà dati che riescono a provare se stessi, autenticati in acquisizione, tracciabili lungo ogni trasformazione, difendibili davanti a un regolatore. Il contesto più profondo su questo tema si trova nell'articolo companion su data integrity nell'era dell'AI e certificazione alla fonte.