AI in azienda: progettare, auditare e migliorare con la GDE

Come uso la GDE per rendere l’intelligenza artificiale comprensibile, misurabile, tracciabile e controllabile nei processi reali di impresa, sia quando si progetta un nuovo caso d’uso sia quando si valuta un ecosistema AI già attivo.

di Andrea Viliotti

L’intelligenza artificiale non è più una promessa da osservare a distanza. È già entrata nei testi, nelle analisi, nei workflow, nelle relazioni con clienti e fornitori, nella ricerca, nel marketing, nella preparazione di gare e nella gestione delle informazioni. La domanda, quindi, non è più solo se un’azienda userà AI, ma in quale sistema la farà entrare, con quali dati, con quali responsabilità e con quali limiti.

La GDE, Geometria Dinamica dell’Entropia, è il framework che uso per leggere sistemi complessi come insiemi di relazioni, vincoli, informazioni incomplete e decisioni distribuite. Tradotta per l’impresa, mi serve a trasformare una domanda generica — “possiamo usare l’AI?” — in un perimetro osservabile: dati disponibili, fonti, ruoli, rischi, KPI, responsabilità, controlli e condizioni di stop.

Per questo, nei miei lavori di consulenza, non parto dal software. Parto dal contesto aziendale: processi, dati, vincoli, persone, responsabilità, capacità di controllo e decisioni che non devono essere delegate a uno strumento. L’AI può generare, classificare, sintetizzare, suggerire e automatizzare. Ma non decide da sola quale obiettivo aziendale sia corretto, quale fonte sia affidabile, quale rischio sia accettabile o quale funzione debba rispondere di una scelta.

Box sintesi — L’AI accelera e amplia le possibilità operative. La GDE è il metodo con cui imposto le condizioni perché quell’esecuzione abbia senso per l’azienda: dati leggibili, fonti qualificate, ruoli chiari, limiti espliciti, controlli praticabili, responsabilità umane, criteri di valutazione e audit riapribile nel tempo.

governance AI aziendale

Il problema non è adottare AI, ma governarne l’impatto

Molte conversazioni sull’intelligenza artificiale iniziano dal tool: quale modello usare, quale piattaforma comprare, quale agente introdurre, quale automazione provare. È comprensibile, perché gli strumenti sono visibili, promettono velocità e producono demo convincenti. Ma una demo non è un sistema aziendale.

Quando l’AI entra in azienda, non modifica solo una schermata o una procedura. Cambia il modo in cui le persone cercano informazioni, scrivono documenti, valutano clienti, leggono dati, preparano decisioni, controllano rischi e dialogano con vendor, partner e funzioni interne. Se questo cambiamento resta implicito, l’AI può accelerare anche ciò che l’azienda non ha ancora chiarito: silos informativi, fonti deboli, responsabilità non assegnate, KPI confusi, promesse commerciali non sostenute da evidenze.

Il primo rischio è organizzativo: l’AI viene trattata come una funzione tecnica e non come un cambiamento nel sistema decisionale. Il secondo rischio è informativo: dati e fonti entrano nei workflow senza essere distinti tra osservato, stimato, proxy o ipotesi. Il terzo rischio è economico: errori piccoli ma ripetuti possono produrre rilavorazioni, scelte sbagliate, blocchi operativi, esposizione reputazionale e costi che emergono solo quando il problema è già entrato nei processi.

Da dove nasce la GDE

La GDE nasce dal mio lavoro di ricerca e dalla mia esperienza imprenditoriale nella tecnologia. Non la considero un’etichetta da appoggiare a un progetto già deciso. La considero una disciplina di osservazione: prima di scegliere una soluzione devo capire il sistema che quella soluzione attraverserà.

Un’azienda non è fatta solo di processi. È fatta di ruoli, relazioni, informazioni, incentivi, vincoli, tempi decisionali, responsabilità e linguaggi. L’AI entra in questo sistema e lo modifica. La GDE serve a rendere visibile questa trasformazione prima che diventi ingestibile, e serve anche a rileggerla quando l’azienda ha già introdotto strumenti AI senza aver costruito un audit sufficiente.

Perché partire dal software è un errore

Non vendo software, non sviluppo piattaforme e non costruisco direttamente agenti AI. Il mio lavoro è aiutare l’azienda a capire quali strumenti abbiano senso, quali condizioni debbano rispettare, quali rischi introducano e come valutarne efficacia e impatto.

