Appendice C — Checklist pack con Question ID

Le checklist sono strumenti di indagine e verifica. Le 118 domande rendono esplicite condizioni che altrimenti resterebbero affidate all’intuizione del consulente; non sono un questionario da inviare senza facilitazione né una certificazione automatica. Ogni risposta richiede rationale, owner ed evidenza proporzionata.

Il practitioner seleziona gli item applicabili, registra N/A motivati, distingue implementazione e forza probatoria e usa i risultati per orientare deliverable, remediation e gate. Le domande proteggono da rischi specifici; le azioni tipiche sono esempi di remediation e vanno adattate al contesto.

Le 118 domande sono il nucleo di verifica dell’assessment. Per ogni item il consulente registra risposta, rationale, owner, Evidence ID, forza dell’evidenza, rischio, gate e remediation. La colonna ‘rischio’ descrive ciò che la domanda protegge; la colonna ‘azione’ indica una remediation tipica, da adattare al contesto.

[CHK01 - Human + AI Readiness]

CHK01 verifica se l’organizzazione può mobilitare responsabilmente un percorso Human + AI. Si usa prima di investire sul singolo caso e osserva priorità, sponsorship, owner, dati, capacità IT, guardrail, utenti, rischio, misura, service management e apprendimento.

Scopo	Gate	Output	Uso
Valutare se l’organizzazione può mobilitare il percorso	[G00]	[DLV09], [DLV01]	Porre le domande su casi ed evidenze reali; non accettare promesse future come implementazione.

Question ID	Domanda	Evidenza richiesta	Rischio protetto	Azione tipica
[CHK01-Q01]	Esiste una priorità aziendale concreta che giustifica l’introduzione dell’AI?	Piano, obiettivo, problema o KPI collegato a valore, rischio, servizio o capacità.	Il programma nasce come ricerca di tool e non come trasformazione finalizzata.	Formalizzare 2-3 capability prioritarie e il relativo outcome atteso.
[CHK01-Q02]	Esiste un executive sponsor disposto a sostenere decisioni, priorità e cambiamenti organizzativi?	Nome, ruolo, mandato e disponibilità per gate e review.	Il programma resta confinato all’IT o a singoli sperimentatori.	Nominare sponsor e decision rights prima dell’assessment.
[CHK01-Q03]	Sono identificati Business Owner, Process Owner e IT Owner per i casi pilota?	RACI preliminare e responsabilità su valore, processo ed esercizio.	Nessuno risponde dell’esito end-to-end.	Assegnare le tre accountability, anche se alcuni ruoli coincidono.
[CHK01-Q04]	L’organizzazione possiede una mappa almeno essenziale dei processi e delle decisioni critiche?	Process inventory, procedure, BPM, RACI o workshop di ricostruzione.	Le opportunità vengono selezionate per visibilità e non per impatto.	Creare un inventario leggero di processi, volumi, owner e pain point.
[CHK01-Q05]	Esistono dati e conoscenze accessibili per avviare assessment e pilot?	ERP, DWH, documenti, database, procedure, storico e owner delle fonti.	Il pilot parte con data debt non stimato.	Produrre un data and knowledge inventory preliminare.
[CHK01-Q06]	Sono definiti principi minimi per sicurezza, privacy, riservatezza e uso accettabile dell’AI?	Policy, classificazione dati, accessi, vincoli cloud/on-premise e approvazioni.	Dati e tool vengono usati senza un perimetro autorizzato.	Adottare guardrail minimi prima di coinvolgere dati reali.
[CHK01-Q07]	L’IT è in grado di integrare, monitorare e supportare almeno un pilot circoscritto?	Competenze, ambienti, API, logging, support owner e capacità di rollback.	La demo non può diventare servizio operativo.	Definire un pilot architecture boundary e un support model minimo.
[CHK01-Q08]	Gli utenti chiave possono partecipare a discovery, validazione e feedback?	Disponibilità nominativa, calendario workshop e ruolo nella validazione.	Il sistema replica un processo teorico e non il lavoro reale.	Riservare tempo agli utenti esperti e formalizzare il loro ruolo.
[CHK01-Q09]	Esiste una tolleranza al rischio coerente con il livello di autonomia previsto?	Risk appetite, azioni vietate, limiti economici e reputazionali.	L’autonomia viene decisa implicitamente dal design tecnico.	Definire decisioni assistite, approvate e vietate per il pilot.
[CHK01-Q10]	L’organizzazione sa misurare baseline e risultati dei processi candidati?	KPI disponibili, fonti, frequenza e responsabile della misura.	Il successo resta narrativo e non confrontabile.	Selezionare pochi KPI misurabili e raccogliere una baseline.
[CHK01-Q11]	Esiste un meccanismo per gestire change, incidenti e problemi dei servizi digitali?	Ticketing, canale di supporto, change log, incident owner e review.	Modifiche ed errori restano invisibili o fuori processo.	Definire un Minimum Viable AI Service Management.
[CHK01-Q12]	L’organizzazione è in grado di trattenere e riusare ciò che il pilot apprende?	Knowledge base, decision log, owner della Corporate Memory e write-back loop.	Correzioni ed eccezioni vengono perse dopo il pilot.	Definire oggetti di memoria, owner, validazione e revisione.

