Policy AI: cosa possono inserire i dipendenti in Claude, guida alla stesura

Questa guida spiega come redigere una policy AI: cosa possono inserire i dipendenti in Claude, cosa non devono inserire mai e cosa possono inserire solo con cautele precise. Per policy AI intendiamo un documento interno breve, approvato dalla direzione, che stabilisce quali strumenti di intelligenza artificiale sono ammessi, con quali account e con quali dati.

Claude è l'assistente AI sviluppato da Anthropic. I dipendenti lo usano per scrivere, riassumere, analizzare documenti e, nelle configurazioni più avanzate, per agire su altri sistemi. Ogni volta che qualcuno incolla un testo o carica un file, quel contenuto esce dal sistema aziendale in cui si trovava e segue le regole del piano e dell'account da cui è stato inviato.

Anthropic stessa prevede questa esigenza. Il suo articolo su chi possiede e gestisce i dati di un team ricorda che l'organizzazione può avere proprie politiche interne sull'uso del piano Claude for Work. La policy è quindi il punto in cui la Sua azienda decide, per iscritto, ciò che il contratto con il fornitore lascia alla Sua scelta.

Una buona policy copre cinque temi: strumenti e piani approvati, quali dati possono entrare e quali mai, chi approva le eccezioni, quale registro si tiene e chi ne risponde. Le sezioni che seguono affrontano ciascun tema, con una tabella decisionale e un esempio concreto.

La distinzione più importante non riguarda il testo che si scrive, ma l'account da cui lo si invia. Anthropic separa i prodotti consumer, cioè Claude Free, Pro e Max, dai prodotti commerciali, cioè Claude for Work sui piani Team o Enterprise e l'API di Anthropic.

Per i prodotti commerciali l'uso dell'account è regolato dall'accordo tra Anthropic e l'organizzazione. Le condizioni d'uso consumer e l'informativa privacy consumer non si applicano all'uso del piano Claude for Work, in cui Anthropic agisce come responsabile del trattamento dei dati (data processor). I piani Free, Pro e Max, anche quando usati con Claude Code, seguono invece regole proprie, descritte separatamente.

La conseguenza pratica è netta. Se un dipendente usa un account personale Pro per lavorare su un contratto aziendale, quel contenuto non rientra nell'accordo che la Sua azienda ha firmato. La policy deve quindi dire in apertura quali piani sono approvati e vietare l'inserimento di qualsiasi dato aziendale in account personali, anche per compiti che sembrano banali.

Il secondo effetto è organizzativo: sui piani commerciali l'organizzazione decide quali servizi e funzioni di Claude i dipendenti possono usare e può limitarne alcune. La policy scritta e la configurazione dell'account devono dire la stessa cosa, altrimenti una delle due viene ignorata.

Il cuore della policy è una classificazione in tre categorie, facile da ricordare per chi non si occupa di sicurezza.

• Consentito: contenuti che la Sua azienda pubblicherebbe senza problemi o che non identificano persone né rivelano informazioni riservate. Esempi: testi del sito, bozze di procedure generiche, domande tecniche senza dati reali.
• Con cautele: contenuti riservati ma necessari al lavoro, ammessi solo su account aziendali approvati, nella forma minima indispensabile e, dove previsto, con approvazione. Esempi: estratti di contratti, dati di clienti ridotti a quanto serve, documenti interni.
• Mai: contenuti che non devono entrare in una conversazione, qualunque sia l'account. Esempi: credenziali e chiavi di accesso, buste paga, dati sanitari, documenti fiscali personali di dipendenti e familiari.

La categoria intermedia è quella che richiede più lavoro, perché è lì che si concentra il valore d'uso di Claude. Vietarla del tutto spinge le persone verso account personali; lasciarla libera espone l'azienda. Le cautele vanno quindi scritte come azioni verificabili: quale account, quale riduzione dei dati, chi approva.

Quando in Svennis introduciamo Claude nei sistemi aziendali dei clienti, partiamo dall'elenco dei gestionali da cui i dipendenti copiano i dati, non da un elenco astratto di tipi di dato: è guardando le esportazioni reali che si capisce che cosa rischia di finire in una conversazione.

La tabella seguente è il riferimento rapido che i dipendenti dovrebbero consultare prima di incollare un contenuto. Conviene allegarla alla policy e renderla disponibile dove le persone lavorano, non solo nella intranet.

Se un caso non rientra in nessuna riga, la regola di default è trattarlo come "con cautele" e chiedere al referente indicato nella policy. Ogni richiesta di questo tipo va poi usata per aggiornare la tabella alla revisione successiva.

Prendiamo un'impresa che gestisce presenze, note spese e buste paga con Dipendenti in Cloud. In questo software una nota spese si crea inserendo categoria di spesa e importo e allegando scontrini o ricevute, e resta in attesa fino all'approvazione. I cedolini vengono caricati e il software si occupa di smistamento, distribuzione e archiviazione.

La responsabile amministrativa vuole che Claude la aiuti a preparare il commento mensile sulle spese di trasferta. Applicando la tabella, le decisioni sono queste:

• Totali per categoria di spesa, senza nomi: consentito, perché non identifica nessuno.
• Elenco delle note spese con nomi e scontrini allegati: con cautele. Si riduce l'estratto a quanto serve, si tolgono i nomi e lo si usa solo su account aziendale.
• Cedolini: mai. Il lavoro sulle buste paga resta nel gestionale.

Poco dopo un collega chiede aiuto per controllare la propria dichiarazione precompilata. Nella sezione Oneri e spese dell'Agenzia delle Entrate compaiono categorie come Sanità, previdenza e assicurazioni, e i dati dei familiari a carico si consultano selezionando il loro codice fiscale. Un documento di questo tipo contiene dati sanitari e identificativi di terzi: è nella categoria "mai".

L'esempio mostra anche perché conviene lasciare i dati dove già esistono permessi. Dipendenti in Cloud consente di aggiungere più amministratori scegliendo per ciascuno sezioni e livello di accesso, e di delegare presenze e assenze a supervisori con permessi stabiliti dall'amministratore. Copiare quei dati in una chat li sottrae a questi controlli.

La policy deve nominare una persona responsabile. Sui piani Claude for Work questa figura esiste già: il Primary Owner, cioè la persona designata dall'organizzazione per gestire l'account Work e tutti i dati associati. Il Primary Owner può richiedere esportazioni dei dati, che possono contenere conversazioni con Claude, file caricati e modalità di utilizzo, e può rimuovere l'accesso di un utente.

Questo punto va scritto nella policy anche per trasparenza verso i dipendenti: le conversazioni su un account aziendale possono essere esportate dall'organizzazione. Chi lo sa sceglie con più attenzione che cosa scrivere.

Per chi usa l'API, l'Admin API di Anthropic permette di gestire membri, workspace, inviti e chiavi API in modo programmatico invece che a mano nella Claude Console. Alcuni dettagli incidono direttamente sulla policy:

• esistono cinque ruoli a livello di organizzazione e solo i membri con ruolo admin possono creare chiavi Admin API;
• le chiavi personali smettono di funzionare quando l'utente viene rimosso, mentre le chiavi dei service account continuano a funzionare anche se chi le ha create lascia l'organizzazione;
• gli inviti scadono dopo 21 giorni e la scadenza non è configurabile;
• l'API non può rimuovere i membri con ruolo admin.

La conseguenza: quando un dipendente lascia l'azienda, la procedura di uscita deve includere la verifica delle chiavi dei service account, che non si disattivano da sole.

Una policy seria non può dare per scontato che quanto si inserisce sparisca subito. Anthropic ha pubblicato una pagina sulle pratiche di conservazione per i modelli coperti, in vigore dal 9 giugno 2026. Per modelli coperti si intendono i modelli di classe Mythos e i modelli futuri con capacità simili che Anthropic designa come tali.

Per questi modelli i prompt inviati e le risposte generate vengono conservati per 30 giorni, su ogni piattaforma in cui i modelli sono offerti. La modifica riguarda le organizzazioni che hanno configurato la conservazione zero (zero data retention, ZDR) nella Claude Console, usano Claude Code con ZDR in Claude Enterprise o accedono a Claude tramite AWS Bedrock, Google Cloud o Microsoft Foundry con ZDR. Chat e Cowork tramite Claude for Enterprise operano già con conservazione standard, mentre i piani consumer non cambiano perché i dati vi sono già conservati.

La pagina precisa che per impostazione predefinita nessun dipendente di Anthropic può leggere le conversazioni conservate, che ogni accesso viene registrato in un log non modificabile e che dopo 30 giorni i dati vengono cancellati, salvo casi segnalati dai sistemi automatici o obblighi di legge.

Per la policy la lezione è semplice: le categorie si definiscono assumendo che il contenuto venga conservato per un periodo. Se usa Claude Cowork in azienda, lo tenga presente nel classificare i documenti ammessi.

Quando Claude non si limita a rispondere ma compie azioni, la policy deve contenere regole specifiche. Un esempio è lo strumento computer use, che secondo la documentazione di Anthropic fornisce schermate e controllo di mouse e tastiera per interagire con un desktop in un ambiente controllato dall'applicazione. Il ciclo in cui Claude chiede un'azione, riceve il risultato e prosegue senza intervento dell'utente si chiama agent loop.

La stessa documentazione avverte che, in alcune circostanze, Claude segue comandi trovati nei contenuti, come pagine web o immagini, anche quando contrastano con le istruzioni dell'utente. Anthropic applica classificatori che analizzano automaticamente ciò che gli strumenti restituiscono, come le schermate, per segnalare possibili prompt injection, cioè istruzioni malevole nascoste nei contenuti.

Altri due elementi contano per la policy. Schermate, azioni del mouse, input da tastiera e file di una sessione vengono acquisiti e conservati nell'ambiente del cliente, non da Anthropic: la responsabilità della loro custodia resta quindi alla Sua azienda. Inoltre i termini di servizio vietano di usare computer use per violare leggi o la Acceptable Use Policy.

