Vai al contenuto principale
FromNine
Menu

IA e dati

Fondamenta di dati e analytics su cui IA e decisioni possono contare

Costruiamo piattaforme dati in cui ogni dataset ha un responsabile, un contratto e una qualità nota, così che analytics, operatività e IA attingano tutte agli stessi numeri affidabili.

Per imprese e amministrazioni che devono conciliare dati sparsi tra gestionali, società del gruppo e banche dati pubbliche, con definizioni condivise.

Parliamo del Suo progettoScopra il nostro approccio
Dati e analytics: lo stack delle competenzeQuattro livelli sovrapposti in profondità. Dall’alto verso il basso: analytics e IA che utilizzano i dati, i data product con responsabili e contratti, i livelli del lakehouse che puliscono e armonizzano e, trasversale a tutto, la governance.01Utilizzo per analytics e IA02Data product e contratti03Livelli del lakehouse04Governance e lineage
  1. 01Data product con responsabili designati, contratti e controlli di qualità
  2. 02Una governance che codifica limitazione della finalità e conservazione, non solo un catalogo
  3. 03Un’unica serie di definizioni dei KPI sottoscritta sia dal business sia dall’IT

01 Problemi

Problemi di dati ben noti

La maggior parte dei progetti di IA che deludono si rivela un progetto sui dati sotto mentite spoglie.

  1. 01

    Tre report, tre numeri diversi

    Amministrazione, area operativa e vertice aziendale calcolano ciascuno a modo proprio il fatturato o il carico di pratiche. Le riunioni iniziano riconciliando invece che decidendo.

  2. 02

    Nessuno è responsabile dei dati, quindi nessuno li corregge

    Gli errori emergono a valle, vengono corretti in un foglio di calcolo e il mese dopo si ripresentano.

  3. 03

    Il team di IA passa la maggior parte del tempo a cercare dati

    Ogni caso d’uso inizia con settimane di richieste di accesso, estrazioni e pulizie che il team successivo ripeterà.

  4. 04

    Gli archivi sono inutilizzabili per l’IA

    Documenti scansionati con un OCR scadente, duplicati e nessun metadato. Il retrieval su questi contenuti restituisce solo rumore.

02 Ambiti di intervento

Che cosa realizziamo

  1. 01 Fondamenta di dati per IA e analytics

    Architetture lakehouse con una modellazione a livelli, dai dati grezzi a quelli armonizzati fino a quelli pronti per l’uso, e data product che dichiarano che cosa contengono, quanto sono aggiornati e chi ne risponde.

    Che cosa facciamo

    • Architettura della piattaforma e scelta dei formati di archiviazione
    • Convenzioni di modellazione a livelli
    • Progettazione dei data product con contratti
    • Acquisizione batch e tramite change data capture

    Che cosa riceve

    • Piattaforma lakehouse definita come codice
    • Primi data product in produzione
    • Modello di data contract e processo di revisione

  2. 02 Qualità, lineage e master data

    Controlli di qualità automatici a ogni livello, lineage dalla fonte al report e dati anagrafici e di riferimento per le entità che contano: cittadini, clienti, prodotti e asset.

    Che cosa facciamo

    • Regole di qualità con soglie e allarmi
    • Rilevazione del lineage a livello di colonna
    • Regole di matching e di survivorship per i master data
    • Gestione dei dati di riferimento

    Che cosa riceve

    • Dashboard di qualità per ciascun data product
    • Lineage interrogabile
    • Golden record per le entità prioritarie

  3. 03 Una governance applicata davvero

    Catalogo, classificazione e policy di accesso che la piattaforma applica automaticamente. Limitazione della finalità e conservazione previste dal GDPR sono codificate, e la condivisione dei dati segue le regole del Data Governance Act dove applicabile.

    Che cosa facciamo

    • Schema di classificazione e tagging
    • Policy di accesso basate su attributi
    • Automazione di conservazione e cancellazione
    • Accordi di condivisione dei dati e relativi controlli tecnici

    Che cosa riceve

    • Catalogo alimentato dalla piattaforma
    • Policy di accesso come codice
    • Piano di conservazione operativo

  4. 04 Contenuti non strutturati pronti per l’IA

    Miglioramento della qualità dell’OCR, arricchimento dei metadati, deduplicazione e riordino degli archivi, perché i sistemi di document intelligence e di retrieval partano da contenuti che valga la pena recuperare.

    Che cosa facciamo

    • Censimento dei contenuti e campionamento della qualità
    • Miglioramento di OCR ed estrazione del layout
    • Rilevamento dei quasi duplicati
    • Arricchimento dei metadati e classificazione

    Che cosa riceve

    • Archivio di contenuti ripulito e arricchito
    • Report sulla qualità dei contenuti
    • Regole per i contenuti aggiunti da qui in avanti

  5. 05 Analytics e BI che le persone usano

    Un livello semantico con definizioni dei KPI concordate tra business e IT, self-service governato e analytics integrata nei prodotti SaaS e nei portali.

    Che cosa facciamo

    • Workshop di definizione dei KPI
    • Modello semantico e livello delle metriche
    • Regole per il self-service e dataset certificati
    • Analytics integrata nei prodotti rivolti ai clienti

    Che cosa riceve

    • Glossario dei KPI con responsabili
    • Modello semantico certificato
    • Dashboard che sostituiscono i fogli di calcolo

  6. 06 Streaming per l’operatività

    Change data capture e flussi di eventi dove le decisioni non possono attendere il caricamento notturno: livelli di scorta, stato delle pratiche, segnali di frode.

    Che cosa facciamo

    • Requisiti di latenza per caso d’uso
    • CDC dai database operativi
    • Stream processing e viste materializzate
    • Progettazione di replay e backfill

    Che cosa riceve

    • Pipeline di streaming in produzione
    • Viste operative con obiettivi di aggiornamento
    • Procedura di replay