[CHK02 - Opportunity]

CHK02 confronta processi e use case candidati. Aiuta a evitare la selezione del caso più visibile o tecnologicamente attraente, valutando impatto, frequenza, componente cognitiva, dati, verificabilità, reversibilità, owner, tempo di pilot, valore e riuso.

Scopo	Gate	Output	Uso
Confrontare i processi candidati e la praticabilità del pilot	[G01]	[DLV01], [DLV02]	Porre le domande su casi ed evidenze reali; non accettare promesse future come implementazione.

Question ID	Domanda	Evidenza richiesta	Rischio protetto	Azione tipica
[CHK02-Q01]	Il processo ha un impatto chiaro su costi, ricavi, tempi, qualità, rischio o servizio al cliente?	KPI esistenti, stime economiche, volumi, tempi medi, errori o esempi reali.	Si investe su un’attività marginale o senza sponsor economico.	Quantificare almeno un outcome prioritario e una baseline.
[CHK02-Q02]	Il processo è ripetitivo o ricorrente abbastanza da giustificare un investimento AI?	Numero di pratiche, ordini, richieste, ticket, documenti o decisioni per periodo.	Il costo di progettazione supera il valore ottenibile.	Calcolare frequenza, volumi e potenziale di riuso.
[CHK02-Q03]	Il processo richiede molte attività cognitive manuali?	Lettura, confronto, classificazione, analisi, controlli, sintesi o ricerca.	L’AI aggiunge poco rispetto a una normale automazione deterministica.	Separare task cognitivi, operativi e puramente procedurali.
[CHK02-Q04]	Il processo contiene decisioni o raccomandazioni che dipendono dall’esperienza individuale?	Esempi di giudizio esperto, criteri impliciti, eccezioni e differenze tra operatori.	La conoscenza tacita resta invisibile e non replicabile.	Condurre decision walkthrough e raccogliere casi limite.
[CHK02-Q05]	Esistono dati, documenti o conoscenze utilizzabili come input?	ERP, DWH, documentale, email, file, database, knowledge base e storico.	Il pilot parte con data debt elevato.	Creare un data and knowledge inventory e stimare la remediation.
[CHK02-Q06]	Il processo produce output verificabili da un umano?	Dossier, ordine, proposta, classificazione, quotazione, report o piano.	Non è possibile verificare qualità, fiducia o miglioramento.	Definire output osservabili, acceptance criteria e reviewer.
[CHK02-Q07]	È possibile mantenere human-in-the-loop nelle prime fasi?	Owner, validatori, approvatori, utenti chiave e punti di controllo.	Il pilot produce rischi decisionali o viene percepito come sostituzione incontrollata.	Progettare validation, approval ed escalation point.
[CHK02-Q08]	Gli errori dell’AI sarebbero correggibili prima di generare impatti gravi?	Autorizzazioni, reversibilità, sandbox, draft mode, rollback o blocchi.	Un errore diventa subito economico, legale o reputazionale.	Limitare autonomia e introdurre guardrail e rollback.
[CHK02-Q09]	Il processo è abbastanza stabile da essere ridisegnato?	Procedura, workflow, stati, ruoli, trigger, output ed eccezioni ricorrenti.	Si automatizza un processo instabile o non compreso.	Eseguire process discovery e redesign prima del pilot.
[CHK02-Q10]	Esiste un Business Owner disposto a sponsorizzare il caso?	Owner nominato, responsabilità sui KPI e disponibilità a workshop e validazione.	Il progetto resta IT-driven e non viene adottato.	Nominare un Business Owner con KPI e decision rights.
[CHK02-Q11]	Esiste un IT Owner per integrazione, sicurezza e supporto?	CIO/IT, system owner, architettura, sistemi e capacità di esercizio.	Il prototipo non può essere integrato o supportato.	Nominare IT Owner e verificare support model e change.
[CHK02-Q12]	Il caso può essere realizzato come pilot circoscritto in poche settimane?	Perimetro MVP, dati minimi, utenti pilota e dipendenze gestibili.	Il progetto diventa plurimensile prima di produrre evidenza.	Definire pilot boundary, durata, utenti e dati minimi.
[CHK02-Q13]	Il valore può essere misurato con baseline e KPI semplici?	Tempo medio, errori, accuracy, stock, lead time, conversione, qualità o backlog.	Non è possibile dimostrare valore né decidere se scalare.	Definire baseline, target, frequenza e success criteria.
[CHK02-Q14]	Il caso può alimentare la Corporate Memory?	Decisioni, correzioni, eccezioni, feedback, razionali, fonti ed esiti.	L’azienda automatizza ma non apprende.	Definire memory object, owner, validation e write-back.
[CHK02-Q15]	Il caso è rappresentativo di altri processi o pattern replicabili?	Processi simili, funzioni analoghe, dati condivisi e componenti riutilizzabili.	Il risultato resta isolato e non costruisce capability.	Identificare componenti, pattern e governance riusabili.