Un approccio centrato solo sul tool cerca un caso d’uso per una tecnologia già scelta. Un approccio GDE parte invece dal sistema: quale decisione deve migliorare, quali dati la alimentano, quali reparti sono coinvolti, quali vincoli normativi o di sicurezza entrano in gioco, quale controllo umano serve, quale output è accettabile e quale risultato deve far scattare un blocco o una revisione.

Il metodo in cinque fasi

Per rendere la GDE leggibile anche a chi lavora in IT, strategia, compliance, procurement o operations, la traduco in un percorso operativo. Non è una sequenza rigida di checklist: è una struttura di analisi che parte dai dati e dalle informazioni disponibili, li qualifica, li collega ai ruoli aziendali e li sottopone a criteri di validazione prima di autorizzare una conclusione o una delega all’AI.

Fase	Domanda guida	Output operativo
1. Mappare il contesto	Quali processi, attori, dati, vincoli, sistemi e decisioni sono coinvolti?	Mappa del caso d’uso AI
2. Classificare il rischio	Quali rischi tecnici, operativi, legali, reputazionali ed economici emergono?	Risk register e priorità
3. Definire limiti e responsabilità	Che cosa l’AI può fare, che cosa non può fare, chi valida e chi risponde?	RACI, policy minima e criteri di escalation
4. Misurare output e impatto	Quali output sono accettabili, con quali fonti, errori, tempi e controlli?	KPI e criteri di accettazione
5. Governare nel tempo	Come si registrano log, incidenti, revisioni, apprendimento e condizioni di stop?	Piano di monitoraggio e miglioramento

La differenza con framework, norme e standard già noti

La GDE non sostituisce il quadro normativo e non si presenta come certificazione. Lavora prima e accanto a norme, framework e standard. Il suo ruolo è costruire un oggetto leggibile: un caso d’uso con confini, dati, ruoli, controlli, fonti, criteri di accettazione e limiti dichiarati.

Questa distinzione è importante. La normativa stabilisce che cosa è richiesto o vietato; gli standard aiutano a strutturare processi e sistemi di gestione; i framework di risk management organizzano responsabilità e controlli. La GDE mi serve a preparare il terreno operativo su cui questi riferimenti possono lavorare senza diventare documentazione formale applicata a un oggetto ambiguo.

Riferimento	Cosa presidia	Dove si innesta la GDE
EU AI Act	Approccio basato sul rischio, obblighi di trasparenza, controllo umano e classificazione dei sistemi.	Traduce gli obblighi in domande operative per funzioni, dati, vendor, log e responsabilità.
Legge italiana 132/2025	Principi di uso corretto, trasparente, responsabile e antropocentrico dell’AI.	Rende osservabili ruoli, dati, limiti e responsabilità prima di usare o proporre automazioni.
NIST AI RMF	Funzioni Govern, Map, Measure, Manage per gestire rischio e affidabilità.	Aiuta a definire che cosa mappare, misurare e governare nel caso d’uso concreto.
ISO/IEC 42001	Sistema di gestione dell’AI, con requisiti per politiche, processi e miglioramento.	Alimenta il sistema di gestione con contesto, confini, evidenze e controlli riapribili.
Modelli di maturità e consulenza	Valutano stato, capacità e roadmap dell’organizzazione.	Evita che la maturità resti astratta: la collega a output, dati, owner, rischi e stop condition.

Applicazioni: RFP, ricerca, supply chain, marketing e IT

In gare, RFP e bandi il metodo serve a distinguere requisiti obbligatori, criteri premianti, documenti mancanti, evidenze disponibili, claim sostenibili, rischi di overpromise e condizioni di go/no-go. Non sostituisce legali, procurement o specialisti tecnici; rende più leggibile il perimetro su cui quei ruoli devono lavorare.

Nella ricerca e nei paper di innovazione, la GDE aiuta a separare ipotesi, fonti, stato dell’arte, risultati attesi, metriche e limiti. In geoeconomia e supply chain serve a collegare segnali esterni, fornitori, rotte, dipendenze, rischi e decisioni aziendali. In marketing, commerciale e web serve a distinguere narrazione, dati osservabili, lead, segmenti, contenuti AI e responsabilità di validazione.

Con IT, vendor e sviluppatori il punto è ancora diverso: non si tratta di sostituire il lavoro tecnico, ma di scrivere meglio le condizioni che il lavoro tecnico deve rispettare. Requisiti dati, log, integrazioni, privacy, cybersecurity, ruoli di validazione, fallback e incidenti devono essere definiti prima che l’AI diventi parte del processo.

KPI e controlli: misurare senza promettere risultati automatici

