Cose che conosciamo, cose che non conosciamo e perché i principi sono ancora importanti (anche quando si tratta di dati e AI)

Il data engineering sta vivendo un momento di rinnovata centralità.

All’improvviso tutti parlano di pipeline, lineage e “fondamenta dell’AI”. E la cosa sorprende, soprattutto perché per anni sono stati temi considerati poco interessanti. Erano la parte meno affascinante del lavoro sui dati: la “tubatura” nascosta dietro le dashboard.

Ora sono tornati al centro della conversazione. Il cerchio del progresso torna sempre ai fondamentali — ed è un bene, perché nulla nell’AI funziona se non funzionano i dati.

L’AI ha concentrato anni di maturazione tecnologica in pochi mesi. Siamo passati da “interessante” a “implementiamola ovunque” senza fermarci a capire cosa si rompe e perché. Questo è il lavoro che ci aspetta ora. E non riguarda le architetture dei modelli o gli algoritmi di tuning. Sta avvenendo nel data engineering, negli stessi fondamentali di sempre: pipeline pulite, governance rigorosa, lineage tracciabile e sistemi progettati per fallire in modo controllato.

L’AI è solo l’ennesima tecnologia a seguire il ciclo di entusiasmo, esplorazione e disillusione. A garantirne la sostenibilità sono i principi che i data engineer applicano da anni.

Il data engineering è l’infrastruttura del mondo digitale. Non riceve complimenti quando funziona, ma tutto si ferma quando smette di funzionare. Il lavoro non consiste semplicemente nel portare i dati da A a B: significa trasformare informazioni grezze in conoscenza, aggiungendo contesto, definendo la struttura e costruendo il tessuto connettivo che dà senso ai dati. Basta guardare i risultati del recente report Snowflake MIT Tech Review, Redefining Data Engineering in the Age of AI: il 72% dei 400 leader tecnologici intervistati considera i data engineer una funzione essenziale per il successo aziendale. 

Il loro lavoro è spesso invisibile: evitare scorciatoie pericolose, individuare problemi che nessun altro nota e mantenere i sistemi stabili grazie a una disciplina silenziosa. Questo è il mestiere.

Come impariamo ciò che non sappiamo

Ogni tecnologia segue lo stesso percorso: entusiasmo, confusione, fallimento e infine comprensione. L’AI non fa eccezione — si muove soltanto più velocemente.

Stiamo ancora imparando cosa sa fare, dove si inceppa e come renderla affidabile. E non è solo una curva di apprendimento tecnica — è anche culturale. Riguarda il modo in cui le persone condividono ciò che sanno e come le organizzazioni trasformano l’incertezza in progresso.

La parte difficile non è costruire i sistemi. È capire cosa sappiamo davvero, cosa pensiamo di sapere e cosa non abbiamo mai messo in discussione.

Di recente ho riscoperto un framework semplice ma illuminante, utilizzato spesso nell’analisi del rischio: le cose note e le cose che non sappiamo. È perfetta per descrivere la nostra condizione attuale con dati e AI. Ci aiuta a vedere non solo ciò che sappiamo, ma anche ciò che supponiamo, ignoriamo o non pensiamo nemmeno di chiedere. Ci mostra dove si annida il rischio reale.

Il 2x2 della realtà

Il modello delle cose note che sappiamo di sapere (“known knowns”) esiste da decenni. È diventato celebre quando il Segretario alla Difesa Donald Rumsfeld lo citò durante un briefing stampa nel 2002, ma le sue origini risalgono agli anni ’50, con la finestra Johari di Joseph Luft e Harrington Ingham, un metodo per distinguere ciò che è noto a noi, agli altri e ciò che resta nascosto.

Questo schema si applica perfettamente ai dati e all’AI perché mostra come persone e sistemi imparano davvero.

È semplice, ma chiarisce dove le organizzazioni prosperano, dove inciampano e dove talvolta falliscono.

Cose note che conosciamo: le fondamenta sotto assedio

Conosciamo tutti i fondamentali — pipeline, governance, lineage, documentazione — ma tendiamo a dimenticarli appena arriva una nuova moda tecnologica.

L’AI non ne ha ridotto l’importanza: ha reso evidente quando mancano. Pensa a cosa accade quando si tenta di costruire l’AI su basi fragili:

• il modello “allucina” perché i dati di training non sono stati validati.
• La pipeline si interrompe in silenzio, alimentando la produzione con dati obsoleti.
• Un “prototipo veloce” diventa all’improvviso una dipendenza business-critical.
  

Le protezioni silenziose sono ciò che mantiene stabile un sistema: un job di lineage che intercetta dipendenze interrotte, uno schema test che blocca la propagazione di dati errati, un interruttore che ferma l’ingestion quando la qualità scende.

L’AI non ha reso tutto questo opzionale. Lo ha reso imprescindibile. 

Fondamenta solide non evitano solo i disservizi: controllano i costi. Ogni job non testato, ogni lineage rotto, ogni modello obsoleto brucia tempo e risorse. I sistemi migliori non sono i più veloci: sono i più prevedibili. L’efficienza nasce dalla comprensione, e la comprensione nasce dai fondamentali.