03 Architettura

Un’architettura di riferimento illustrativa

I dati passano dai sistemi operativi e dai documenti, attraverso l’acquisizione, a un lakehouse organizzato a livelli: grezzo così come ricevuto, poi armonizzato e verificato nella qualità, infine data product con un responsabile e un contratto. Chi consuma i dati non legge mai il livello grezzo.

Dai data product, un percorso alimenta il livello semantico e la BI; altri alimentano il retrieval e le feature per l’IA e le API dati verso altri sistemi. La governance sta alla base di tutto ed è applicata dalla piattaforma, non da un documento di policy.

Esempio illustrativo

  1. Fonti e acquisizione

    • Sistemi operativi
    • Documenti dopo OCR e arricchimento
    • Batch e change data capture

  2. Lakehouse

    • Livello grezzo
    • Livello armonizzato
    • Controlli di qualità e lineage
    • Master data e dati di riferimento
    • Data product con contratti

  3. Utilizzo

    • Livello semantico e BI
    • Retrieval e feature per l’IA
    • API dati e condivisione

  4. Governance

    • Governance: catalogo, classificazione, policy di accesso, conservazione
Dai livelli del lakehouse a data product con un responsabile

Architettura illustrativa, non un sistema di un cliente.

Leggere il diagramma in forma testuale

Il percorso principale va dai sistemi operativi, attraverso l’acquisizione batch e tramite change data capture, un livello grezzo, un livello armonizzato e i data product, fino a un livello semantico con BI governata.

Anche i documenti non strutturati entrano attraverso l’acquisizione, dopo OCR e arricchimento. Controlli di qualità e lineage coprono i livelli grezzo e armonizzato. Master data e dati di riferimento alimentano i data product. I data product servono anche il retrieval e le feature per l’IA e le API dati per la condivisione.

Una fascia di governance con catalogo, classificazione, policy di accesso e conservazione copre l’intera piattaforma.

04 Considerazioni e limiti

Scelte progettuali e limiti

  • Prima la responsabilità, poi gli strumenti

    Come lo affrontiamo

    Ogni data product ha un responsabile di business, che ne stabilisce il significato, e un responsabile tecnico, che lo mantiene in funzione. La aiutiamo a definire entrambi i ruoli e il contratto tra chi produce e chi utilizza i dati.

    Limiti e dipendenze

    Una piattaforma non può creare responsabilità. Se l’organizzazione non designa i responsabili, i problemi di qualità torneranno, qualunque sia lo strumento.

  • La limitazione della finalità nella pratica

    Come lo affrontiamo

    I dati personali sono etichettati con le finalità a cui possono servire, e policy di accesso e conservazione seguono automaticamente quelle etichette.

    Limiti e dipendenze

    Quali finalità siano lecite lo decidono il Suo responsabile della protezione dei dati e i Suoi consulenti legali. Noi lo implementiamo, non lo decidiamo.

  • I dati per l’IA hanno una propria soglia di qualità

    Come lo affrontiamo

    Per i casi d’uso di IA misuriamo ciò che serve a retrieval e modelli: copertura, aggiornamento, duplicati e qualità dell’estrazione del testo.

    Limiti e dipendenze

    Per alcuni archivi non vale la pena intervenire. Una valutazione a campione lo dirà, e a volte la scelta giusta è lasciarli fuori.

05 Come lavoriamo

Come lavoriamo

Costruiamo la piattaforma attorno ai primi data product che contano, non il contrario.

  1. 01

    Scegliere decisioni, non dataset

    Partire da due o tre decisioni o casi d’uso di IA e dai dati che richiedono, con i responsabili già designati.

    RisultatoBacklog dei data product con responsabili

  2. 02

    Costruire le fondamenta attorno a loro

    Piattaforma, acquisizione, controlli di qualità e governance, quanto basta per servire bene quei prodotti.

    RisultatoPrimi data product in produzione

  3. 03

    Crescere per prodotto

    Ogni nuovo prodotto riutilizza le fondamenta; il catalogo e il glossario dei KPI crescono con esso.

    RisultatoRoadmap dei prodotti e misure di adozione

