Gestione delle policy aziendali: la guida all’acquisto nell’era dell’IA

In sintesi

• La gestione delle policy aziendali è stata a lungo valutata su tre criteri: archiviazione, iter di approvazione e presa visione. Dal 2025 viene valutata anche sulla capacità di produrre una prova opponibile.
• Il regolamento europeo sull’IA trasforma la policy in un adempimento normativo: l’articolo 4 impone misure di alfabetizzazione in materia di IA a fornitori e deployer, mentre l’articolo 53, paragrafo 1, lettera c) impone ai fornitori di modelli di IA per finalità generali di dotarsi di una policy sul diritto d’autore.
• Il controllo A.2 dell’allegato A di ISO/IEC 42001 richiede una policy sull’IA documentata, allineata alle altre policy dell’organizzazione e riesaminata a intervalli pianificati.
• Una presa visione dimostra che un documento è stato aperto. Non dimostra che un controllo funzioni e non copre nulla riguardo agli strumenti di IA mai entrati nell’inventario.
• Il criterio d’acquisto decisivo è la dimostrabilità: policy legata al controllo, controllo legato a un responsabile e a una data, catena completa esportabile per qualunque periodo passato.

Che cosa fa davvero un software per la gestione delle policy aziendali

La gestione delle policy aziendali consiste nel centralizzare il ciclo di vita delle regole interne: stesura, riesame, approvazione, pubblicazione, distribuzione, presa visione, monitoraggio, riesame periodico e ritiro. La categoria esiste perché né le cartelle condivise né gli scambi di posta elettronica sanno rispondere all’unica domanda che conta durante un audit, ossia quale versione di quale regola si applicava a quali persone in una data determinata. La maggior parte di chi valuta un acquisto arriva cercando un archivio migliore. L’archivio è la parte meno interessante. Quattro capacità distinguono un vero strumento per la gestione delle policy aziendali da una cartella ben ordinata:

• La separazione obbligatoria tra stesura e approvazione. Chi redige una policy non può essere chi la approva, e il sistema conserva entrambe le identità insieme al momento dell’approvazione.
• La ricostruzione a una data passata. Si può mostrare che cosa diceva la versione pubblicata il 14 marzo, non soltanto che cosa dice oggi.
• La presa visione mirata. Viene sollecitato soltanto il sottoinsieme di persone pertinente, in base al ruolo, all’entità giuridica o al sistema interessato, e le eccezioni restano visibili.
• L’esportazione per l’audit. La prova esce dallo strumento in un formato leggibile da un valutatore senza bisogno di una licenza.

Tutto il resto, compresi gli assistenti di scrittura basati su IA ormai integrati nella quasi totalità dei prodotti, riguarda la comodità d’uso. Se queste quattro capacità sono deboli, nessuna raffinatezza dell’editor salverà l’audit. È la stessa logica che separa un archivio documentale da un sistema di gestione della conformità realmente operativo.

Policy, standard, procedura: la distinzione che determina lo strumento

Una policy enuncia l’intento e assegna la responsabilità. Uno standard fissa la soglia misurabile. Una procedura descrive i passaggi operativi. Le organizzazioni che fondono i tre livelli in un unico documento finiscono per riscrivere l’intero testo ogni volta che cambia un parametro tecnico, ed è questa la ragione per cui i loro cicli di riesame slittano sistematicamente. Gli strumenti si differenziano nettamente su questo punto: alcuni prevedono un unico tipo di documento, piatto, altri modellano una gerarchia nella quale uno standard può cambiare senza riaprire la policy che lo autorizza. Se i vostri controlli sull’IA verranno rivisti più spesso del vostro intento di governance, e così sarà, pretendete la gerarchia.

Perché il 2026 ha cambiato i requisiti