[CHK03 - Decision]

CHK03 analizza le decision unit emerse dall’AS-IS. Per ogni decisione chiarisce trigger, outcome, frequenza, impatto, owner, informazioni, regole, eccezioni, spiegabilità, supervisione, errori, autonomia e write-back.

Scopo	Gate	Output	Uso
Analizzare le decision unit emerse dall’AS-IS	[G02], [G03]	[DLV03]	Porre le domande su casi ed evidenze reali; non accettare promesse future come implementazione.

Question ID	Domanda	Evidenza richiesta	Rischio protetto	Azione tipica
[CHK03-Q01]	La decisione è formulata in modo preciso e collegata a un outcome?	Nome decisione, trigger, risultato, destinatario e KPI.	Il sistema automatizza attività senza sapere quale scelta deve migliorare.	Scrivere la decision statement e collegarla all’outcome.
[CHK03-Q02]	Frequenza, impatto e reversibilità della decisione sono noti?	Volumi, valore economico, severità, tempo e possibilità di annullamento.	Autonomia e controlli risultano sproporzionati.	Classificare frequenza, impatto e reversibilità.
[CHK03-Q03]	Sono chiari accountable, decisore, approvatore e soggetti consultati?	Decision rights map o RACI/RASCI.	La responsabilità si dissolve tra umano, sistema e funzione.	Formalizzare decision rights e contestazione.
[CHK03-Q04]	Sono identificate le informazioni necessarie e la loro provenienza?	Dati, documenti, regole, precedenti, owner, versioni e qualità.	La raccomandazione non è spiegabile o usa fonti non affidabili.	Creare evidence requirements e fonte autorevole.
[CHK03-Q05]	Regole, soglie e policy applicabili sono esplicite?	Policy, criteri, calcoli, limiti, priorità e divieti.	Il ruolo digitale applica criteri impliciti o incoerenti.	Formalizzare regole e ordinare le priorità.
[CHK03-Q06]	Eccezioni, conflitti e casi limite sono conosciuti?	Esempi reali, incidenti, override, eccezioni e motivazioni.	Il pilot funziona solo sull’happy path.	Costruire un exception catalogue e criteri di escalation.
[CHK03-Q07]	La decisione dipende da conoscenza tacita o da persone chiave?	Interviste, casi comparati e key-person memory assessment.	Il sistema replica dati ma non il giudizio reale.	Acquisire razionali e precedenti nella Corporate Memory.
[CHK03-Q08]	L’output della decisione è osservabile e verificabile?	Decision record, proposta, azione, motivazione e criterio di accettazione.	Non è possibile misurare qualità o errore.	Definire output, reviewer e acceptance criteria.
[CHK03-Q09]	Il ruolo digitale deve citare fonti, versione e livello di confidenza?	Requisiti di spiegabilità business-first e audit.	Gli utenti non possono valutare la raccomandazione.	Definire evidence pack minimo per ogni decisione.
[CHK03-Q10]	Sono stabiliti i punti di validazione umana?	Approval point, sampling, override ed escalation.	La supervisione è nominale o arriva troppo tardi.	Progettare human-in/on-the-loop per evento e rischio.
[CHK03-Q11]	Sono definiti errori accettabili, vietati e recovery path?	Error taxonomy, soglie, blocchi, fallback e rollback.	Un errore noto produce conseguenze non controllate.	Stabilire risk boundaries e recovery.
[CHK03-Q12]	Il livello di autonomia iniziale è deciso per questa specifica decisione?	Livello 0-4, soglie, condizioni e gate di aumento.	L’agente riceve un’autonomia generale non calibrata.	Assegnare autonomia per decisione e definire review gate.
[CHK03-Q13]	Decisione, razionale, eccezioni ed esito alimentano la Corporate Memory?	Decision memory schema e write-back workflow.	Le correzioni non migliorano la decisione successiva.	Definire oggetti, owner e validazione del write-back.

