Sviluppo LLM nella PA

Sviluppo LLM nella PA: la guida tecnica per sviluppatori e AI engineer

Analisi delle Linee Guida AgID per lo sviluppo di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione: come leggerle, applicarle e partecipare alla loro evoluzione.

Indice Sviluppo LLM nella PA

1. Scopo del documento e come applicarlo
2. Il quadro normativo di riferimento
3. Le famiglie di sistemi di IA nella PA
4. Lo Stack IA: i cinque livelli tecnologici
5. Il modello di Architettura AI di riferimento per la PA
6. Il ciclo di vita dei sistemi AI nella PA
7. Buone pratiche di sicurezza per la PA
8. La consultazione pubblica: come contribuire alle linee guida
9. Conclusioni: padroneggiare gli LLM è un vantaggio competitivo

1. Scopo del documento e come applicarlo – Sviluppo LLM nella PA

AgID (l’Agenzia per l’Italia Digitale) ha pubblicato la Bozza di Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione, un documento tecnico-normativo di 109 pagine redatto ai sensi del D.P.C.M. 12 gennaio 2024 (Piano Triennale per l’informatica nella PA 2024-2026) e in allineamento con la Legge 132/2025, l’AI Act europeo e il GDPR.

L’obiettivo è chiaro: fornire alle PA, e ai team di sviluppo che lavorano per esse, un framework operativo per progettare, sviluppare, testare, mettere in produzione e dismettere sistemi di IA in modo conforme, sicuro, sostenibile e governabile.

Il documento si rivolge esplicitamente a tutti i soggetti di cui all’art. 2, comma 2, del Codice dell’Amministrazione Digitale (CAD): ministeri, enti locali, agenzie pubbliche, università, aziende sanitarie e ogni organismo che rientra nella definizione di pubblica amministrazione.

Come si applica concretamente? Le linee guida usano una terminologia normativa precisa, mutuata dagli standard ISO/IEC: DEVE/DEVONO indica requisiti obbligatori, DOVREBBE/NON DOVREBBE indica raccomandazioni da valutare attentamente, PUÒ/POSSONO indica opzioni discrezionali. Un team di sviluppo che lavora per una PA deve quindi trattare ogni “DEVE” come un vincolo di progetto vero e proprio, non come un suggerimento.

Il documento è accompagnato da Strumenti operativi (allegati tecnici) che possono essere aggiornati in modo indipendente per seguire l’evoluzione tecnologica, una scelta architetturale intelligente per garantire longevità alle linee guida pur in un settore che si evolve rapidamente.

2. Il quadro normativo di riferimento – Sviluppo LLM nella PA

Prima di entrare nel merito tecnico, è utile avere chiaro l’ecosistema normativo entro cui questi sistemi devono operare. Le linee guida citano esplicitamente: l’AI Act (Reg. UE 2024/1689), il GDPR, il Cyber Resilience Act (CRA), la direttiva NIS 2, il Data Act e la legge italiana 132/2025 sull’Intelligenza Artificiale.

Per un AI engineer che lavora su una commessa pubblica, questo si traduce in una lista di vincoli da mappare fin dalle prime fasi di progettazione: classificazione del rischio del sistema AI, misure di data protection by design, requisiti di spiegabilità (explainability), audit trail e gestione delle vulnerabilità nel ciclo di vita del software.

3. Le famiglie di sistemi di IA nella PA – Sviluppo LLM nella PA

Le linee guida classificano i sistemi di IA in una tassonomia progressiva che vale la pena comprendere bene, perché determina il livello di attenzione normativa richiesto:

• IA classica (rule-based, sistemi esperti)
• IA Statistica / Data-driven (modelli probabilistici, regressioni)
• Machine Learning (algoritmi che apprendono da dati)
• Reti Neurali e Deep Learning
• Generative AI — la famiglia più recente, che include i Large Language Model (LLM)

Gli LLM occupano la punta di questa piramide e, secondo le rilevazioni condotte da AgID nel 2025 su PA centrali e locali, sono già ampiamente adottati in produzione. Il documento riconosce esplicitamente che l’uso dell’IA “si è rapidamente trasformato da iniziative sperimentali verso realizzazioni essenziali e strategiche”.

4. Lo Stack IA: i cinque livelli tecnologici – Sviluppo LLM nella PA

