3 - Architettura logica di riferimento: orchestratore, modelli, dati e tool

Consultazioni pubbliche LG per lo sviluppo di sistemi IA nella PA
1

Bozza di Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella pubblica amministrazione

La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.

Questo argomento accoglie i commenti relativi al capitolo 3. Architettura logica di riferimento: orchestratore, modelli, dati e tool.

I commenti dovranno includere il numero del paragrafo o sotto-paragrafo (se presente) e un riferimento puntuale al brano di testo al quale si riferiscono (ad esempio paragrafo 4.3, terzo capoverso).

Leggi il documento in consultazione.

2

Contributo a cura della Taskforce IA dell’Autorità Nazionale Anticorruzione (ANAC)

Il livello di astrazione adottato risulta in diversi passaggi elevato e prevalentemente teorico. Il modello architetturale proposto, pur solido sul piano concettuale, non è accompagnato da esempi concreti di implementazione o da schemi di riferimento immediatamente utilizzabili dalle amministrazioni. In assenza di reference architecture operative, le PA potrebbero incontrare difficoltà nel tradurre tali indicazioni in soluzioni effettivamente realizzabili.

Un ulteriore elemento di criticità riguarda il ruolo centrale attribuito all’orchestratore, descritto come componente chiave per il coordinamento di modelli, dati e servizi. Tuttavia, non vengono fornite indicazioni sufficientemente chiare su come tale elemento debba essere implementato, quali caratteristiche debba possedere o quali tecnologie possano essere adottate, lasciando ampio margine interpretativo.

Rileviamo inoltre una marcata enfasi sulle architetture agentiche che, sebbene rappresentino un paradigma promettente, non costituiscono ancora uno standard consolidato né facilmente adottabile in tutti i contesti della Pubblica Amministrazione. Questo orientamento rischia, in alcuni casi, di spingere verso soluzioni eccessivamente complesse rispetto ai reali fabbisogni.

Alla luce di queste considerazioni, proponiamo di integrare il capitolo con esempi concreti di architetture di riferimento, differenziati per tipologia di caso d’uso (ad esempio sistemi di retrieval augmented generation, pipeline di machine learning, applicazioni di assistenza automatizzata). Ritengo inoltre utile fornire indicazioni tecnologiche, anche a titolo esemplificativo e non vincolante, per supportare le amministrazioni nelle scelte progettuali.

Infine, proponiamo di distinguere esplicitamente tra un’architettura minima, applicabile anche in contesti a bassa maturità digitale, e architetture più avanzate, così da rendere il modello proposto più accessibile, progressivo e concretamente adottabile da parte dell’intero ecosistema delle Pubbliche Amministrazioni.

3

Refuso pag. 35: “La necessità di disporre di strumenti di IA, considerata finora come un fenomeno sperimentare“

4

