---
title: "La policy AI 2.0: che cosa può fare il sistema, e chi lo decide"
url: https://zerofive.ai/blog/ai-governance/policy-ai-2-0-cosa-puo-fare-il-sistema
canonical: https://zerofive.ai/blog/ai-governance/policy-ai-2-0-cosa-puo-fare-il-sistema
language: it
published: 2026-10-24
updated: 2026-10-20
author: "ZeroFive.AI"
tags: policy AI, agenti AI, governance, AI Act, livelli di delega
abstract: "Dalla policy che vieta alle persone a quella che configura i sistemi: otto elementi, owner, riferimenti AI Act e un percorso per riscriverla."
---

# La policy AI 2.0: che cosa può fare il sistema, e chi lo decide

**In sintesi.** La policy AI che quasi tutte le aziende hanno scritto negli ultimi due anni è una lista di comportamenti vietati alle persone, pensata per un'AI che rispondeva in una chat. Con gli agenti che aprono connettori, scrivono sui gestionali e a volte spendono, quella policy non dice niente su ciò che il sistema può fare da solo. La policy 2.0 lo dichiara con otto elementi raggruppati in quattro livelli (perimetro, autonomia, tracciabilità, controllo), ha valori misurabili invece di principi, cambia intensità a seconda del livello di delega e viene firmata insieme da IT, legale e business.

Ne abbiamo parlato in Confindustria con Ernesto Belisario, partendo da una frase che avevamo messo in cima a una slide: la policy 1.0 diceva che cosa non inserire nel prompt, la policy 2.0 deve dire che cosa il sistema può fare. Qui riprendiamo quella slide e la sviluppiamo nel modo in cui la usiamo nei progetti, con gli elementi, chi ne risponde, i riferimenti normativi e un percorso per riscrivere la policy che c'è già.

![La policy AI 2.0: otto elementi in quattro livelli, perimetro, autonomia, tracciabilità e controllo](/policy-ai-2-0-elementi-it.png)

## La policy di prima generazione

Se guardate le policy AI approvate nella maggior parte delle aziende tra il 2023 e il 2025 trovate più o meno lo stesso documento: quali strumenti si possono usare, quali dati non vanno inseriti nel prompt, l'obbligo di rileggere quello che produce il modello, un indirizzo a cui rivolgersi in caso di dubbi. È un regolamento di comportamento rivolto alle persone, coerente con il modo in cui l'AI entrava in azienda, cioè come una chat in cui qualcuno incollava un testo e leggeva la risposta.

Quel documento ha fatto il suo lavoro. Ha ridotto l'uso di account personali, ha reso visibile il problema dei dati dei clienti, ha dato a chi usava gli strumenti un riferimento scritto, e resta il punto di partenza di chi oggi combatte la [shadow AI](/blog/approfondimenti/shadow-ai-azienda-rischi-policy). Funzionava perché il lavoro lo faceva la persona e l'AI stava ai margini, quello che nei nostri assessment chiamiamo livello [AI-assisted](/blog/strategia/ai-assisted-ai-first-ai-native-livelli-delega).

Con gli agenti cambia il destinatario. Un agente collegato al CRM, alla posta e al gestionale legge documenti, prepara ordini, risponde ai clienti, e nessuna regola rivolta alle persone gli dice quali sistemi può toccare, in lettura o in scrittura, fino a quale importo, con quale registro delle sue azioni. Quelle informazioni esistono solo se qualcuno le ha decise, e il posto in cui decidere è la policy.

## Gli otto elementi della policy 2.0

La slide che abbiamo presentato elencava otto voci. Nel nostro lavoro le raggruppiamo in quattro livelli, ciascuno con la domanda a cui risponde, perché la domanda aiuta a capire chi deve compilare l'elemento e con quali dati.

