Automazione documentale e AI per la pubblica amministrazione

Il problema

Negli enti pubblici gran parte del lavoro quotidiano è documentale e ripetitivo: protocollare la posta in arrivo, smistare i compiti ai referenti giusti, tenere in ordine un archivio che cresce ogni anno, acquisire le fatture e tenerne le scadenze, riconciliare i pagamenti. È lavoro che va fatto bene e in tempo, ma che raramente ha bisogno di una decisione umana ad ogni singolo passaggio - e che oggi assorbe ore di personale che potrebbero andare altrove.

Cosa consegno

Il punto di partenza è sempre uno studio di fattibilità e un piano operativo: mappo i processi reali, non quelli sulla carta, e disegno le automazioni intorno a un backend che resta l'unica fonte di verità.

• Backend proprietario su ABP Framework (.NET): il database è l'unica fonte di verità, non un modello linguistico.
• Un server MCP di dominio: gli assistenti AI scrivono solo attraverso tool controllati e autorizzati per permesso - mai in SQL diretto.
• Un secondo server MCP, separato, che legge le condivisioni file con l'identità dell'utente loggato: le ACL NTFS le applica il file server, non il codice applicativo.
• Infrastruttura interamente on-premise, PostgreSQL come database.
• Un impianto di governance AI Act: policy interna, registro dei sistemi AI, piano di formazione art. 4.

Perché on-premise, e perché due server MCP separati

Per un ente pubblico il vincolo che conta di più, di solito, non è quale modello AI si usa: è dove vivono i documenti e chi può leggerli. Per questo l'infrastruttura resta on-premise, e per questo divido l'accesso in due canali con superfici di fiducia diverse. Il server MCP di dominio espone all'AI solo operazioni esplicitamente autorizzate, mai una query libera sul database. Il server MCP che legge le condivisioni file, invece, non implementa permessi propri: gira con l'identità dell'utente loggato, cosicché sia il file server - con le sue ACL NTFS esistenti - a decidere chi vede cosa, non una lista di permessi scritta a mano nel codice applicativo.

Cosa dice la normativa

Chi valuta un progetto come questo in un ente pubblico si scontra presto con l'AI Act e con la normativa italiana di recepimento. Quello che segue è verificato sul testo consolidato EUR-Lex (CELEX:02024R1689, versione 27.07.2026) e sulla Legge 132/2025, controllato il 21-22 settembre 2026:

• Art. 4 (alfabetizzazione in materia di IA): in vigore dal 2 febbraio 2025, vincola sia i fornitori sia gli utilizzatori. Dal Digital Omnibus (Regolamento (UE) 2026/1744, in vigore dal 27 luglio 2026) il testo è cambiato: oggi si parla di «adottare misure a sostegno dello sviluppo» dell'alfabetizzazione IA, e non si richiede più di garantire un livello specifico in ogni singola persona. Buona parte del materiale italiano in circolazione cita ancora la formulazione del 2024 («garantire un livello sufficiente»), superata da luglio 2026.
• Obblighi per i sistemi ad alto rischio (capo III, sezioni 1-3): rinviati al 2 dicembre 2027 per i sistemi standalone dell'Allegato III, e al 2 agosto 2028 per quelli incorporati nei prodotti dell'Allegato I.
• Art. 27 (valutazione d'impatto sui diritti fondamentali, FRIA): nomina esplicitamente gli enti pubblici tra i soggetti tenuti a effettuarla, e segue lo stesso rinvio del capo III.
• Legge 132/2025 (in vigore dal 10 ottobre 2025), art. 14 comma 2: l'uso dell'IA nella pubblica amministrazione è «in funzione strumentale e di supporto» e chi decide «resta l'unica responsabile» della decisione. Il comma 4 aggiunge che gli enti devono rispettare questi obblighi con le risorse già disponibili, senza un budget dedicato.

Informazioni aggiornate a settembre 2026 - la materia cambia in fretta, verificale prima di usarle come riferimento operativo.

Il caso reale

Per il consorzio C.I.S.A. sto seguendo la fase 1 - studio di fattibilità e piano operativo - per cinque automazioni: protocollazione assistita della posta in arrivo, smistamento dei compiti ai referenti, riordino e indicizzazione dell'archivio documentale, acquisizione delle fatture con scadenzari, riconciliazione dei pagamenti. Il backend è in C# su ABP Framework, con il database come unica fonte di verità e un server MCP di dominio per l'accesso dell'AI. Un secondo server MCP, a parte, legge le condivisioni file con l'identità dell'utente loggato. Ogni decisione persistita registra la propria origine - AI o operatore - con conferma umana obbligatoria sui passaggi contabili. L'infrastruttura è interamente on-premise, con il lavoro di governance EU AI Act incluso. È la fase 1: uno studio di fattibilità e un piano operativo, non un sistema già in produzione.

Per un riferimento su cosa intendo per «portato in produzione davvero»: con SPRocket, in FEDRO Software, sono passato da zero a produzione in 3 mesi, con un sistema che oggi gestisce 4.000+ ore di audio al mese al 99.9% di uptime.

Chi sono

Sono Solution Architect & Technical Lead in FEDRO Software, dove lavoro da 7+ anni su sistemi .NET enterprise. Questo tipo di progetto lo seguo in proprio, come libero professionista con partita IVA, parallelamente al ruolo in FEDRO.