La presente osservazione è da leggersi nel contesto complessivo, argomentato nel seguente position paper: [ https://www.huandroid.com/wp-content/uploads/2026/03/PositionPaper_Linee_Guida_AGID.pdf ] (che provvedo a trasmettervi anche via PEC)

L’architettura giuridica delle Linee Guida AgID poggia su due pilastri: l’AI Act europeo (classificazione per rischio, obblighi per i sistemi ad alto rischio) e la Legge italiana 132/2025, che pone al centro l’intervento umano e la protezione della dignità della persona. L’articolo 3 di quest’ultima impone, in ogni fase del ciclo di vita dell’IA, sorveglianza e intervento umano, trasparenza e spiegabilità, principi già recepiti nel Principio 13 delle Linee Guida Sviluppo.

Una criticità dell’attuale impianto è la declinazione del controllo umano come mero monitoraggio a valle (Human-in-the-loop), modello fragile per il rischio di automation bias (fiducia eccessiva nell’algoritmo). Per superare questo limite, è necessario adottare il paradigma Human-in-Command (HIC), in cui l’umano non si limita a correggere output, ma mantiene il controllo strategico sul sistema, definendone a monte obiettivi, vincoli e regole etico-logiche. Questo approccio è coerente con il Regolamento (UE) 2024/1689, che per i sistemi ad alto rischio richiede un controllo effettivo da parte di persone fisiche durante l’uso.

Osservazione 1 – Governance dei sistemi: dall’oversight reattivo allo Human-in-Command

Riferimenti AgID:

  • Linee Guida Sviluppo: Cap. 2 (Principi generali), Principio 13 – Sorveglianza umana

  • Linee Guida Procurement: Par. 3.1 (Principi generali), Tabella 1 (Principio di controllo)

Criticità rilevata:
Il quadro attuale declina il controllo umano prevalentemente in ottica reattiva (Human-in-the-loop): l’operatore supervisiona output, corregge errori, interviene a valle. Questo modello, pur necessario, non è sufficiente per i sistemi ad alto impatto procedimentale. Esso rischia di ridurre l’umano a “controllore di bozze” in contesti in cui le derive sistemiche possono manifestarsi solo dopo iterazioni massive.

Proposta:
Si suggerisce di integrare nel Principio 13 (Sorveglianza umana) in Tabella 1 (pag. 24-25) e nel Par. 3.5.4 (Operatore controllore), accanto al concetto di supervisione, quello di progettazione costituzionale del sistema, riconoscendo la figura dell’Architetto Cognitivo come ruolo istituzionale (cfr. Operatore controllore in Sviluppo, Par. 3.5.4).

Tale figura:

  • Definisce a monte i guardrail etico-logici (Costituzioni degli Agenti) entro cui i modelli operano;

  • Non valida output caso per caso, ma ricalibra il sistema in caso di derive strutturali;

  • Garantisce che la responsabilità decisionale rimanga in capo alla PA (Principio 5 – Responsabilità).

Testo integrato nel para 3.5.4 - Operatore controllore (pag.75), come segue :

*"Gli Operatori controllori (11) rappresentano le Pubbliche Amministrazioni con mandato strategico, responsabilità istituzionali sensibili o esigenze operative tali da richiedere un controllo completo sull’intero ciclo di vita dei sistemi e dei servizi che facciano uso di Intelligenza Artificiale. **Per i sistemi classificati ad alto rischio o che incidono su procedimenti amministrativi sensibili, la PA deve assicurarsi di operare secondo un paradigma Human-in-Command.** A differenza degli Operatori avanzati ed esperti, che si collocano lungo la catena del valore come adattatori o creatori, l’Operatore controllore mira a eliminare ogni dipendenza critica da fornitori esterni, esercitando pieno governo tecnologico, infrastrutturale e operativo su ogni componente del sistema AI. **La figura dell'Architetto Cognitivo, interviene sull'architettura del modello in caso di derive sistemiche, preservando la piena titolarità delle decisioni amministrative.”***

Analisi ([cfr. Allegato, Cap.3]): La Legge 132/2025 richiede “sorveglianza e intervento umano”. L’attuale declinazione come Human-in-the-loop è fragile per il rischio di automation bias. È necessario un salto di paradigma verso lo Human-in-Command, in cui l’umano progetta a monte le regole costituzionali del sistema.

5

La presente osservazione è da leggersi nel contesto complessivo, argomentato nel position paper che provvedo a trasmettervi anche via PEC

L’architettura giuridica delle Linee Guida AgID poggia su due pilastri: l’AI Act europeo (classificazione per rischio, obblighi per i sistemi ad alto rischio) e la Legge italiana 132/2025, che pone al centro l’intervento umano e la protezione della dignità della persona. L’articolo 3 di quest’ultima impone, in ogni fase del ciclo di vita dell’IA, sorveglianza e intervento umano, trasparenza e spiegabilità, principi già recepiti nel Principio 13 delle Linee Guida Sviluppo.

Una criticità dell’attuale impianto è la declinazione del controllo umano come mero monitoraggio a valle (Human-in-the-loop), modello fragile per il rischio di automation bias (fiducia eccessiva nell’algoritmo). Per superare questo limite, è necessario adottare il paradigma Human-in-Command (HIC), in cui l’umano non si limita a correggere output, ma mantiene il controllo strategico sul sistema, definendone a monte obiettivi, vincoli e regole etico-logiche. Questo approccio è coerente con il Regolamento (UE) 2024/1689, che per i sistemi ad alto rischio richiede un controllo effettivo da parte di persone fisiche durante l’uso.

Osservazione 2 – Architetture multi-agente e Epistemic Security

Riferimenti AgID:

  • Linee Guida Sviluppo: Cap. 3.2 (Modello di Architettura IA di riferimento), in particolare l’architettura agentica

  • Linee Guida Procurement: Par. 3.3 (Architettura logica di riferimento: implicazioni per il procurement)

  • Artt. 12 e 16 AI Act (documentazione, trasparenza)

Criticità rilevata:
L’architettura logica proposta (orchestratore, modelli, dati, tool) è solida e modulare. Tuttavia, non prevede un layer esplicito dedicato alla verifica fattuale e alla riduzione dei bias in fase di inferenza. In contesti amministrativi, dove l’affidabilità dell’informazione è presupposto per la legittimità dell’atto, le “allucinazioni” o le distorsioni cognitive dei modelli non possono essere gestite solo a valle dalla supervisione umana. Servono meccanismi procedurali incorporati nell’architettura.

Proposta:
Integrare nell’architettura logica un layer esplicito di Epistemic Security, realizzato tramite pattern Multi-Agente. In questo modello, l’istanza cognitiva principale viene affiancata da uno o più Critic Agents indipendenti, il cui unico scopo è:

  • verificare le fonti e la provenienza dei dati;

  • smascherare i bias nel ragionamento (anche applicando principi della Teoria del Prospetto);

  • attaccare la produzione per testarne la robustezza.

L’obiettivo non è un’oggettività assoluta – impossibile – ma una oggettività procedurale, garantita dalla trasparenza e verificabilità del processo di revisione incrociata. L’integrazione va fatta nella Figura 3 (architettura logica) e nel testo descrittivo del Par. 3.2

Testo proposto per integrazione para 3.2 pagina 44:

"L’architettura agentica deve prevedere un ciclo iterativo di feedback continuo, basato su tre step: osservazione, decisione e azione. Tale ciclo deve essere supportato da meccanismi di controllo, verifica e feedback, tali da garantire il rispetto dei limiti di autonomia definiti, la tracciabilità delle decisioni, la coerenza degli output e la possibilità di interrompere, modificare o correggere l’esecuzione dell’agente in qualsiasi momento, nel rispetto delle soglie di sicurezza, dei vincoli funzionali e dei requisiti normativi applicabili.

Nei casi d’uso complessi o ad alto impatto, è necessario prevedere un un layer dedicato all’Epistemic Security: in questo scenario l’architettura dovrebbe privilegiare pattern Multi-Agente in cui ‘Critic Agents’ indipendenti – specializzati nella verifica delle fonti, nell’identificazione dei bias e nel test di robustezza – operano in parallelo all’istanza cognitiva principale. Le logiche di verifica e i relativi output devono essere documentati e resi accessibili ai fini di audit, garantendo una oggettività procedurale e una maggiore affidabilità fattuale per il decisore pubblico."

Da integrarsi anche la figura 3 pag 47: aggiungere una infografica con Epistemic Security Layer (Critic Agents)

Analisi ([cfr. Allegato, Cap.5; arXiv, 2603.02960]): L’evoluzione verso sistemi agentici richiede un layer di Epistemic Security per proteggere l’integrità delle basi di conoscenza pubbliche. I pattern Multi-Agente con Critic Agents indipendenti garantiscono una “oggettività procedurale” verificabile.

6

Il CSIG (Centro studi di informatica giuridica di Ivrea e Torino) suggerisce di attenzionare la valutazione dei Principi di Sviluppo rispetto alla Sorveglianza Algoritmica. I 20 principi individuati nel capitolo 2.2 delle Linee Guida definiscono il perimetro etico-tecnico dello sviluppo, ma presentano ambiguità che potrebbero abilitare forme di sorveglianza occulta.

Il Principio 2 (Rispetto dei valori fondamentali dell’UE), pur richiamando la CDFUE e l’AI Act (Reg. UE 1689/2024), rimane eccessivamente generico: la tutela dei diritti fondamentali nel contesto lavorativo italiano richiede riferimenti espliciti alle procedure di co-determinazione sindacale.

Analogamente, il Principio 13 (Sorveglianza umana) rischia di essere ridotto a una verifica tecnica dell’output, ignorando la necessità di supervisionare la legittimità stessa del controllo esercitato dall’algoritmo sulla condotta del lavoratore.

Un elemento di rischio inedito è rappresentato dalle Architetture Agentiche (sez. 2.1) e dall’Orchestratore (sez. 3.2.4). Se non correttamente vincolata, la logica di orchestrazione può diventare il luogo dove vengono codificate regole di monitoraggio della performance in tempo reale, agendo come un supervisore automatizzato invisibile.

7

§3.2 Modello di Architettura IA di riferimento per la PA e §3.2.4 Orchestratore

Il capitolo descrive correttamente i vantaggi dell’Orchestratore IA come punto di coordinamento unificato, ma non tratta in modo esplicito l’altra faccia della stessa scelta architetturale. L’Orchestratore, proprio in virtù della sua posizione di snodo verso modelli, dati e tool, costituisce anche un punto di concentrazione del rischio di sicurezza. Una sua compromissione, oppure il transito attraverso di esso di input malevoli o non fidati, può amplificare in modo non banale il raggio d’azione di un attaccante, estendendolo ai modelli, alle sorgenti dati e agli strumenti che l’Orchestratore è in grado di raggiungere. A fronte di questo, il ruolo di sicurezza assegnato al componente è descritto in §3.2.4 in termini ancora limitati, cioè validazione delle richieste di attivazione dei modelli e tracciabilità, coprendo soprattutto audit e routing ma non la mediazione attiva tra input non fidati e capability privilegiate.

Raccomandazione: integrare §3.2 e §3.2.4 chiarendo che l’Orchestratore costituisce anche un punto di concentrazione del rischio e che, di conseguenza, tra le sue responsabilità architetturali devono essere esplicitamente comprese almeno: (a) la mediazione delle chiamate ai tool applicativi, con allow-list, quote e policy di esecuzione differenziate in funzione della sorgente dell’input; (b) la propagazione del livello di fiducia delle fonti dati in ingresso lungo il contesto, con riduzione dinamica delle capability disponibili al modello quando nel contesto siano presenti input non fidati; (c) la validazione degli output prima di azioni ad alto impatto; (d) meccanismi di approvazione rafforzata per azioni sensibili o irreversibili. Tali responsabilità dovrebbero inoltre essere oggetto di test di sicurezza specifici, inclusi test avversariali mirati all’Orchestratore stesso.

§3.2.2 Fonti dati eterogenee (cloud, on-prem, hybrid)

Il §3.2.2 cita correttamente il Retrieval-Augmented Generation tra le modalità di accesso ai dati da parte dell’Orchestratore e descrive con buon livello di dettaglio una pipeline di Data Engineering articolata in quattordici fasi. Nessuna di queste fasi, tuttavia, tratta in modo esplicito i corpora RAG, gli indici testuali e vettoriali, gli embedding e i vector store come superficie di attacco specifica dei sistemi di IA. In particolare, non sono richiamati: il rischio di prompt injection indiretta veicolata da contenuti indicizzati, quali documenti, pagine web, e-mail, ticket o altre sorgenti suscettibili di contribuire al contesto del modello; l’esigenza di controllo degli accessi e di isolamento coerente con i permessi dell’utente finale anche a livello di documenti, indici ed embedding; il rischio di avvelenamento del corpus; il monitoraggio di integrità del vector store. Il risultato è che il RAG è presentato come opportunità di accesso ai dati e come leva di qualità, ma non come data plane sensibile che richiede presìdi dedicati.

Raccomandazione: integrare §3.2.2 chiarendo che i corpora RAG, gli indici testuali e vettoriali e gli embedding devono essere trattati come data plane sensibile dei sistemi di IA, con requisiti espliciti di: (a) sanitizzazione e validazione dei contenuti prima dell’indicizzazione, con particolare attenzione ai rischi di prompt injection indiretta; (b) controllo degli accessi e isolamento coerente con i permessi dell’utente finale anche a livello di documenti, indici ed embedding; (c) monitoraggio di integrità del corpus e degli indici contro tentativi di avvelenamento; (d) inclusione delle fonti del retrieval nel perimetro del threat modeling e dei test di sicurezza del sistema di IA. La pipeline di Data Engineering descritta nel paragrafo andrebbe di conseguenza integrata con una o più fasi esplicitamente dedicate alla sicurezza del corpus, degli indici e del retrieval, oggi non evidenziate in modo espresso tra quelle nominate.

§3.2.3 Tool del livello applicativo

Il §3.2.3 descrive i tool del livello applicativo come componenti in grado di invocare API, eseguire codice e raccogliere dati da fonti eterogenee. Questa è una delle classi di capability più critiche dal punto di vista della sicurezza nelle architetture agentiche, perché un input non fidato che riesca a influenzare la selezione o l’invocazione di un tool può tradursi in chiamate API privilegiate, esecuzione di codice o accesso a dati e sistemi esterni non previsti. Il paragrafo, tuttavia, non richiama questo rischio e non indica alcun requisito minimo per l’invocazione sicura dei tool.

Raccomandazione: integrare il §3.2.3 precisando che i tool del livello applicativo devono essere progettati e governati tenendo conto dell’impatto del loro potenziale uso improprio da parte del modello, e che in particolare devono prevedere almeno: (a) una classificazione dei tool per criticità e reversibilità delle azioni che possono produrre; (b) allow-list esplicite e policy di esecuzione differenziate, gestite centralmente dall’Orchestratore; (c) isolamento delle capability di esecuzione di codice e di accesso a sistemi esterni, tramite sandboxing, privilegi minimi e segmentazione di rete; (d) meccanismi di approvazione umana rafforzata per tool che producono effetti irreversibili o che operano su dati sensibili; (e) log dettagliati delle invocazioni, correlati all’input o alla sessione che le ha originate, al fine di consentire analisi post-incidente e test di sicurezza mirati.

§3.5.1 Operatore base

Il §3.5.1 riconosce esplicitamente che l’Operatore base, pur rappresentando “la maggioranza delle amministrazioni”, dispone di un controllo limitato sullo stack IA, in quanto utilizza soluzioni fornite da terze parti senza poter intervenire sui modelli, sui dati di addestramento né sulle pipeline sottostanti. Questa presa d’atto è corretta, ma nel paragrafo non si traduce in indicazioni progettuali per lo strato che l’Operatore base effettivamente sviluppa e governa, ossia il livello applicativo di integrazione tra il servizio pubblico e i componenti di IA forniti da terzi. Proprio perché il modello e le sue pipeline restano opachi, è su questo strato che si concentra lo spazio residuo di progettazione sicura disponibile all’Operatore base, e sarebbe opportuno che le Linee guida lo richiamassero esplicitamente.

Raccomandazione: integrare il §3.5.1 chiarendo che, in ragione del minore controllo sullo stack sottostante, lo sviluppo dello strato applicativo da parte dell’Operatore base deve prevedere almeno:
(a) configurazione iniziale dei componenti di IA al minimo delle capability necessarie al caso d’uso (connettori, tool, fonti dati, scope degli accessi), con abilitazioni successive soggette a valutazione del rischio;
(b) validazione e filtraggio degli input e degli output a livello applicativo, trattando il sistema di IA come componente non fidato anche nei confronti del servizio che lo incapsula;
(c) monitoraggio continuo del comportamento del sistema osservabile dal livello applicativo (tassi di errore, anomalie, pattern di uso sospetti), come controllo compensativo rispetto all’impossibilità di ispezionare il modello;
(d) progettazione esplicita di modalità di degraded mode, di fallback non basati sul sistema di IA e di procedure di disattivazione rapida del componente in caso di anomalia o incidente.

8

Intervento 1 — Paragrafo 3.1.1.1 (numerazione anomala)

Riferimento: Paragrafo 3.1.1.1 “Energy Layer (Livello Energetico)”.

Osservazione: Il primo livello dello Stack IA è numerato come paragrafo 3.1.1.1 (quattro livelli di profondità), mentre i quattro livelli successivi sono numerati 3.1.2 (Chip Layer), 3.1.3 (Infrastructure Layer), 3.1.4 (AI Model Layer) e 3.1.5 (Application Layer). La numerazione del primo livello è quindi incoerente con quella degli altri quattro: dovrebbe essere 3.1.1, in modo da mantenere uno schema uniforme su tre livelli di profondità (3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5). Si tratta probabilmente di un residuo di una versione precedente del documento in cui esisteva un paragrafo 3.1.1 contenitore.

Proposta di modifica: Rinumerare il paragrafo 3.1.1.1 come 3.1.1, aggiornando di conseguenza l’indice.

Intervento 2 — Paragrafo 3.2, secondo capoverso (riferimento alla figura)

Riferimento: Paragrafo 3.2 “Modello di Architettura IA di riferimento per la PA”, nota a piè di pagina e capoverso che precede l’elenco numerato dei tre domini.

Brano di riferimento: “Tale architettura è illustrata nella 3 e analogamente descritta a seguire.” e successivamente “Il modello di riferimento che la Pubblica amministrazione DEVE prendere a riferimento per lo sviluppo di sistemi e servizi basati sull’uso di IA è rappresentato dalla 3.”

Osservazione: Le espressioni “illustrata nella 3” e “rappresentato dalla 3” sono evidentemente residui di un sistema di riferimenti incrociati a una figura (“Figura 3”) il cui prefisso non è stato risolto nel testo finale. Lo stesso problema si ripresenta più avanti, nello stesso paragrafo: “Come rappresentato in figura, l’orchestratore è connesso a tre estensioni…” e nel paragrafo 3.2.4.1 “Il sequence diagram proposto in 4 descrive…”. Il documento contiene quindi numerosi riferimenti rotti a figure, nei quali è rimasto solo il numero senza il prefisso “Figura”. In un documento normativo che genera clausole contrattuali, questi riferimenti rotti compromettono la leggibilità e l’interpretazione del modello architetturale obbligatorio.

Proposta di modifica: Effettuare una revisione sistematica di tutti i riferimenti alle figure nel capitolo 3 (e nell’intero documento), ripristinando il prefisso “Figura N” e verificando che le figure citate siano effettivamente presenti e numerate correttamente.

9

Intervento 3 — Paragrafo 3.2, capoverso che introduce l’AI Orchestrator

Riferimento: Paragrafo 3.2, capoverso che inizia con “Al fine di evitare il rischio di lock-in, l’API Middleware DEVE essere tecnicamente realizzato mediante un abstraction layer.”

Brano di riferimento: “In particolare, l’API Middleware DEVE implementare un’interfaccia di inferenza basata su standard di mercato aperti e documentati.”

Osservazione: La prescrizione è condivisibile nel suo intento — evitare il lock-in attraverso uno standard aperto — ma è inattuabile come formulata, perché allo stato attuale non esiste uno standard di mercato aperto e documentato universalmente adottato per le interfacce di inferenza degli LLM e dei modelli generativi. Esistono interfacce di fatto (la più diffusa è il dialetto OpenAI Chat Completions, replicato da molti fornitori) ma si tratta di specifiche proprietarie de facto, non di standard formali. Esistono iniziative emergenti (ad esempio Model Context Protocol per la comunicazione tra modelli e tool) ma anch’esse non hanno ancora lo statuto di standard consolidato. Imporre con “DEVE” l’adozione di “standard di mercato aperti e documentati” senza specificare quali standard, e in assenza di standard effettivi, produce una clausola inverificabile in fase di collaudo e impugnabile in sede di gara.

Proposta di modifica: Riformulare la clausola in due modi alternativi: (a) rimandare a uno Strumento operativo dedicato che mantenga aggiornato l’elenco delle specifiche tecniche accettate come “standard di mercato aperti e documentati” ai fini delle Linee Guida, prevedendone la revisione periodica; oppure (b) riformulare la prescrizione in termini di requisiti funzionali verificabili (ad esempio: l’interfaccia deve essere documentata pubblicamente, deve essere implementabile da almeno N fornitori indipendenti, deve consentire la sostituzione del modello sottostante senza modifiche al codice client) anziché in termini di standard astratti.

Intervento 4 — Paragrafo 3.2.4 (Orchestratore — assenza di specifiche)

Riferimento: Paragrafo 3.2.4 “Orchestratore”, nel suo complesso.

Brano di riferimento: “L’AI Orchestrator può essere rappresentato come un motore decisionale centrale, responsabile della logica di coordinamento, selezione del modello opportuno nella molteplicità di quelli disponibili, orchestrando operazioni di inferenza e gestione dei flussi informativi tra modelli, dati e strumenti (Tool).”

Osservazione: Il paragrafo descrive l’Orchestratore come elemento centrale e obbligatorio dell’architettura di riferimento (cfr. par. 3.2 nota: “Il modello di riferimento che la Pubblica amministrazione DEVE prendere a riferimento […] è rappresentato dalla [Figura] 3”), ma non fornisce alcuna specifica tecnica che permetta a un’amministrazione di riconoscere, valutare o acquisire un orchestratore conforme. Non sono indicati: (a) i requisiti funzionali minimi obbligatori; (b) le interfacce che l’orchestratore deve esporre; (c) i protocolli di comunicazione con modelli, dati e tool; (d) i criteri di selezione e routing; (e) le garanzie di portabilità tra orchestratori diversi. Il rischio operativo è duplice. Da un lato, ogni fornitore potrà certificare il proprio prodotto come “orchestratore” senza che esistano criteri oggettivi di conformità. Dall’altro, e in modo paradossale rispetto al principio anti-lock-in che permea il documento, l’imposizione di un’architettura centrata su un componente non specificato favorisce l’adozione dei pochi framework di orchestrazione oggi disponibili (LangChain, CrewAI, AutoGen, LlamaIndex e simili), che sono ecosistemi proprietari o semi-proprietari in rapida evoluzione e con API instabili — generando una nuova forma di lock-in verso questi framework.

Proposta di modifica: Integrare il paragrafo 3.2.4 con i requisiti minimi obbligatori che un orchestratore deve soddisfare per essere considerato conforme alle presenti Linee Guida, oppure rinviare a uno Strumento operativo dedicato che fornisca tale specifica. In particolare, andrebbero definiti: requisiti di interfaccia (API esposte e protocolli); requisiti di portabilità (formato di esportazione delle configurazioni); requisiti di osservabilità (logging, tracing, metriche); requisiti di governance (controllo accessi, audit trail). In assenza di tali specifiche, l’obbligo architetturale rischia di restare inverificabile.

Intervento 5 — Paragrafo 3.2.1, ultimi capoversi (separazione dati/modelli)

Riferimento: Paragrafo 3.2.1 “Modelli di IA”, capoverso che descrive PEFT e LoRA.

Brano di riferimento: “Con questa categoria di modelli, si possono fare attività di fine-tuning e inferenza: la prima (fine-tuning) non richiede di ri-addestrare tutto il modello, ma solo la sua caratterizzazione secondo lo specifico dominio applicativo, anche con tecniche PEFT (Performance-Efficient Fine-Tuning) e LORA (Low Rank Adaptation).”

Osservazione: Il capoverso introduce le tecniche PEFT e LoRA come opzioni di personalizzazione dei modelli fondazionali, ma non discute le implicazioni di queste tecniche rispetto al Principio 4 (Protezione dei dati personali) della Tabella 1, che impone una “netta separazione tra dati, modelli e servizi”. Le tecniche di fine-tuning, anche quelle parameter-efficient come PEFT e LoRA, producono adattatori i cui pesi sono funzione diretta dei dati su cui sono stati addestrati: ciò significa che la separazione tra “dati” e “modello” può essere mantenuta a livello architetturale (l’adattatore è un file distinto dal modello base) ma non a livello epistemologico (l’adattatore è una rappresentazione compressa dei dati di addestramento, dalla quale è in linea di principio possibile estrarre informazioni sui dati stessi tramite attacchi di inferenza). Inoltre, va corretto un refuso: la sigla PEFT corrisponde a “Parameter-Efficient Fine-Tuning”, non a “Performance-Efficient Fine-Tuning” come riportato nel testo.

Proposta di modifica: (a) Correggere il refuso sull’acronimo PEFT, che è Parameter-Efficient Fine-Tuning. (b) Integrare il capoverso con un riconoscimento esplicito che le tecniche di fine-tuning, incluse PEFT e LoRA, comportano l’incorporazione delle informazioni sui dati di addestramento nei pesi degli adattatori, e che la “separazione tra dati e modelli” prescritta dal Principio 4 va quindi intesa come separazione architetturale, non come isolamento epistemologico. (c) Rinviare a uno Strumento operativo dedicato per la valutazione dei rischi residui di estrazione di informazioni dagli adattatori e per le relative misure di mitigazione (ad esempio differential privacy, controllo degli accessi agli adattatori, valutazione della memorizzazione).

Intervento 6 — Paragrafo 3.4.1, terzo elenco puntato (Federated Learning)

Riferimento: Paragrafo 3.4.1 “Dati di Addestramento (Training)”, terza opzione di deploy per il training, con rinvio alla Tabella 4.

Brano di riferimento: “opzione 3 – Hybrid: questa tipologia di deploy prevede un approccio ibrido, con dati non sensibili in cloud e dati sensibili on-prem. Il modello è quello del Federated Learning, cioè di un training distribuito senza condivisione dati; un esempio può essere rappresentato da un modello che impara da più enti senza centralizzare dati personali.”

Osservazione: Il Federated Learning è presentato in questo paragrafo (e nella Tabella 4) come opzione di deploy accessibile e priva di criticità, quando invece la letteratura scientifica e tecnica documenta limitazioni e rischi specifici di questa tecnica che vanno presi in considerazione prima di orientare scelte progettuali della PA. In particolare: (a) il Federated Learning è vulnerabile ad attacchi di inferenza sui gradienti, che possono in determinate condizioni ricostruire dati individuali a partire dagli aggiornamenti del modello inviati al server di aggregazione; (b) presenta significativo overhead comunicativo, specialmente con modelli di grandi dimensioni; (c) ha difficoltà di convergenza in presenza di dati non identicamente distribuiti tra i nodi partecipanti (condizione tipica quando PA diverse contribuiscono con dataset eterogenei per struttura, volume e dominio); (d) richiede competenze implementative significativamente superiori a quelle attribuibili a un Operatore base o avanzato secondo la tassonomia del paragrafo 3.5. Va riconosciuto che il paragrafo 5.5.2 del documento, nella parte sulla sicurezza, discute esplicitamente la vulnerabilità dell’apprendimento federato al model poisoning. Tuttavia, il caveat è in un altro capitolo, separato da circa cinquanta pagine dalla tabella operativa che orienta le scelte progettuali. Un funzionario che consulta il paragrafo 3.4.1 e la Tabella 4 per decidere il deploy del training non viene in alcun modo allertato sulle limitazioni della tecnica.

Proposta di modifica: Integrare l’opzione 3 del paragrafo 3.4.1 con un breve riferimento — anche solo una nota a piè di pagina — alle limitazioni note del Federated Learning, con rinvio esplicito al paragrafo 5.5.2 per la trattazione dei rischi di sicurezza e a uno Strumento operativo dedicato per la valutazione delle condizioni di applicabilità (volume del modello, distribuzione dei dati, competenze richieste, costi comunicativi).

Intervento 7 — Paragrafo 3.5.4 (Operatore controllore)

Riferimento: Paragrafo 3.5.4 “L’Operatore controllore”, primo e secondo capoverso.

Brano di riferimento: “l’Operatore controllore mira a eliminare ogni dipendenza critica da fornitori esterni, esercitando pieno governo tecnologico, infrastrutturale e operativo su ogni componente del sistema AI. Queste Amministrazioni devono garantire che i modelli, i dataset, le pipeline dei dati, le infrastrutture e i sistemi di supporto siano nel pieno controllo senza condizioni esterne che possano limitarne l’autonomia o generare rischi strategici.”

Osservazione: Il profilo dell’Operatore controllore, come descritto, presuppone il pieno controllo end-to-end sull’intera filiera dell’IA, dall’Energy Layer fino all’Application Layer (cfr. par. 3.1). Allo stato attuale, nessuna Pubblica Amministrazione italiana possiede questa filiera completa, nemmeno per un singolo caso d’uso: i grandi centri di calcolo nazionali (CINECA in primis) dispongono di capacità HPC di eccellenza, ma non sviluppano modelli fondazionali propri; nessun ente pubblico italiano controlla un proprio Energy Layer dedicato all’IA; i modelli fondazionali utilizzabili sono pressoché tutti prodotti da soggetti privati esteri o da iniziative open weight non sotto controllo istituzionale italiano. La nota 7 del paragrafo 3.5 precisa correttamente che i quattro profili sono “famiglie di utilizzatori” e che una stessa PA può ricoprire profili diversi per casi d’uso diversi: questa precisazione attenua il problema, ma non lo risolve. Anche limitando l’analisi a un singolo caso d’uso, nessuna PA italiana è oggi in condizione di “garantire pieno controllo” sull’intero stack. Presentare l’Operatore controllore come una delle quattro categorie operative attualmente disponibili — alla pari con le altre tre, che descrivono situazioni reali — confonde il piano prescrittivo con quello aspirazionale e rischia di generare classificazioni di gara basate su un profilo che nessun operatore può legittimamente rivendicare.

Proposta di modifica: Riformulare il paragrafo 3.5.4 distinguendo esplicitamente tra (a) il profilo dell’Operatore controllore come obiettivo strategico di lungo termine che richiede investimenti di politica industriale di scala nazionale, da perseguire attraverso meccanismi di aggregazione interamministrativa e partnership con centri di calcolo nazionali, e (b) la situazione attuale, nella quale nessuna PA italiana soddisfa pienamente questo profilo. In alternativa, rinominare il profilo (ad esempio “Operatore strategico” o “Operatore con controllo end-to-end”) e specificare in modo non ambiguo quali requisiti minimi una PA deve soddisfare per potersi auto-classificare come tale, distinguendo i requisiti di filiera completa (oggi non soddisfacibili) dai requisiti di controllo parziale (oggi accessibili a un numero limitato di soggetti, principalmente CINECA in collaborazione con i propri consorziati).

10

Confintesa FP — Federazione Funzione Pubblica (organizzazione sindacale maggiormente rappresentativa nel Comparto Funzioni Centrali) presenta le seguenti osservazioni nell’ambito della consultazione pubblica (Determinazione AgID n. 43 del 10 marzo 2026). Il testo integrale delle osservazioni sarà trasmesso formalmente ad AgID.

OSSERVAZIONE — Livelli di autonomia e mansioni: rischio di demansionamento di fatto (sez. 3.5)

La sez. 3.5 introduce quattro livelli operativi (Operatore base, avanzato, esperto, controllore) che descrivono il grado di autonomia nell’interazione con i sistemi di IA. Questa tassonomia tecnica, in assenza di un presidio contrattuale esplicito, è idonea a produrre una ridefinizione di fatto delle mansioni dei dipendenti, al di fuori delle procedure previste dall’art. 52 del D.Lgs. 165/2001.

L’Operatore base potrebbe giustificare riclassificazioni verso aree contrattuali inferiori o il diniego di progressioni economiche. L’Operatore controllore potrebbe essere invocato per pretendere responsabilità superiori senza il corrispondente riconoscimento contrattuale. In entrambi i casi il danno per il lavoratore è reale e non è escluso dal testo delle Linee Guida.

Proposta di integrazione alla sez. 3.5:

Inserire la seguente clausola di salvaguardia:

«I livelli di autonomia descritti nella presente sezione costituiscono esclusivamente categorie tecniche di classificazione dei sistemi di IA e delle modalità di interazione uomo-macchina. Essi NON HANNO alcuna valenza ai fini dell’inquadramento contrattuale del personale, della definizione o modifica delle mansioni, della valutazione della prestazione individuale, dell’attribuzione o revoca di incarichi.

Qualsiasi ridefinizione dei profili professionali o delle aree di inquadramento derivante dall’introduzione di sistemi di IA DEVE avvenire nell’ambito delle procedure di contrattazione collettiva, ai sensi dell’art. 52 D.Lgs. 165/2001 e del CCNL di comparto applicabile, con preventiva informazione sindacale ai sensi della disciplina contrattuale vigente nel comparto di riferimento.»

Confintesa FP — Segretario Generale Claudia Ratti | www.confintesafp.it

11

Commenti a 3.4.1 Dati di Addestramento (Training)

Con riferimento al suddetto paragrafo, si intende portare all’attenzione un critico disallineamento normativo e tecnologico rispetto all’impianto regolatorio già definito dall’Agenzia per la Cybersicurezza Nazionale (ACN) in materia di Cloud per la PA.

Le criticità individuate si articolano su due profili principali:

1. Incoerenza nella terminologia e classificazione dei dati

Il documento AGID categorizza i dati in “non sensibili”, “personali comuni” e “sensibili”. Questa terminologia risulta generica e in aperta contraddizione con la tassonomia ufficiale stabilita dall’Articolo 3 del Regolamento Cloud ACN, il quale impone alle Pubbliche Amministrazioni di classificare i propri dati e servizi digitali esclusivamente in tre categorie basate sull’impatto di un’eventuale compromissione: “ordinari”, “critici” e “strategici”.

L’utilizzo di una nomenclatura divergente nelle Linee Guida sull’IA rischia di generare profonda incertezza operativa e interpretativa tra le amministrazioni, complicando le procedure di adeguamento e conformità.

2. Limitazioni tecnologiche ingiustificate (Cloud vs On-Premise)

Il regolamento AGID dispone vincoli architetturali stringenti legati alla propria definizione di dati “sensibili”. In particolare, richiede l’obbligo di utilizzo di infrastrutture “on-premise” (o cloud privato della PA con forte segregazione) sia per la fase di addestramento dei modelli (identificata come “Opzione 2”), sia per la fase di esercizio (identificata come “Scenario C”).

Tale imposizione contrasta con il Regolamento Cloud ACN, il quale ha già stabilito un framework che consente l’elaborazione in cloud per tutte le categorie di dati, inclusi quelli “critici” e “strategici” (previa l’applicazione di opportune e piu’ stringenti misure di sicurezza). Il regolamento ACN dimostra infatti che la tutela del patrimonio informativo non passa unicamente per l’isolamento fisico dell’hardware (on-premise), ma si ottiene applicando stringenti prescrizioni sovrane in ambiente Cloud, quali ad esempio: la localizzazione obbligatoria dei dati dell’amministrazione sul territorio dell’Unione Europea, il controllo e la segregazione logica spinta tramite sovranità crittografica, imponendo meccanismi come il Bring Your Own Key (BYOK) per i dati critici e l’Hold Your Own Key (HYOK) gestito tramite Hardware Security Module (HSM) esclusivi per i dati strategici. E l’impossibilità di accesso ai dati da parte di entità extra-UE per i dati strategici senza una previa ed esplicita autorizzazione della singola Amministrazione.

Proposta di modifica: Alla luce di quanto esposto, si raccomanda di armonizzare il testo delle Linee Guida AGID con il Regolamento Cloud ACN. In particolare, si suggerisce di:

  1. Adottare integralmente la classificazione ACN (dati ordinari, critici e strategici) sostituendo i riferimenti generici ai dati “sensibili”.

  2. Rimuovere il vincolo esclusivo dell’infrastruttura “on-premise”, riconoscendo che le Pubbliche Amministrazioni possono avvalersi di servizi Cloud per addestrare ed eseguire modelli di IA anche su dati di massima criticità o strategici, a condizione che tali servizi possiedano le qualifiche di sicurezza del regolamento Cloud ACN e del Perimetro di Sicurezza Nazionale Cibernetica adeguate ai livelli previsti, e implementino le necessarie tutele di sovranità tecnologica e crittografica previste dalla vigente normativa. Questa modifica permetterebbe alla PA di beneficiare della potenza computazionale e della scalabilità intrinseche del Cloud pubblico, requisiti spesso fondamentali per l’IA moderna

12

Segnaliamo le nostre proposte, puntualmente riferite ad alcuni passaggi.
Cordialmente

Paragrafo 3.2

Non è esplicitato un livello dedicato all’interazione e comunicazione con l’utente. Si propone di introdurre un riferimento a componenti di:

  • interfaccia comunicativa,
  • spiegazione degli output (explainability per utenti non tecnici).

Paragrafo 3.2 - Pag 44

Per una migliore comprensione, si propone di riformulare il secondo capoverso come segue:

“Gli agenti software in architetture di questo tipo possono gestire compiti complessi e articolati in più fasi. Il loro comportamento varia in funzione del livello di autonomia, classificato da L0 a L5:

Livello 0 – Completamente manuale

Livello 1 – Automazione basata su regole

Livello 2 – Automazione intelligente dei processi

Livello 3 – Workflow agentici

Livello 4 – Agenti semi-autonomi

Livello 5 – Agenti completamente autonomi

I livelli sono descritti nel seguito e sintetizzati nella Tabella 2.”

Paragrafo 3.2 - Pag 44

Relativamente al Livello 2 si propone la seguente riformulazione: “Nel Livello 2 – Automazione intelligente dei processi, un agente combina: capacità di automazione (es. RPA, workflow orchestration) capacità di percezione e analisi basate su tecniche di IA (es. Machine Learning, Natural Language Processing, Computer Vision) L’agente non è autonomo, ma opera con supervisione umana, analogamente ai sistemi ADAS, che supportano il guidatore attraverso funzioni avanzate di assistenza basate su sensori e modelli di AI. Dal punto di vista tecnologico, questi sistemi integrano componenti di ML, NLP, CV, insieme a strumenti di automazione dei processi e orchestrazione.” al fine di osservare una più precisa aderenza tecnologica

Paragrafo 3.2 - Pag 45

Relativamente al Livello 3 si propone la seguente riformulazione: “Livello 3 – Workflow agentici. Gli agenti sono in grado di pianificare sequenze di azioni, adattarsi al contesto, generare contenuti e prendere decisioni operative all’interno di domini ben definiti. L’autonomia è limitata e l’essere umano interviene nei casi limite o nelle situazioni non previste. Un’analogia utile è la navigazione automatica in autostrada: il sistema gestisce la guida ordinaria, mentre l’essere umano mantiene la supervisione e interviene quando necessario.

Dal punto di vista tecnologico, questi agenti combinano modelli linguistici di grandi dimensioni (LLM), sistemi di memoria, capacità di utilizzare strumenti esterni (tool use) e forme semplici di apprendimento per rinforzo o feedback iterativo. Le applicazioni includono copilot per il supporto alla scrittura o al codice, analisti RAG (Retrieval-Augmented Generation), pipeline ETL automatizzate, ambienti di esercizio supervisionati e progetti pilota.”

Paragrafo 3.2 - Pag 45

Relativamente al Livello 4 si propone la seguente riformulazione: “Gli agenti operano in modo autonomo all’interno di ambiti di competenza chiaramente delimitati, adattando le strategie operative e ottimizzando le decisioni in base al contesto. Possono apprendere o aggiornare i propri comportamenti in modo controllato. L’essere umano interviene solo in situazioni eccezionali o fuori dai limiti operativi previsti. Un’analogia utile è la guida autonoma in condizioni specifiche: il sistema gestisce la maggior parte delle situazioni, mentre l’essere umano interviene nei casi limite.

Dal punto di vista tecnologico, questi agenti integrano capacità avanzate di pianificazione, ragionamento guidato da modelli, adattamento in tempo reale e forme di ragionamento causale assistito. Le applicazioni includono taxi autonomi operanti in aree geografiche delimitate, robotica di magazzino, droni per ispezioni, sistemi di auto‑remediation AIOps e ambienti di esercizio semi‑autonomi in contesti vincolati.”

Paragrafo 3.2 - Pag 45

Relativamente al Livello 5 si propone la seguente riformulazione: “Livello 5 – Agenti completamente autonomi. Gli agenti operano in modo pienamente autonomo, con capacità di generalizzazione e adattamento che si estendono oltre i singoli domini applicativi. Sono in grado di apprendere, pianificare e prendere decisioni complesse senza intervento umano, gestendo anche condizioni non previste. Un’analogia utile è quella dei veicoli completamente autonomi, in grado di operare ovunque e in qualsiasi condizione senza supervisione.

Dal punto di vista tecnologico, questi agenti richiedono sistemi di memoria avanzati, meccanismi di apprendimento sofisticati, capacità di ragionamento generalizzato e componenti di safety automation per garantire affidabilità e sicurezza in autonomia completa. Al momento non esistono applicazioni operative: il Livello 5 è oggetto esclusivo di attività di ricerca.”

Paragrafo 3.2 - Pag 48

Si propone di riformulare il seguente periodo “Al centro dell’architettura si colloca l’Orchestratore IA, un sistema di coordinamento che funge da punto di controllo unificato per tre componenti fondamentali dell’ecosistema IA della PA.” Con “Al centro dell’architettura si colloca l’Orchestratore IA, il componente di coordinamento che funge da punto di controllo unificato per le tre componenti fondamentali dell’ecosistema di Intelligenza Artificiale della Pubblica Amministrazione.”

Paragrafo 3.2 - Pag 49

PEFT: Parameter-Efficient Fine-Tuning

Paragrafo 3.2.2 - Pag 50

Si propone di riformulare il primo capoverso come segue: “I dati utilizzati nell’architettura possono appartenere a diverse tipologie e strutture: basi di conoscenza, data lake, basi dati semantiche o graphDB. Possono essere distribuiti o centralizzati, con storage on‑premise, in cloud o in modalità ibrida.

A titolo esemplificativo:

- Database distribuiti: Sistemi in cui i dati sono archiviati su più nodi fisici o logici, mantenendo coerenza e disponibilità. Sono utilizzati per dati transazionali e operativi che richiedono scalabilità e resilienza.

- Graph Database (graphDB): Basi dati progettate per rappresentare e interrogare relazioni complesse tra entità (ad esempio cittadini, procedimenti, organizzazioni esterne). Sono ideali per modelli semantici, knowledge graph e analisi di relazioni.

- Data Lake: Archivi scalabili che raccolgono grandi volumi di dati eterogenei (strutturati, semi‑strutturati e non strutturati). Sono utilizzati per basi di conoscenza, archivi storici e dataset su cui applicare tecniche avanzate di data analytics e AI.”

Paragrafo 3.2 .2 - Pag 51

In riferimento al seguente capoverso” Alimentando la molteplicità dei modelli sopra citati, i dati possono essere utilizzati per attività di training di modelli propri, per il tuning di modelli utilizzati mediante servizi cloud o per l’esercizio di modelli già in produzione. L’accesso stesso ai dati, inoltre, può avvenire tramite strumenti come Retrieval-Augmented Generation (RAG), API esterne o altre fonti in cloud e on-prem.” Si segnala che la descrizione appare non semanticamente chiara, sarebbe opportuno inserire la classificazione dei dati che, a titolo di esempio, viene di seguito riportata:

I metodi di classificazione nell’AI possono essere: Supervised Learning (Apprendimento supervisionato), Unsupervised Learning (Non supervisionato), Semi‑supervised Learning, Reinforcement Learning, Deep Learning, ecc. (Tom Mitchell, Machine Learning, 1997).

Paragrafo 3.4

Si evidenzia il divario tra le prescrizioni teoriche riportate nel documento e la realtà operativa delle Pubbliche Amministrazioni:

  1. Le linee guida impongono che i dati siano accurati, rappresentativi e privi di bias. Tecnicamente, ciò richiede pipeline di Data Cleaning e Bias Detection estremamente sofisticate. La criticità risiede nella mancanza di protocolli standardizzati per certificare che un dataset della PA sia effettivamente “pronto per l’IA”, rischiando di addestrare modelli su dati storici che riflettono inefficienze o discriminazioni pregresse.
  2. Sebbene si promuova l’uso di basi dati nazionali, l’integrazione tecnica tra sistemi obsoleti e i nuovi sistemi di IA è un collo di bottiglia. La trasformazione di dati eterogenei in formati pronti per il machine learning comporta costi e tempi di sviluppo che il documento tende a sottostimare.
  3. L’anonimizzazione e la protezione dei dati si scontra con la difficoltà tecnica di garantire l’irreversibilità in dataset complessi. Mancano indicazioni su standard matematici specifici, lasciando alle singole amministrazioni il rischio legale e tecnico di possibili attacchi di re-identificazione.
  4. Il paragrafo non approfondisce la necessità di tracciare l’origine e le trasformazioni dei dati. Senza un rigoroso versionamento dei dataset diventa tecnicamente impossibile effettuare il debugging di un errore del sistema di IA o rispondere ad audit legali sulla decisione presa dall’algoritmo.

Paragrafo 3.4.1 – pag 60

È opportuno considerare che avere una certificazione della provenienza del dato è indispensabile per non incorrere nel problema della “sindrome della mucca pazza” (Alemohammad, S., Casco-Rodriguez, J., Luzi, L., Humayun, A. I., Babaei, H., LeJeune, D., Siahkoohi, A., & Baraniuk, R. G. (2023). Self-Consuming Generative Models Go MAD). Nel contesto dell’AI, l’espressione “morbo della mucca pazza” indica il rischio che i modelli vengano addestrati su dati generati da altre AI (o da sé stessi), invece che su dati reali. Questo auto‑riutilizzo porta a un progressivo deterioramento della qualità e alla propagazione degli errori e, nel tempo, a un vero e proprio “collasso del modello”.

Paragrafo 3.4.1 – pag 61

È opportuno precisare meglio il “Volume” come di seguito “Volume: rappresenta la scala dei dati di addestramento, tipicamente composta da miliardi/trilioni di token, cioè unità elementari di testo.”

Paragrafo 3.4.2 pag 67/68

Si segnala una possibile incoerenza. Il paragrafo sembra affrontare il tema della gestione dei dati strutturati; tuttavia, lo collega allo scenario del Data Lake che invece riferisce all’utilizzo di dati non strutturati.

13

Contributo a cura di Dedalus Italia S.p.A.

Dedalus riconosce l’architettura logica proposta come pienamente coerente con le esperienze maturate nello sviluppo di piattaforme di Intelligenza Artificiale per la Pubblica Amministrazione. In particolare, l’adozione di un orchestratore potrebbe rappresentare un elemento di vantaggio in quanto consente di governare in modo centralizzato la selezione, la composizione e l’evoluzione di modelli eterogenei, includendo sia modelli linguistici sia modelli non linguistici, open e non, come strumenti di ottimizzazione dei processi decisionali e dell’efficienza operativa. L’orchestratore consente di bilanciare accuratezza, costi computazionali e requisiti di servizio, adattando dinamicamente il comportamento del sistema al contesto applicativo.

Nei contesti caratterizzati da dati ad alta sensibilità, come quelli trattati da Dedalus in ambito sanitario, l’architettura permette una gestione del dato conforme a molteplici vincoli, quali anonimizzazione e pseudo‑anonimizzazione, separando in modo rigoroso i livelli di accesso ai dati, ai modelli e alle funzionalità applicative. Questo approccio rafforza la governance del dato, la conformità normativa e la possibilità di riuso controllato delle informazioni.

14

Par 3.2 — Modello di Architettura IA di riferimento per la PA

Il documento propone come architettura di riferimento un impianto con orchestratore centrale, agenti e middleware di astrazione. Questo modello è ragionevole per sistemi complessi e multi-dominio; diventa un vincolo ingiustificato se inteso come schema universale. La maggioranza degli use case PA — funzioni assistite, ricerca documentale, classificazione — richiede architetture ben più semplici, per le quali il modello agentico è sovradimensionato e introduce costi di progettazione, testing e governance sproporzionati.

Si propone di riformulare il modello come riferimento per sistemi complessi o per quei sistemi in cui sia necessario un approccio agentico rispetto a tecniche di AI classica non generativa, con esplicito riconoscimento delle architetture più semplici come scelta tecnicamente corretta per use case a bassa complessità. Più in generale, l’obiettivo delle Linee Guida non dovrebbe essere prescrivere una specifica tipologia architetturale, ma richiedere garanzie verificabili su portabilità, integrazione, livelli di servizio, auditabilità, reversibilità e gestione del rischio fornitore, indipendentemente dalla forma della soluzione sottostante.

Con riferimento all’interoperabilità tra agenti software, si raccomanda che le Linee Guida promuovano l’adozione di protocolli e standard aperti riconosciuti per l’interazione tra modelli e strumenti, la cooperazione tra agenti e la descrizione delle capacità agentiche. A titolo di esempio, protocolli quali Model Context Protocol, Agent-to-Agent e Open Agent Specification. L’adozione di standard aperti in questo dominio è la condizione necessaria per garantire la portabilità dei sistemi agentici tra piattaforme diverse senza oneri di re-engineering, in coerenza con gli obiettivi anti lock-in già enunciati nel documento.

15

Contributo a cura di Traent Srl.

Si propone di integrare il §3.2.4 -*Orchestrazione IA” (pagg. 53-54) - *dell’architettura logica prevedendo un componente dedicato alla certificazione indipendente degli eventi di sistema, strutturalmente separato sia dall’Orchestratore IA («motore decisionale centrale», pag. 53) sia dal middleware API che attualmente svolge funzioni di «gestione di sicurezza e compliance, validando le richieste di attivazione di Modelli IA e garantendone caratteristiche di tracciabilità» (pag. 54). L’attuale architettura configura un conflitto strutturale: le funzioni di certificazione risiedono nello stesso componente che esegue le operazioni da certificare. Il principio di separazione dei ruoli, consolidato nel framework NIST AI RMF (MAP 1.5, GOVERN 1.2) e nella prassi di sicurezza ISO/IEC 27001, richiede che chi certifica sia indipendente da chi opera. Un componente di verifica separato — che registri e certifichi crittograficamente invocazioni, selezione dati, output e modifiche di configurazione — renderebbe le dichiarazioni di conformità opponibili e non autoreferenziali. Si chiede inoltre di richiamare tale componente nel §3.3, dimensione “Sicurezza e compliance”.

16

La sezione sull’architettura rappresenta uno dei punti più avanzati del documento, ma necessita di un rafforzamento significativo sul piano della sicurezza, in particolare per quanto riguarda l’orchestratore. Questo componente costituisce infatti il punto di maggiore esposizione del sistema, in quanto coordina modelli, dati e strumenti esterni. L’assenza di requisiti specifici espone le PA a rischi elevati, tra cui prompt injection indiretta, esfiltrazione di dati e abuso dei tool. Si propone pertanto di introdurre obblighi espliciti relativi a input validation, principio del minimo privilegio, audit trail immutabile e rilevamento di comportamenti anomali. Inoltre, si suggerisce di integrare la sezione con riferimenti alla Piattaforma Digitale Nazionale Dati (PDND) per l’accesso alle basi dati pubbliche e di prevedere l’adozione di principi di Zero Trust Architecture per i sistemi che trattano dati sensibili o supportano decisioni amministrative con effetti giuridici.

17

Questo argomento è stato automaticamente chiuso dopo 26 giorni. Non sono permesse altre risposte.