Regola pratica: gli strumenti che agiscono da soli richiedono un'approvazione separata, un ambiente dedicato e la verifica umana delle azioni con effetti esterni. Il nostro post su che cosa sono gli agenti AI mostra come si organizza questo controllo in un caso reale.

Una policy efficace sta in poche pagine. La struttura che segue copre tutti i temi visti finora e può essere adattata alle dimensioni della Sua impresa.

1. Scopo e ambito: a chi si applica, compresi collaboratori esterni e consulenti con accesso ai dati aziendali.
2. Strumenti e piani approvati: quali piani Claude sono ammessi, divieto di account personali per dati aziendali, quali funzioni sono abilitate.
3. Classificazione dei dati: le tre categorie con la tabella decisionale allegata.
4. Approvazioni: chi autorizza i casi "con cautele" che lo richiedono, le integrazioni con altri sistemi e gli strumenti che agiscono da soli.
5. Registro: elenco di utenti, ruoli, chiavi API, service account e integrazioni attive, con data di approvazione e responsabile. Chi usa l'API può appoggiarsi al feed attività della Compliance API, l'unica parte che le chiavi Admin API possono leggere.
6. Responsabilità: il Primary Owner, un referente per le domande quotidiane, i responsabili di reparto.
7. Errori e segnalazioni: che cosa fare se un dato vietato viene inserito per errore, a chi scrivere, entro quando.
8. Revisione: data della prossima revisione e criteri per aggiornare la tabella.

La sezione sugli errori è spesso quella che manca. Una persona che ha incollato una chiave API per sbaglio deve sapere che segnalarlo subito è la cosa giusta, e che la chiave va revocata senza discussioni.

Per un'impresa italiana il rischio più frequente non riguarda i documenti strategici, ma quelli amministrativi di tutti i giorni. Come mostra l'esempio della precompilata, i documenti fiscali collegano spese e familiari a carico ai codici fiscali, e le pratiche del personale contengono dati sanitari e retributivi. La categoria "mai" va quindi scritta con esempi presi dai moduli e dai gestionali che i Suoi uffici usano davvero.

Un secondo tema è il rapporto con i professionisti esterni. Dipendenti in Cloud, per esempio, permette di collegare alla piattaforma il consulente del lavoro o il commercialista, che accede ai dati necessari per le paghe. La policy deve chiarire se e come questi soggetti possono usare Claude sui dati della Sua azienda; chi opera in questo ambito trova spunti nella nostra pagina sull'intelligenza artificiale per commercialisti.

Infine, la policy interna non sostituisce il quadro normativo, ma deve essere coerente con esso e con il contratto firmato con Anthropic. Per le norme applicabili può consultare la nostra panoramica sul quadro normativo AI in Italia e il testo annotato dell'AI Act. Conviene far rileggere la policy da chi in azienda cura la protezione dei dati prima della pubblicazione.

Una policy si può introdurre in cinque giorni lavorativi se le decisioni vengono prese dalle persone giuste, senza lunghi giri di commenti.

1. Giorno 1, inventario: elencare chi usa già Claude, con quali account, e da quali gestionali copia dati. Individuare il Primary Owner.
2. Giorno 2, classificazione: compilare la tabella decisionale con esempi reali di ogni reparto, partendo dalle esportazioni più frequenti.
3. Giorno 3, configurazione: allineare l'account aziendale alla policy, limitando le funzioni non approvate, verificando ruoli, chiavi e inviti in sospeso.
4. Giorno 4, approvazione: far approvare il testo dalla direzione e da chi cura la protezione dei dati, nominare il referente.
5. Giorno 5, comunicazione: presentare la policy in una breve riunione per reparto, con la tabella e due esempi del reparto stesso, e aprire il registro.

Nelle settimane successive raccolga le domande arrivate al referente. Le domande ricorrenti indicano quali righe della tabella sono poco chiare e vanno riscritte alla prima revisione.

Se la Sua azienda collega Claude a sistemi come Zoho CRM o Zoho Desk, l'integrazione va inserita nel registro come uno strumento a sé, con il proprio responsabile e i propri permessi.

Per passare dalla lettura all'azione, proceda in quest'ordine:

• verifichi oggi quali piani Claude sono in uso in azienda e se qualcuno lavora su dati aziendali con account personali Free, Pro o Max;
• designi il Primary Owner e un referente per le domande quotidiane, se non esistono già;
• prepari la tabella decisionale con tre esempi reali per categoria, presi dai gestionali più usati;
• controlli chiavi API e service account attivi, perché non si disattivano quando chi li ha creati lascia l'azienda;
• fissi la data della prima revisione, preferibilmente dopo un mese di uso.

Se vuole capire prima da dove partire, la nostra valutazione della prontezza all'AI aiuta a individuare i sistemi, i dati e le persone da coinvolgere. È un buon punto di partenza per stabilire quali regole scrivere per prime e quali integrazioni rimandare a una fase successiva.

La policy non deve essere perfetta al primo giro. Deve essere chiara, applicata dall'account aziendale e rivista con regolarità.