[CHK04 - Process]

CHK04 verifica che il processo reale e quello target siano sufficientemente compresi. Confini, baseline, varianti, handoff, eccezioni, fallback, dati, integrazioni e criteri di accettazione devono rendere il pilot eseguibile e osservabile.

Scopo	Gate	Output	Uso
Verificare AS-IS, target process, eccezioni e pilot boundary	[G01], [G02]	[DLV02]	Porre le domande su casi ed evidenze reali; non accettare promesse future come implementazione.

Question ID	Domanda	Evidenza richiesta	Rischio protetto	Azione tipica
[CHK04-Q01]	Trigger, confini ed end state del processo sono espliciti?	Process statement, input, output, start/end e clienti del processo.	Il perimetro del pilot si espande senza controllo.	Formalizzare process boundary e definition of done.
[CHK04-Q02]	Esistono baseline su volumi, tempi, errori, rilavorazioni e costi?	KPI, log, campioni, tempi medi e backlog.	Il redesign non può dimostrare miglioramento.	Misurare una baseline minima prima del pilot.
[CHK04-Q03]	Il processo è sufficientemente stabile e le varianti principali sono note?	Workflow, versioni, casi tipo, deviazioni ed eccezioni.	Si automatizza una prassi instabile o contraddittoria.	Eseguire discovery e consolidare varianti.
[CHK04-Q04]	Sono identificati passaggi eliminabili, accorpabili o parallelizzabili?	Analisi 5D e motivazione dei passaggi AS-IS.	L’AI rende più veloce un processo inutilmente complesso.	Applicare Delete, Delegate, Decide, Digitize, Do with AI.
[CHK04-Q05]	Le decisioni critiche sono collocate nel punto corretto del flusso?	Decision map collegata a task, input e output.	Le informazioni arrivano tardi o le decisioni vengono duplicate.	Ridisegnare sequenza e disponibilità delle evidenze.
[CHK04-Q06]	Ruoli, handoff e separazione dei compiti sono chiari?	Swimlane, RACI, code, SLA e responsabilità.	Attese e responsabilità ambigue restano invisibili.	Ridurre handoff e formalizzare accountability.
[CHK04-Q07]	Eccezioni, fallback e recovery sono disegnati oltre all’happy path?	Exception catalogue, percorsi alternativi e owner.	Il pilot si blocca nei casi reali più importanti.	Disegnare exception flow e fallback umano.
[CHK04-Q08]	Dati e conoscenza sono disponibili nel momento della decisione?	Mappa input, latenza, freshness, accessi e fonti.	Il ruolo digitale decide con contesto incompleto o obsoleto.	Anticipare retrieval e controlli di validità.
[CHK04-Q09]	I punti human-in/on-the-loop sono proporzionati al rischio?	Approval, review, sampling, override e escalation.	Controlli eccessivi annullano il valore o controlli deboli aumentano il rischio.	Calibrare supervisione per impatto e reversibilità.
[CHK04-Q10]	Sistemi, API e transazioni necessarie sono identificati?	Integration map, permessi, eventi, error handling e idempotenza.	Il processo target non è tecnicamente esercibile.	Definire integrazioni minime e modalità di recovery.
[CHK04-Q11]	Il processo acquisisce e recupera Corporate Memory senza lavoro parallelo inutile?	Capture event, retrieval point, write-back e owner.	L’apprendimento richiede documentazione separata e non avviene.	Integrare capture e retrieval negli eventi di lavoro.
[CHK04-Q12]	Esistono criteri di accettazione del processo target e rollback?	Scenario test, KPI, pilot boundary, fallback e stop criteria.	Il go-live avviene senza una definizione condivisa di successo.	Definire acceptance, pilot exit e rollback.

[CHK05 - Data & Corporate Memory]

CHK05 valuta dati e Corporate Memory lungo l’intero lifecycle: fonti, qualità, provenienza, accessi, retention, oggetti di memoria, validazione, retrieval, write-back, dipendenze da persone chiave, sovranità e portabilità.

Scopo	Gate	Output	Uso
Verificare fonti, qualità, provenienza, accesso e memory lifecycle	[G02], [G03]	[DLV05]	Porre le domande su casi ed evidenze reali; non accettare promesse future come implementazione.

