Dai dati al contesto: la nuova frontiera AI del vantaggio competitivo aziendale

I dati come nuovo petrolio. Pochi modi di dire hanno avuto, nella prima fase del digitale, una fortuna paragonabile a questa metafora. Ha aiutato un’intera generazione di manager a capire che i dati non erano un sottoprodotto delle operazioni, ma una risorsa strategica da proteggere e da raffinare. L’ho usata anch’io, per anni, e in quel momento serviva. Applicata all’AI di oggi, però, comincia a confondere più di quanto chiarisca, perché suggerisce un’equivalenza che non regge: il petrolio è prezioso in quanto materia, basta estrarlo per averne valore. I dati, nell’AI applicata, non hanno valore in quanto materia. Hanno valore in quanto contesto, e tra le due cose c’è uno scarto che molte aziende stanno scoprendo a proprie spese.

Una conferma empirica arriva dalla survey AI Readiness 2025 di Apryse, secondo cui il quarantanove per cento delle organizzazioni dichiara che i propri dati non sono abbastanza puliti o strutturati per essere usati efficacemente con l’AI. Quasi una su due. Eppure quasi tutte queste aziende possiedono enormi quantità di dati, archivi documentali da terabyte, knowledge base curate da anni, sistemi gestionali pieni di transazioni storicizzate. Il problema non è la quantità, è la struttura. E la struttura separa un archivio da un contesto.

Qui sta il punto di questa puntata. In un mondo in cui i foundation model sanno quasi tutto del mondo pubblico, e dove il fine-tuning (l’adattamento del modello a un dominio specifico) diventa più accessibile ogni mese, il vantaggio competitivo difensivo non sta nel dato in sé, sta nella qualità del contesto operativo che un’azienda è capace di costruire attorno al dato. È una distinzione sottile ma decisiva, e merita di essere disimballata bene.

Tre cose diverse che chiamiamo dati

Pensate a una biblioteca. Un’azienda che ha un’enorme quantità di documenti senza un sistema di catalogazione coerente possiede un archivio: i libri ci sono, ma trovarli richiede tempo, e usarli per uno scopo specifico richiede ancora più tempo. Un’azienda che ha lo stesso patrimonio organizzato per categorie, con metadati e indici, e con riferimenti incrociati tra le voci, possiede un dataset: i libri sono ricercabili e confrontabili. Un’azienda che oltre a questo sa quali sono i libri canonici per ciascun tema, quali sono superati, quali si applicano a quali contesti d’uso, quali decisioni si prendono in genere consultandoli, possiede un contesto operativo: la biblioteca smette di essere uno spazio fisico e diventa una funzione cognitiva dell’organizzazione.

I tre livelli (archivio, dataset, contesto) sono spesso confusi nelle conversazioni AI. In una board di una multinazionale industriale, qualche tempo fa, il CIO dichiarava di avere dieci anni di dati pronti per l’AI; scendendo nei dettagli, emergeva poi che si trattava di file PDF accumulati su file server senza standardizzazione, senza metadati strutturati, senza distinzione tra versioni canoniche e versioni superate. Era un archivio, non un dataset, e ancora meno un contesto. Da un archivio, anche quando viene messo in un sistema RAG (retrieval-augmented generation, una tecnica che permette al modello di consultare documenti specifici al momento della risposta), si ottengono risposte plausibili ma poco affidabili, perché il sistema non sa quali fonti privilegiare e quali ignorare.

Per arrivare al contesto operativo serve un lavoro che è metà tecnico e metà editoriale. Tecnico perché bisogna costruire infrastruttura: pipeline di ingestione, sistemi di versioning, indici semantici, tassonomie applicate. Editoriale perché bisogno decidere cosa è canonico e cosa non lo è, quali fonti hanno priorità su quali altre, quali documenti vanno archiviati come storici e quali tenuti in memoria attiva, quali eccezioni meritano di diventare regole codificate. Questo secondo lavoro, quello editoriale, è quello che le aziende sottovalutano più frequentemente, perché non si compra, si fa.

Cinque forme di contesto operativo

Quando provo a descrivere a un cliente cosa serve davvero per costruire un contesto utile, mi accorgo che la parola “contesto” è troppo larga. Le cose diverse che ci stanno dentro hanno funzioni diverse, e capire le distinzioni aiuta a impostare il lavoro. Le cinque facce che ricorrono nei progetti sono il contesto dichiarativo, quello procedurale, quello relazionale, quello storico e quello normativo.