Cose sconosciute che conosciamo: le domande si fanno più difficili

Ogni organizzazione ha una lista di cose che non comprende appieno. Nell’AI, questa lista si allunga continuamente:

• come misuriamo l’explainability quando i modelli prendono decisioni non auditabili?

• Come tracciamo il lineage tra dati di training e output quando i modelli si riaddestrano autonomamente?

• Come governiamo i dati sintetici?

• Come gestiamo il drift quando i guasti avvengono in millisecondi?

Queste sono le cose sconosciute di cui siamo a conoscenza. Il vecchio playbook — job batch e workflow prevedibili — non si applica più. Stiamo scrivendo quello nuovo mentre il sistema è in funzione.

Se qualcuno chiede: “Comprendiamo e ci fidiamo dei nostri dati nei sistemi AI di produzione?” e la risposta è esitante — quello è vero data engineering. Riconoscere una cosa sconosciuta che conosciamo è il primo passo per trasformarla in cosa conosciuta che conosciamo. Riduciamo l’incertezza una domanda sincera alla volta.

Cose note che non conosciamo: le risposte nascoste in bella vista

Questo è il quadrante che manda in crisi molti progetti: ciò che non sappiamo, ma qualcun altro sa.

Lo vediamo ovunque:

• il sistema del fornitore “si ottimizza” fino a degradare le prestazioni, e ci ritroviamo a fare debug al buio mentre loro hanno la mappa.

• Il team upstream cambia lo schema senza avvisare nessuno.

• Qualcuno aveva già risolto lo stesso problema un anno prima, ma nessuno lo ha documentato.

• Il modello funziona… finché non smette di funzionare, e nessuno ricorda perché fosse stato progettato così.
  

Le cose note che non conosciamo sono il debito nascosto della complessità. Emergono quando la conoscenza smette di circolare tra persone e team.

La soluzione non è “più automazione”, ma più comunicazione. Fai domande. Ascolta. Coinvolgi le persone fin dall’inizio. A volte il miglior strumento di debug è chiedere: “Qualcuno l’ha già visto?”.

Il lavoro va condiviso tra discipline. Gli ingegneri vedono i rischi tecnici. Il product valuta l’impatto sul cliente. La sicurezza vede le minacce. Il business vede la compliance. Ciò che è imprevedibile per uno può essere ovvio per un altro.

Saresti sorpreso da quanti “problemi di AI” si rivelino essere cose note che non conosciamo: risposte che qualcuno aveva già, ma che non sono mai state condivise.

Cose sconosciute che non conosciamo: ciò che arriva e che ancora non possiamo vedere

Sono le sorprese che non vediamo arrivare — ma che sembrano ovvie solo a posteriori.

Immagina un agente AI che “ottimizza” la pipeline eliminando tabelle che ritiene di basso valore. O sistemi di inferenza real-time che falliscono più velocemente della capacità umana di reagire.

Non è una novità. Ogni ondata tecnologica inizia così. Anche le migrazioni al cloud hanno avuto i loro incidenti imprevisti, come auto-scaling perfetto nei test ma disastroso in produzione. Abbiamo imparato — e costruito guardrail.

L’AI segue lo stesso ciclo, solo più rapidamente. Non puoi prevedere le cose che non sai di non sapere, ma puoi prepararti. Come?

• Progetta per il fallimento: Non chiederti se succederà, ma quando. Progetta con rollback, retry e interruttori di sicurezza.

• Contieni l’impatto: Un singolo modello o agente non deve mai compromettere l’intera piattaforma.

• Dai autonomia a chi è in prima linea: L’ingegnere che nota un’anomalia deve sentirsi libero di intervenire.

• Impara dagli incidenti: Un buon post-mortem permette di capire cosa è successo davvero — e perché.

L’obiettivo non è la perfezione, ma la resilienza. Significa costruire sistemi e culture capaci di assorbire l’imprevisto e adattarsi.

Il lungo gioco

L’AI è nata come un’incognita sconosciuta, astratta e teorica. Ora ci è familiare, ma resta ancora poco compresa. Il nostro compito è portarla tra le cose note che conosciamo — non semplificandola, ma rendendola spiegabile, affidabile e degna di fiducia.

Con l’AI che automatizza sempre più i compiti operativi, il mestiere del data engineering si sta trasformando. La prossima generazione imparerà attraverso contesto e mentorship, trasformando esperienze difficili da acquisire in conoscenza trasmissibile e non solo ereditata.

I principi contano ancora. Trasformano la reazione in resilienza e la resilienza in progresso duraturo.

La tecnologia continuerà a cambiare, ma le fondamenta resteranno le stesse, perché la vera infrastruttura non è la piattaforma. Sono le persone che continuano a costruire, imparare e tramandare il mestiere.

Ogni generazione pensa di costruire per il futuro. In realtà, stiamo costruendo per il team che verrà dopo di noi. La cosa migliore che possiamo lasciare è chiarezza — e i principi per continuare a imparare.

Avvertenza: queste riflessioni sono personali dell’autrice, basate sulla propria esperienza, e non rappresentano la posizione dei suoi attuali o precedenti datori di lavoro.