Applicazione alle due modalità
Regulatory Essentials: screening minimo
Lo screening considera finalità, ruoli, territorio, dati personali, profilazione o decisioni automatizzate, categorie biometriche o sentiment/emotion, trasparenza, supervisione, logging, alfabetizzazione AI, terze parti, incidenti, diritti e ritiro. L’esito determina soltanto la profondità dei controlli e l’eventuale necessità di una review specialistica.
[SCR01 - Regulatory Essentials] è uno screening iniziale e ricorrente: non certifica la conformità, ma impedisce che questioni regolatorie emergano soltanto al go-live. Il practitioner registra intended purpose, territorio, soggetti coinvolti, ruoli di provider/deployer e terze parti, categorie di dati, presenza di profilazione o decisioni automatizzate, destinatari degli output e possibilità di contestazione. Se il caso tratta dati personali, verifica finalità, base giuridica, minimizzazione, accessi, conservazione, trasparenza, diritti, sicurezza, trasferimenti e necessità di coinvolgere DPO o specialisti.
Per l’AI Act lo screen esclude innanzitutto pratiche vietate, classifica il ruolo dell’organizzazione e verifica se il sistema ricade in trasparenza o alto rischio. Controlla inoltre istruzioni d’uso, supervisione umana, logging, competenza degli utenti, incidenti, change e ritiro. Alla data della v1.2, gran parte dell’AI Act è applicabile dal 2 agosto 2026; alcune regole per sistemi ad alto rischio seguono le scadenze differite introdotte nel 2026. Per questo la classificazione deve essere confermata su fonti ufficiali e, quando necessario, da professionisti competenti.
| Caso | Segnale rilevato | Azione proporzionata |
|---|---|---|
| Assistente interno su dati di acquisto | Dati prevalentemente business; log nominativi degli utenti | Controlli leggeri su accessi, retention, logging, istruzioni e incidenti |
| Customer analytics in punto vendita | Video, stime demografiche, sentiment/emotion, profilazione e trasparenza | Valutare minimizzazione, separazione video/metadati, informativa, DPIA e classificazione AI Act; disabilitare capacità non necessarie |
| Prodotto per clienti esterni | Ruolo di provider, intended purpose, versioni, supporto e terze parti | Attivare SCR01 e SCR02; collegare condizioni a release, contratti e Gate G03/G05 |
| RIFERIMENTI UFFICIALI GDPR: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng · AI Act consolidato: https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng · quadro e scadenze: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Lo screening non sostituisce un parere legale. | ||
| PRIVACY BY DESIGN Definire finalità e base giuridica, minimizzare dati e conservazione, limitare accessi, separare video grezzo e metadati quando possibile e documentare le responsabilità prima del pilot. |
La governance costruisce fiducia rendendo espliciti accountability, controlli, tracciabilità, contestabilità e operabilità. Il core obbligatorio non richiede ITIL: richiede che ogni Digital Role destinato al pilot abbia un service model minimo e praticabile.
[SM01 - Minimum Viable AI Service Management]
È il set minimo di decisioni e pratiche necessario affinché un ruolo digitale non resti una demo. È obbligatorio per tutti i pilot, anche quando l’azienda non usa ITIL e non intende adottarlo.
| Capacità minima | Domanda operativa | Evidenza |
|---|---|---|
| [SMC01 - Service ownership] | Chi risponde del servizio e del processo quando l’AI non funziona? | [DLV06] con owner e sostituto |
| [SMC02 - Support & escalation] | Dove segnala l’utente e chi prende in carico? | Canale, categorie, priorità e contatti |
| [SMC03 - Incident & containment] | Che cosa costituisce incidente e come si contiene l’impatto? | Tassonomia, severità, containment e comunicazione |
| [SMC04 - Change & versioning] | Chi può modificare modello, prompt, regole, fonti, tool e autonomia? | Change record, test, approvazione, versione e rollback |
| [SMC05 - Monitoring] | Quali segnali indicano degrado, rischio o costo anomalo? | Metriche, soglie, alert, owner e cadenza |
| [SMC06 - Continuity] | Come continua il processo durante indisponibilità o incertezza? | Fallback e recovery testati |
| [SMC07 - Retirement] | Come si sospende, sostituisce o dismette il ruolo? | Exit criteria, comunicazione, conservazione e decommission |
[SM01 - Minimum Viable AI Service Management] rende il ruolo digitale esercibile anche in organizzazioni che non adottano formalmente ITIL. Ogni componente [SMC01–SMC07] deve produrre una risposta operativa, non una policy astratta. L’esempio seguente mostra il set minimo per un servizio di raccomandazione di riordino.
| Componente | Esempio completo |
|---|---|
| SMC01 — Ownership | AI Service Owner nominato; buyer utenti; orario 8–18; dipendenze ERP, DWH e pipeline; AL1 Recommend / MA1 Propose. |
| SMC02 — Support | Canale ticket; priorità P1–P3; primo riscontro 30 min per indisponibilità; knowledge article per errori ricorrenti. |
| SMC03 — Incident | Input, output, versione, SKU, impatto e containment registrati; sospensione automatica del brand se supera la soglia di errore. |
| SMC04 — Change | Regole, prompt, modelli e fonti versionati; test su campione; approvazione del Service Owner; rollback documentato. |
| SMC05 — Monitoring | Disponibilità, latenza, copertura SKU, override, errore per classe, costo e drift; soglie con owner ed escalation. |
| SMC06 — Continuity | Fallback al report manuale; capacità della coda verificata; recovery con riconciliazione delle proposte non elaborate. |
| SMC07 — Retirement | Criteri di ritiro, comunicazione ai buyer, revoca accessi, conservazione delle evidenze e dismissione delle integrazioni. |
[ITIL01 - ITIL Compatibility Profile]
È un profilo opzionale che mappa le capacità minime sugli strumenti e sulle pratiche ITSM dell’organizzazione. È utile se l’azienda è già ITIL-oriented, dispone di processi ITSM strutturati o prevede concretamente di implementarli. Se ITIL non è presente né previsto, il profilo non si attiva: imporlo aggiungerebbe terminologia, ruoli e artefatti senza un beneficio proporzionato.
| Scelta | Vantaggi | Rischi / condizione |
|---|---|---|
| Solo [SM01] | Semplice, sufficiente per l’operabilità minima e adatto alle PMI | Richiede disciplina anche senza terminologia ITIL |
| [SM01] + [ITIL01] | Integra AI service, service desk, change, configuration e continual improvement esistenti | Attivare solo se tali pratiche vengono realmente usate o pianificate |
| ITIL obbligatorio per tutti | Uniformità formale | Non adottato: over-engineering e rischio di compliance teatrale |
| DECISIONE METODOLOGICA [SM01] è core obbligatorio. [ITIL01] è opzionale. Le domande esclusivamente ITIL, quando presenti in moduli applicativi, sono N/A e non entrano nello scoring; le condizioni di service readiness restano invece obbligatorie. |
|---|
Comprendere — sintesi practitioner
La domanda di controllo è se l’engagement riesca davvero a rendere il servizio governabile, supportabile, conforme e reversibile. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.
Governance e service management rendono il ruolo digitale controllabile nel lavoro quotidiano, non soltanto conforme in teoria.
Applicare — sequenza minima
Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è rendere il servizio governabile, supportabile, conforme e reversibile.
Applicare [SM01 - Minimum Viable AI Service Management] sempre; aggiungere [ITIL01 - ITIL Compatibility Profile] solo se proporzionato. Definire ownership, supporto, monitoring, incident, change, continuity e retirement in [DLV06 - Minimal Governance & AI Service Card].
Vedere in pratica — Buyer Assistant
Il caso mostra come rendere il servizio governabile, supportabile, conforme e reversibile senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.
Buyer Assistant definisce un fallback al report manuale, un owner del servizio e un playbook per dati stock non aggiornati; non introduce un CAB completo per ogni modifica minore.
Verificare — definition of done
La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile rendere il servizio governabile, supportabile, conforme e reversibile; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.
Owner e sostituto sono reperibili.
Incident e change hanno trigger e registro.
Fallback e continuità sono provati prima del pilot.