Prompting e policy interne nella PA: come usare LLM senza data leak e senza allucinazioni operative

Gli LLM, cioè i grandi modelli linguistici alla base di molti strumenti di intelligenza artificiale generativa, possono essere molto utili nella Pubblica Amministrazione. Possono aiutare a cercare informazioni, sintetizzare documenti, preparare bozze, confrontare testi, supportare operatori, individuare incongruenze e rendere più accessibili procedure complesse.

Ma possono anche creare problemi seri se vengono usati senza regole.

Il rischio non è solo che l’AI “sbagli”. Il rischio è che un ente pubblico inserisca dati non appropriati in strumenti non governati, produca risposte apparentemente convincenti ma non fondate su fonti interne, generi bozze con errori operativi, diffonda procedure non validate o lasci che ogni ufficio adotti strumenti diversi senza controllo.

In altre parole: il problema non è il prompting in sé. Il problema è usare LLM senza una policy interna, senza fonti autorizzate, senza regole sui dati, senza controllo umano e senza criteri di qualità.

Per questo un ente pubblico complesso — Regione, ASL, Università, ente territoriale multi-sede, azienda sanitaria o istituto pubblico articolato — dovrebbe affrontare il tema in modo pratico: non vietare tutto per paura e non aprire tutto per entusiasmo. Serve una via intermedia, governata e misurabile.

Questo contenuto prosegue il pillar su AI nei flussi documentali della PA, dove il punto centrale era distinguere cosa automatizzare davvero e cosa no. Qui il focus è più specifico: come usare gli LLM nei processi documentali e organizzativi senza generare data leak, allucinazioni operative o responsabilità opache.

Che cosa intendiamo per prompting in un ente pubblico

Il prompting è il modo in cui un utente formula una richiesta a un modello linguistico.

Nel contesto della PA può significare chiedere a un LLM di:

• riassumere un documento;
• estrarre punti chiave;
• trasformare un testo tecnico in una versione più chiara;
• confrontare due versioni di una procedura;
• generare una bozza di risposta;
• individuare possibili incongruenze;
• suggerire metadati;
• preparare una checklist;
• rispondere a una domanda usando una knowledge base interna.

Il prompting, quindi, non è solo una competenza “creativa”. È una competenza operativa. Se usato male, può produrre risposte inutili o pericolose. Se usato bene, può ridurre tempi, migliorare comprensione e supportare il lavoro degli uffici.

Ma negli enti pubblici il prompting non può essere lasciato solo alla sensibilità individuale. Deve essere inserito in una cornice di regole.

Il primo rischio: data leak

Il data leak è la fuoriuscita, volontaria o involontaria, di informazioni che non dovrebbero essere condivise con uno strumento, un fornitore, un ambiente o un modello non governato.

Nel caso degli LLM, il rischio nasce quando un utente copia dentro il prompt:

• dati personali;
• dati sanitari;
• informazioni su minori o soggetti fragili;
• dati disciplinari;
• dati giudiziari;
• documenti riservati;
• atti non pubblicabili;
• credenziali;
• chiavi API;
• informazioni su vulnerabilità;
• documenti interni non destinati a strumenti esterni;
• contenuti coperti da riservatezza o vincoli contrattuali.

Il problema non è soltanto “quale strumento uso”. È anche: in quale ambiente sto lavorando? I dati vengono conservati? Sono usati per addestramento? Dove vengono trattati? Chi può accedervi? Il contratto lo consente? L’ente ha autorizzato quello specifico uso?

Una policy interna deve dare risposte semplici a queste domande, perché l’utente operativo non può ogni volta improvvisare una valutazione legale, tecnica e organizzativa. Il tema si intreccia direttamente con la security-by-design nella gestione documentale: gli stessi principi di minimizzazione e controllo degli accessi valgono anche quando l’interfaccia è un prompt.

Il secondo rischio: allucinazioni operative

Le allucinazioni sono risposte generate dal modello che sembrano plausibili, ma non sono corrette o non sono supportate da fonti affidabili.

In un contesto pubblico questo rischio è particolarmente delicato. Un conto è una risposta sbagliata in una bozza privata. Un altro è una risposta che entra in una procedura, in una comunicazione, in un’istruzione operativa, in una valutazione documentale o in un supporto agli utenti.

Le allucinazioni operative possono produrre:

• riferimenti normativi inesatti;
• procedure interne inventate;
• sintesi incomplete;
• classificazioni documentali sbagliate;
• suggerimenti di pubblicazione non corretti;
• indicazioni privacy troppo generiche;
• risposte agli operatori non allineate al manuale dell’ente;
• decisioni basate su testi non verificati.

Per questo la regola deve essere chiara: un LLM può aiutare a preparare, ordinare, sintetizzare e suggerire. Ma le risposte operative devono essere verificate su fonti governate.

