In breve: l'IA non sostituirà completamente gli ingegneri dei dati; automatizzerà il lavoro ripetitivo come la stesura di query SQL, la creazione di pipeline, i test e la documentazione. Se il tuo ruolo è prevalentemente di basso livello e basato su ticket, sarai più esposto; se invece ti occupi di affidabilità, definizioni, governance e gestione degli incidenti, l'IA ti renderà principalmente più veloce.
Punti chiave:
Proprietà: dare priorità alla responsabilità dei risultati, non solo alla produzione rapida del codice.
Qualità: creare test, osservabilità e contratti in modo che le pipeline rimangano affidabili.
Governance: mantenere la privacy, il controllo degli accessi, la conservazione e i percorsi di controllo di proprietà umana.
Resistenza all'uso improprio: trattare gli output dell'IA come bozze; rivederli per evitare errori certi.
Cambio di ruolo: dedica meno tempo alla digitazione di testo standard e più tempo alla progettazione di sistemi durevoli.
Se avete trascorso più di cinque minuti in compagnia di team di dati, avrete sicuramente sentito ripetere questo ritornello – a volte sussurrato, a volte lanciato durante una riunione come un colpo di scena – l'intelligenza artificiale sostituirà gli ingegneri dei dati?
E... ho capito. L'IA può generare SQL, costruire pipeline, spiegare stack trace, creare modelli dbt e persino suggerire schemi di data warehouse con una sicurezza inquietante. GitHub Copilot per SQL Informazioni sui modelli dbt GitHub Copilot
È come guardare un carrello elevatore che impara a fare il giocoliere. Impressionante, leggermente allarmante, e non sei del tutto sicuro di cosa significhi per il tuo lavoro 😅
Ma la verità è meno chiara del titolo. L'intelligenza artificiale sta cambiando radicalmente l'ingegneria dei dati. Sta automatizzando le parti noiose e ripetibili. Sta accelerando i momenti in cui "so cosa voglio ma non ricordo la sintassi". Sta anche generando nuovi tipi di caos.
Quindi, cerchiamo di esporre le cose in modo chiaro, senza ottimismi superficiali o panico catastrofico.
Articoli che potrebbero interessarti dopo questo:
🔗 L'intelligenza artificiale sostituirà i radiologi?
Come l'intelligenza artificiale nell'imaging cambia il flusso di lavoro, la precisione e i ruoli futuri.
🔗 L'intelligenza artificiale sostituirà i contabili?
Scopri quali attività contabili vengono automatizzate dall'intelligenza artificiale e quali rimangono di competenza umana.
🔗 L'intelligenza artificiale sostituirà i banchieri d'investimento?
Comprendere l'impatto dell'intelligenza artificiale su accordi, ricerche e relazioni con i clienti.
🔗 L'intelligenza artificiale sostituirà gli agenti assicurativi?
Scopri come l'intelligenza artificiale trasforma la sottoscrizione, le vendite e l'assistenza clienti.
Perché la domanda "L'intelligenza artificiale sostituisce gli ingegneri dei dati" continua a riaffiorare 😬
La paura nasce da un fattore ben preciso: l'ingegneria dei dati comporta molto lavoro ripetibile.
-
Scrittura e refactoring di SQL
-
Creazione di script di ingestione
-
Mappatura dei campi da uno schema all'altro
-
Creazione di test e documentazione di base
-
Debug dei guasti della pipeline che sono... in un certo senso prevedibili
L'intelligenza artificiale è insolitamente abile nel creare pattern ripetibili. E gran parte dell'ingegneria dei dati è proprio questo: pattern sovrapposti a pattern. Suggerimenti di codice per GitHub Copilot
Inoltre, l'ecosistema degli strumenti sta già "nascondendo" la complessità:
-
Documentazione Fivetran sui connettori ELT gestiti
-
Elaborazione senza server AWS Lambda (elaborazione senza server)
-
Approvvigionamento del magazzino con un clic
-
Documentazione di Apache Airflow sull'orchestrazione automatica
-
Framework di trasformazione dichiarativa Che cos'è dbt?
Quindi, quando l'intelligenza artificiale si presenta, può sembrare l'ultimo tassello. Se lo stack è già astratto e l'intelligenza artificiale può scrivere il codice di collegamento... cosa rimane? 🤷
Ma ecco il punto che molti trascurano: l'ingegneria dei dati non consiste principalmente nel digitare. Digitare è la parte facile. La parte difficile è far sì che una realtà aziendale oscura, politica e in continua evoluzione si comporti come un sistema affidabile.
E l'intelligenza artificiale si scontra ancora con questa oscurità. Anche le persone hanno difficoltà, solo che improvvisano meglio.
Cosa fanno realmente gli ingegneri dei dati tutto il giorno (la verità poco affascinante) 🧱
Siamo sinceri: la qualifica di "Ingegnere dei dati" fa pensare che si stia costruendo motori a razzo usando solo la matematica. In pratica, si tratta di costruire fiducia.
Una giornata tipo è meno “inventare nuovi algoritmi” e più:
-
Negoziare con i team upstream sulle definizioni dei dati (doloroso ma necessario)
-
Indagare sul perché una metrica è cambiata (e se è reale)
-
Gestione della deriva dello schema e delle sorprese del tipo "qualcuno ha aggiunto una colonna a mezzanotte"
-
Garantire che le pipeline siano idempotenti, recuperabili e osservabili
-
Creare delle barriere di sicurezza affinché gli analisti a valle non creino accidentalmente dashboard senza senso
-
Gestire i costi per evitare che il tuo magazzino si trasformi in un falò di soldi 🔥
-
Protezione degli accessi, audit, conformità, politiche di conservazione dei dati Principi GDPR (Commissione europea) Limitazione della conservazione dei dati (ICO)
-
Creare prodotti di dati che le persone possano effettivamente utilizzare senza inviarti messaggi diretti: 20 domande
Gran parte del lavoro è di natura sociale e operativa:
-
"Chi è il proprietario di questo tavolo?"
-
“Questa definizione è ancora valida?”
-
"Perché il CRM esporta duplicati?"
-
"Possiamo inviare questa metrica ai dirigenti senza imbarazzo?" 😭
L'intelligenza artificiale può certamente dare una mano in alcuni aspetti. Ma sostituirla completamente è... un'esagerazione.
Cosa rende un ruolo di data engineering una versione efficace? ✅
Questa sezione è importante perché il discorso sulla sostituzione di solito dà per scontato che gli ingegneri dei dati siano principalmente "costruttori di pipeline". È come dare per scontato che gli chef si occupino principalmente di "tagliare le verdure". Fa parte del lavoro, ma non è il lavoro.
Un ingegnere dei dati esperto solitamente è in grado di svolgere la maggior parte delle seguenti attività:
-
Progettare per il cambiamento
. I dati cambiano. I team cambiano. Gli strumenti cambiano. Un bravo ingegnere costruisce sistemi che non crollano ogni volta che la realtà starnutisce 🤧 -
Definire contratti e aspettative
Cosa significa "cliente"? Cosa significa "attivo"? Cosa succede quando una riga arriva in ritardo? I contratti prevengono il caos più di quanto non faccia un codice sofisticato. Open Data Contract Standard (ODCS) ODCS (GitHub) -
Integrare l'osservabilità in ogni cosa.
Non solo "è stato eseguito?", ma "è stato eseguito correttamente?". Aggiornamento, anomalie di volume, esplosioni di valori nulli, variazioni di distribuzione. Osservabilità dei dati (Dynatrace) Cos'è l'osservabilità dei dati? -
Fai compromessi come un adulto:
velocità contro correttezza, costo contro latenza, flessibilità contro semplicità. Non esiste una pipeline perfetta, solo pipeline con cui puoi convivere. -
Tradurre le esigenze aziendali in sistemi duraturi.
Le persone chiedono metriche, ma ciò di cui hanno bisogno è un prodotto basato sui dati. L'IA può scrivere il codice, ma non può magicamente conoscere le insidie del business. -
Mantieni i dati riservati.
Il complimento più grande per una piattaforma dati è che nessuno ne parli. I dati senza problemi sono dati di qualità. Come un impianto idraulico: te ne accorgi solo quando si rompe 🚽
Se ti occupi di queste cose, la domanda "L'IA sostituirà gli ingegneri dei dati?" inizia a sembrare... un po' fuori luogo. L'IA può sostituire le attività, non la responsabilità.
Dove l'intelligenza artificiale sta già aiutando gli ingegneri dei dati (ed è davvero fantastico) 🤖✨
L'intelligenza artificiale non è solo marketing. Se usata bene, è un legittimo moltiplicatore di forza.
1) SQL più veloce e lavoro di trasformazione
-
Disegno di giunzioni complesse
-
Scrivere funzioni di finestra a cui preferiresti non pensare
-
Trasformare la logica in linguaggio semplice in scheletri di query
-
Rifattorizzazione di query brutte in CTE leggibili GitHub Copilot per SQL
Questo è fondamentale perché riduce l'effetto "pagina bianca". È comunque necessario convalidare, ma si parte dal 70% anziché dallo 0%.
2) Debug e breadcrumb delle cause principali
L'intelligenza artificiale è discreta in:
-
Spiegazione dei messaggi di errore
-
Suggerire dove cercare
-
Consigliare passaggi del tipo "verifica mancata corrispondenza dello schema" GitHub Copilot
È come avere un ingegnere junior instancabile che non dorme mai e a volte mente con sicurezza 😅
3) Arricchimento della documentazione e del catalogo dati
Generato automaticamente:
-
Descrizioni delle colonne
-
Riepiloghi dei modelli
-
Spiegazioni sulla discendenza
-
"A cosa serve questa tabella?" bozze di documentazione dbt
Non è perfetto, ma spezza la maledizione delle pipeline non documentate.
4) Prova ponteggi e controlli
L'intelligenza artificiale può proporre:
-
Test nulli di base
-
Controlli di unicità
-
Idee di integrità referenziale
-
“Questa metrica non dovrebbe mai diminuire” asserzioni di stile test dei dati dbt Grandi aspettative: aspettative
Di nuovo, sei ancora tu a decidere cosa è importante, ma questo velocizza le parti di routine.
5) Codice “collante” della pipeline
Modelli di configurazione, scaffold YAML, bozze di DAG di orchestrazione. Questa roba è ripetitiva e l'IA si nutre di ripetitività a colazione 🥣 DAG di Apache Airflow
Dove l'intelligenza artificiale è ancora in difficoltà (e questo è il nocciolo della questione) 🧠🧩
Questa è la parte più importante, perché risponde alla domanda sulla sostituzione con una consistenza reale.
1) Ambiguità e definizioni mutevoli
La logica aziendale raramente è chiara. Le persone cambiano idea a metà frase. "Utente attivo" diventa "utente pagante attivo" diventa "utente pagante attivo esclusi i rimborsi tranne qualche volta"... sapete com'è.
L'intelligenza artificiale non può accettare questa ambiguità. Può solo fare supposizioni.
2) Responsabilità e rischio
Quando una pipeline si interrompe e la dashboard esecutiva mostra informazioni non pertinenti, qualcuno deve:
-
triage
-
comunicare l'impatto
-
aggiustarlo
-
prevenire la recidiva
-
scrivere l'autopsia
-
decidere se l'azienda può ancora fidarsi dei numeri della scorsa settimana
L'intelligenza artificiale può essere d'aiuto, ma non può essere ritenuta responsabile in modo significativo. Le organizzazioni non si basano sulle vibrazioni, ma sulla responsabilità.
3) Pensiero sistemico
Le piattaforme dati sono ecosistemi: acquisizione, archiviazione, trasformazioni, orchestrazione, governance, controllo dei costi, SLA. Un cambiamento in un singolo livello ha ripercussioni. Concetti di Apache Airflow
L'intelligenza artificiale può proporre ottimizzazioni locali che creano problemi globali. È come riparare una porta che cigola rimuovendola 😬
4) Sicurezza, privacy, conformità
È qui che le fantasie sostitutive vanno a morire.
-
Controlli di accesso
-
Sicurezza a livello di riga Criteri di accesso alle righe di Snowflake Sicurezza a livello di riga di BigQuery
-
Gestione delle informazioni personali identificabili (PII) NIST Privacy Framework
-
Regole di conservazione Limiti di conservazione (ICO) Linee guida UE sulla conservazione
-
Tracce di audit NIST SP 800-92 (gestione dei log) Controllo CIS 8 (Gestione dei log di audit)
-
Vincoli di residenza dei dati
L'intelligenza artificiale può elaborare politiche, ma la loro attuazione in sicurezza è vera ingegneria.
5) Gli “incogniti sconosciuti”
Gli incidenti sui dati sono spesso imprevedibili:
-
Un'API del fornitore modifica silenziosamente la semantica
-
Un presupposto sul fuso orario si ribalta
-
Un riempimento duplica una partizione
-
Un meccanismo di ripetizione causa doppie scritture
-
Una nuova funzionalità del prodotto introduce nuovi modelli di eventi
L'intelligenza artificiale è più debole quando la situazione non segue uno schema noto.
Tabella comparativa: cosa riduce cosa, in pratica 🧾🤔
Di seguito una visione pratica. Non "strumenti che sostituiscono le persone", ma strumenti e approcci che riducono il carico di lavoro di determinati compiti.
| Strumento/approccio | Pubblico | Vibrazione del prezzo | Perché funziona |
|---|---|---|---|
| Copiloti del codice AI (helper SQL + Python) GitHub Copilot | Ingegneri che scrivono molto codice | Da gratuito a a pagamento | Ottimo per l'impalcatura, i refactoring, la sintassi... a volte presuntuoso in un modo molto specifico |
| Connettori ELT gestiti Fivetran | I team sono stanchi di dover gestire l'ingestione | Abbonamento-y | Elimina il fastidio dell'ingestione personalizzata, ma introduce nuovi modi divertenti |
| Piattaforme di osservabilità dei dati Osservabilità dei dati (Dynatrace) | Chiunque possieda SLA | Da medie a grandi imprese | Rileva le anomalie in anticipo, come gli allarmi antincendio per le condutture 🔔 |
| Framework di trasformazione (modellazione dichiarativa) dbt | Ibridi di analisi + DE | Di solito strumento + calcolo | Rende la logica modulare e testabile, meno spaghetti |
| Cataloghi dati + livelli semantici dbt Semantic Layer | Organizzazioni con confusione metrica | Dipende, in pratica | Definisce la “verità” una volta sola, riducendo gli infiniti dibattiti metrici |
| Orchestrazione con modelli Apache Airflow | Team orientati alla piattaforma | Costo di apertura e chiusura | Standardizza i flussi di lavoro; meno DAG a fiocco di neve |
| Generazione di documenti dbt assistita dall'intelligenza artificiale | Team che odiano scrivere documenti | Da economico a moderato | Crea documenti "abbastanza buoni" in modo che la conoscenza non svanisca |
| Politiche di governance automatizzate NIST Privacy Framework | Ambienti regolamentati | Impresa-y | Aiuta a far rispettare le regole, ma ha comunque bisogno che siano gli esseri umani a progettarle |
Nota cosa manca: una riga che dice "premi il pulsante per rimuovere gli ingegneri dei dati". Sì... quella riga non esiste 🙃
Quindi... l'intelligenza artificiale sostituirà gli ingegneri dei dati o cambierà solo il ruolo? 🛠️
Ecco la risposta senza sensazionalismi: l'intelligenza artificiale sostituirà alcune fasi del flusso di lavoro, non la professione stessa.
Ma questo ridefinirà il ruolo. E se lo ignori, ne pagherai le conseguenze.
Cosa cambia:
-
Meno tempo per scrivere testo standard
-
Meno tempo nella ricerca dei documenti
-
Più tempo per rivedere, convalidare, progettare
-
Più tempo per definire i contratti e le aspettative di qualità Open Data Contract Standard (ODCS)
-
Più tempo dedicato alla collaborazione con prodotti, sicurezza e finanza
Questo è il sottile cambiamento: l'ingegneria dei dati diventa meno una questione di "costruzione di pipeline" e più una questione di "costruzione di un sistema di prodotti dati affidabile"
E, per una svolta silenziosa, questo è più prezioso, non meno.
Inoltre - e lo dirò anche se può sembrare esagerato - l'IA aumenta il numero di persone in grado di produrre artefatti di dati, il che aumenta la necessità di qualcuno che mantenga l'ordine nel sistema. Più output significa più potenziale confusione. GitHub Copilot
È come dare a tutti un trapano elettrico. Fantastico! Ora qualcuno deve far rispettare la regola "per favore, non forare le tubature dell'acqua" 🪠
Il nuovo stack di competenze che rimane prezioso (anche con l'IA ovunque) 🧠⚙️
Se vuoi una checklist pratica e "a prova di futuro", ecco come appare:
Mentalità di progettazione del sistema
-
Modellazione dei dati che sopravvive al cambiamento
-
Compromessi tra batch e streaming
-
Pensiero su latenza, costo e affidabilità
Ingegneria della qualità dei dati
-
Contratti, convalide, rilevamento delle anomalie Standard di contratto Open Data (ODCS) Osservabilità dei dati (Dynatrace)
-
SLA, SLO, abitudini di risposta agli incidenti
-
Analisi della causa principale con disciplina (non vibrazioni)
Architettura di governance e fiducia
-
Modelli di accesso
-
Auditabilità NIST SP 800-92 (gestione dei log)
-
Privacy by design NIST Privacy Framework
-
Gestione del ciclo di vita dei dati: linee guida dell'UE sulla conservazione
Pensiero di piattaforma
-
Modelli riutilizzabili, percorsi d'oro
-
Modelli standardizzati per l'ingestione, la trasformazione e il test Fivetran dbt
-
Utensili self-service che non si fondono
Comunicazione (sì, davvero)
-
Scrivere documenti chiari
-
Allineamento delle definizioni
-
Dire "no" educatamente ma con fermezza
-
Spiegare i compromessi senza sembrare un robot 🤖
Se riuscite a fare tutto questo, la domanda "L'intelligenza artificiale sostituirà gli ingegneri dei dati?" diventa meno minacciosa. L'intelligenza artificiale diventa il vostro esoscheletro, non il vostro sostituto.
Scenari realistici in cui alcuni ruoli di data engineering si riducono 📉
Ok, un rapido controllo della realtà, perché non è tutto rose e fiori e coriandoli emoji 🎉
Alcuni ruoli sono più esposti:
-
Ruoli di sola ingestione pura in cui tutto è connettori standard Connettori Fivetran
-
Team che eseguono principalmente pipeline di reporting ripetitive con sfumature di dominio minime
-
Organizzazioni in cui l’ingegneria dei dati è trattata come “scimmie SQL” (duro, ma vero)
-
Ruoli a bassa proprietà in cui il lavoro consiste solo in biglietti e copia-incolla
L'intelligenza artificiale, unitamente agli strumenti gestiti, può ridurre tali esigenze.
Ma anche in questo caso la sostituzione solitamente si presenta così:
-
Meno persone svolgono lo stesso lavoro ripetitivo
-
Maggiore enfasi sulla proprietà e l'affidabilità della piattaforma
-
Un passaggio verso “una persona può supportare più oleodotti”
Quindi sì, i modelli di organico possono cambiare. I ruoli si evolvono. I titoli cambiano. Questa parte è reale.
Tuttavia, la versione del ruolo basata su un elevato grado di proprietà e di fiducia persiste.
Riepilogo finale 🧾✅
L'intelligenza artificiale sostituirà gli ingegneri dei dati? Non nel modo pulito e totale che la gente immagina.
L'intelligenza artificiale:
-
automatizzare le attività ripetitive
-
Accelerare la codifica, il debug e la documentazione con GitHub Copilot per la documentazione di SQL dbt.
-
ridurre i costi di produzione delle condotte
Ma l'ingegneria dei dati riguarda fondamentalmente:
-
responsabilità
-
progettazione del sistema
-
fiducia, qualità e governance Standard per i contratti sui dati aperti (ODCS) Quadro di riferimento sulla privacy del NIST
-
tradurre la realtà aziendale poco chiara in prodotti di dati affidabili
L'intelligenza artificiale può aiutare in questo... ma non ne è "padrona".
Se sei un ingegnere dei dati, la scelta è semplice (non facile, ma semplice):
concentrati sulla responsabilità, sulla qualità, sulla mentalità orientata alle piattaforme e sulla comunicazione. Lascia che l'IA si occupi delle attività ripetitive mentre tu ti dedichi agli aspetti che contano davvero.
E sì, a volte questo significa essere l'adulto nella stanza. Non glamour. Ma silenziosamente potente 😄
L'intelligenza artificiale sostituirà gli ingegneri dei dati?
Sostituiremo alcune mansioni, rimescoleremo le gerarchie e renderemo gli ingegneri dei dati più qualificati ancora più preziosi. Questa è la vera storia.
Esempio concreto: Creazione di un flusso di lavoro per la revisione di pipeline di dati assistita dall'intelligenza artificiale 🛠️
Scenario
Immaginate una piccola azienda di e-commerce con un ingegnere dei dati, due analisti e un problema fin troppo comune: la dashboard finanziaria si blocca ogni volta che il fornitore di servizi di pagamento cambia il nome di un campo.
Il team non vuole che l'IA "domini" la pipeline. Sarebbe rischioso. Piuttosto, la utilizzano come assistente di prima bozza per attività di routine ma importanti: scrivere scheletri di modelli dbt, suggerire test, redigere la documentazione e creare una checklist per la revisione del codice.
Il data engineer umano rimane comunque responsabile della progettazione finale, delle definizioni dei dati, delle regole di accesso e della distribuzione in produzione. L'intelligenza artificiale si limita ad accelerare la complessa fase intermedia.
Cosa richiede il flusso di lavoro
Prima di utilizzare l'IA, il team le fornisce un contesto sufficiente affinché sia utile:
-
Schema della tabella dei pagamenti esistente
-
Le definizioni delle metriche finanziarie target, come "ricavo netto", "importo del rimborso" e "pagamento saldato"
-
Convenzioni di denominazione per i modelli dbt
-
Esempi di test approvati
-
Un breve contratto dati per il flusso di pagamenti
-
Regole per la gestione dei dati personali, dei pagamenti non andati a buon fine, dei duplicati e dei documenti pervenuti in ritardo
-
Una selezione di incidenti passati, con indicazione di cosa è andato storto e come è stato risolto
Il punto chiave non è "chiedere all'IA di costruire una pipeline". È troppo vago.
L'approccio più efficace è: "Ecco le nostre regole, ecco lo schema, ecco il comportamento previsto. Preparate una bozza che possiamo esaminare."
Esempio di istruzione
Stai contribuendo alla stesura di un modello dbt per i nostri dati di pagamento. Utilizza lo schema e le regole seguenti per creare una prima bozza del modello, suggerire dei test dbt e redigere delle note di documentazione.
Il modello deve calcolare le entrate giornaliere liquidate in base a order_id e payment_provider. Escludere i pagamenti non andati a buon fine, escludere le transazioni di prova e sottrarre i rimborsi solo quando refund_status = “confirmed”.
Non inventate colonne. Se manca una colonna obbligatoria, elencatela nella sezione "Domande per la revisione umana" invece di fare supposizioni.
Suggerisci inoltre di effettuare test per l'unicità, i valori nulli, i valori accettati e la ragionevolezza dei ricavi. Segnala qualsiasi logica che potrebbe influire sulla rendicontazione finanziaria.
Come testarlo
Un test sensato è piccolo e volutamente banale:
-
Fornisci all'IA uno schema di pagamento noto e valido e verifica se evita di inventare campi.
-
Fornisci uno schema con una colonna `refund_status` mancante e verifica se pone una domanda invece di tirare a indovinare.
-
Esegui il codice SQL generato su un set di dati di staging, non su quello di produzione.
-
Confronta il risultato con 20 registrazioni di pagamento verificate manualmente.
-
Chiedi a un analista e all'ingegnere dei dati di rivedere le definizioni prima di procedere all'unione.
-
Aggiungi i test accettati alla CI in modo che la pipeline continui a eseguire i controlli dopo il deployment.
La cosa importante è testare l'IA sulle modalità di errore che più temi: colonne inventate, logica di calcolo dei ricavi errata, gestione dei rimborsi mancante e righe duplicate silenziose.
Risultato
Risultato illustrativo: basato sulla misurazione dei tempi di tre attività campione di modifica della pipeline prima e dopo l'utilizzo di questo flusso di lavoro.
Prima di utilizzare l'IA, l'ingegnere impiegava circa 5 ore e 30 minuti per ogni modifica: all'incirca 2 ore per scrivere codice SQL, 1 ora per creare test, 45 minuti per redigere la documentazione e il resto per verificare i casi limite con il reparto finanziario.
Utilizzando l'IA solo per le prime bozze, lo stesso tipo di modifica ha richiesto circa 2 ore e 10 minuti. Il risparmio maggiore si è ottenuto con la fase di test della struttura e delle bozze della documentazione, che è passata da 1 ora e 45 minuti a circa 25 minuti.
La fase di revisione umana richiedeva comunque circa 45 minuti e non dovrebbe essere eliminata.
Nel test a tre fasi, l'IA ha suggerito 18 verifiche. L'ingegnere ne ha accettate 11, ne ha modificate 5 e ne ha rifiutate 2 perché presupponevano regole aziendali errate. Il numero di verifiche rifiutate è importante: dimostra che il flusso di lavoro necessita di una revisione, non di una fiducia cieca.
Cosa può andare storto?
L'intelligenza artificiale può far apparire una pipeline più completa di quanto non sia in realtà.
I punti critici più comuni includono:
-
Inventare colonne che sembrino plausibili
-
Trattare rimborsi, storni e pagamenti non andati a buon fine come la stessa cosa
-
Mancata rilevazione dei problemi di fuso orario nelle entrate giornaliere
-
Suggerire test generici che non rilevano errori finanziari
-
Redigere documenti che sembrino sicuri di sé ma che nascondano incertezza
-
Dimenticare le regole sulla privacy quando i dati campione contengono informazioni sui clienti
Una buona regola: l'IA può redigere il modello, ma un essere umano deve approvare le definizioni, la logica finanziaria, il controllo degli accessi e il rilascio in produzione.
Da portare via in modo pratico
La versione più valida dell'IA nell'ingegneria dei dati non è "sostituire l'ingegnere dei dati", bensì "rimuovere la pagina bianca e poi rivederla attentamente".
Questo si traduce in SQL più veloce, test più rapidi e una documentazione iniziale migliore, mentre l'ingegnere rimane responsabile dell'aspetto più importante: la correttezza, l'affidabilità, la sicurezza e la comprensibilità dei dati.
Domande frequenti
L'intelligenza artificiale sostituirà completamente gli ingegneri dei dati?
Nella maggior parte delle organizzazioni, l'IA è più propensa a farsi carico di compiti specifici piuttosto che a eliminarli del tutto. Può accelerare la stesura di SQL, la creazione di pipeline, i primi passaggi della documentazione e la creazione di test di base. Ma l'ingegneria dei dati comporta anche responsabilità e senso di responsabilità, oltre al poco affascinante compito di far sì che la caotica realtà aziendale si comporti come un sistema affidabile. Queste parti hanno ancora bisogno degli esseri umani per decidere cosa sia "giusto" e per assumersi la responsabilità quando le cose non funzionano.
Quali parti dell'ingegneria dei dati sono già automatizzate dall'intelligenza artificiale?
L'intelligenza artificiale funziona meglio su lavori ripetibili: stesura e refactoring di SQL, generazione di scheletri di modelli DBT, spiegazione di errori comuni e produzione di schemi di documentazione. Può anche supportare test come controlli null o di unicità e generare codice "collante" per gli strumenti di orchestrazione. Il vantaggio è lo slancio: si inizia più vicini a una soluzione funzionante, ma è comunque necessario convalidarne la correttezza e assicurarsi che si adatti al proprio ambiente.
Se l'intelligenza artificiale può scrivere codice SQL e pipeline, cosa resta agli ingegneri dei dati?
Molte: definire contratti dati, gestire le deviazioni degli schemi e garantire che le pipeline siano idempotenti, osservabili e recuperabili. I data engineer dedicano tempo all'analisi delle modifiche alle metriche, alla creazione di barriere di sicurezza per gli utenti a valle e alla gestione dei compromessi in termini di costi e affidabilità. Il lavoro spesso si riduce a creare fiducia e a mantenere la piattaforma dati "silenziosa", ovvero sufficientemente stabile da non doverci pensare quotidianamente.
In che modo l'intelligenza artificiale cambia il lavoro quotidiano di un data engineer?
In genere, riduce i tempi di boilerplate e di ricerca, in modo da dedicare meno tempo alla digitazione e più tempo alla revisione, alla convalida e alla progettazione. Questo cambiamento orienta il ruolo verso la definizione di aspettative, standard di qualità e modelli riutilizzabili, piuttosto che la codifica manuale di tutto. In pratica, probabilmente si lavorerà di più in partnership con i team di prodotto, sicurezza e finanza, perché l'output tecnico diventa più facile da creare, ma più difficile da gestire.
Perché l'intelligenza artificiale ha difficoltà a gestire definizioni aziendali ambigue come "utente attivo"?
Poiché la logica aziendale non è statica o precisa, cambia a metà progetto e varia a seconda degli stakeholder. L'intelligenza artificiale può elaborare un'interpretazione, ma non può prendere decisioni quando le definizioni evolvono o emergono conflitti. L'ingegneria dei dati richiede spesso negoziazione, documentazione di ipotesi e trasformazione di requisiti vaghi in contratti durevoli. Questo lavoro di "allineamento umano" è una delle ragioni principali per cui il ruolo non scompare, nemmeno con il miglioramento degli strumenti.
L'intelligenza artificiale è in grado di gestire in modo sicuro la governance dei dati, la privacy e la conformità?
L'intelligenza artificiale può aiutare a elaborare policy o suggerire approcci, ma un'implementazione sicura richiede comunque una vera e propria progettazione e un'attenta supervisione. La governance implica controlli di accesso, gestione delle informazioni personali identificabili (PII), regole di conservazione, audit trail e talvolta vincoli di residenza. Si tratta di aree ad alto rischio in cui "quasi giusto" non è accettabile. Gli esseri umani devono progettare le regole, verificarne l'applicazione e rimanere responsabili dei risultati di conformità.
Quali competenze restano preziose per gli ingegneri dei dati man mano che l'intelligenza artificiale migliora?
Competenze che rendono i sistemi resilienti: system design thinking, ingegneria della qualità dei dati e standardizzazione basata sulla piattaforma. Contratti, osservabilità, abitudini di risposta agli incidenti e un'analisi disciplinata delle cause profonde diventano ancora più importanti quando più persone possono generare rapidamente artefatti di dati. Anche la comunicazione diventa un fattore di differenziazione: allineare le definizioni, scrivere documenti chiari e spiegare i compromessi senza drammi è un aspetto fondamentale per mantenere l'affidabilità dei dati.
Quali ruoli di data engineering sono maggiormente a rischio a causa dell'intelligenza artificiale e degli strumenti gestiti?
I ruoli focalizzati esclusivamente sull'ingestione ripetitiva o sulle pipeline di reporting standard sono più esposti, soprattutto quando i connettori ELT gestiti coprono la maggior parte delle fonti. Il lavoro a bassa proprietà e basato sui ticket può ridursi perché l'intelligenza artificiale e l'astrazione riducono lo sforzo per pipeline. Ma questo di solito si traduce in un minor numero di persone che svolgono attività ripetitive, non in "nessun data engineer". I ruoli ad alta proprietà incentrati su affidabilità, qualità e fiducia rimangono duraturi.
Come dovrei utilizzare strumenti come GitHub Copilot o dbt con l'intelligenza artificiale senza creare caos?
Considera l'output dell'IA come una bozza, non come una decisione. Utilizzalo per generare scheletri di query, migliorare la leggibilità o creare un'impalcatura per test e documenti DBT, quindi convalidalo rispetto a dati reali e casi limite. Abbinalo a convenzioni rigorose: contratti, standard di denominazione, controlli di osservabilità e pratiche di revisione. L'obiettivo è una consegna più rapida senza sacrificare affidabilità, controllo dei costi o governance.
Riferimenti
-
Commissione Europea - Spiegazione della protezione dei dati: principi del GDPR - commission.europa.eu
-
Ufficio del Garante per la protezione dei dati personali (ICO) - Limitazioni di archiviazione - ico.org.uk
-
Commissione europea - Per quanto tempo possono essere conservati i dati ed è necessario aggiornarli? - commission.europa.eu
-
National Institute of Standards and Technology (NIST) - Quadro normativo sulla privacy - nist.gov
-
NIST Computer Security Resource Center (CSRC) - SP 800-92: Guida alla gestione dei registri di sicurezza informatica - csrc.nist.gov
-
Center for Internet Security (CIS) - Gestione del registro di controllo (controlli CIS) - cisecurity.org
-
Documentazione Snowflake - Criteri di accesso alle righe - docs.snowflake.com
-
Documentazione di Google Cloud - Sicurezza a livello di riga di BigQuery - docs.cloud.google.com
-
BITOL - Standard contrattuale per i dati aperti (ODCS) v3.1.0 - bitol-io.github.io
-
BITOL (GitHub) - Standard contrattuale per dati aperti - github.com
-
Apache Airflow - Documentazione (stabile) - airflow.apache.org
-
Apache Airflow - DAG (concetti fondamentali) - airflow.apache.org
-
Documentazione dbt Labs - Che cos'è dbt? - docs.getdbt.com
-
Documentazione dbt Labs - Informazioni sui modelli dbt - docs.getdbt.com
-
Documentazione dbt Labs - Documentazione - docs.getdbt.com
-
Documentazione dbt Labs - Test dei dati - docs.getdbt.com
-
Documentazione dbt Labs - Livello semantico dbt - docs.getdbt.com
-
Documentazione Fivetran - Per iniziare - fivetran.com
-
Fivetran - Connettori - fivetran.com
-
Documentazione AWS - Guida per gli sviluppatori AWS Lambda - docs.aws.amazon.com
-
GitHub - GitHub Copilot - github.com
-
GitHub Docs - Ottenere suggerimenti di codice nel tuo IDE con GitHub Copilot - docs.github.com
-
Microsoft Learn - GitHub Copilot per SQL (estensione VS Code) - learn.microsoft.com
-
Documentazione Dynatrace - Osservabilità dei dati - docs.dynatrace.com
-
DataGalaxy - Che cosa è l'osservabilità dei dati? - datagalaxy.com
-
Documentazione di Great Expectations - Panoramica delle aspettative - docs.greatexpectations.io