Question ID	Domanda	Evidenza richiesta	Rischio protetto	Azione tipica
[CHK05-Q01]	Fonti dati, documenti e conoscenze necessarie sono inventariate?	Source inventory con sistema, contenuto, formato, owner e utilizzo.	Fonti critiche emergono tardi o restano fuori dal pilot.	Creare un inventario per decisione e processo.
[CHK05-Q02]	Ogni fonte ha un owner responsabile di qualità e accesso?	Nome, ruolo, responsabilità, contatto e decision rights.	Errori e accessi non hanno un responsabile.	Assegnare Data/Content Owner e regole di escalation.
[CHK05-Q03]	Qualità, completezza e coerenza sono misurate su campioni reali?	Profiling, errori, missing, duplicati, riconciliazione e remediation.	Il modello compensa o amplifica difetti non noti.	Eseguire data quality assessment e fissare soglie.
[CHK05-Q04]	Semantica, definizioni e unità di misura sono condivise?	Glossario, data dictionary, tassonomie e mapping.	Persone e AI interpretano lo stesso campo in modi diversi.	Consolidare definizioni e fonti autorevoli.
[CHK05-Q05]	Accessi e permessi rispettano minimo privilegio e finalità?	Ruoli, gruppi, policy, audit e segregazione.	Il ruolo digitale vede o usa informazioni fuori mandato.	Definire capability e filtri per ruolo e contesto.
[CHK05-Q06]	Dati e memoria sono classificati per sensibilità e vincoli?	Classificazione, privacy, riservatezza, retention e localizzazione.	Architettura e condivisione violano vincoli aziendali o legali.	Applicare classificazione e autorizzazioni prima dell’ingestion.
[CHK05-Q07]	Freshness, latenza e periodo di validità sono adeguati alla decisione?	Timestamp, SLA aggiornamento, scadenze e warning.	Decisioni corrette su dati obsoleti diventano operativamente errate.	Definire freshness requirement e blocchi/warning.
[CHK05-Q08]	Provenienza, versione e trasformazioni sono ricostruibili?	Lineage, source reference, versioning, log e data pipeline.	Non è possibile spiegare o riprodurre un output.	Conservare lineage ed evidence reference.
[CHK05-Q09]	Il retrieval restituisce contenuti pertinenti, autorizzati e citabili?	Test set, precision/recall utile, filtri, citazioni e fallback.	Il RAG recupera contenuti plausibili ma non applicabili.	Testare retrieval per scenario e validità.
[CHK05-Q10]	Sono definiti gli oggetti della Corporate Memory?	Schema per fonti, decisioni, razionali, regole, eccezioni, esiti e relazioni.	La memoria resta un archivio non operativo.	Definire memory object e metadati obbligatori.
[CHK05-Q11]	Proposta, validazione, pubblicazione e ritiro della conoscenza sono separati?	Workflow, stati, owner, confidence e change log.	Feedback grezzo diventa verità operativa.	Implementare lifecycle evidence → proposed → validated → operational → retired.
[CHK05-Q12]	Retention, obsolescenza e diritto all’oblio operativo sono gestiti?	Scadenze, review date, ritiro, sostituzione e cancellazione.	La memoria diventa rumorosa, contraddittoria o non conforme.	Definire retention e review periodiche.
[CHK05-Q13]	La dipendenza da persone chiave è stata misurata?	Key-person memory map, decisioni critiche e tempo di ricostruzione.	La perdita di una persona interrompe capacità operative.	Prioritizzare capture e validazione delle conoscenze concentrate.
[CHK05-Q14]	Sovranità, portabilità e architettura della memoria sono coerenti con il valore del know-how?	Scelta cloud/ibrida/on-premise, export, backup, portabilità e controllo.	Il DNA operativo dell’impresa dipende da piattaforme non controllate.	Definire memory sovereignty requirements e exit plan.

[CHK06 - Digital Role]

CHK06 trasforma una capacità AI in un Digital Role organizzativo. Verifica purpose, input/output, strumenti, permessi, limiti, negative requirements, autonomia, supervisione, KPI, owner, change e memory authority.

Scopo	Gate	Output	Uso
Verificare mandato, autonomia, limiti e accountability	[G02], [G03]	[DLV04]	Porre le domande su casi ed evidenze reali; non accettare promesse future come implementazione.

