Di Andrew Tan
Perché l'85% delle imprese non è pronto per l'AI
Il benchmark del 2026 di Fivetran ha rilevato che l'85% delle imprese utilizza AI agentica su infrastrutture che non sono pronte. Il problema non è il modello. Sono i data pipeline che lo alimentano.
Ecco un modello che si sta manifestando in un numero crescente di luoghi:
Un'azienda trascorre sei mesi a valutare LLM: eseguono benchmark, negoziano contratti, costruiscono una prova di concetto. Il modello sembra ottimo. Poi lo implementano in produzione e gli agenti iniziano a fare allucinazioni in modi che non hanno nulla a che fare con il modello stesso.
L'AI è a posto, ma i dati che lo alimentano no.
Questo è ciò che il Fivetran's Enterprise Data Infrastructure Benchmark Report 2026 sta effettivamente misurando quando afferma che l'85% delle imprese non è pronto per l'AI agentica. Non che i loro modelli siano sbagliati, ma che i loro pipeline siano sbagliati.
Cosa significa effettivamente "non pronto"
La frase "infrastruttura pronta per l'AI" viene usata per vendere molte cose. Di solito significa qualcosa di vago sulla scalabilità del Cloud. Non è ciò che il report di Fivetran sta misurando.
I tre problemi concreti che hanno identificato:
Dati obsoleti. L'agente sta ragionando sullo stato di ieri. Per un agente del servizio clienti, ciò significa che non sa che un rimborso è già stato emesso. Per un agente di rilevamento delle frodi, sta lavorando su modelli che hanno 18 ore. I pipeline batch che funzionano ogni ora o notte non possono supportare agenti che devono agire su ciò che sta accadendo ora.
Nessuna applicazione dello schema. I sistemi sorgente cambiano costantemente. Le colonne vengono rinominate, i tipi vengono ampliati, compaiono nuovi campi. Se il tuo pipeline non applica contratti di schema a valle, un agente può ricevere dati malformati che sembrano validi — e agire con sicurezza su di essi.
Nessuna osservabilità. La maggior parte del monitoraggio dei pipeline ti dice se un lavoro è stato eseguito. Non ti dice se i dati sono corretti. Un agente può consumare dati da un pipeline che tecnicamente funziona ma che silenziosamente scarta il 20% degli eventi. Non lo saprai finché qualcuno non si accorge che l'agente si comporta in modo strano, e a quel punto il danno è fatto.
Questi non sono problemi nuovi. Sono gli stessi problemi di qualità dei dati che hanno afflitto i team di analisi per anni. Ciò che è cambiato è il raggio d'azione. Un problema di qualità dei dati in una dashboard BI è un grafico sbagliato. Un problema di qualità dei dati in un sistema agentico è una decisione autonoma presa su informazioni errate.
La dissonanza dello stack
Il problema dello stack dati pronto per l'AI è una profonda dissonanza nelle assunzioni architetturali.
La maggior parte degli stack dati aziendali è stata costruita attorno all'elaborazione batch. Lavori ETL notturni. Aggiornamenti giornalieri del magazzino dati. Dashboard che si aggiornano ogni mattina. L'intero sistema è stato ottimizzato per il throughput rispetto alla freschezza.
Gli agenti AI hanno requisiti diversi. Hanno bisogno di dati aggiornati, non solo accurati. Devono agire su ciò che sta accadendo negli ultimi secondi o minuti, non nelle ultime dodici ore. E quando sbagliano, il sistema deve rilevarlo — non solo registrarlo e andare avanti.
Le aziende che sono pronte — il 15% — non hanno necessariamente sostituito l'intero stack. La maggior parte di loro è passata al real-time dove è importante e ha mantenuto il batch dove ha senso. Il flusso degli ordini dei clienti funziona in tempo reale. Il conteggio dei costi trimestrali funziona ancora di notte. La differenza è l'intenzionalità: hanno preso decisioni esplicite su quali dati necessitano di freschezza e hanno costruito pipeline di conseguenza.
Le tre proprietà che contano davvero
C'è molto rumore su ciò che richiede un'infrastruttura "pronta per l'AI". Di solito è una checklist di un fornitore che si adatta convenientemente al loro prodotto. Quindi ecco la versione che si adatta ai veri modelli di fallimento:
Freschezza. Non solo "real-time per tutto" — è costoso e spesso non necessario. Ma per i dati su cui i tuoi agenti agiscono effettivamente, devi conoscere il ritardo e avere garanzie su di esso. Se i tuoi dati sui clienti sono vecchi di 4 minuti, va bene — purché il tuo agente lo sappia e agisca di conseguenza. Ciò che rompe gli agenti è quando assumono che i dati siano attuali e non lo sono.
Consistenza. Gli agenti spesso combinano dati da più fonti per prendere una decisione. Se quelle fonti funzionano su orari diversi o a livelli di freschezza diversi, ottieni sottili incoerenze difficili da debugare. Una ricerca cliente dice che l'account è attivo; il flusso di transazioni non ha ancora raggiunto e lo mostra come in chiusura pendente. L'agente prende una decisione che è corretta per ciascuna fonte individualmente ma sbagliata per lo stato combinato.
Osservabilità a livello di evento. Il monitoraggio dei pipeline ti dice sui lavori. L'affidabilità degli agenti richiede il monitoraggio degli eventi individuali. Gli eventi vengono elaborati o scartati? Lo schema corrisponde a ciò che l'agente si aspetta? Ci sono picchi che sovraccaricano i consumatori a valle? Questo è un diverso tipo di monitoraggio rispetto a quello che la maggior parte dei team ha costruito.
Cosa significa per la decisione di costruire o acquistare
L'ondata di AI sta facendo emergere un conto che si è accumulato in molte organizzazioni di ingegneria: il costo di trattare l'infrastruttura dati come un problema risolto.
I team che hanno costruito pipeline batch personalizzate due anni fa e l'hanno considerato fatto ora affrontano una scelta difficile: adattare il real-time a un sistema che non è stato progettato per esso, o ricostruire. Nessuna delle due opzioni è economica. L'adattamento tende a produrre il problema dei due pipeline — un sistema batch per la storia, un sistema streaming per il real-time, due codebase che fanno approssimativamente la stessa cosa con logiche leggermente diverse e risultati che divergono perpetuamente.
I team che gestiscono bene questo problema sono quelli che non devono fare quella scelta. Quando batch e streaming funzionano come gli stessi pipeline con gli stessi strumenti, passare un Workflow da orario a real-time è un cambiamento di configurazione, non una riscrittura. L'osservabilità, l'applicazione dello schema, la gestione degli errori — viene con la piattaforma, non come una costruzione personalizzata sopra.
Questo è ciò su cui è costruito layline.io. Non solo real-time per il suo scopo, ma la capacità di prendere decisioni esplicite e intenzionali sulla freschezza dei dati in tutto lo stack — senza mantenere due sistemi separati per arrivarci.
La domanda da considerare
Il numero dell'85% è sorprendente. Ma la domanda più interessante è: quante di quelle imprese sanno di essere in quell'85%?
I team che sono nei guai di solito non sono quelli con pipeline ovviamente rotte. Sono quelli con pipeline che sembrano funzionare — lavori in esecuzione, dashboard che si caricano, nessun incidente attivo — ma con problemi di affidabilità silenziosi che si manifestano solo quando un agente AI inizia a prendere decisioni importanti sui dati.
Se i tuoi agenti si comportano in modo strano e hai già escluso il modello, guarda i dati.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro sia batch che real-time su larga scala.