Fino a poco tempo fa dotarsi di una policy rientrava nelle buone pratiche. Per chiunque sviluppi o utilizzi sistemi di IA si tratta ormai di un obbligo giuridico sorretto da articoli precisi. L’articolo 4 del regolamento europeo sull’IA, dedicato all’alfabetizzazione in materia di intelligenza artificiale, si applica dal 2 febbraio 2025. Prevede che i fornitori e i deployer di sistemi di IA adottino misure per garantire, nella misura del possibile, un livello sufficiente di alfabetizzazione del proprio personale e delle altre persone che si occupano del funzionamento e dell’utilizzo dei sistemi di IA per loro conto. Tali misure devono essere documentate, calibrate sui ruoli corretti e mantenute aggiornate. E il registro di chi ha ricevuto quale formazione è esattamente ciò che uno strumento di gestione delle policy aziendali dovrebbe custodire. L’articolo 53, paragrafo 1, lettera c) si spinge oltre per i fornitori di modelli di IA per finalità generali, tenuti ad attuare una policy volta a rispettare il diritto dell’Unione in materia di diritto d’autore e diritti connessi. La formulazione merita attenzione: l’obbligo non consiste nel comportarsi correttamente, bensì nel disporre di una policy, e l’autorità competente può chiederne l’esibizione. La nostra guida agli obblighi per l’IA per finalità generali ricostruisce il resto del regime. Le norme tecniche vanno nella stessa direzione. Il controllo A.2 dell’allegato A di ISO/IEC 42001 richiede una policy sull’IA documentata, il suo allineamento alle altre policy dell’organizzazione e il riesame a intervalli pianificati sotto il profilo dell’idoneità e dell’efficacia. Il punto 7.5 la qualifica come informazione documentata obbligatoria, ragione per cui in sede di certificazione verrà richiesta per nome. Il NIST AI RMF è coerente con questa impostazione: la sottocategoria GOVERN 1.2 si attende che le caratteristiche di un’IA affidabile siano integrate nelle policy, nei processi, nelle procedure e nelle prassi dell’organizzazione, mentre GOVERN 1.1 si attende che i requisiti legali e regolamentari siano compresi, gestiti e documentati. A ciò si aggiunge il livello nazionale. Il Garante per la protezione dei dati personali si è più volte pronunciato sull’impiego di sistemi di IA rispetto alla disciplina sulla protezione dei dati, e l’AgID definisce le linee guida applicabili alle amministrazioni che adottano queste tecnologie. Una policy sull’IA redatta in Italia deve potersi agganciare a entrambi i corpi normativi senza riscritture, il che presuppone uno strumento capace di far convivere più riferimenti sulla medesima clausola. La conseguenza pratica, per chi sta costruendo una rosa di soluzioni, sta nello spostamento della domanda. Prima si trattava di sapere se lo strumento fosse in grado di recapitare un documento a tutti e registrarne l’apertura. Oggi si tratta di sapere se lo strumento sappia fornire a un valutatore una risposta difendibile a una richiesta stretta e scomoda: mostratemi la policy che assolve questo obbligo, la versione vigente nel periodo che rivendicate, le persone alle quali si applicava e la prova che il controllo sottostante abbia effettivamente operato. I prodotti concepiti come motori di distribuzione rispondono benissimo alla prima domanda e molto male alla seconda.

La trappola della presa visione: una firma non è conformità

Tutti i prodotti della categoria contano le prese visione, e la maggior parte delle guide all’acquisto ne fa l’indicatore principale. È un indicatore debole. Una presa visione registra che una persona identificata ha aperto un documento e ha cliccato per confermare. Non registra che l’abbia compresa, che il suo comportamento sia cambiato, né che il controllo descritto dalla policy stia operando. Una funzione aziendale può esibire il 100 per cento di prese visione su una policy di utilizzo accettabile e nel frattempo mandare in produzione un modello mai riesaminato, mentre il cruscotto resta verde dall’inizio alla fine. Con l’IA il divario si allarga. Le policy di utilizzo accettabile coprono soltanto gli strumenti di cui si è a conoscenza. Lo shadow AI, ossia i modelli e gli assistenti che il personale adotta senza passare da alcun processo di ingresso, sfugge alla presa visione per costruzione: uno strumento mai entrato nell’inventario non è mai rientrato nel perimetro di una campagna di conferma. Un tasso di copertura misurato su un registro cui manca un terzo del parco misura il registro, non la conformità. Ciò che un valutatore chiede è invece una catena. Quale obbligo impone questo controllo, quale policy lo enuncia, chi ne risponde e quale prova ne attesta il funzionamento nel periodo esaminato. Uno strumento che si ferma a “pubblicato, 94 per cento di prese visione” lascia a voi il compito di ricomporre quella catena a mano, in un foglio di calcolo, nella settimana che precede l’audit. È la verifica pratica dell’auditabilità, ed è il punto in cui finisce lo strumento documentale e comincia lo strumento di governance. Nulla di tutto questo rende inutile la presa visione. Resta il modo meno costoso di dimostrare che una regola è stata comunicata, e la comunicazione costituisce un elemento giuridico reale di diversi obblighi, incluso il dovere di alfabetizzazione richiamato sopra. L’errore consiste nel trattare la percentuale di conferme come un risultato anziché come uno fra più dati in ingresso. Leggetela come indicatore di distribuzione, conservatela, e ponete separatamente la domanda difficile: per ciascuna policy, quale artefatto indipendente convincerebbe qualcuno che non si fida di noi che la regola è stata rispettata?