| Livello | Elemento | Cosa fissa la policy | Esempio di parametro | Owner |
|---|---|---|---|---|
| Perimetro | Strumenti autorizzati | Modelli, assistenti e agenti ammessi, con versione e attività | Assistente sul tenant aziendale ammesso, account consumer esclusi | IT |
| Perimetro | Dati utilizzabili | Categorie di dati per sistema, base giuridica, esclusioni | Dati clienti pseudonimizzati ammessi per analisi, dati sanitari esclusi | Legale e DPO |
| Autonomia | Permessi e connettori | Sistemi raggiunti, lettura o scrittura, identità usata | CRM in lettura, posta solo bozze, nessun accesso all'ERP | IT |
| Autonomia | Attività con approvazione | Azioni preparate dal sistema che una persona deve approvare | Comunicazioni ai clienti e modifiche contrattuali | Business |
| Autonomia | Soglie economiche | Limiti di spesa per azione e per periodo | Ordini oltre una soglia definita passano dal responsabile acquisti | Business e CFO |
| Tracciabilità | Logging | Cosa si registra, per quanto tempo, chi consulta | Ogni azione con utente, orario, esito, conservata per un periodo fissato | IT |
| Tracciabilità | Incident reporting | Definizione di incidente, destinatari, tempi | Output errato inviato a un cliente, segnalazione al referente entro poche ore | Legale e IT |
| Controllo | Sospensione e kill switch | Chi ferma il sistema, come, in quanto tempo, come si riparte | Revoca delle credenziali dei connettori, prova programmata | IT e business |

Il **perimetro** stabilisce con che cosa lavora il sistema. Sono i due elementi che anche la policy 1.0 conteneva, ma qui vengono dichiarati sistema per sistema e non per l'intera azienda, perché un assistente di scrittura e un agente che riconcilia fatture hanno bisogno di dati diversi.

L'**autonomia** stabilisce che cosa il sistema può fare senza chiedere. È il livello che la policy di prima generazione non conosceva, e contiene le decisioni più delicate: quali connettori aprire e con quali permessi, quali azioni passano da una persona, quanto può spendere. Le soglie economiche sono l'elemento che sorprende di più nelle discussioni con i comitati, perché fino a ieri nessun software aziendale poteva impegnare l'azienda verso un fornitore senza che un dipendente premesse un pulsante.

La **tracciabilità** stabilisce che cosa resta e chi viene avvisato. Un registro delle azioni dell'agente serve a ricostruire cosa è successo, e una procedura di segnalazione serve perché qualcuno lo sappia in tempo. Sul legame tra registri e reversibilità di un agente abbiamo scritto nel pezzo su [quattro livelli e il perimetro di delega](/blog/ai-governance/agenti-ai-quattro-livelli-perimetro-delega).

Il **controllo** stabilisce come si ferma il sistema. Ha un solo elemento e lo trattiamo come un gate: per i sistemi ad alto rischio l'AI Act, all'articolo 14, chiede che chi supervisiona possa interrompere il sistema con un pulsante di arresto o una procedura simile, e per un agente in produzione lo consideriamo un requisito anche fuori da quel perimetro. Un kill switch che nessuno ha mai provato vale quanto non averlo, per cui la policy deve indicare anche la frequenza della prova.

## Valori al posto dei principi

La differenza più visibile tra le due generazioni sta nel tipo di frase. La policy 1.0 scrive "l'uso dei dati personali deve essere conforme alla normativa", la 2.0 scrive quali categorie di dati un certo agente può leggere e quali no. Una frase di principio non si può configurare in un sistema, una soglia sì.

Per questo la policy 2.0 si compone di due parti. La prima è un documento breve con i principi, i ruoli e le regole valide per tutti. La seconda è una scheda per ogni sistema in produzione, con gli otto elementi compilati: valori, permessi, soglie, tempi, nomi. Quando un sistema cambia si aggiorna la sua scheda, e il documento generale resta stabile.