Un progetto AI non diventa serio perché contiene molte metriche. Diventa serio quando le metriche rispondono a una domanda chiara: che cosa devo osservare per capire se l’AI sta migliorando il processo, spostando il rischio o creando una zona grigia? Per questo distinguo KPI di qualità, tracciabilità, controllo umano, efficienza, rischio e apprendimento.

Area	Esempi di KPI o controllo	Perché conta
Qualità output	Output approvati senza revisione sostanziale; errore per categoria; coerenza con policy.	Misura se l’AI migliora davvero il lavoro, non solo se produce più testo.
Tracciabilità	Output con fonte, log, prompt o evidenza verificabile.	Riduce opacità e facilita audit, procurement, compliance e sicurezza.
Controllo umano	Override rate, escalation rate, tempo medio di validazione.	Mostra dove serve presidio umano e dove l’automazione è fragile.
Efficienza operativa	Riduzione del ciclo di lavoro, tempo di risposta, rilavorazioni evitate.	Misura impatto operativo senza trasformarlo in ROI promesso.
Rischio	Incidenti, claim non sostenuti, output respinti, violazioni di policy, blocchi.	Rende visibili i costi nascosti prima che diventino problema economico.
Apprendimento	Decisioni riviste, requisiti aggiornati, fonti escluse, casi riaperti.	Trasforma l’uso dell’AI in miglioramento continuo e non in delega cieca.

Un micro-caso: AI nel commerciale B2B

Immaginiamo un’azienda che voglia usare AI per qualificare prospect e preparare email commerciali. L’approccio tool-first parte dal modello: collego il CRM, genero testi, automatizzo follow-up. Il rischio è che l’AI trasformi dati incompleti in messaggi sicuri, ruoli presunti in decision maker reali, segnali deboli in intenzioni di acquisto.

Con la GDE parto invece da domande diverse. Quali dati cliente possono essere usati? Quali fonti alimentano il CRM? Chi valida il profilo del prospect? Quali settori o categorie vanno esclusi? Quali claim commerciali non posso scrivere se non ho evidenze? Quando l’AI deve preparare una bozza e quando deve fermarsi?

L’output non è “scegliere un modello”. L’output è un perimetro di lavoro: matrice dati-fonti, regole di esclusione, protocollo di validazione, criteri di stop e audit riapribile. Qui la differenza diventa concreta: il lettore non deve fidarsi della parola “metodo”; deve poter vedere che cosa produce.

Estratto anonimizzato di output GDE del micro-caso

Questo è un esempio di artefatto operativo anonimizzato: non espone un cliente reale e non contiene dati sensibili, ma mostra la forma dell’output che sposta il discorso da “fidati che è un metodo” a “guarda il perimetro che il metodo produce”.

Blocco output	Elemento	Fonte/controllo	Decisione
Matrice dati-fonti	Ragione sociale prospect	CRM + sito aziendale + registro pubblico quando disponibile	Ammesso solo se nome, dominio e settore sono coerenti; in caso di conflitto il record torna a validazione umana.
Matrice dati-fonti	Contatto decisionale	CRM + pagina aziendale + fonte professionale pubblica	Non inferire il ruolo dal titolo generico; usare solo ruolo verificato o scrivere bozza non personalizzata.
Matrice dati-fonti	Trigger commerciale	Richiesta inbound, RFP, news aziendale pubblica o segnale dichiarato dal sales owner	Classificare come segnale, non come intenzione di acquisto; vietato trasformarlo in promessa di budget.
Regola di esclusione	Fonte critica mancante	Controllo dati	Escludo l’automazione dell’email quando il dato che giustifica il messaggio non ha fonte o ha fonte contraddittoria.
Regola di esclusione	Vincolo compliance o reputazionale non valutato	Controllo rischio	Escludo il prospect o lo sposto a revisione quando settore, paese, trattamento dati o claim attivano vincoli non chiusi.
Criterio di stop	Confusione tra fatto osservato e inferenza del modello	Controllo decisionale	Il workflow si ferma quando l’AI non può distinguere dato verificato, proxy e ipotesi in una decisione commerciale sensibile.

Cosa faccio e cosa non faccio

Il mio ruolo è aiutare l’azienda a impostare il problema prima di delegarlo a uno strumento o a un fornitore. Posso supportare assessment, audit di casi d’uso, review vendor, RFP, requisiti funzionali, matrici dati-fonti, criteri di accettazione, KPI, controlli, workshop di governance e memo di readiness.