Nove criteri di valutazione che contano oggi

Le griglie funzionali di questa categoria contano una cinquantina di voci, quasi tutte soddisfatte da qualunque prodotto. Sono questi nove criteri a fare la differenza.

1. Il collegamento policy, controllo, prova. Una clausola può puntare a un controllo, e quel controllo all’artefatto che ne dimostra l’esecuzione? Se la risposta è un collegamento a una cartella condivisa, non esiste alcun collegamento.
2. La mappatura su più framework. Una stessa policy soddisfa di norma più obblighi contemporaneamente. Una singola clausola dovrebbe poter portare simultaneamente le corrispondenze verso il regolamento europeo sull’IA, ISO/IEC 42001 e il NIST AI RMF, altrimenti aggiungere un framework equivale a riscrivere la biblioteca. Il nostro framework di governance dell’IA illustra la logica delle corrispondenze.
3. Riesami attivati da eventi. I cicli annuali sono stati concepiti per una regolamentazione stabile. Verificate che un riesame possa essere attivato da un nuovo atto normativo, da un cambio di versione del modello o da un incidente, e non soltanto da una scadenza di calendario.
4. Date di efficacia e successione delle versioni. Il numero di versione non basta. Servono una data di entrata in vigore, una catena di sostituzione e la capacità di rispondere alla domanda su che cosa fosse vigente in un qualunque momento passato.
5. Presa visione mirata. Conferme indirizzate per ruolo, entità giuridica, giurisdizione o singolo sistema di IA, con una coda di eccezioni visibile. Le campagne indifferenziate producono numeri lusinghieri e poco segnale.
6. Aggancio all’inventario. La biblioteca delle policy dovrebbe poggiare sulla stessa fonte autorevole del vostro inventario dei sistemi di IA. Mantenuti separatamente, i due divergeranno, e quella divergenza diventerà il rilievo di audit.
7. Dati strutturati ed esportabili. Policy conservate soltanto in PDF non possono essere interrogate, confrontate o trasmesse a controlli a valle. Chiedete un’interfaccia programmabile e un’esportazione strutturata prima di chiedere i modelli di documento.
8. Registro di audit inalterabile. Ogni cambiamento di stato tracciato, con il registro stesso protetto da modifiche da parte degli amministratori.
9. Delega della stesura con separazione mantenuta. Gli esperti di materia redigono sul proprio perimetro mentre l’autorità di approvazione resta al responsabile designato.

In che cosa differiscono le categorie di strumenti

Citare i prodotti invecchia in fretta e insegna poco, dato che in questo mercato la parità funzionale si raggiunge una o due release dopo qualunque novità reale. Le categorie sono più stabili, perché rispecchiano l’origine di ciascun prodotto. Quattro famiglie si spartiscono oggi la gestione delle policy aziendali, e ciascuna porta con sé le assunzioni del problema per cui era stata costruita. Le suite di controllo documentale nascono dal management della qualità e dall’accreditamento del settore pubblico. Ciclo di vita, versionamento e presa visione vi sono risolti in modo eccellente, spesso il migliore sul mercato. La mappatura normativa resta superficiale e gli obblighi propri dell’IA sono assenti oppure trattati come un tipo documentale qualunque. Le piattaforme GRC trasversali collegano le policy a rischi, controlli e normative come funzione di primo livello, il che corrisponde esattamente al primo criterio. Il prezzo da pagare è la configurazione: questi progetti si misurano in trimestri, e i contenuti relativi all’IA si presentano di norma come un modulo aggiunto su un modello dati anteriore all’IA. Gli strumenti di intranet e di suite per l’ufficio vincono sull’adozione, perché il personale ci lavora già, e sul prezzo, perché la licenza è spesso già pagata. Sono i più deboli sul rigore probatorio: separazione dei ruoli, inalterabilità dei registri e ricostruzione a una data passata vi sono più convenzioni che comportamenti imposti dal sistema. Le piattaforme di governance native per l’IA partono dall’obbligo anziché dal documento, sicché le policy vi arrivano già collegate ai controlli e a un inventario dei sistemi di IA. Trattandosi di una categoria più giovane, la copertura al di fuori della governance dell’IA è disomogenea. La maggior parte delle organizzazioni possiede già uno strumento delle prime tre famiglie. La domanda realistica raramente riguarda quindi una sostituzione integrale, bensì quale strato custodirà la prova. Affrontiamo questo bilanciamento nella nostra analisi della governance dell’IA.