Policy interna: il documento che evita il fai-da-te

Una policy interna sull’uso degli LLM non deve essere lunga e incomprensibile. Deve essere chiara, applicabile e leggibile da chi lavora davvero sui documenti.

Dovrebbe rispondere almeno a queste domande:

• quali strumenti AI sono autorizzati;
• quali strumenti non sono autorizzati;
• quali dati possono essere inseriti;
• quali dati non devono mai essere inseriti;
• quali casi d’uso sono ammessi;
• quali casi d’uso richiedono autorizzazione;
• quando è obbligatorio il controllo umano;
• quali fonti devono essere usate;
• come citare o verificare le fonti;
• come gestire output incerti;
• chi risponde in caso di errore;
• come vengono tracciati usi, decisioni e validazioni.

La policy non dovrebbe limitarsi a dire “usare con cautela”. Questa formula non aiuta nessuno. Deve tradurre la cautela in comportamenti concreti. Anche il Regolamento UE 2024/1689 (Artificial Intelligence Act) segue questa logica: obblighi proporzionati al rischio del caso d’uso, non divieti generici.

Classificare i casi d’uso per livello di rischio

Un modo pratico per costruire la policy è distinguere i casi d’uso in base al rischio.

Basso rischio · supporto generale senza dati riservati

Attività di supporto generale, senza dati personali o documenti riservati.

Esempi:

• riscrivere un testo pubblico in linguaggio più chiaro;
• preparare una scaletta;
• generare una checklist generica;
• semplificare una comunicazione già destinata alla pubblicazione;
• creare bozze non operative da validare.

In questi casi la policy può essere più flessibile, purché l’output non venga usato come fonte ufficiale senza verifica.

Medio rischio · documenti interni e bozze operative

Attività su documenti interni, procedure, contenuti organizzativi o bozze operative.

Esempi:

• sintetizzare una procedura interna;
• confrontare due versioni di un documento;
• preparare una bozza di istruzione operativa;
• suggerire metadati;
• individuare incoerenze in un flusso;
• creare FAQ per operatori.

Qui servono fonti autorizzate, controllo umano e divieto di inserire dati personali non necessari.

Alto rischio · dati personali e decisioni amministrative

Attività che coinvolgono dati personali, documenti sensibili, pubblicazione, decisioni amministrative, valutazioni privacy, procedimenti disciplinari, contenziosi o documentazione sanitaria.

In questi casi l’uso deve essere limitato, autorizzato e controllato. In molti scenari l’LLM può al massimo supportare l’analisi, ma non sostituire il giudizio umano o la procedura dell’ente.

Regole pratiche per evitare data leak

Una policy efficace dovrebbe includere regole semplici.

1. Non inserire dati personali se non necessario

Se il compito può essere svolto con dati anonimizzati, sintetici o generalizzati, usare quelli.

2. Non incollare documenti integrali riservati in strumenti non autorizzati

Soprattutto se non è chiaro come vengono trattati i dati.

3. Non inserire credenziali, token, chiavi o configurazioni tecniche sensibili

Questo divieto deve essere assoluto.

4. Usare ambienti approvati dall’ente

Gli strumenti AI devono essere valutati, autorizzati e contrattualizzati quando necessario.

5. Separare bozza e decisione

Un output AI può essere una bozza, non una decisione finale.

6. Annotare quando l’AI è stata usata nei casi rilevanti

Non sempre serve tracciare ogni uso banale, ma nei processi delicati deve restare evidenza del supporto AI e della validazione umana.

7. Evitare prompt con più dati del necessario

Il principio è simile alla minimizzazione: dare al modello solo ciò che serve davvero al compito.

Regole pratiche per ridurre le allucinazioni

Anche qui servono regole operative.

1. Chiedere sempre risposte basate su fonti

Quando si lavora su procedure interne, manuali o documenti dell’ente, il modello deve rispondere usando solo quelle fonti.

2. Pretendere riferimenti puntuali

Per sintesi, confronti o risposte operative, l’output dovrebbe indicare da quali documenti o sezioni deriva.

3. Evitare domande troppo generiche

Domande vaghe producono risposte vaghe. Meglio chiedere compiti specifici, con contesto e formato desiderato.

4. Non chiedere al modello di “inventare” regole

Se una procedura non esiste, il modello può proporre una bozza, ma deve essere chiaro che non si tratta di regola interna validata.

5. Far emergere incertezza e limiti

Un buon prompt dovrebbe chiedere al modello di segnalare cosa non può verificare.

6. Verificare sempre riferimenti normativi, dati e procedure

Gli LLM possono sbagliare citazioni, date, riferimenti e interpretazioni. In ambito PA, questi elementi non vanno mai accettati senza controllo.

Prompt utili e prompt pericolosi

