Il titolare di una piccola impresa apre il gestionale il lunedì mattina. Sullo schermo compare una raccomandazione: ridurre gli acquisti del 15 per cento. Il sistema prevede una diminuzione della domanda nelle settimane successive.
La previsione sembra ragionevole. I grafici sono chiari, i numeri convincenti. Il responsabile degli acquisti approva.
Due settimane dopo, alcuni prodotti cominciano a mancare. I clienti ordinano, il magazzino non riesce a soddisfare le richieste. L’azienda perde vendite che avrebbe potuto realizzare.
Il fornitore del software spiega che il modello aveva elaborato correttamente i dati disponibili. Il responsabile degli acquisti sostiene di essersi affidato a una previsione attendibile. L’imprenditore vuole capire dove sia nato l’errore.
Ma scopre che nessuno ha conservato una documentazione sufficiente a ricostruire quella decisione.
È uno scenario ipotetico. Non serve però immaginare un’impresa particolarmente tecnologica perché il problema sia riconoscibile.
Bastano un gestionale evoluto, una previsione automatizzata e una decisione presa troppo rapidamente.
Il dato esiste. L’evidenza va costruita
In molte imprese i dati non mancano.
Ci sono fatture, ordini, previsioni, statistiche commerciali, informazioni sui clienti, rilevazioni delle presenze, consumi energetici e risultati delle campagne pubblicitarie.
La disponibilità di queste informazioni può generare una convinzione: se un sistema le analizza, la decisione che ne deriva sarà necessariamente fondata.
Non è così.
Un dato può essere autentico ma incompleto. Una previsione può essere matematicamente corretta rispetto agli input utilizzati e risultare comunque inadeguata alla situazione reale.
Un aumento delle vendite potrebbe dipendere da una circostanza eccezionale. Una diminuzione dei consumi potrebbe essere collegata a una chiusura temporanea. Una valutazione positiva potrebbe nascondere un campione troppo ristretto per rappresentare il comportamento della clientela.
Il punto non è mettere in discussione l’utilità degli algoritmi.
È riconoscere una differenza fondamentale: possedere informazioni non significa avere evidenze sufficienti per decidere.
Un’evidenza richiede che si possa conoscere la provenienza del dato, il contesto in cui è stato raccolto, le trasformazioni subite, i limiti della sua interpretazione e il rapporto con la conclusione proposta. [1]
È un lavoro che esisteva prima dell’intelligenza artificiale. L’automazione ne ha reso più evidenti le conseguenze.
Quando una previsione diventa un ordine
Immaginiamo un albergo di cinquanta camere.
Un sistema suggerisce di aumentare i prezzi perché prevede una crescita della domanda. La direzione accetta la raccomandazione e modifica le tariffe.
La previsione potrebbe essere corretta. Potrebbe anche basarsi su dati storici che non considerano la cancellazione di un evento locale, l’apertura di una nuova struttura concorrente o una modifica nei collegamenti ferroviari.
Il problema non è che il software possa sbagliare. Anche un direttore esperto può farlo.
La differenza emerge quando viene chiesto di spiegare la decisione.
Quali informazioni erano disponibili? Quanto erano aggiornate? Quali variabili sono state considerate? Il direttore aveva la possibilità effettiva di correggere la proposta? È rimasta traccia del suo intervento?
Senza queste risposte, il risultato economico può essere misurato, ma il percorso che lo ha generato resta difficile da ricostruire.
L’azienda sa quanto ha guadagnato o perso. Non necessariamente sa perché.
E ciò che non può essere ricostruito diventa più difficile da correggere.
La governance comincia prima del risultato
La parola governance viene spesso associata a strutture complesse, comitati, documenti e procedure che una piccola impresa considera lontani dalla propria operatività.
Eppure il principio può essere molto semplice.
Se un collaboratore prende una decisione importante, normalmente ci aspettiamo che sappia spiegare su quali elementi si è basato.
Perché non dovremmo aspettarci la stessa possibilità di verifica quando interviene un sistema di intelligenza artificiale?
Non significa pretendere che ogni algoritmo sia completamente interpretabile in ogni sua componente tecnica.
Significa almeno conoscere quali informazioni sono state utilizzate, che cosa ha prodotto il sistema, quali controlli sono stati effettuati e chi ha autorizzato l’azione. [2]
La presenza di un essere umano nella procedura non garantisce, da sola, un controllo significativo.
Se il responsabile può soltanto premere un pulsante per approvare una raccomandazione che non è in grado di valutare, la responsabilità formale rischia di allontanarsi dalla capacità reale di decidere.
Una governance efficace deve perciò rendere possibile anche il dissenso: individuare quando una raccomandazione è incerta, sospendere un’azione, richiedere ulteriori informazioni e registrare una motivazione diversa. [2]
Dalla conformità normativa alla capacità di dimostrare
Il regolamento europeo sull’intelligenza artificiale, noto come AI Act, ha introdotto un quadro di obblighi differenziati in base ai soggetti coinvolti e alle caratteristiche dei sistemi utilizzati.
Non ogni applicazione dell’IA nelle PMI è soggetta agli stessi requisiti. In particolare, gli obblighi più stringenti relativi alla gestione dei rischi, alla documentazione e alla supervisione umana riguardano specifiche categorie di sistemi ad alto rischio, secondo le condizioni previste dal regolamento. [3]
L’articolo 4 prevede inoltre misure per sostenere lo sviluppo delle competenze sull’IA nelle persone che operano con questi sistemi, tenendo conto delle loro conoscenze e del contesto di utilizzo. [4]
Ma c’è una questione che precede e supera la sola conformità.
Un’impresa dovrebbe volere decisioni ricostruibili anche quando non esiste un obbligo normativo specifico che imponga una determinata documentazione.
Per una ragione economica, prima ancora che giuridica.
Se una previsione produce un risultato negativo e non sappiamo quali ipotesi l’abbiano determinata, rischiamo di ripetere lo stesso errore.
Se invece possiamo individuare la fonte, il passaggio interpretativo e il momento dell’approvazione, possiamo correggere il processo.
La verificabilità non elimina l’incertezza. Consente di gestirla meglio.
Misurare ciò che sappiamo, dichiarare ciò che non sappiamo
È da questo problema che nasce una parte del lavoro che conduco con Cognitive Logic, attraverso il framework QEN, Quantificazione Etica Naturale, e la sua evoluzione QEN Sovereign.
L’obiettivo metodologico è collegare una valutazione alle evidenze che la sostengono, distinguendo i fatti documentati dalle interpretazioni, dalle informazioni mancanti e dalle responsabilità decisionali. [5]
Questo approccio non attribuisce automaticamente a un’informazione il carattere della verità.
Al contrario, richiede di dichiararne i limiti.
Una fonte pubblica verificabile non equivale a un’ipotesi formulata dall’analista. Un’informazione non disponibile non può essere trasformata arbitrariamente in un giudizio negativo. Una valutazione deve conservare il proprio contesto e la propria data di riferimento. [5]
In un processo strutturato, queste distinzioni possono essere documentate e rese consultabili.
Un esempio pratico riguarda la sostenibilità ambientale.
Un’impresa dichiara di avere ridotto i consumi energetici del 20 per cento.
Il dato può essere corretto. Ma rispetto a quale periodo? A parità di produzione? Con quali misurazioni? Sono cambiate le condizioni operative? La riduzione dipende da un intervento strutturale oppure da una diminuzione temporanea dell’attività?
La percentuale, isolata, comunica un risultato.
Le evidenze permettono di comprenderne il significato.
QEN Sovereign è un’infrastruttura metodologica e software in sviluppo e validazione. Non costituisce una certificazione automatica dei risultati né un sostituto del giudizio professionale o delle verifiche previste dalla normativa. La validazione scientifica indipendente del framework non è attualmente dichiarata come completata. [5]
È una distinzione necessaria: anche chi sviluppa strumenti di valutazione deve sottoporre le proprie affermazioni allo stesso principio di verificabilità che propone alle imprese.
Cinque domande prima di approvare
Una piccola impresa non deve necessariamente costruire un sistema complesso per cominciare.
Può introdurre un controllo essenziale, proporzionato all’importanza della decisione.
Prima di approvare una raccomandazione prodotta dall’intelligenza artificiale, l’imprenditore o il responsabile del processo può chiedersi: [6]
- Da dove arrivano i dati? Sono identificabili, aggiornati e pertinenti alla situazione da valutare?
- Che cosa è stato effettivamente verificato? Quali elementi sono documentati e quali restano ipotesi?
- Quali informazioni mancano? La loro assenza potrebbe modificare la conclusione?
- Chi autorizza la decisione? Questa persona dispone delle conoscenze e del tempo necessari per valutarla o contestarla?
- Potremo ricostruire il percorso in futuro? Sono conservati gli elementi indispensabili per comprendere e riesaminare la decisione?
Non tutte le scelte richiedono lo stesso livello di controllo.
L’acquisto di materiale di cancelleria non equivale alla selezione del personale, alla concessione di un finanziamento o a una decisione che incide significativamente sui diritti di una persona.
La documentazione deve essere proporzionata al rischio, all’impatto e alle caratteristiche del processo. [3]
Ma il principio resta valido: una decisione importante dovrebbe lasciare una traccia comprensibile.
L’imprenditore non deve diventare un programmatore
Nelle piccole imprese la conoscenza più importante spesso non si trova nei sistemi informatici.
È nell’esperienza di chi conosce i clienti, i fornitori, la stagionalità, le difficoltà dei dipendenti, le caratteristiche del territorio.
Questa conoscenza non deve essere contrapposta all’intelligenza artificiale.
Deve poter dialogare con essa.
Un algoritmo può individuare correlazioni difficili da riconoscere manualmente. Un responsabile esperto può conoscere circostanze che non figurano nel dataset. Una buona decisione può nascere dall’incontro fra queste due capacità, a condizione che sia possibile comprendere dove termina l’elaborazione automatica e dove comincia il giudizio umano.
Il vantaggio competitivo non consiste soltanto nel produrre una risposta più velocemente.
Consiste nel saper riconoscere quando quella risposta è abbastanza fondata da essere utilizzata.
E quando, invece, occorre fermarsi.
Torniamo all’imprenditore davanti al suo gestionale.
Il software suggerisce di ridurre gli acquisti del 15 per cento. Potrebbe avere ragione. La previsione potrebbe anche rivelarsi sbagliata.
La domanda che conta non è se una macchina possa sbagliare. È se l’azienda abbia conservato la capacità di riconoscere, spiegare e correggere le proprie decisioni.
Perché una decisione non diventa affidabile soltanto perché è stata calcolata. Diventa governabile quando possiamo ricostruire perché è stata presa.
Riferimenti
[1] Cognitive Logic, «Dal dato alla decisione» — https://cognitivelogic.it/brief/dal-dato-alla-decisione/ (approfondimento metodologico; non fonte normativa).
[2] NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), gennaio 2023 — https://doi.org/10.6028/NIST.AI.100-1 (principi di governance, trasparenza, controllo e gestione dei rischi).
[3] Parlamento europeo e Consiglio, Regolamento (UE) 2024/1689 (AI Act), articoli 6 e 9–15 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj (obblighi differenziati e disciplina dei sistemi ad alto rischio).
[4] Commissione europea, «AI Literacy — Questions & Answers», in riferimento all’articolo 4 dell’AI Act — https://digital-strategy.ec.europa.eu/en/faqs/ai-literacy-questions-answers.
[5] Cognitive Logic, «Programma di Validazione QEN» — https://cognitivelogic.it/validation.html (descrizione del framework e dei limiti della validazione, fonte dell’autore).
[6] Cognitive Logic, «QEN Case Studies» — https://cognitivelogic.it/case-studies/ (esempi e materiali metodologici sviluppati dall’autore; le cinque domande nell’articolo sono una sintesi redazionale, non uno standard).
Nota editoriale: le situazioni aziendali presentate nell’articolo sono scenari illustrativi, non casi di cronaca documentati. I richiami [1]–[6] distinguono fonti pubbliche, normativa e materiali prodotti dall’autore.