La questione del costruire su SharePoint

Costruire su una piattaforma documentale già in casa è difendibile finché il numero di policy è contenuto, non è coinvolta alcuna autorità di settore e nessuno vi ha ancora chiesto di ricostruire uno stato passato. Smette di esserlo il giorno in cui servono la separazione obbligatoria dei ruoli e un registro inalterabile, perché entrambi vanno sviluppati e poi mantenuti al variare della piattaforma sottostante. Mettete a bilancio la manutenzione, non soltanto la costruzione.

Dove sta andando il settore: policy leggibili dalle macchine

L’attuale generazione di strumenti tratta la policy come un documento cui sono associati dei metadati. La direzione di marcia porta verso la policy come dato strutturato, utilizzabile dai sistemi stessi. La formulazione pubblicata più netta di questa idea è la proposta delle Policy Cards (Mavracic, ottobre 2025), secondo cui Model Card, Data Card e System Card descrivono un sistema ma difettano di uno strato normativo operativo. Le Policy Card codificano regole di autorizzazione e divieto, obblighi e requisiti probatori che un agente applica in fase di esecuzione, con corrispondenze verso il NIST AI RMF, ISO/IEC 42001 e il regolamento europeo sull’IA. Che si affermi o meno proprio questo formato, l’esigenza che esprime è già concreta per chiunque metta in esercizio agenti di IA autonomi. Un agente non può leggere un PDF e dedurne il divieto di trasmettere dati di clienti a un modello esterno. Il vincolo deve esistere in una forma che il motore di esecuzione sappia valutare. Chi assume una decisione pluriennale ha quindi convenienza a pesare la rappresentazione strutturata delle policy e l’apertura del formato di esportazione più dell’ergonomia dell’editor.

Un piano di valutazione in 30 giorni

Settimana 1: inventariare l’esistente. Censite ogni policy, standard e procedura con il relativo responsabile, la data dell’ultima approvazione e la prossima scadenza di riesame. La maggior parte delle organizzazioni scopre due cose: diversi documenti non hanno alcun responsabile e il totale supera qualunque stima. In questa fase non acquistate nulla. Settimana 2: collegare i documenti agli obblighi. Per ciascuna voce annotate l’obbligo che la impone. Alcune non si collegheranno a nulla, il che di norma segnala un documento ereditato. Più utile ancora è l’elenco inverso: gli obblighi cui non corrisponde alcun documento. Sul versante dell’IA questo vuoto comprende in genere le misure di alfabetizzazione dell’articolo 4, una posizione sull’uso accettabile degli strumenti generativi e una regola di gestione dei cambiamenti di modello. Settimana 3: portare due policy dall’inizio alla fine. Scegliete una policy semplice e una che tocchi l’IA. Fatele transitare in ciascuno strumento in rosa dalla stesura all’approvazione, alla pubblicazione e alla presa visione mirata, quindi esportate la prova. È l’esportazione a costituire il test, non l’iter. Settimana 4: condurre un audit simulato. Scegliete una data collocata tre mesi indietro e chiedete a ciascuno strumento che cosa fosse allora vigente, chi ne avesse preso visione e quale prova attesti il funzionamento del controllo associato. Valutate quanta ricomposizione manuale ha richiesto la risposta. L’esercizio riproduce lo svolgimento di un audit dell’IA ed è l’unica parte della valutazione che predica il comportamento dello strumento sotto pressione.

Domande frequenti