Prompt utile · sintesi vincolata alle fonti

“Usando esclusivamente il documento allegato, sintetizza i passaggi operativi della procedura in 10 punti. Se un’informazione non è presente, scrivi ‘non indicato nel documento’. Non aggiungere interpretazioni normative.”

Questo prompt è utile perché limita le fonti, impone una forma, chiede di non inventare e forza il modello a dichiarare i vuoti.

Prompt pericoloso · consiglio generale senza fonti

“Dimmi qual è la procedura corretta per pubblicare questi atti e oscurare i dati personali.”

Questo prompt è pericoloso perché chiede una risposta generale su un tema delicato, senza fonti interne, senza contesto, senza responsabilità e senza verifica. Su questi temi valgono le regole illustrate in trasparenza vs privacy nella PA e nella redaction operativa, non l’intuizione di un modello.

Prompt utile · confronto tra due versioni

“Confronta queste due versioni della procedura e indica solo le differenze operative. Non dare suggerimenti, limitati a riportare cosa cambia tra versione A e versione B.”

Prompt pericoloso · «rendila conforme» senza riferimenti

“Riscrivi questa procedura migliorandola e rendendola conforme.”

Perché “conforme” a cosa? A quale norma? A quale policy interna? Con quale validazione?

Prompt utile · riscrittura di un testo già pubblico

“Analizza questo testo pubblico già approvato e proponi una versione più chiara per cittadini, mantenendo invariato il contenuto sostanziale.”

Prompt pericoloso · risposta ufficiale al cittadino

“Prepara una risposta ufficiale al cittadino su questo caso.”

Soprattutto se il caso contiene dati personali, diritti, scadenze o valutazioni amministrative.

Come costruire una libreria di prompt approvati

Un ente può ridurre il rischio creando una piccola libreria di prompt approvati.

Non serve partire con decine di modelli. Bastano prompt per attività ricorrenti e a rischio controllato.

Esempi:

• sintesi di procedura interna;
• checklist da documento validato;
• confronto tra versioni;
• semplificazione linguistica di testo pubblico;
• estrazione di punti operativi;
• preparazione di FAQ basate su knowledge base;
• individuazione di dati da verificare in un atto, senza decisione automatica;
• bozza di comunicazione interna da validare.

Ogni prompt approvato dovrebbe indicare:

• scopo;
• dati ammessi;
• dati vietati;
• fonti da usare;
• output atteso;
• obbligo di verifica;
• casi in cui non va usato.

Questa libreria aiuta gli uffici a usare l’AI in modo più omogeneo, evitando sperimentazioni casuali.

LLM e knowledge base interna

Uno degli usi più promettenti per la PA è collegare un assistente AI a una knowledge base interna validata.

Per esempio:

• manuale di gestione documentale;
• procedure interne;
• istruzioni su protocollo e fascicolazione;
• policy di pubblicazione;
• checklist operative;
• FAQ per operatori;
• linee guida interne su metadati;
• procedure di sicurezza;
• documenti di progetto approvati.

In questo scenario, l’LLM non dovrebbe “sapere tutto”. Dovrebbe rispondere solo sulla base delle fonti autorizzate.

La qualità della knowledge base diventa quindi decisiva. Se le fonti sono vecchie, incoerenti o non validate, l’assistente produrrà risposte deboli anche con un buon modello. Per questo il lavoro sui metadati per enti complessi e sulla governance documentale negli enti complessi non è un prerequisito formale: è ciò che rende l’assistente affidabile.

Governance minima per l’uso degli LLM

Un ente dovrebbe definire almeno questi elementi.

Owner della policy

Chi mantiene aggiornata la policy e decide le regole generali.

Elenco strumenti autorizzati

Quali piattaforme possono essere usate e in quali condizioni.

Classificazione dei dati

Quali dati possono essere inseriti, quali solo in ambienti protetti e quali mai.

Casi d’uso autorizzati

Quali attività sono ammesse, limitate o vietate.

Controllo umano

Quando è obbligatorio e chi lo effettua.

Registro o tracciamento degli usi rilevanti

Non per controllare ogni bozza, ma per presidiare processi delicati.

Formazione

Gli utenti devono capire non solo come scrivere prompt, ma anche quando non usarli.

Riesame periodico

La policy va aggiornata perché strumenti, rischi, contratti e casi d’uso cambiano.

Chi deve essere coinvolto

La policy sugli LLM non può essere scritta solo dall’IT o solo dalla funzione privacy.

Dovrebbero essere coinvolti:

• RTD;
• Responsabile della gestione documentale;
• Responsabile della conservazione, quando l’uso impatta fascicoli, evidenze o ciclo documentale;
• IT e sicurezza;
• DPO / privacy;
• ufficio legale;
• dirigenti delle aree coinvolte;
• referenti operativi;
• formazione interna.

