L’economia dei dati sta creando figure professionali che fino a poco tempo fa non esistevano, a metà tra tecnologia, processi e responsabilità legali. Dal data steward all’MLOps engineer, dai curatori di dataset agli specialisti di Explainable AI, le imprese stanno ridisegnando ruoli, competenze e catene decisionali.
Data steward: governare qualità, accesso e conformità dei dati
Nel lessico delle aziende abituate a lavorare con molti dati, la parola data steward è diventata quasi quotidiana. È la figura che si occupa della qualità dei dati, della loro coerenza tra sistemi e della corretta definizione dei data owner. In pratica è chi decide cosa significa davvero un certo campo nel CRM, quali valori sono ammessi, chi può modificarli e con quali controlli.
Un buon data steward lavora a stretto contatto con IT, legale e funzioni operative. Non è un puro tecnico: deve conoscere i processi di business, capire come vengono generati i dati, come vengono arricchiti e quali errori tipici si ripetono. In un’azienda retail, per esempio, è la persona che stabilisce una volta per tutte cosa si intende per “cliente attivo” e come si calcola, evitando interpretazioni fantasiose nei report.
C’è poi la dimensione della conformità regolatoria, dagli obblighi sul trattamento dei dati personali alle policy interne sulla data retention. Il data steward scrive e fa rispettare regole di accesso, mascheramento e anonimizzazione. È un lavoro che richiede pazienza, fermezza e una certa diplomazia: spesso significa dire “no” a richieste di analisi creative ma rischiose, senza bloccare l’innovazione.
MLOps engineer per orchestrare modelli in produzione
Se i data scientist costruiscono i modelli, l’MLOps engineer è chi li fa funzionare davvero nel mondo reale. Questa figura unisce competenze da ingegnere del software, esperto di DevOps e conoscenze di machine learning. Il suo obiettivo è portare i modelli dall’ambiente sperimentale al deployment in produzione, gestendo versioni, prestazioni e monitoraggio continuo.
Un MLOps progetta pipeline che partono dai dati grezzi, passano per le fasi di validazione e trasformazione, arrivano all’addestramento del modello e alla pubblicazione come servizio API o componente di un’applicazione. Il tutto con strumenti di CI/CD, test automatizzati e metriche di controllo, come in qualsiasi sistema critico. In banca, ad esempio, un modello di scoring creditizio non può bloccarsi o degradare improvvisamente senza che qualcuno se ne accorga.
C’è poi la gestione della drift detection: i dati cambiano nel tempo, i comportamenti degli utenti evolvono, i modelli invecchiano. L’MLOps engineer definisce soglie, alert, procedure di rollback e ri-addestramento periodico. Lavora gomito a gomito con data scientist e responsabili applicativi, facendo da cerniera tra laboratorio e produzione, tra prototipo brillante e servizio affidabile.
Specialisti di data governance tra normativa e tecnologia
La data governance è diventata un campo a sé, dove competenze legali, organizzative e tecnologiche si intrecciano. Gli specialisti di data governance disegnano il modello complessivo di gestione dei dati: policy, ruoli, responsabilità, processi di approvazione, strumenti di catalogazione e classificazione.
In pratica definiscono come l’azienda decide, con metodo, cosa fare dei propri dati. Quali dataset sono critici, quali possono essere condivisi esternamente, come si gestiscono i consensi, come si documentano i flussi tra sistemi. In presenza di normative su privacy, antiriciclaggio o supervisione settoriale, questi professionisti lavorano quasi quotidianamente con il reparto compliance.
Non si limitano ai documenti. Collaborano nella scelta di data catalog, soluzioni di data lineage e strumenti di access control che permettano di implementare davvero le regole. In una logica molto vicina a quella del risk management: identificare i rischi legati ai dati, valutarli e decidere come mitigarli.
Per questo servono profili ibridi. Persona capace di capire un diagramma di flusso ETL, ma anche di scrivere una policy leggibile a chi lavora in finanza, marketing o logistica. Un ruolo che spesso finisce per diventare un “arbitro” neutrale nelle discussioni tra funzioni che litigano sui dati.
Curatori di dataset per addestrare sistemi di machine learning
Nei progetti di machine learning, si parla molto di algoritmi ma il vero fattore critico è spesso il dataset. I curatori di dataset si occupano proprio di questo: selezionare le fonti, pulire, etichettare, bilanciare i dati e documentarli in modo accurato. In molte realtà sono figure nate quasi dal basso, tra analisti e data scientist che hanno strutturato un mestiere.
Lavorano su problemi molto concreti. Per un modello di riconoscimento immagini in ambito sportivo, ad esempio, devono assicurarsi che le foto coprano davvero tutte le situazioni possibili: tipi di campo, condizioni di luce, divise, posizioni degli atleti. Devono evitare che il modello riconosca solo giocatori di una certa categoria o solo stadi di un determinato campionato.
La parte di data labeling è centrale: definire linee guida chiare, controllare la qualità delle annotazioni, gestire team distribuiti o servizi esterni di etichettatura. Il curatore di dataset documenta le scelte fatte, i limiti del dataset, i possibili bias. In molti casi produce vere e proprie “schede prodotto” dei dati, utili poi a chi dovrà spiegare o auditare il modello.
È un lavoro meticoloso, ma con impatto diretto sulle prestazioni dei sistemi intelligenti.
Explainable AI specialist per modelli trasparenti e auditabili
Con l’uso crescente di modelli complessi, dagli ensemble fino alle reti neurali profonde, è emersa una figura dedicata a renderli comprensibili: lo Explainable AI specialist. Il suo compito è progettare e applicare tecniche che rendano i modelli trasparenti, spiegabili e quindi auditabili da chi deve assumersi la responsabilità delle decisioni.
Lavora con strumenti come SHAP, LIME, saliency map e metodi di interpretabilità intrinseca, ma soprattutto cura il modo in cui queste spiegazioni vengono presentate a chi non è tecnico. Un responsabile del credito, un medico o un recruiter devono poter capire, in forma sintetica, perché un modello ha proposto un certo esito.
Questa figura si muove tra etica, regolamentazione e pratica quotidiana. In alcuni settori, la spiegabilità non è solo una buona pratica, è un requisito normativo. L’Explainable AI specialist aiuta a progettare modelli che rispettino tali vincoli fin dall’inizio, evitando di ritrovarsi con una “scatola nera” da giustificare a posteriori.
Spesso collabora con legali, risk manager e data governance per definire metriche di spiegabilità e procedure di revisione periodica. È il punto di contatto tra il mondo degli algoritmi e quello delle decisioni che devono essere difendibili davanti a un revisore, a un’autorità o semplicemente a un cliente.
Nuove responsabilità manageriali nell’impresa guidata dai dati
L’economia dei dati non crea solo ruoli tecnici. Cambia anche il lavoro dei manager, che si trovano con nuove responsabilità. Un direttore marketing o operations oggi è, di fatto, anche sponsor di progetti di data analytics e AI, responsabile dell’uso corretto dei modelli nei propri processi.
In molte organizzazioni nascono figure come il chief data officer (CDO) o il head of data & analytics, che coordinano strategia, piattaforme e priorità di investimento. Ma anche i manager di linea devono abituarsi a ragionare in termini di data product: servizi interni basati su dati e algoritmi, con obiettivi chiari, utenti definiti e cicli di miglioramento continuo.
Cambia il modo di prendere decisioni. Non basta approvare un modello perché “funziona bene in test”. Occorre capire quali metriche di business presidiare, come integrare i risultati algoritmici nei processi umani, quando dare precedenza al giudizio esperto rispetto alle previsioni automatiche. Un responsabile della supply chain, ad esempio, deve saper discutere con data scientist e MLOps di soglie, margini di errore accettabili, scenari di fallback.
La responsabilità si sposta verso la accountability algoritmica. Chi guida un’unità organizzativa non può più delegare in blocco “alla tecnologia”, ma deve farsi carico delle scelte su quali modelli usare, come controllarli e quando fermarli.