Il contesto dichiarativo è il più immediato, ed è ciò che la maggior parte delle aziende intende quando parla di “knowledge base”: documenti e manuali, cataloghi e listini, clausole contrattuali, policy interne. È la materia grezza, e da sola non basta. Il contesto procedurale è la sequenza di passaggi con cui un compito viene svolto, con i suoi ruoli e tempi. Sapere quale documento serve, in quale ordine, a chi va inviato, quando, e cosa accade se manca. Il contesto relazionale mappa chi dipende da chi, quali oggetti sono collegati ad altri, quali documenti si richiamano a vicenda, quali casi appartengono alla stessa famiglia. Il contesto storico raccoglie come sono stati gestiti casi simili in passato, quali decisioni sono state prese, quali errori si ripetono. Il contesto normativo definisce limiti e autorizzazioni, soglie e regole esplicite o implicite entro cui il sistema può operare.

Un sistema AI che usa tutte e cinque le facce coerentemente è molto diverso da uno che ne usa solo una. La maggior parte dei prodotti AI applicati che vedo sul mercato lavora prevalentemente con il contesto dichiarativo, perché è il più facile da estrarre e da fornire al modello. Ma un assistente che conosce solo i manuali, e non conosce la procedura, le relazioni, lo storico e le regole, è destinato a produrre output formalmente corretti ma operativamente fragili, perché manca di tutto ciò che fa la differenza tra una risposta giusta e una risposta utile.

La conoscenza tacita come asset

Tra tutti gli asset di contesto, il più prezioso e il più sottovalutato è la conoscenza tacita. Quella quota di sapere che vive nelle persone, nelle abitudini, nei piccoli aggiustamenti, nelle eccezioni risolte informalmente, nei modi di dire, nelle scorciatoie cognitive dei professionisti esperti. È una conoscenza raramente documentata bene, e tuttavia determina la qualità di molti processi, spesso più di quanto le procedure ufficiali siano in grado di esprimere.

In un progetto di qualche tempo fa, un sistema di supporto per un team di consulenti fiscali, la vera svolta è arrivata dal momento in cui due senior dello studio hanno accettato di verbalizzare le regole non scritte che applicavano da anni nella classificazione delle pratiche. Cose come “se il cliente è una società agricola e il fatturato è sotto una certa soglia, la classificazione cambia anche se formalmente non dovrebbe”. Quella conoscenza, una volta resa accessibile e governata, ha trasformato il sistema da genericamente utile a specificamente indispensabile. Toglierlo avrebbe significato perdere una mappa di competenze che lo studio aveva accumulato in vent’anni di esperienza, e che nessun nuovo assunto avrebbe potuto acquisire in meno di due anni di affiancamento.

Il processo per estrarre questa conoscenza ha richiesto tre mesi di lavoro paziente. Non serviva un modello più potente, serviva che qualcuno si sedesse con i professionisti, facesse emergere le regole implicite, le traducesse in criteri leggibili dal sistema, le validasse su casi reali, le aggiornasse quando si rivelavano incomplete. Alla fine lo studio aveva un prodotto migliore, e una mappa delle proprie competenze che prima non esisteva in nessun documento. Il sistema era diventato il depositario operativo di un sapere che prima viveva solo nelle persone, e questo è probabilmente il vantaggio più difficile da replicare per un competitor che arrivi dopo.

Selezionare, non accumulare

Una tentazione che vedo ricorrere nei progetti AI corporate è pensare che basti riversare grandi quantità di documenti, conversazioni e archivi dentro un sistema perché questo diventi più intelligente. L’effetto è opposto. Troppo rumore produce confusione, allucinazioni pertinenti solo in apparenza, risposte meno affidabili, maggiore opacità sulle ragioni delle risposte.

La differenza è tra infrastruttura tecnica, che rende possibile l’accesso ai dati, e architettura informativa, che determina se l’accesso sia utile. Un’azienda che lavora bene sul contesto non si limita a “mettere dati a disposizione”. Decide quali informazioni sono canoniche, quali obsolete, quali devono avere priorità, quali vanno separate per ruolo, quali devono essere convalidate, quali casi meritano di entrare in memoria lunga e quali possono essere dimenticati senza perdita.

Tornando allo studio fiscale che ho citato prima, la prima versione del sistema era stata alimentata con l’intero archivio documentale degli ultimi sette anni. Il risultato era paradossale: il sistema sapeva troppo e capiva poco. Recuperava pratiche obsolete, confondeva versioni successive dello stesso regolamento, mescolava circolari superate con quelle in vigore. La qualità è migliorata solo quando il team ha selezionato le fonti, assegnato pesi, definito una gerarchia di autorità tra i documenti. Ridurre il volume ha aumentato la precisione, e questo è un risultato che rivela quanto la cura del contesto sia un lavoro editoriale prima ancora che tecnico.