Question ID	Domanda	Evidenza richiesta	Rischio protetto	Azione tipica
[CHK06-Q01]	Purpose e outcome del ruolo digitale sono definiti?	Mandato, beneficiario, risultato e KPI collegati.	Il ruolo diventa una collezione di funzioni senza responsabilità.	Scrivere purpose e outcome in una frase verificabile.
[CHK06-Q02]	Perimetro, esclusioni e attività vietate sono espliciti?	In-scope, out-of-scope, divieti e confini organizzativi.	L’agente espande implicitamente il proprio mandato.	Formalizzare confini e negative requirements.
[CHK06-Q03]	Task e decisioni assegnati al ruolo sono collegati al processo target?	Process blueprint e decision map con responsabilità.	Il digital role duplica o confligge con ruoli esistenti.	Mappare ogni capacità a task e decisione.
[CHK06-Q04]	Input, fonti e Corporate Memory utilizzabili sono autorizzati?	Source list, permessi, freshness e provenance requirements.	Il ruolo usa contesto incompleto o fuori mandato.	Definire input contract e accessi minimi.
[CHK06-Q05]	Output e azioni possibili sono definiti e verificabili?	Output schema, destinatario, action list e acceptance criteria.	Non è chiaro cosa il ruolo produce o modifica.	Formalizzare output/action contract.
[CHK06-Q06]	Tool, sistemi e permessi sono limitati al minimo necessario?	API, capability, ruoli applicativi, limiti e segregazione.	Una failure del modello si trasforma in azione eccessiva.	Applicare least privilege e tool allowlist.
[CHK06-Q07]	Il livello di autonomia è assegnato per decisione e azione?	Autonomy matrix 0-4, soglie e condizioni.	Autonomia generica e non proporzionata al rischio.	Calibrare autonomia per impatto e reversibilità.
[CHK06-Q08]	Esiste un accountable umano e un supervisore operativo?	Owner, reviewer, sostituto e disponibilità.	L’AI viene trattata come responsabile dell’esito.	Nominare accountable e supervisor.
[CHK06-Q09]	Validazione e human-in/on-the-loop sono progettati?	Approval, sampling, override, queue ed escalation.	La supervisione è tardiva o non sostenibile.	Definire punti, frequenza e capacità di review.
[CHK06-Q10]	Errori accettabili, vietati e blocchi preventivi sono espliciti?	Error taxonomy, guardrail, threshold e stop condition.	Il pilot scopre i confini solo dopo un incidente.	Definire risk boundary e test negativi.
[CHK06-Q11]	Escalation e fallback indicano quando fermarsi e a chi rivolgersi?	Trigger, destinatario, evidence pack, SLA e fallback.	Il ruolo insiste, improvvisa o blocca il processo.	Formalizzare escalation contract.
[CHK06-Q12]	Spiegabilità, citazioni e audit trail sono adeguati al contesto?	Reason code, fonti, confidenza, log e decision record.	Utenti e audit non possono contestare o ricostruire l’output.	Definire explanation requirements business-first.
[CHK06-Q13]	KPI misurano outcome, qualità, rischio, costo e adozione?	Scorecard, baseline, target, owner e frequenza.	Il ruolo viene valutato per task prodotti e non per valore.	Selezionare KPI bilanciati e stop criteria.
[CHK06-Q14]	Change e learning stabiliscono chi può modificare ruolo, regole, strumenti e memoria?	Change authority, versioning, test, review e write-back.	Il comportamento cambia senza controllo o apprendimento tracciato.	Definire change model e memory authority.

[CHK07 - Governance & Trust]

CHK07 rende verificabili governance e fiducia. Collega rischi, controlli, accountability, audit, sicurezza, privacy, trasparenza, contestazione, incidenti, review periodiche e decisioni di limitazione o stop.

Scopo	Gate	Output	Uso
Verificare rischi, controlli, audit e decision rights	[G03], [G04]	[DLV06], [DLV08]	Porre le domande su casi ed evidenze reali; non accettare promesse future come implementazione.

