- Come applicare l’AI Act al Service Desk?
- Quali casi d’uso AI devono essere censiti?
- Cosa chiedere ai fornitori ITSM?
Il 2 agosto non trasforma ogni chatbot in un sistema ad alto rischio
Dal 2 agosto 2026 la Commissione europea e le autorità nazionali hanno iniziato ad applicare l’AI Act; dalla stessa data sono operative specifiche regole di trasparenza. Per chatbot e altri sistemi interattivi, il principio è comprensibile anche fuori dagli uffici legali: la persona deve sapere quando sta interagendo con un’AI e non con un essere umano.
Questo fatto non autorizza però una scorciatoia concettuale. L’AI Act adotta un approccio basato sul rischio e la Commissione ricorda che la grande maggioranza dei sistemi ricade nel rischio minimo o nullo. Un assistente che suggerisce una procedura per reimpostare una password non diventa automaticamente “high-risk”. La classificazione dipende dalla finalità prevista, dal contesto e dall’effetto sulla persona. Le regole per alcuni impieghi ad alto rischio dell’Allegato III, tra cui specifici usi in ambito lavorativo, sono inoltre previste dal 2 dicembre 2027 dopo la revisione del calendario europeo.
Per un Service Manager la conseguenza è netta: non serve applicare il controllo più pesante a tutto. Serve dimostrare perché ogni caso d’uso riceve il livello di controllo appropriato.
L’unità di governo non è il prodotto: è il caso d’uso
L’errore più comune è costruire un inventario di licenze: “abbiamo il copilota del vendor A e il bot del vendor B”. È insufficiente. Lo stesso motore può riassumere un ticket, suggerire una risposta, classificare un dipendente, avviare una remediation o negare un servizio. Sono impatti diversi, anche quando l’interfaccia è identica.
L’inventario operativo dovrebbe quindi partire dal caso d’uso e registrare almeno: scopo, utenti coinvolti, dati trattati, output generato, azioni consentite, grado di autonomia, base di conoscenza, fornitore, proprietario interno, meccanismo di escalation e controllo umano. A questo vanno aggiunte la data dell’ultima valutazione e la versione significativa del modello o della configurazione.
Questa mappa risolve anche un problema economico. Evita di finanziare controlli indiscriminati e concentra test, monitoraggio e revisione sui punti dove un errore costa davvero: accessi, dati personali, continuità del servizio, diritti del lavoratore o decisioni che limitano un beneficio. Permette inoltre di confrontare iniziative diverse con criteri omogenei e di motivare perché un’automazione resta assistiva, mentre un’altra richiede approvazione preventiva e verifiche più frequenti.
La trasparenza deve vivere nel journey, non nelle note legali
La Commissione ha pubblicato il 20 luglio 2026 linee guida dedicate all’articolo 50, con l’obiettivo di rendere l’applicazione coerente e proporzionata. Per il supporto digitale questo significa progettare la trasparenza come parte del servizio.
Una dicitura nascosta nel footer non basta a costruire fiducia. L’utente dovrebbe capire, nel momento utile, se sta parlando con un sistema automatico; quali attività può svolgere; quando passa a una persona; come chiedere revisione o assistenza umana. Se l’AI prepara una risposta che viene poi controllata dall’operatore, l’esperienza e il controllo saranno diversi rispetto a un agente che modifica direttamente un account.
La metrica manageriale non è quindi soltanto “disclosure presente”. Occorre verificare comprensione, tasso di abbandono dopo l’avviso, richiesta di operatore, errori prima dell’handoff e differenze tra canali. Trasparenza e qualità del servizio diventano la stessa conversazione.
Dal contratto al fascicolo di evidenze del fornitore
Nel Service Desk l’AI arriva spesso dentro piattaforme SaaS, motori di knowledge, strumenti di workforce management o componenti incorporati dal fornitore. La governance non può fermarsi alla clausola “AI compliant”. Serve un fascicolo aggiornabile di evidenze.
Il responsabile del servizio dovrebbe poter ottenere: descrizione della finalità prevista; responsabilità tra provider, integratore e cliente; provenienza e limiti delle fonti usate in esercizio; log disponibili; criteri di rilascio; notifica delle modifiche rilevanti; controlli su sicurezza e dati; modalità di sospensione; assistenza agli audit e conservazione delle evidenze. Non tutto deriva dallo stesso articolo di legge: è una traduzione manageriale del bisogno di controllo lungo la catena di fornitura.
Questa impostazione cambia anche gli SLA. Disponibilità e tempo di risposta restano necessari, ma non misurano drift, grounding scorretto, escalation tardiva o un’azione automatica non autorizzata. I contratti dovrebbero includere indicatori di qualità e rischio, soglie di arresto e tempi per la correzione di regressioni.
Persone, processo e costi: la governance deve entrare nell’operating model
L’AI literacy è applicabile dal febbraio 2025, ma un corso una tantum non crea capacità operativa. Agenti, knowledge manager, service owner, procurement, security, privacy e legal devono condividere un linguaggio minimo: cosa fa il sistema, quali segnali indicano un errore, chi può ridurne l’autonomia e chi conserva le evidenze.
Conviene inserire i controlli nei meccanismi già esistenti: service design, change enablement, major incident, problem management, supplier review e continual improvement. Ogni aumento di autonomia dovrebbe superare un gate esplicito; ogni incidente AI dovrebbe alimentare knowledge e registro dei rischi; ogni review del fornitore dovrebbe discutere qualità, modifiche e casi limite, non soltanto volumi e uptime.
I costi vanno resi visibili in tre voci: costo di esercizio del modello, costo del controllo e costo dell’errore. Se il business case contabilizza soltanto ticket evitati e minuti risparmiati, sposta il rischio fuori dal foglio Excel. Un modello sostenibile attribuisce budget anche a test, supervisione, logging, formazione e rollback.
Una roadmap di 90 giorni, senza aspettare il prossimo audit
Nei primi trenta giorni: censire i casi d’uso reali, compresi quelli attivati dai fornitori; assegnare owner; distinguere assistenza, raccomandazione, decisione e azione; verificare dove l’utente incontra l’AI. Nei trenta successivi: classificare impatti e dati, correggere disclosure e handoff, concordare con i fornitori l’evidence pack, definire log e soglie di arresto.
Negli ultimi trenta giorni: testare scenari critici, misurare comprensione ed escalation, simulare sospensione e rollback, portare i risultati nella service review. Il deliverable non è una presentazione sulla compliance, ma un registro vivo collegato a cambiamenti, incidenti, contratti e KPI.
La mia interpretazione manageriale è questa: l’AI Act rende visibile una disciplina che il Service Management avrebbe dovuto adottare comunque. La fiducia non nasce dal badge “powered by AI” né da un disclaimer. Nasce dalla capacità di sapere dove opera l’automazione, spiegarla, limitarla e dimostrare che il servizio continua a restituire valore alle persone.
Fonti e approfondimenti
- Commissione europea — Commission starts enforcing AI Act rules and new transparency requirements on 2 August — 31 luglio 2026 ↗
- Commissione europea — AI Act: regulatory framework, risk categories e calendario — aggiornato 3 agosto 2026 ↗
- Commissione europea — Guidelines on transparency obligations for providers and deployers of AI systems — 20 luglio 2026 ↗
- Unione europea — Regolamento (UE) 2024/1689 (AI Act) — 13 giugno 2024 ↗
- NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1 — 26 luglio 2024; aggiornato 8 aprile 2026 ↗
Analisi e interpretazioni sono personali e non rappresentano le posizioni delle organizzazioni citate o del mio datore di lavoro.