La scheda va tenuta allineata con la configurazione reale. Il rischio che vediamo più spesso, e che abbiamo corso anche noi con i nostri agenti interni, è che la scheda dica "posta solo in bozza" mentre qualcuno, per risolvere un problema operativo, ha dato all'agente il permesso di invio. La verifica periodica consiste nel confrontare le due cose, e chi la fa deve poter leggere entrambe.

## Il peso degli elementi per livello di delega

Non tutti i sistemi hanno bisogno degli otto elementi con la stessa intensità. Un assistente che suggerisce testi a un dipendente, che poi decide cosa usare, si governa con il perimetro e con un registro minimo. Un agente che esegue un processo end to end ha bisogno di tutti gli elementi configurati nel sistema e verificati.

![Intensità degli otto elementi per livello di delega: AI-assisted, AI-first, AI-native](/policy-ai-2-0-delega-it.png)

| Elemento | AI-assisted | AI-first | AI-native |
|---|---|---|---|
| Strumenti autorizzati | Definito | Configurato e verificato | Configurato e verificato |
| Dati utilizzabili | Definito | Configurato e verificato | Configurato e verificato |
| Permessi e connettori | Non necessario | Definito | Configurato e verificato |
| Attività con approvazione | Non necessario | Definito | Configurato e verificato |
| Soglie economiche | Non necessario | Definito | Configurato e verificato |
| Logging | Definito | Configurato e verificato | Configurato e verificato |
| Incident reporting | Definito | Configurato e verificato | Configurato e verificato |
| Sospensione e kill switch | Non necessario | Definito | Configurato e verificato |

"Definito" significa che la scheda riporta valori espliciti. "Configurato e verificato" significa che quei valori sono impostati nel sistema (permessi del connettore, limiti di spesa, conservazione dei log) e che qualcuno ha controllato che il sistema li rispetti. Nel livello AI-first l'approvazione è già nella definizione, perché una persona rivede ogni output, e per questo la policy deve dire chi rivede e con quali criteri.

## La firma condivisa

La slide si chiudeva con una frase su chi firma: IT, legale e business. Ognuno dei tre è owner di elementi diversi. L'IT risponde di strumenti, connettori, log e meccanismi di arresto. Il legale, con il DPO, risponde di dati, incidenti e allineamento normativo. Il business risponde di approvazioni e soglie economiche, perché decidere quanto un sistema può impegnare l'azienda è una scelta di chi ne porta il risultato.

La firma condivisa evita le policy scritte da una sola funzione, che conosciamo bene: quella dell'IT è precisa sui permessi e tace sulle responsabilità, quella del legale cita tutte le norme e non si traduce in nessuna configurazione. Ogni sistema ha poi un owner con nome e cognome, che risponde della sua scheda, un punto su cui abbiamo scritto nel pezzo sugli [agenti senza owner nominativo](/blog/ai-governance/agenti-ai-owner-nominativo-produzione).

Con le modifiche al D.Lgs. 231/2001 introdotte dal D.Lgs. 160/2026 la policy entra anche nel perimetro dei modelli organizzativi, e la documentazione che la accompagna diventa materiale da produrre quando qualcosa va storto, come abbiamo spiegato nell'articolo sulla [documentazione AI come prova](/blog/compliance/documentazione-ai-difesa-dlgs-160-2026).

## I riferimenti normativi

La policy 2.0 non nasce da un obbligo specifico, ma quasi ogni elemento ha un riferimento in una norma o in uno standard che l'azienda deve già considerare.

| Elemento | Riferimenti principali |
|---|---|
| Strumenti autorizzati | AI Act art. 26 (obblighi dei deployer), ISO/IEC 42001 Allegato A |
| Dati utilizzabili | GDPR artt. 5 e 35, ISO/IEC 42001 Allegato A |
| Permessi e connettori | NIS2 art. 21 (controllo degli accessi), principio del minimo privilegio |
| Attività con approvazione | AI Act art. 14 (sorveglianza umana) |
| Soglie economiche | Sistema di deleghe e procure, modello 231 |
| Logging | AI Act artt. 12 e 26, ISO/IEC 42001 Allegato A |
| Incident reporting | AI Act art. 73, NIS2 art. 23, GDPR art. 33 |
| Sospensione e kill switch | AI Act art. 14, par. 4 |