Il cuore architetturale del documento è la definizione dello Stack IA, una stratificazione funzionale che ogni PA deve presidiare quando sviluppa soluzioni AI end-to-end. I cinque livelli, dal basso verso l’alto, sono:

Energy Layer (Livello Energetico): la base fisica. Riguarda alimentazione, raffreddamento e sostenibilità dei data center. Per la PA è rilevante sia per i costi operativi che per la resilienza dei servizi. Le linee guida prescrivono di stimare ex ante l’impatto energetico del training e dell’inferenza, tenendo conto anche degli impatti sulla rete elettrica locale.

Chip Layer (Livello Computazionale): GPU, TPU, ASIC, memorie HBM. Le scelte su questo layer influenzano direttamente la portabilità dei modelli. La regola d’oro prescritta è la neutralità hardware: progettare sistemi che non dipendano da uno specifico acceleratore, prevedendo sempre percorsi di fallback su CPU.

Infrastructure Layer (Livello Infrastrutturale): data center, cloud pubblico/privato/ibrido, container orchestration, storage distribuito, reti ad alta velocità. Questo è il layer su cui si innestano i requisiti di qualificazione cloud (Regolamento ACN n. 21007) e i principi di sovranità del dato. Kubernetes, microservizi e API standard sono le tecnologie raccomandate.

AI Model Layer (Livello dei Modelli IA): il “cuore logico” dell’IA. Comprende framework ML/DL, pipeline di addestramento, strumenti di fine-tuning, MLOps, versioning, explainability e, naturalmente, gli LLM. Le scelte a questo livello incidono direttamente su correttezza, qualità, gestione del rischio e conformità normativa.

Application Layer (Livello Applicativo): API, applicazioni AI-based, assistenti conversazionali, sistemi di forecasting, dashboard analitiche. È il layer dove il valore dell’IA diventa tangibile per cittadini e funzionari pubblici. Deve essere progettato secondo centralità dell’utente, accessibilità e accountability.

5. Il modello di Architettura AI di riferimento per la PA

Le linee guida promuovono esplicitamente le architetture agentiche come paradigma di riferimento per la PA. Un’architettura agentica trasforma un LLM da semplice generatore di testo a componente software con autonomia operativa limitata e orientata a un obiettivo.

Un agente, in questo modello, deve essere capace di: acquisire informazioni dall’ambiente (lettura di documenti, query a database, chiamate API); mantenere uno stato interno; scomporre un obiettivo in attività elementari; pianificare ed eseguire azioni; interagire con risorse esterne.

Le linee guida classificano il livello di autonomia degli agenti in una scala da L0 a L5, analoga a quella dei veicoli autonomi: da sistemi completamente manuali (L0) a workflow agentici con supervisione umana (L3), fino ad agenti semi-autonomi (L4) e completamente autonomi (L5). Per la PA, i livelli L3 e L4 rappresentano la frontiera più praticabile nel breve-medio termine.

Un esempio concreto: un sistema RAG (Retrieval-Augmented Generation) che risponde a domande di cittadini attingendo alla normativa comunale si colloca al livello L3. In Python, l’impostazione di base di un tale sistema potrebbe essere:

from openai import OpenAI
import chromadb

# Connessione al vector store con i documenti della PA
chroma_client = chromadb.HttpClient(host="localhost", port=8000)
collection = chroma_client.get_collection("normativa_comunale")

def rispondi_cittadino(domanda: str) -> str:
    # 1. Recupero dei documenti rilevanti (Retrieval)
    risultati = collection.query(
        query_texts=[domanda],
        n_results=3
    )
    contesto = "\n".join(risultati["documents"][0])

    # 2. Generazione della risposta con contesto (Augmented Generation)
    client = OpenAI()
    risposta = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {
                "role": "system",
                "content": (
                    "Sei un assistente della pubblica amministrazione. "
                    "Rispondi solo sulla base dei documenti forniti. "
                    "Se non trovi risposta, dillo esplicitamente."
                )
            },
            {
                "role": "user",
                "content": f"Contesto normativo:\n{contesto}\n\nDomanda: {domanda}"
            }
        ]
    )
    return risposta.choices[0].message.content

# Esempio di utilizzo
print(rispondi_cittadino("Quali sono i requisiti per richiedere il ISEE?"))