Question ID	Domanda	Evidenza richiesta	Rischio protetto	Azione tipica
[CHK07-Q01]	Il caso è registrato con scopo, utenti, owner, decisioni e perimetro?	Use-case record o service card approvata.	L’organizzazione non sa quali sistemi AI sono in uso e perché.	Creare registro e assegnare owner.
[CHK07-Q02]	Accountability business, tecnica, dati/memoria e supervisione sono assegnate?	RACI/RASCI e decision rights.	Controlli ed escalation non hanno responsabili.	Formalizzare accountability end-to-end.
[CHK07-Q03]	Rischi e tolleranze sono valutati per impatto e reversibilità?	Risk assessment, severity, likelihood, tolerance e residual risk.	I controlli sono standard e non proporzionati al caso.	Costruire risk-control-autonomy matrix.
[CHK07-Q04]	Dati e Corporate Memory sono governati per accesso, qualità, provenienza e lifecycle?	Owner, policy, versioni, permessi, retention e validazione.	Output affidabili vengono costruiti su conoscenza non governata.	Integrare Data & Memory governance nel pilot.
[CHK07-Q05]	Accessi, tool e azioni rispettano minimo privilegio e separazione dei compiti?	Ruoli, capability, allowlist, approval e segregazione.	Il ruolo digitale può eccedere il mandato o auto-approvarsi.	Ridurre permessi e separare proposta, approvazione ed esecuzione.
[CHK07-Q06]	Validazione e approvazione umana sono sostenibili per volumi e tempi?	Queue, reviewer capacity, SLA, sampling e fallback.	Human-in-the-loop esiste solo formalmente.	Dimensionare la supervisione e automatizzare controlli non decisionali.
[CHK07-Q07]	L’autonomia è vincolata da soglie e gate di progressione?	Autonomy level, threshold, evidence, review e rollback.	L’autonomia cresce senza evidenze o autorizzazione.	Definire autonomy readiness gate.
[CHK07-Q08]	Decisioni, fonti, output e azioni sono tracciati in modo ricostruibile?	Audit log, decision record, model/prompt/source version e timestamp.	Non è possibile spiegare incidenti o contestazioni.	Definire audit trail minimo e retention.
[CHK07-Q09]	Modifiche a modelli, prompt, regole, fonti, tool e autonomia sono governate?	Change request, test, approvazione, versione e rollback.	Il comportamento cambia senza controllo.	Adottare AI change model e configuration baseline.
[CHK07-Q10]	Incidenti ed errori ricorrenti hanno canale, priorità, owner e problem review?	Incident/problem procedure, severity, workaround e root cause.	Gli utenti correggono fuori processo e gli errori si ripetono.	Integrare incident e problem management.
[CHK07-Q11]	Fallback, rollback e continuità del processo sono testati?	Manual fallback, backup, recovery scenario e test evidence.	Un guasto AI interrompe il processo essenziale.	Eseguire test di failure e business continuity.
[CHK07-Q12]	Performance, drift, qualità, costi e rischio sono monitorati?	Dashboard, alert, review threshold e owner.	Il servizio degrada senza essere rilevato.	Definire monitoring e review trigger.
[CHK07-Q13]	Utenti e stakeholder ricevono istruzioni su capacità, limiti e contestazione?	Training, disclosure, help, feedback e appeal channel.	Overtrust, undertrust e uso fuori perimetro.	Creare user guidance e feedback loop.
[CHK07-Q14]	Esiste una review periodica con decisione scale, revise, restrict o stop?	Review calendar, scorecard, risk acceptance e decision log.	Il pilot resta indefinitamente in esercizio senza riesame.	Istituire governance review e stop authority.

[CHK08 - AI Service Readiness]

CHK08 verifica la readiness minima del servizio AI: ownership, supporto, incident, problem, change, release, monitoring, continuità, capacità, miglioramento e retirement. ITIL01 resta un mapping opzionale.

Scopo	Gate	Output	Uso
Verificare operabilità minima; [ITIL01] resta profilo separato	[G03], [G04]	[DLV06]	Porre le domande su casi ed evidenze reali; non accettare promesse future come implementazione.

Question ID	Domanda	Evidenza richiesta	Rischio protetto	Azione tipica
[CHK08-Q01]	Il servizio AI è descritto in un catalogo o in una service card?	Nome, scopo, utenti, owner, limiti, dipendenze e KPI.	Il servizio resta una demo non riconoscibile o governata.	Creare AI Service Card e catalog entry.
[CHK08-Q02]	Business Owner e IT/Service Owner sono identificati?	Nomi, ruoli e responsabilità formalizzate.	Valore, esercizio e priorità non hanno accountability.	Nominare entrambi gli owner e definire escalation.
[CHK08-Q03]	Utenti, perimetro, accessi e livelli di servizio sono chiari?	Gruppi, autorizzazioni, orari, criticità e aspettative di servizio.	Uso fuori perimetro e aspettative non gestite.	Definire utenti, access model e service expectation.
[CHK08-Q04]	Esiste un canale di supporto e una procedura di escalation?	Service desk, queue, categorie, owner e SLA operativi.	Gli utenti aggirano il servizio o contattano direttamente gli sviluppatori.	Integrare il servizio nel support model.
[CHK08-Q05]	Le modifiche possono essere richieste, valutate e approvate?	Change channel, classificazione, approvatore e calendario.	Prompt, modelli e regole cambiano senza controllo.	Definire AI change enablement minimo.
[CHK08-Q06]	Versioni di modelli, prompt, fonti, regole, tool e autonomia sono tracciate?	Configuration baseline, version log, test e rollback.	Non è possibile spiegare perché il comportamento è cambiato.	Adottare versioning e configuration record.
[CHK08-Q07]	È chiaro cosa costituisce un AI incident e come segnalarlo?	Incident taxonomy, severità, canale, contenimento e comunicazione.	Output errati vengono corretti informalmente.	Definire incident model e playbook.
[CHK08-Q08]	Gli errori ricorrenti vengono analizzati come AI problem?	Problem record, root cause, workaround e known error.	Gli stessi errori si ripetono e non generano apprendimento.	Introdurre problem review per pattern ricorrenti.
[CHK08-Q09]	Knowledge management e Corporate Memory sono collegati?	Knowledge article, decision memory, owner, validazione e write-back.	La correzione resta nel ticket e non migliora il servizio.	Collegare incident/problem a memory update.
[CHK08-Q10]	Monitoraggio e reporting coprono qualità, utilizzo, disponibilità, rischio e costi?	Dashboard, eventi, KPI e review owner.	Il servizio è gestito soltanto quando qualcuno segnala un problema.	Definire monitoring e service report.
[CHK08-Q11]	Esiste un backlog di continual improvement alimentato da KPI, feedback e incidenti?	Improvement register, priorità, owner e decisioni.	Il servizio rimane fermo dopo il pilot.	Istituire continual improvement register.
[CHK08-Q12]	Ritiro, sostituzione o sospensione del servizio sono governati?	Exit criteria, comunicazione, conservazione dati/memoria e decommission plan.	Servizi obsoleti restano accessibili o dipendenze vengono perse.	Definire service retirement e knowledge preservation.