Tre orizzonti di memoria del sistema

Quando si parla di memoria nei sistemi AI è utile distinguere tre livelli che lavorano insieme ma con orizzonti diversi. La memoria breve copre l’interazione in corso, ciò che serve per non perdere il filo durante una conversazione o un task. La memoria lunga ospita le conoscenze che devono persistere nel tempo: documenti e configurazioni, cronologie operative, tassonomie costruite, decisioni ricorrenti che hanno valore oltre il singolo caso. La memoria viva è la più dinamica delle tre, ed è quella che continua ad aggiornarsi attraverso l’uso, raccogliendo i feedback degli utenti e le eccezioni gestite, le correzioni di volta in volta applicate, i casi nuovi e gli schemi emergenti man mano che il sistema incontra il lavoro reale.

La distinzione aiuta a evitare due errori opposti. Il primo è costruire sistemi amnesici, costretti a ripartire sempre da zero, che non sedimentano apprendimento e quindi non costruiscono vantaggio nel tempo. Il secondo è costruire sistemi che ricordano troppo e male, senza gerarchia, senza contesto di validità, senza governance di cosa dimenticare e quando. Una memoria strategica non coincide con la quantità massima di persistenza possibile, coincide con la persistenza giusta, organizzata secondo il valore che produce.

Sistemi falliscono per entrambi i motivi. Sistemi amnesici che ogni mattina facevano ripartire l’utente dal foglio bianco, costringendolo a reintrodurre il contesto del lavoro precedente, e che dopo poche settimane venivano abbandonati. Sistemi iper-memoria che archiviavano tutto e che, dopo qualche mese, soffocavano sotto il peso di vecchi documenti irrilevanti, vecchie correzioni superate, vecchi pattern che non si applicavano più. Il design della memoria è probabilmente il pezzo di architettura più sottovalutato nei progetti AI corporate, ed è anche uno di quelli che separa più nettamente i sistemi che maturano da quelli che si fermano alla fase pilota.

Il vantaggio nasce dalla combinazione

Raramente il vantaggio competitivo nasce da un singolo dataset o da un singolo tipo di contesto. Nasce molto più spesso dalla combinazione di contesti diversi che, messi insieme, diventano difficili da replicare. Manuali più cronologie, ticket più knowledge base, CRM più policy commerciali, documenti più approvazioni, storico casi più tassonomia interna. Ciascun pezzo, preso da solo, è replicabile da un competitor sufficientemente attrezzato. L’intreccio molto meno.

La forza sta nella combinazione orchestrata dentro un workflow specifico. Un competitor può ricostruire una parte del patrimonio informativo, può comprare dataset, può fare scraping di knowledge base pubbliche, può addestrare un modello sui dati di settore disponibili. Ma ricostruire la qualità delle relazioni tra fonti e ruoli, decisioni e criteri, e tra le memorie via via accumulate richiede tempo che il competitor quasi mai ha, perché quel tempo si guadagna stando dentro processi reali, e i processi reali si abitano solo se si hanno clienti che li espongono.

Questa è anche la ragione per cui le startup AI che reggono meglio la pressione competitiva sono spesso quelle che hanno scelto un dominio specifico e ci sono rimaste a lungo, anche quando la tentazione di espandersi orizzontalmente era forte. Non perché l’espansione sia sbagliata, ma perché l’espansione fatta troppo presto disperde la qualità del contesto che si è costruita nel primo dominio, e il vantaggio si dissolve invece di consolidarsi.

Una nuova forma di debito tecnico

Così come esiste il debito tecnico, esiste un debito di contesto. Si forma quando un’organizzazione lancia iniziative AI senza investire nella pulizia delle fonti, nella formalizzazione delle eccezioni, nella definizione dei criteri, nella qualità delle etichette, nella governance della memoria. All’inizio il sistema può sembrare funzionare, perché i casi semplici sono sempre quelli più frequenti, e sui casi semplici anche un contesto povero produce risultati accettabili. Col tempo, però, la mancanza di contesto strutturato produce attrito ed errori che generano sfiducia, costi di manutenzione più alti, e rallenta tutto ciò che dovrebbe essere il prossimo passo del prodotto.

Il debito di contesto è più pericoloso del debito tecnico per una ragione semplice: non appare subito. Si manifesta nei casi difficili, nelle integrazioni successive, nei momenti in cui il prodotto dovrebbe espandersi e invece fatica. E quando si manifesta, ripagarlo richiede mesi di lavoro paziente che spesso non si vedono nelle metriche di prodotto, e che quindi rischiano di non essere prioritizzati nella roadmap.

Ridurre il debito di contesto è uno dei modi più realistici per costruire una base forte, anche se è un lavoro poco visibile e raramente celebrato. In un’azienda con cui ho lavorato, il team ha dedicato sei settimane a pulire e strutturare la knowledge base prima di rilanciare il sistema dopo un primo tentativo fallito. Il modello sottostante era lo stesso, l’interfaccia era la stessa, era cambiata solo la qualità del contesto disponibile. Il tasso di risposte accettate al primo passaggio è passato dal quaranta al settantadue per cento. Sei settimane di lavoro invisibile che hanno fatto più differenza di qualsiasi aggiornamento del modello.

Una figura organizzativa che emerge

Una conseguenza pratica di tutto questo è che nelle aziende emerge una figura nuova, ancora poco codificata ma sempre più necessaria. Il custode del contesto operativo. È una figura che decide quali fonti sono autorevoli, quali vanno aggiornate, quali eccezioni meritano di diventare regola, quali feedback sono davvero utili, quali memorie vanno rimosse. Non è un product owner classico, perché si occupa di un asset che è insieme tecnico, editoriale e organizzativo. Non è un data steward classico, perché va oltre la qualità del dato e arriva alla qualità della rappresentazione del lavoro.

Le aziende che riescono meglio a far sedimentare valore dall’AI hanno quasi sempre identificato questa figura, anche quando non le hanno dato un titolo formale. Spesso è qualcuno che proviene dal dominio (un consulente senior, un capo operations esperto, un responsabile compliance con anni di esperienza), e che ha imparato a parlare la lingua dei dati e dei sistemi senza diventare un ingegnere. È una figura ibrida, e nei prossimi anni mi aspetto che diventi una posizione esplicita nelle organizzazioni che prendono sul serio l’AI applicata.

Per chi costruisce prodotti AI, una conseguenza pratica è che vendere a un’azienda che ha già identificato questa figura è completamente diverso da vendere a un’azienda che non l’ha ancora identificata. Nel primo caso il dialogo è strategico, si discute di come integrare il sistema con il contesto esistente. Nel secondo caso il dialogo è preliminare, si discute prima di tutto di chi sarà responsabile del contesto, e finché questa risposta non arriva il prodotto difficilmente entra in produzione seria. Saper riconoscere in quale dei due scenari ci si trova fa parte della maturità commerciale di una startup AI.

Il segreto, riformulato per l’era AI

Se nel libro Zero to One Peter Thiel parlava del “segreto” come di una verità rilevante condivisa con poche persone, oggi quel segreto sta cambiando forma. Non coincide più con un’ipotesi tecnica sottovalutata o con una previsione controcorrente sul futuro. Coincide sempre più spesso con la rappresentazione operativa di un dominio specifico, fatta di contesto raffinato, eccezioni codificate, memoria curata, tassonomia chiara, regole esplicite e tacite messe in dialogo tra loro. Un’azienda che possiede questa rappresentazione possiede un asset che il modello generalista, per quanto potente, non ha. E proprio per questo, nei prossimi anni, sarà uno degli asset meno visibili ma più resistenti.

In una conversazione recente con il direttore IT di un’azienda industriale del nord Italia, è emersa una domanda che riassume bene il punto. Stavano per firmare un contratto da un milione di euro con un fornitore AI per assistere la gestione dei processi di qualità. Il direttore mi ha chiesto cosa cercare nel contratto. La mia risposta è stata una sola domanda da rivolgere internamente: chi nella nostra organizzazione possiede e cura il contesto operativo che alimenterà questo sistema? Se la risposta è “nessuno per ora”, il progetto va rallentato e va costruita prima la struttura. Se la risposta è “lo costruiremo strada facendo”, il rischio è che si finisca a costruirlo affannosamente e in maniera parziale, perdendo i vantaggi della prima fase. Se la risposta è precisa, la persona è identificata, le fonti canoniche sono già selezionate, le tassonomie sono definite, allora il sistema ha tutte le condizioni per produrre valore reale. Quel direttore ha rinviato la firma di tre mesi, e ha usato il tempo per identificare il proprio custode del contesto. Quando ha firmato, lo ha fatto con un perimetro più stretto e un margine di successo molto più alto.

La prossima puntata applica questo ragionamento a una delle scelte più decisive che un founder AI fa nei primi diciotto mesi della startup, ed è la scelta del wedge. Wedge, contesto e workflow sono i tre pezzi che, messi insieme, decidono se la posizione si forma o si dissolve. La trattazione completa del framework, con i sette loop e gli strumenti operativi, è nel libro Da Zero a Loop.