Gli articoli 12, 14, 26 e 73 dell'AI Act riguardano i sistemi ad alto rischio, i cui obblighi per l'Allegato III decorrono dal 2 dicembre 2027 dopo il Digital Omnibus. Per gli altri sistemi li usiamo come riferimento di buona pratica: la policy si prepara prima e l'azienda arriva alla scadenza con schede, registri e prove già in esercizio. Sulla parte di [controllo umano effettivo](/blog/compliance/decisioni-assistite-controllo-umano-effettivo) e sulle sue implicazioni per la formazione c'è un approfondimento dedicato.

## Come riscrivere la policy esistente

Il percorso che seguiamo parte da quello che l'azienda usa già, sistema per sistema.

1. **Inventario.** Censire assistenti, agenti e integrazioni in uso, comprese quelle adottate dai team senza passare dall'IT, come descritto nell'articolo sull'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001).
2. **Livello di delega.** Classificare ogni sistema come AI-assisted, AI-first o AI-native e, dove serve, per classe di rischio secondo l'AI Act.
3. **Scheda per sistema.** Compilare gli otto elementi con valori misurabili, usando la tabella delle intensità per capire dove fermarsi.
4. **Firma condivisa.** IT, legale e business approvano la scheda, e ogni elemento ha il suo owner.
5. **Configurazione.** Tradurre la scheda in impostazioni (permessi, limiti, conservazione dei log, alert) e verificare che il sistema le rispetti.
6. **Revisione.** Aggiornare la scheda a ogni nuovo connettore, modello, incidente o cambio normativo, e provare il kill switch con la frequenza prevista.

Il documento generale della policy 1.0 non si butta. Diventa la prima parte della 2.0, con le regole di comportamento ancora valide per chi usa gli strumenti, e si arricchisce delle schede.

## Gli errori più frequenti

Il primo è scrivere la policy 2.0 come un documento più lungo della 1.0, aggiungendo capitoli su agenti e automazione senza scendere ai valori. Il risultato è un testo che nessun sistema può applicare e che nessuno verifica.

Il secondo è una policy unica per tutti i sistemi. Applicare a un assistente di scrittura le regole di un agente che firma ordini blocca l'adozione, mentre applicare a quell'agente le regole dell'assistente lascia scoperta proprio la parte che espone l'azienda.

Il terzo è considerare il kill switch una funzione del fornitore. Molte piattaforme permettono di disattivare un agente, poche garantiscono che le credenziali dei connettori vengano revocate e che i processi in corso si fermino in modo ordinato, e lo si scopre soltanto provando.

Il quarto è lasciare la scheda separata dalla configurazione. Una policy che dice una cosa mentre il sistema ne fa un'altra è peggio di una policy assente, perché dà al comitato una sicurezza che non corrisponde ai fatti.

## Da dove partire

Nel modello [AI Rating](/servizi/ai-rating) la policy entra nella dimensione AI Risk, dove conformità di base e governance sono gate non compensabili: un'azienda con punteggi alti nelle altre dimensioni non raggiunge la classe A se questa parte è assente. La valutazione mostra anche quali sistemi hanno bisogno per primi di una scheda.

Per capire come si dichiara quanto lavoro affidare a ciascun sistema c'è l'articolo sui [livelli di delega](/blog/strategia/ai-assisted-ai-first-ai-native-livelli-delega), per la reversibilità e i gate di un agente quello su [quattro livelli e il perimetro di delega](/blog/ai-governance/agenti-ai-quattro-livelli-perimetro-delega).

Per verificare a che punto è la vostra policy potete [avviare un AI Rating](/avvia-ai-rating) o [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive).