I vostri dati sono il vantaggio: perché serve un layer digitale proprietario

La maggior parte delle aziende non ha un problema di scarsità di dati. Ha lo stesso dato in cinque posti diversi, e in ognuno significa qualcosa di leggermente differente.

Il cliente è nel CRM, l’ordine nell’ERP, l’offerta in PDF, una nota nell’e-mail e lo stato reale più recente in un file Excel gestito dalla persona che tiene in piedi quel processo da anni. Quando il management chiede quanto ha pagato davvero quel cliente nel corso dell’anno, la risposta richiede tre sistemi e una persona che sappia a quale campo credere.

Non è un problema delle sole piccole imprese. La decima edizione del MuleSoft Connectivity Benchmark, condotta su 1.050 responsabili IT di aziende con almeno 1.000 dipendenti, riporta una media di 897 applicazioni per organizzazione, di cui solo il 29% risulta collegato. Il novanta per cento degli intervistati afferma che i silos di dati creano problemi di business.

Questo testo approfondisce un solo layer. La mappa complessiva dei livelli aziendali l’ho descritta nell’articolo Come costruirei oggi un’azienda che non ha bisogno di un esercito amministrativo. Qui si parla soltanto di dati: chi li possiede e dove sta la verità.

L’AI è affidabile quanto l’infrastruttura sottostante

Un modello riassume, classifica o propone la prossima azione in modo eccellente. Ma se due sistemi contengono un prezzo differente, uno stato ordine diverso o un cliente duplicato, l’AI non è in grado di stabilire quale record sia autorevole. Sceglie quello che riceve, oppure quello che suona più convincente. Nessuno dei due è un criterio decisionale.

Il NIST AI Risk Management Framework 1.0 del gennaio 2023 colloca la caratteristica Valid & Reliable, cioè validità e affidabilità, come base sotto le altre caratteristiche di un’AI degna di fiducia e aggiunge che l’affidabilità complessiva è forte quanto la sua caratteristica più debole. Un modello costruito su dati di cui voi stessi non vi fidate è un generatore di errori più veloci.

L’azienda deve quindi definire la source of truth per le entità chiave: cliente, prodotto, prezzo, ordine, fattura, disponibilità, utente e permessi. È un accordo su quale sistema sia autorevole per un determinato dato e da dove gli altri si limitino a leggerlo. Non è tecnologia, è una decisione.

Che non si tratti di un tema marginale lo mostra la ricerca Salesforce State of Data and Analytics, raccolta nell’estate 2025 e pubblicata nel novembre 2025: l’84% dei responsabili di dati e analytics dichiara che la propria strategia dati necessita di una ricostruzione completa. Stimano inoltre che il 19% dei dati aziendali sia chiuso nei silos o comunque inutilizzabile e che il 26% non sia attendibile.

Come si prende la decisione sulla fonte di verità

Per ogni entità servono quattro risposte. Quale sistema la possiede? Chi può scriverci e attraverso quale interfaccia? Qual è il suo identificatore unico attraverso i sistemi? E come funziona la riconciliazione quando due record divergono?

Sembra banale, ma di solito è l’ora più difficile del progetto. Esempio tipico: il prezzo appartiene a tre persone e ognuna ha ragione nel proprio contesto, il commerciale ha l’eccezione, l’e-commerce ha il listino e la contabilità ha ciò che è uscito in fattura. Se quella conversazione non avviene attorno al tavolo, la risolverà più tardi l’integrazione. In modo casuale e sbagliato.

La regolamentazione spinge nella stessa direzione. L’articolo 10 del regolamento EU AI Act richiede, per i sistemi ad alto rischio, set di dati pertinenti, sufficientemente rappresentativi e, nella massima misura possibile, privi di errori e completi rispetto alla finalità prevista. Senza allarmismi: si applica dal 2 dicembre 2027, rispettivamente dal 2 agosto 2028 a seconda del tipo di sistema, e la maggior parte delle implementazioni aziendali non rientra nell’alto rischio.

Un modello dati condiviso semplifica l’intero ecosistema

Quando il cliente ha un identificatore unico, l’ordine un ciclo di vita chiaro e ogni sistema sa dove leggere prezzo e disponibilità, le integrazioni si semplificano. Un lead che arriva dal sito nasce nel CRM, viene arricchito, assegnato a un commerciale e collegato più tardi a offerta, ordine e fattura, senza che qualcuno reinserisca quattro volte la stessa informazione.

L’economia della cosa è aritmetica banale, non un risultato di ricerca. Se collegate i sistemi ognuno con ognuno, con cinque sistemi sono dieci collegamenti, con dieci sono quarantacinque. Ogni collegamento è codice che qualcuno ha scritto, qualcuno mantiene e che prima o poi si rompe. Con un vocabolario e identificatori condivisi, aggiungere uno strumento significa un solo attacco, non altri nove.

Zhamak Dehghani, nel testo sul data mesh pubblicato nel maggio 2019 su martinfowler.com, ha messo a fuoco i fallimenti delle piattaforme dati centralizzate: la capacità di elaborare e armonizzare tutti i dati in un unico punto cala con la crescita delle sorgenti e dei consumatori, e suddividere la piattaforma per passaggi tecnici invece che per domini di business crea un accoppiamento stretto, in cui una nuova richiesta impone una modifica lungo l’intera catena. Particolarmente utilizzabile è la sua asticella dei «dati come prodotto»: un dataset deve essere individuabile, indirizzabile, affidabile e sicuro.

Il fornitore di solito non dice la parte scomoda: la maggior parte delle aziende di media dimensione non ha bisogno del data mesh, è un concetto per organizzazioni con più team dati. Un’azienda più piccola ottiene gran parte del valore da tre passi economici. Un CRM ben configurato come proprietario del cliente. Un identificatore documentato. Un export che si possa lanciare in qualsiasi momento.

Lo stesso layer può servire clienti, team e AI

Un layer dati e API ben progettato, cioè l’interfaccia attraverso cui i sistemi si passano i dati secondo regole concordate, può servire contemporaneamente portale clienti, dashboard interno, pricing, reporting, personalizzazione del sito e assistente AI. L’azienda non deve costruire ogni volta una nuova isola.

La prova è semplice. Prendete una regola di business, per esempio il calcolo dello sconto per un cliente fedele, e contate in quanti punti è scritta oggi. Se è in cinque, ogni modifica sono cinque modifiche e cinque occasioni perché le versioni divergano. Se è in uno solo, un nuovo canale non è un progetto ma una schermata. Per questo conviene considerare l’azienda come un unico prodotto, non come reparti che si scambiano file.

La sicurezza deve stare nell’architettura

Non ogni utente e non ogni processo AI ha bisogno di accedere a tutto. I dati sensibili vanno separati, gli accessi registrati e i flussi progettati in modo da poter spiegare a posteriori chi ha avuto accesso a cosa e perché.

Non è un’opinione, è uno standard. Il NIST Special Publication 800-207 sull’architettura zero trust, dell’agosto 2020, afferma nel terzo dei sette principi che l’accesso viene concesso su base di singola sessione e con i privilegi minimi necessari a completare il compito. Il settimo principio chiede di raccogliere quante più informazioni possibile sullo stato di dispositivi, rete e comunicazioni e di usarle per migliorare la postura di sicurezza. Il logging quindi non è una seccatura, è un input decisionale.

Con l’AI è inoltre ragionevole minimizzare quali dati il modello riceva. Più contesto non significa automaticamente un sistema migliore. La lista OWASP Top 10 for LLM Applications 2025 mette la fuga di informazioni sensibili subito al secondo posto e raccomanda la sanitizzazione dei dati, controlli di accesso rigorosi secondo il minimo privilegio e, letteralmente, la limitazione dell’accesso del modello alle fonti dati esterne. Nella stessa direzione punta il principio di minimizzazione dei dati dell’articolo 5 del GDPR: i dati devono essere adeguati, pertinenti e limitati a quanto necessario.

Il sesto rischio della stessa lista, l’autonomia eccessiva (Excessive Agency), descrive ciò che nasce dai piloti veloci: l’agente riceve più funzioni, più permessi e più libertà di quanto il compito richieda. Limitate le estensioni e i loro permessi al minimo necessario. Per le azioni ad alto impatto richiedete l’approvazione di una persona. L’autorizzazione va imposta nei sistemi a valle, non nel modello. Il modello non è un confine di sicurezza, il modello è un client.

Lo mostra anche il Cost of a Data Breach Report 2025, realizzato dal Ponemon Institute e sponsorizzato da IBM su un campione di 600 organizzazioni. Il tredici per cento di esse ha segnalato una violazione dei propri modelli o applicazioni AI e, di questo 13%, non del totale delle aziende, ben il 97% ha dichiarato di non avere controlli di accesso all’AI. Una organizzazione su cinque ha segnalato una violazione causata dalla shadow AI e le aziende con un livello elevato di shadow AI hanno registrato costi medi superiori di 670.000 USD rispetto a quelle con livello basso o assente, a fronte di una media globale di 4,44 milioni di USD.

La shadow AI non nasce dalla malizia, ma dal fatto che la strada ufficiale verso i dati è lenta e la persona ne trova una più rapida. Il divieto non funziona, funziona una strada ufficiale migliore.

Quando un layer dati proprietario non conviene

Un layer dati proprietario è un investimento con costi fissi di gestione, e non ogni azienda ne ha bisogno. La mia regola operativa, cioè una stima basata sull’esperienza e non un risultato di ricerca: se la stessa entità viene scritta da un solo sistema e gli altri la leggono da lì, non serve costruire nulla, basta metterlo per iscritto. Se la scrivono due sistemi e la differenza viene sistemata ogni tanto a mano da una persona, basta un’integrazione nativa o un’automazione senza codice. Un layer proprietario ha senso soltanto quando la stessa entità viene scritta da tre o più sistemi e quando l’azienda ha un processo che non si può comprare già pronto, perché è il suo vantaggio competitivo.

Le strade più economiche vanno provate per prime. Eliminare uno degli strumenti duplicati. Attivare l’integrazione nativa che state già pagando nella licenza. Costruire un layer di reporting in sola lettura invece di una sincronizzazione bidirezionale, perché la maggior parte delle domande del management è lettura, non scrittura. Meno parti in movimento è di solito una soluzione migliore di una sincronizzazione più astuta, ed è il tema dell’intero articolo La vostra azienda non ha bisogno di più software. Ha bisogno di meno caos.

I modelli cambieranno. Il layer digitale proprietario resta

Il modello AI migliore oggi potrebbe non esserlo tra due anni. Un fornitore SaaS può cambiare prezzo, API o strategia di prodotto. Un’azienda che controlla il proprio modello dati, la logica di integrazione e le interfacce può sostituire i servizi senza rompere l’intero processo. È l’unica posizione negoziale verso un fornitore che funziona anche senza avvocato.

Qui la regolamentazione ha aiutato. Il Data Act europeo, regolamento (UE) 2023/2854, è entrato in vigore l’11 gennaio 2024 e si applica dal 12 settembre 2025. Secondo la Commissione europea crea un quadro che consente ai clienti di trasferire i dati e di cambiare fornitore cloud, e vieta le clausole contrattuali abusive che ostacolano la condivisione dei dati. Il contratto vi dà il diritto di andarvene. L’architettura decide quanto vi costerà l’uscita.

Il test pratico della proprietà conviene porlo con ogni nuovo strumento, prima della firma. Se domani lo spegnessimo, in quanto tempo avremmo i dati fuori in una struttura utilizzabile? La risposta che si possono esportare in CSV non basta. La domanda è se nell’export restano i collegamenti tra i record, lo storico delle modifiche, gli allegati e gli identificatori. Uno strumento che restituisce dati senza relazioni non vi sta restituendo i dati.

Da qui nasce la linea di demarcazione. Conviene possedere il modello dati, gli identificatori, le regole di business, la logica di integrazione e le interfacce. Conviene affittare quasi tutto il resto: e-mail, contabilità, storage, magazzino, gateway di pagamento e gli stessi modelli. Nessuna persona ragionevole costruisce oggi un CRM da zero né scrive un proprio modello linguistico. L’obiettivo non è possedere il software, ma la verità che quel software elabora.

Il vantaggio nell’AI non lo avrà l’azienda con il maggior numero di abbonamenti, ma l’azienda che sa dove stanno i suoi dati, cosa significano e come scorrono in sicurezza attraverso i suoi processi.

Un layer dati non si ordina come una voce di listino. Si può però diagnosticare: mappare entità, proprietari, flussi e punti in cui la verità diverge. Solo da una mappa così si può dire se l’azienda ha bisogno di un progetto, di una singola integrazione, oppure soltanto di uno strumento eliminato e di un accordo messo per iscritto. L’ordine conta più del budget: prima il processo, poi la rimozione del superfluo e solo alla fine la tecnologia.

Cosa portarsi a casa

• Prima di comprare un altro modello o un altro strumento, scrivete su una sola pagina quale sistema possiede cliente, prodotto, prezzo, ordine e fattura. Se il team non trova un accordo in un’ora, avete appena trovato il vero progetto.
• Con ogni nuovo strumento, prima della firma chiedete come farete uscire i dati insieme a relazioni e storico. Il Data Act vi dà il diritto di andarvene, il costo dell’uscita lo determina la vostra architettura.
• Al processo AI date solo i dati che servono al suo compito e imponete l’autorizzazione nei sistemi di destinazione, non nel modello. Per le azioni ad alto impatto tenete una persona nel loop.
• Se la stessa entità viene scritta da uno o due sistemi, non costruite un layer proprietario. Documentate la proprietà e attivate l’integrazione nativa.
• Non misurate il successo con il numero di integrazioni, ma con il tempo in cui l’azienda sa rispondere in modo attendibile a una domanda importante per il business senza dover chiedere a una persona specifica.