Qui torna utile la logica della matrice RACI nella PA: un uso maturo degli LLM deve chiarire chi autorizza, chi usa, chi controlla, chi aggiorna e chi risponde.

Un template essenziale di policy interna

Una policy minima può essere strutturata così.

1. Oggetto e finalità

Definire perché l’ente disciplina l’uso degli LLM e quali obiettivi vuole raggiungere: efficienza, qualità, supporto agli operatori, riduzione errori, sicurezza dei dati.

2. Ambito di applicazione

Indicare chi può usare gli strumenti, per quali attività e su quali processi.

3. Strumenti autorizzati

Elencare strumenti approvati e condizioni d’uso.

4. Dati ammessi e dati vietati

Definire categorie di dati che possono o non possono essere inserite nei prompt.

5. Casi d’uso consentiti

Indicare attività ammesse e limiti.

6. Casi d’uso vietati o soggetti ad autorizzazione

Per esempio decisioni amministrative, valutazioni su diritti, dati sensibili, documenti riservati, oscuramenti definitivi o risposte ufficiali senza controllo.

7. Regole di prompting

Definire buone pratiche: fonti, limiti, richiesta di incertezza, divieto di inventare, formato output, controllo.

8. Validazione degli output

Stabilire quando e come l’output deve essere verificato.

9. Tracciabilità

Definire quando l’uso dell’AI deve essere documentato.

10. Formazione e aggiornamento

Prevedere formazione minima e revisione periodica della policy.

Test rapido: il tuo ente è pronto?

Prova a rispondere a queste domande:

• sappiamo quali strumenti AI sono autorizzati?
• gli utenti sanno quali dati non inserire mai?
• esistono prompt approvati per attività ricorrenti?
• le risposte operative devono citare fonti interne?
• è chiaro quando serve controllo umano?
• gli output AI non vengono usati come decisioni finali?
• esiste una policy scritta e comprensibile?
• esiste un owner della policy?
• gli utenti sono formati sui rischi di data leak e allucinazioni?

Se molte risposte sono negative, il problema non è tecnologico. È di governance. Un AI readiness assessment aiuta a trasformare queste risposte in un percorso ordinato.

Da dove partire nei prossimi 60 giorni

Un percorso realistico può essere questo.

Giorni 1-20 · Raccogli gli usi AI già presenti negli uffici

Raccogliere gli usi AI già presenti o probabili negli uffici.

Giorni 1-20 · Classifica i casi d’uso per livello di rischio

Classificare i casi d’uso per rischio: basso, medio, alto.

Giorni 21-40 · Scrivi una policy minima di 3-5 pagine

Definire una policy minima di 3-5 pagine, chiara e operativa.

Giorni 21-40 · Crea una prima libreria di prompt approvati

Creare una prima libreria di prompt approvati.

Giorni 41-60 · Forma un gruppo pilota sui casi a basso rischio

Formare un gruppo pilota su casi a basso rischio.

Giorni 41-60 · Misura i risultati e aggiorna la policy

Misurare errori, benefici, criticità e aggiornare la policy prima di estendere l’uso.

L’obiettivo non è fermare l’innovazione. È renderla sicura, utile e sostenibile.

Usare gli LLM senza perdere il controllo

Gli LLM possono aiutare davvero gli enti pubblici, ma solo se vengono usati con fonti affidabili, dati protetti, prompt controllati, responsabilità chiare e verifica umana.

Scopri come Docsuite Next può aiutarti a costruire knowledge base, workflow e assistenti documentali più sicuri, tracciabili e coerenti con le policy del tuo ente.

Domande frequenti

Che cosa deve contenere una policy interna sugli LLM?

Deve indicare strumenti autorizzati, dati ammessi e vietati, casi d’uso consentiti, casi vietati o soggetti ad autorizzazione, regole di prompting, controllo umano, tracciabilità e formazione.

Qual è il rischio principale nell’uso degli LLM nella PA?

I rischi principali sono data leak, cioè inserimento di dati non appropriati in strumenti non governati, e allucinazioni operative, cioè risposte plausibili ma non fondate su fonti validate.

Si possono usare LLM per scrivere procedure interne?

Sì, ma come supporto alla bozza o alla revisione. La procedura finale deve essere validata dai ruoli competenti e non può essere considerata corretta solo perché prodotta da un modello.

Come si riducono le allucinazioni?

Limitando le fonti, chiedendo riferimenti puntuali, imponendo al modello di dichiarare ciò che non sa, evitando prompt vaghi e verificando sempre output, dati e riferimenti.

Serve formare gli operatori sul prompting?

Sì. Ma la formazione non deve riguardare solo “come scrivere prompt migliori”. Deve spiegare anche dati vietati, rischi, limiti, controllo umano e casi in cui l’AI non va usata.