06 Controllo umano

Dove il controllo resta alle persone

Le piattaforme dati automatizzano spostamenti e controlli. Significato, accesso e finalità li decidono le persone.

  • Le definizioni le approvano i responsabili

    Un KPI o un data product cambia significato solo con l’approvazione del suo responsabile di business, e la modifica viene versionata.

  • L’accesso lo concedono i titolari delle policy

    I responsabili dei dati decidono chi può usare quali dati e per quale finalità; la piattaforma lo applica e registra ogni autorizzazione.

  • Le violazioni di qualità bloccano la pubblicazione

    Quando un controllo del contratto fallisce, chi utilizza i dati viene avvisato e il responsabile decide se pubblicare, sospendere o correggere.

07 Tecnologie

Tecnologie con cui lavoriamo

Piattaforme
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Lakehouse aperto su Apache Iceberg o Delta Lake
Pipeline
  • dbt
  • Apache Spark
  • Kafka e Debezium
  • Orchestrazione cloud-native
Governance
  • Unity Catalog e Purview
  • Cataloghi open source
  • Framework per la qualità dei dati
  • Controllo degli accessi basato su policy
Analytics
  • Power BI
  • Livelli semantici e delle metriche
  • Analytics integrata
  • SAP analytics (sistemi esistenti)

La citazione di una tecnologia descrive la nostra esperienza di ingegneria. Non implica una partnership con il relativo fornitore né la sua approvazione.

08 Esempio

Un esempio illustrativo

Esempio illustrativo

Indicatori di gestione unici per un gruppo con più società

01Situazione
Le società di un gruppo della distribuzione calcolano margini e giacenze ciascuna dal proprio gestionale, con definizioni diverse; la direzione confronta numeri che non significano la stessa cosa.
02Che cosa realizzeremmo
Data product per società che alimentano un unico livello semantico, con definizioni degli indicatori concordate a livello di gruppo e il dettaglio locale preservato.
03Dove decidono le persone
I controller di ogni società approvano la mappatura dei propri dati; il responsabile degli indicatori di gruppo approva definizioni e modifiche.
04Che cosa misureremmo
Tempi di chiusura del report mensile, numero di rettifiche di riconciliazione, utilizzo dei cruscotti certificati.

09 Settori

Nel Suo settore

  • Sanità e scienze della vita

    Dati di ricerca e operativi governati, con rigorosa limitazione della finalità, pseudonimizzazione e registrazione degli accessi.

  • Manifattura e industria

    Anagrafiche di prodotti e asset, dati di qualità e di produzione collegati per pianificazione, tracciabilità e IA.

  • Pubblica Amministrazione

    Fonti autoritative, principio «once only» e reportistica che decisori pubblici e organi di controllo possono ricondurre al singolo dato.

Italia

Dati, Garante privacy e interoperabilità pubblica

In Italia la valorizzazione dei dati segue regole precise. Il GDPR e i provvedimenti del Garante per la protezione dei dati personali fissano finalità e tempi di conservazione; il regolamento europeo sui dati dà agli utenti diritti sui dati generati da prodotti connessi. Nella PA la PDND rende disponibili i dati delle amministrazioni tramite e-service con finalità dichiarate, e il CAD stabilisce che i dati si chiedono all’ente che li detiene, non al cittadino.

Progettiamo data product con contratti che indicano dove i dati si possono trattare, per quali finalità e per quanto tempo.

Domande su dati e analytics

Ci serve un data mesh?

Le servono le sue parti utili: data product con responsabili e contratti. La piena decentralizzazione ripaga nelle grandi organizzazioni con team di dominio maturi. Molte organizzazioni ottengono risultati migliori con un platform team centrale e la responsabilità dei prodotti affidata ai domini.

I nostri dati sono pronti per l’IA?

Può dirGlielo una breve valutazione a campione delle fonti necessarie a un caso d’uso: copertura, qualità, diritti di accesso e base giuridica. Di solito la risposta è «in parte», con un elenco chiaro di che cosa sistemare per primo. I nostri team di ingegneria IA usano la stessa valutazione.

Abbiamo già un data warehouse. Dobbiamo ripartire da zero?

Raramente. Un data warehouse che alimenta report affidabili è un patrimonio. Di solito lo estendiamo con funzionalità lakehouse per i dati non strutturati e ad alto volume, e migriamo solo dove costi o limiti lo giustificano.

Come gestite la condivisione dei dati con partner o altre amministrazioni?

Tramite data product esposti attraverso API governate, con accordi, limitazione della finalità e registrazione degli accessi. Dove si applicano il Data Governance Act o il Data Act, progettiamo i controlli tecnici; l’inquadramento giuridico resta in capo ai Suoi consulenti legali.

Ci dica quale decisione oggi non riesce a prendere con i dati

Risaliremo alle fonti che servono e Le mostreremo che cosa richiede un primo data product, partendo dai sistemi che il Suo team già gestisce.

Parliamo del Suo progettoScoprire il nostro approccio