Il documento sottolinea un principio architetturale fondamentale: la separazione netta tra logica applicativa, modello di IA e infrastruttura. Cambiare il modello sottostante (da GPT-4o a un modello open source come Llama 3, per esempio) non deve richiedere la riscrittura dell’applicazione. Questo disaccoppiamento non è solo una buona pratica ingegneristica, nelle linee guida è un requisito obbligatorio.

6. Il ciclo di vita dei sistemi AI nella PA

Le linee guida adottano un modello di ciclo di vita in sette fasi, che copre l’intero arco temporale del sistema AI. Per ogni fase, vengono definite azioni obbligatorie declinate sui cinque layer dello stack.

Fase 1 – Pianificazione e design: stimare l’impatto energetico fin dall’inizio, progettare architetture hardware-agnostic, definire criteri di selezione dei modelli coerenti con la classificazione del rischio.

Fase 2 – Raccolta e trattamento dei dati: applicare data minimization, gestire la qualità dei dati con versioning e tracciabilità, progettare pipeline compatibili con hardware eterogeneo. Un punto critico: i dataset devono essere adeguati anche a modelli di piccole dimensioni, evitando il cosiddetto “big model bias”, la tendenza a sovradimensionare i modelli solo perché disponibili.

Fase 3 – Costruzione e addestramento dei modelli: privilegiare fine-tuning e transfer learning rispetto al training completo, che ha costi energetici altissimi. Isolare il modello come componente sostituibile. Ecco un esempio di fine-tuning efficiente con LoRA, tecnica raccomandata implicitamente dalle linee guida per il suo basso consumo energetico:

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model, TaskType

# Carica un modello base (es. modello open source per la PA)
model_name = "mistralai/Mistral-7B-v0.1"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

# Configurazione LoRA: fine-tuning efficiente senza riaddestrare tutto il modello
lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,               # rank della matrice di aggiornamento
    lora_alpha=32,      # scaling factor
    lora_dropout=0.05,
    target_modules=["q_proj", "v_proj"]  # solo i layer di attenzione
)

# Il modello risultante ha pochissimi parametri addestrabili (~0.1% del totale)
model_lora = get_peft_model(model, lora_config)
model_lora.print_trainable_parameters()
# Output: trainable params: 4,194,304 || all params: 3,752,071,168 || trainable%: 0.1118

Fase 4 – Testing, valutazione, verifica e validazione: valutare performance, robustezza e bias dei modelli; testare la portabilità su ambienti diversi (cloud, on-prem, ibrido); verificare scenari di fallback. Le linee guida richiedono che i test siano condotti su dataset rappresentativi degli scenari reali della PA, non solo su benchmark generici.

Fase 5 – Messa a disposizione per l’esercizio: validazione finale prima del go-live, attivazione del monitoraggio, separazione netta tra ambienti di produzione e test.

Fase 6 – Operatività e monitoraggio: qui le linee guida introducono due concetti fondamentali per chi gestisce LLM in produzione: il data drift (cambiamento nella distribuzione dei dati in input rispetto al training) e il concept drift (cambiamento nella relazione tra input e output). Entrambi richiedono monitoraggio continuo e processi di ri-addestramento o sostituzione dei modelli.

Fase 7 – Ritiro e disattivazione: la dismissione deve essere pianificata, documentata e reversibile. Le PA devono garantire la portabilità dei dati e la possibilità di sostituire componenti senza perdere il controllo del servizio.

7. Buone pratiche di sicurezza per la PA

Il capitolo dedicato alla sicurezza cibernetica dei sistemi AI è particolarmente denso e introduce una tassonomia degli attacchi specifica per i sistemi di machine learning:

• Evasion attacks: input appositamente modificati per ingannare il modello (il classico adversarial example)
• Poisoning attacks: contaminazione dei dati di training per degradare le performance o introdurre backdoor
• Privacy attacks: tecniche per estrarre dati sensibili memorizzati nel modello (model inversion, membership inference)
• Abuse attacks: uso del sistema per scopi non previsti, come la generazione di contenuti dannosi

Le linee guida organizzano le buone pratiche in tre categorie operative:

• Sviluppo sicuro: modellare le minacce prima di scrivere codice; effettuare analisi statica e dinamica del codice; scegliere i modelli considerando il trade-off sicurezza/prestazioni; documentare dati, modelli e prompt.
• Deployment sicuro: configurare l’infrastruttura seguendo il principio del minimo privilegio; isolare i componenti AI dagli altri sistemi; implementare logging e audit trail di tutte le interazioni.
• Gestione e manutenzione sicura: monitorare anomalie nel comportamento del modello; pianificare aggiornamenti regolari; mantenere procedure di incident response specifiche per i sistemi AI.

Un aspetto pratico spesso sottovalutato: le linee guida raccomandano di progettare i sistemi tenendo conto dei cosiddetti shortage, cioè i disequilibri di mercato nell’approvvigionamento di chip e servizi cloud. Architetture rigide che dipendono da un unico fornitore di GPU o da un unico provider LLM espongono la PA a rischi operativi concreti.

8. La consultazione pubblica: come contribuire alle linee guida

Uno degli aspetti più interessanti di questo documento è che si tratta di una bozza aperta alla consultazione pubblica. AgID ha scelto un modello partecipativo in cui sviluppatori, aziende, ricercatori e professionisti IT possono contribuire attivamente alla revisione e al miglioramento delle linee guida.

La consultazione avviene tramite una piattaforma forum dedicata, dove è possibile proporre modifiche, segnalare lacune tecniche, suggerire integrazioni normative o semplicemente commentare sezioni specifiche del testo. Questo approccio, ispirato ai modelli open source di governance documentale, permette alle linee guida di beneficiare dell’esperienza pratica di chi sviluppa sistemi AI ogni giorno sul campo.

Per i professionisti del settore, AI engineer, sviluppatori software, solution architect che lavorano con la PA, partecipare alla consultazione è un’opportunità concreta per influenzare gli standard tecnici che governeranno l’adozione dell’IA in uno dei settori con maggiore impatto sulla vita dei cittadini. Le proposte vengono esaminate da AgID e, se pertinenti, integrate nelle versioni successive delle linee guida.

Gli strumenti allegati al documento (Strumento A sui termini e definizioni, Strumento B su training, fine-tuning e RAG) potranno anch’essi essere aggiornati attraverso questo processo partecipativo, garantendo che la documentazione tecnica resti allineata con l’evoluzione rapida del settore.

9. Conclusioni: padroneggiare gli LLM è un vantaggio competitivo

Leggendo le linee guida AgID emerge un messaggio chiaro: l’integrazione di LLM e sistemi AI nella PA non è più una sperimentazione, è una priorità strategica. Le amministrazioni che sapranno governare queste tecnologie, con architetture modulari, cicli di vita controllati e team competenti, avranno un vantaggio competitivo misurabile in efficienza operativa, qualità dei servizi e capacità di risposta alle esigenze dei cittadini.

Per i team di sviluppo, questo cambia il profilo delle competenze richieste. Non basta saper chiamare un’API di un LLM: serve saper progettare stack AI a più livelli, gestire il ciclo di vita di un modello in produzione, monitorare data drift e concept drift, garantire neutralità hardware e conformità normativa. Sono competenze nuove, trasversali, che stanno ridefinendo il ruolo dello sviluppatore software nella PA e nel settore privato che ci lavora.

Saper governare queste tecnologie non è più opzionale per i team di sviluppo di oggi: è una competenza fondamentale.

Per chi vuole costruire o consolidare queste competenze in modo strutturato, Innovaformazione propone percorsi formativi dedicati all’AI Generativa progettati specificamente per sviluppatori e professionisti IT:

• Corsi AI Generativa – Innovaformazione

In particolare, è disponibile il:

• Corso Sviluppo Applicazioni LLM

Un percorso pratico e aggiornato che copre architetture RAG, agenti LLM, integrazione con API, MLOps e deployment sicuro, esattamente le competenze che le linee guida AgID richiedono ai team che sviluppano per la PA.

I corsi sono attivati per le aziende in modalità online classe virtuale, con calendario da concordare in base alle esigenze del team.

Per richiedere informazioni e p reventivo:

📩Email: info@innovaformazione.net Tel.: 347 101 2275 Referente: Dario Carrassi

(fonte)

Per altri articoli di settore consigliamo di navigare sul nostro blog QUI.