Non prometto ROI, certificazioni, vincita di gare, conformità automatica o risultati garantiti. Una buona governance AI non elimina il rischio. Lo rende osservabile, discutibile, documentabile e governabile. Questa è una differenza essenziale: non vendo certezza, costruisco condizioni di controllo.

La GDE è solo la mia esperienza o è qualcosa d’altro?

Questa è la domanda che un lettore tecnico, un CIO, un responsabile compliance o un consulente esterno dovrebbe porsi. La GDE non è semplicemente “la mia esperienza” raccontata con un nome. La mia esperienza è il punto di origine, perché un metodo nasce sempre da problemi reali osservati nel tempo. Ma la GDE è qualcosa di diverso: è una struttura logico-matematica che uso per obbligare ogni progetto a dichiarare perimetro, relazioni, dati, ipotesi, limiti, criteri di validazione e condizioni di blocco.

Non la tratto come una checklist. Le checklist sono utili, ma spesso confermano che alcuni campi sono stati compilati. La GDE lavora prima: prende dati e informazioni, li qualifica, li collega a ruoli e decisioni, separa ciò che è osservato da ciò che è dedotto, mette sotto controllo le ipotesi e stabilisce quando una conclusione non è autorizzata. Quando il caso lo richiede, questo processo può essere supportato da modelli matematici, procedure Python di calcolo o verifica, matrici di fonte, log di controllo e audit dell’elaborazione. Le procedure non sono il prodotto che vendo: sono strumenti di rigore, ripetibilità e verifica.

Detto in modo più vicino al linguaggio IT: non mi basta dire che un’applicazione AI “funziona”. Devo sapere quali input riceve, quali fonti usa, quali strumenti può attivare, quali output produce, quali log lascia, quali errori genera, quando chiama un umano e quale criterio permette di accettare o rifiutare il risultato. Detto in linguaggio strategico: non mi basta sapere che il caso d’uso è interessante. Devo capire quale decisione migliora, quale rischio introduce, quale funzione ne risponde e quale trade-off aziendale rende visibile.

Detto in linguaggio normativo e standard: la GDE non pretende di sostituire EU AI Act, ISO/IEC 42001, NIST AI RMF, procedure privacy, cybersecurity o audit interni. Serve invece a costruire il terreno su cui quei riferimenti possono lavorare. Se il caso d’uso non è definito, se le fonti non sono chiare, se i ruoli non sono assegnati, se i controlli non sono osservabili, anche il miglior standard rischia di diventare documentazione formale applicata a un oggetto poco leggibile.

Il nucleo tecnico è questo: ogni progetto viene letto come un sistema di decisioni distribuite. Le funzioni aziendali non sono “stakeholder” generici, ma punti di osservazione con dati, vincoli, incentivi e responsabilità diverse. Il metodo cerca le relazioni tra questi punti, separa ciò che è dato da ciò che è ipotesi, individua i punti ciechi, definisce controlli e produce una traccia riapribile. È qui che la GDE diventa più di una sensibilità consulenziale: diventa una disciplina di osservazione, progettazione e verifica.

Le zone grigie sono il nemico principale. In un ecosistema AI aziendale, una zona grigia può essere una fonte non qualificata, un owner non dichiarato, un output senza log, una metrica non collegata a una decisione, una responsabilità lasciata al vendor, una policy non tradotta in workflow, oppure un’eccezione che tutti conoscono ma nessuno registra. Sono proprio queste ambiguità a rendere difficili da intercettare molti malfunzionamenti delle piattaforme AI: non sempre l’errore appare come errore tecnico; spesso appare come decisione formalmente plausibile ma costruita su premesse non controllate.

L’obiettivo della GDE è ridurre queste ambiguità fino a un livello fisiologico: non eliminare ogni rischio, ma impedire che il rischio resti invisibile. Quando dati, ipotesi, controlli, owner e stop condition sono dichiarati, l’azienda può correggere prima, negoziare meglio con il vendor, evitare automazioni premature e ridurre la probabilità che errori nascosti diventino costi, ritardi, rilavorazioni, contenziosi o impatti economici difficili da attribuire.

Come riconosco un progetto AI impostato con GDE

Un progetto AI impostato con GDE non si riconosce dal lessico tecnico. Si riconosce dalle domande che obbliga a fare prima di partire e dai limiti che rende espliciti prima di promettere risultati.

• parte dal contesto aziendale, non dal tool;

• identifica funzioni coinvolte, owner, utenti e punti di controllo;

• separa dati osservati, proxy, ipotesi e informazioni non disponibili;

• dichiara cosa l’AI può fare, cosa non può fare e quando deve chiamare un umano;

• collega KPI locali e obiettivi aziendali;

• rende tracciabili fonti, log, requisiti, output e claim;

• prevede criteri di accettazione, escalation, incidenti e condizioni di stop;

• definisce requisiti per team tecnici, vendor e sviluppatori;

• lascia un audit riapribile nel tempo.

FAQ

Che cosa significa governance AI aziendale?

Significa definire prima del tool dati, ruoli, limiti, responsabilità, controlli e criteri di valutazione. L’AI non è solo una funzione tecnica: entra nel modo in cui l’azienda decide, comunica e lavora.

Che cos’è la GDE?

La GDE, Geometria Dinamica dell’Entropia, è il framework con cui leggo sistemi complessi come relazioni, vincoli, informazioni incomplete e decisioni distribuite. Nel contesto AI la uso per rendere casi d’uso, fonti, KPI, rischi e responsabilità più osservabili.

La GDE è una checklist?

No. Una checklist verifica la presenza di campi. La GDE costruisce il perimetro logico dell’analisi: dati, fonti, ipotesi, relazioni, controlli, regole di esclusione e criteri di stop. Le checklist possono entrare nel processo, ma non lo esauriscono.

La GDE è solo esperienza personale?

No. L’esperienza è il punto di origine, ma il metodo impone una struttura: perimetro, dati, ipotesi, ruoli, controlli, KPI, log, audit e condizioni di blocco. L’esperienza umana resta decisiva nella validazione finale, ma non sostituisce la struttura dell’analisi.

La GDE sostituisce EU AI Act, NIST AI RMF o ISO/IEC 42001?

No. La GDE non è una norma, una certificazione o un sistema di gestione sostitutivo. Aiuta a costruire il perimetro operativo su cui norme, standard, risk management e audit interni possono lavorare meglio.

La GDE serve solo prima di adottare AI?

No. Può servire prima di progettare un nuovo caso d’uso, ma anche dopo: per auditare chatbot, workflow, copilots, sistemi RAG, agenti, integrazioni vendor o automazioni già presenti, individuando zone grigie e migliorie operative.

La GDE sostituisce sviluppatori, vendor o software house?

No. Gli sviluppatori e i vendor costruiscono e integrano strumenti. Io posso supportare l’azienda nel definire requisiti, limiti, metriche, log, controlli e criteri di accettazione con cui quei soggetti devono lavorare.

La GDE può aiutare in gare, RFP e bandi?

Sì. Può aiutare a leggere requisiti, distinguere evidenze da ipotesi, costruire risposte più coerenti e ridurre promesse non sostenibili. Non garantisce aggiudicazioni o finanziamenti.

La GDE garantisce risultati, ROI o certificazioni?

No. La GDE non è una promessa di risultato. Serve a rendere esplicite condizioni, rischi, limiti e punti di controllo prima che un progetto AI entri nei processi aziendali o venga esteso.

Progettare, auditare, migliorare: il primo passo GDE

Il vero tema non è solo introdurre AI in azienda. Il vero tema è rendere osservabile il sistema che la usa. Questo vale prima della progettazione, quando bisogna decidere se partire, con quali dati e con quale vendor. Ma vale anche dopo, quando l’azienda ha già strumenti AI attivi: chatbot interni, copilots, workflow automatizzati, sistemi di ricerca documentale, RAG, agenti, modelli integrati in CRM, marketing, customer service o operations.

In questi casi la domanda non è “ripartiamo da zero?”. La domanda corretta è: che cosa sta già facendo l’AI, con quali fonti, con quali log, con quali controlli, con quali responsabilità e con quali effetti sui processi? Un audit GDE su un ecosistema già presente può evidenziare zone grigie, ridondanze, promesse non sostenute, dipendenze da vendor, assenza di stop condition, metriche deboli, processi da correggere e miglioramenti da introdurre senza distruggere ciò che funziona.

Con la GDE provo a fare il contrario della corsa cieca al tool: rallentare abbastanza da capire, per poi accelerare meglio. Prima il contesto, poi lo strumento. Prima i dati e i limiti, poi l’automazione. Prima le responsabilità, poi la delega. Prima la decisione umana, poi l’esecuzione assistita. E, quando l’AI è già stata introdotta, prima l’audit, poi il miglioramento.

Il primo passo può essere un audit GDE su un caso d’uso AI, una review vendor/RFP, un assessment di ecosistemi AI già attivi, un workshop di governance o un memo di readiness. L’obiettivo è sempre lo stesso: decidere se procedere, rimandare, correggere o bloccare un’applicazione AI sulla base di un perimetro leggibile.