Che cos’è un software per la gestione delle policy aziendali? Un software per la gestione delle policy aziendali governa l’intero ciclo di vita delle regole interne di un’organizzazione: stesura, riesame, approvazione, pubblicazione, distribuzione, presa visione, riesame periodico e ritiro. Sostituisce cartelle condivise e scambi di posta con iter obbligati, versionamento corredato di date di efficacia, un registro di chi ha confermato quale versione e una tracciatura che copre ogni modifica. I prodotti più maturi collegano inoltre ciascuna policy ai controlli e agli obblighi che essa serve. La gestione delle policy aziendali coincide con la gestione documentale? No. Un sistema di gestione documentale archivia file e tiene traccia delle versioni. La gestione delle policy aziendali vi aggiunge lo strato di governance: separazione obbligatoria tra stesura e approvazione, campagne di presa visione mirate, pianificazione dei riesami e reportistica pensata per i valutatori anziché per gli archivisti. Potete costruire quello strato sopra un sistema documentale, ma ve ne assumete sviluppo e manutenzione. Il regolamento europeo sull’IA impone un software per la gestione delle policy aziendali? Impone policy, non un prodotto determinato. L’articolo 4 obbliga fornitori e deployer ad adottare misure che garantiscano un livello sufficiente di alfabetizzazione in materia di IA, e l’articolo 53, paragrafo 1, lettera c) obbliga i fornitori di modelli per finalità generali a dotarsi di una policy di conformità al diritto d’autore. Nulla vi costringe ad acquistare uno strumento. In concreto, però, quando occorre dimostrare quale versione si applicava a chi e quando, il foglio di calcolo smette di reggere. Si veda la nostra guida alla conformità dell’IA. Serve una policy sull’IA autonoma oppure si possono estendere quelle esistenti? Entrambe le strade funzionano, e il controllo A.2 di ISO/IEC 42001 si attende proprio un allineamento con le altre policy dell’organizzazione anziché un documento isolato. Una policy sull’IA autonoma si dimostra di norma con maggiore facilità, perché il valutatore che chiede la policy sull’IA riceve un unico artefatto anziché clausole emendate distribuite su sei documenti. Qualunque strada scegliate, tenete la responsabilità nominativa e l’intervallo di riesame esplicito. Un software gratuito per la gestione delle policy aziendali può bastare? Per una piccola organizzazione con una manciata di policy e senza autorità di settore, uno strumento gratuito o già compreso in una suite è spesso proporzionato. Smette di esserlo nel momento in cui servono separazione obbligatoria dei ruoli, ricostruzione a una data passata o esportazione della prova, cioè esattamente le funzioni che le versioni gratuite omettono. Il prezzo dello strumento raramente è il fattore decisivo. Lo è il costo di ricomporre le prove a mano. Quanto costa un software per la gestione delle policy aziendali? I listini pubblici sono rari in questa categoria. La maggior parte dei fornitori quota per utente e per anno con l’aggiunta di un canone di piattaforma, e il totale dipende dal numero di persone tenute a confermare le policy assai più che dal numero di redattori. Definite quel numero di destinatari prima di richiedere le offerte, perché è la variabile che incide di più sul prezzo ed è quella che chi acquista sottostima più spesso. Con quale frequenza vanno riesaminate le policy? ISO/IEC 42001 richiede il riesame a intervalli pianificati senza fissarne la cadenza. La periodicità annuale è la scelta corrente e resta ragionevole per gli ambiti stabili. Per le policy sull’IA il solo intervallo di calendario non basta, perché obblighi e sistemi cambiano fra un ciclo e l’altro. Aggiungete inneschi legati a eventi: un nuovo atto normativo, un cambiamento significativo di modello o di fornitore, oppure un incidente.

Conclusione

Questa categoria si vende da un decennio sulla stessa promessa: togliere le policy dalle cartelle condivise e dimostrare che il personale le ha lette. Quella promessa è ormai il biglietto d’ingresso e non più l’elemento distintivo. La regolamentazione ha spostato l’asticella dalla distribuzione alla prova, e l’IA l’ha spostata più rapidamente di ogni altra cosa, perché i sistemi da governare cambiano assai più spesso di quanto prevedesse un ciclo di riesame annuale. Quando valutate una soluzione per la gestione delle policy aziendali, conducete l’audit simulato prima della dimostrazione funzionale. Uno strumento incapace di ricostruire che cosa fosse vigente nel trimestre scorso, e di produrne la prova, non sopravviverà all’incontro con un valutatore, per quanto piacevole possa risultare il suo editor. Se state costruendo quello strato probatorio specificamente per l’IA, partite dalla nostra guida alla governance dell’IA.