[CHK09 - Value]

CHK09 verifica che il valore sia misurabile e decisionale. Baseline, target, formule, fonti, attribuzione, qualità, rischio, adozione, servizio, TCO e regole scale/revise/restrict/stop devono essere definite prima di interpretare il pilot.

Scopo	Gate	Output	Uso
Verificare baseline, KPI, attribuzione e criteri di scala	[G03], [G05]	[DLV07], [DLV08]	Porre le domande su casi ed evidenze reali; non accettare promesse future come implementazione.

Question ID	Domanda	Evidenza richiesta	Rischio protetto	Azione tipica
[CHK09-Q01]	La value hypothesis collega il caso a un outcome aziendale prioritario?	Value statement, beneficiario, meccanismo causale e sponsor.	Si misurano output tecnici senza sapere perché contano.	Scrivere value hypothesis e collegarla al business outcome.
[CHK09-Q02]	Esiste una baseline affidabile prima dell’introduzione dell’AI?	Periodo, fonte, formula, campione e owner.	Il miglioramento non è dimostrabile.	Raccogliere baseline o definire gruppo/scenario di confronto.
[CHK09-Q03]	Sono selezionati pochi KPI di outcome business?	Ricavi, margine, costi, servizio, qualità o rischio evitato.	Il pilot ottimizza task locali senza valore complessivo.	Selezionare 1-3 outcome KPI prioritari.
[CHK09-Q04]	Sono misurati KPI di processo?	Lead time, touch time, rilavorazioni, backlog, eccezioni e produttività.	Non si comprende dove nasce il beneficio.	Definire metriche di flusso end-to-end.
[CHK09-Q05]	La qualità delle decisioni è osservabile?	Accuracy utile, coerenza, override, motivazioni e outcome successivi.	Velocità e automazione mascherano decisioni peggiori.	Definire decision quality e review sample.
[CHK09-Q06]	Rischio e affidabilità sono inclusi nella scorecard?	Incidenti, severità, false action, recovery time e residual risk.	Il valore economico ignora costi e impatti degli errori.	Integrare KPI di rischio e trust calibration.
[CHK09-Q07]	Adozione e comportamento degli utenti sono misurati?	Usage, completion, override, feedback, training e abbandono.	Il sistema sembra efficace ma non viene usato correttamente.	Definire adoption metrics e user research.
[CHK09-Q08]	Il costo totale include tecnologia, integrazione, supervisione, change ed esercizio?	TCO, cost per decision, support, licenze, infrastruttura e lavoro umano.	Il business case sottostima i costi reali.	Costruire TCO e costo per outcome/decisione.
[CHK09-Q09]	Il valore della Corporate Memory è misurato?	Memory reuse, freshness, time-to-context, memory debt e key-person risk.	L’apprendimento trattenuto resta invisibile e non finanziato.	Aggiungere memory metrics collegate agli outcome.
[CHK09-Q10]	Target, tolleranze e orizzonte temporale sono definiti?	Valore target, intervallo, data, owner e confidence.	Ogni risultato può essere dichiarato successo.	Definire success threshold e minimum observation window.
[CHK09-Q11]	È possibile attribuire ragionevolmente il cambiamento al pilot?	Confronto prima/dopo, cohort, controllo di fattori esterni e note.	Benefici o peggioramenti vengono attribuiti senza evidenza.	Definire evaluation design proporzionato.
[CHK09-Q12]	Sono predefiniti criteri scale, revise, restrict e stop?	Gate, soglie, decision authority, rischio residuo e backlog.	Il pilot continua per inerzia o viene scalato per entusiasmo.	Approvare decision rule prima dell’avvio.