Sviluppo software per la pubblica amministrazione: guida 2026 a compliance, costi e realizzazione

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Nel 2026 lo sviluppo software per la pubblica amministrazione riguarda tanto l’abbandono dei vecchi sistemi quanto la costruzione di nuovi. Nella sua analisi 2025 dell’IT federale, GAO-25-107795, il Government Accountability Office statunitense ha rilevato che circa 83 miliardi di dollari, ovvero il 79% della spesa IT pianificata per l’anno fiscale 2025 dalle 24 principali agenzie federali, erano destinati alla gestione e alla manutenzione dei sistemi esistenti, e che le agenzie spendono in questo modo in genere circa l’80% dei propri budget IT. Ogni dollaro speso per tenere in vita un sistema vecchio di decenni è un dollaro non investito nei servizi che i cittadini usano davvero.

Realizzare software pubblico è inoltre più difficile che realizzare software commerciale. Lo stesso progetto deve superare un’autorizzazione di sicurezza, rispettare le leggi sull’accessibilità, affrontare una procedura di appalto, conservare documentazione per anni e reggere il controllo pubblico quando qualcosa va storto. Per questo le agenzie affidano sempre più spesso la realizzazione a team specializzati in sviluppo software GovTech, che progettano per l’autorizzazione e l’accessibilità fin dal primo giorno anziché trattarle come una checklist finale.

Questa guida tratta lo sviluppo software per il settore pubblico in tre contesti: le agenzie federali statunitensi, le amministrazioni statali e locali degli Stati Uniti e gli enti pubblici dell’Unione europea. Spiega che cos’è il software per la pubblica amministrazione, quali sistemi realizzano le agenzie, le regole di compliance in vigore nel 2026, in cosa differiscono i progetti federali, statali, locali e dell’UE, quando sviluppare o acquistare, il processo di realizzazione, la modernizzazione legacy, il ruolo dell’IA, costi e tempistiche realistici, il procurement e come scegliere un partner di sviluppo.

Che cos’è lo sviluppo software per la pubblica amministrazione?

Lo sviluppo software per la pubblica amministrazione è la progettazione, la realizzazione e la gestione di sistemi digitali per gli enti pubblici: portali per i cittadini, gestione delle pratiche, piattaforme fiscali e per i sussidi, sistemi di pubblica sicurezza e gli strumenti interni su cui lavorano le agenzie. Segue le stesse pratiche di ingegneria del software commerciale, ma aggiunge quattro vincoli che i team commerciali raramente affrontano tutti insieme: autorizzazione di sicurezza formale, leggi sull’accessibilità, regole degli appalti pubblici e obblighi di lungo periodo in materia di documentazione e trasparenza.

Questi vincoli cambiano il modo in cui il lavoro viene pianificato. Un team di prodotto commerciale può lanciare una beta e sistemare l’accessibilità in seguito; un’agenzia statale di solito no, perché l’accessibilità è un obbligo di legge fin dal primo rilascio pubblico. Una startup può scegliere qualsiasi regione cloud; un programma federale deve girare su un’infrastruttura che disponga dell’autorizzazione adeguata ai suoi dati. Un’azienda privata può cambiare fornitore con un preavviso contrattuale; un’agenzia ha bisogno di un piano di uscita documentato, della portabilità dei dati e, nell’UE, talvolta dell’obbligo di condividere la propria soluzione con altri enti pubblici.

La maggior parte dei sistemi pubblici rientra in quattro modelli di relazione. Il modello indica chi sono gli utenti, quali regole di identità e accessibilità si applicano e quanta visibilità pubblica avrà il sistema.

All’interno di questi modelli, le agenzie scelgono tra prodotti pronti all’uso, piattaforme configurabili e sviluppo di software su misura per l’agenzia. Il lavoro su misura è di solito riservato ai processi definiti da una legge specifica, ai sistemi che devono dialogare con mainframe legacy e ai servizi per cui nessun prodotto autorizzato è adatto. Funzioni standard come HR, buste paga ed email sono in genere servite meglio da prodotti commerciali autorizzati.

Perché nel 2026 le agenzie modernizzano il software pubblico?

Nel 2026 le agenzie modernizzano perché i sistemi legacy assorbono la maggior parte dei budget IT, diverse scadenze di legge sono vicine e i cittadini si aspettano ormai che i servizi pubblici funzionino con la stessa semplicità dell’app della propria banca. La pressione arriva da sei direzioni contemporaneamente:

• Gestione e manutenzione si mangiano il budget. Nel 2025 il GAO ha riferito che circa il 79% della spesa IT pianificata per l’anno fiscale 2025 dalle 24 agenzie soggette al CFO Act, circa 83 miliardi di dollari, era destinato a gestione e manutenzione, lasciando poco per nuove capacità.
• I sistemi critici sono molto vecchi. Lo stesso rapporto del GAO ha rilevato che gli 11 sistemi legacy federali più critici hanno tra 23 e 60 anni e che 8 di essi girano su linguaggi di programmazione obsoleti come il COBOL.
• I piani di modernizzazione sono in ritardo. A febbraio 2025 il GAO contava 28 modernizzazioni legacy completate su 65 pianificate, ovvero il 43%, per cui la maggior parte delle agenzie porta ancora nel 2026 un arretrato di modernizzazione.
• L’esperienza digitale è ormai un’aspettativa di legge. Il 21st Century Integrated Digital Experience Act (21st Century IDEA) richiede che i siti web e i servizi digitali federali siano accessibili, coerenti, adatti ai dispositivi mobili e ricercabili, spingendo le agenzie a ricostruire i vecchi portali.
• Le scadenze sull’accessibilità sono fissate. La norma ADA Title II del Dipartimento di Giustizia degli Stati Uniti impone che i contenuti web e le app mobili delle amministrazioni statali e locali soddisfino le WCAG 2.1 AA, con date di conformità ad aprile 2027 e aprile 2028 dopo la proroga del 2026.
• L’UE si muove verso l’identità digitale. In base a eIDAS 2.0, ogni Stato membro dell’UE deve offrire un portafoglio europeo di identità digitale (EUDI Wallet) e le pubbliche amministrazioni devono accettarlo entro il 24 dicembre 2026, quindi i servizi pubblici in tutta Europa hanno bisogno di accessi e flussi documentali compatibili con il wallet.

L’intelligenza artificiale aggiunge una settima pressione. Le agenzie vogliono usare l’IA per ridurre gli arretrati nell’elaborazione dei documenti e nei contact center, ma hanno bisogno di supervisione umana, log di audit e test sui bias che i team commerciali spesso possono saltare.

Quali tipi di software realizzano le agenzie pubbliche?

Le agenzie realizzano nove tipi principali di software pubblico, dai portali rivolti ai cittadini ai sistemi contabili interni. Ogni tipo ha un profilo di rischio diverso, quindi è il tipo a determinare il livello di autorizzazione, l’impegno per l’accessibilità e il lavoro di integrazione molto prima che venga scritta una riga di codice.

Portali e servizi digitali per i cittadini

I portali per i cittadini sono la porta d’ingresso della pubblica amministrazione: un unico luogo per presentare domande, pagare, prenotare, seguire una richiesta o aggiornare i propri dati personali. Un buon portale nasconde l’organigramma ed è strutturato attorno agli eventi della vita, come un trasloco, l’avvio di un’impresa o la nascita di un figlio. Una capacità chiave è l’account unico con domande salvate e monitoraggio dello stato, così i cittadini non devono reinserire gli stessi dati per ogni agenzia. La nostra guida allo sviluppo di portali web illustra modelli architetturali validi anche per i portali pubblici.

Gestione delle pratiche, permessi e licenze

I sistemi di gestione delle pratiche governano il lavoro che sta dietro a una decisione pubblica: arriva una domanda, il personale la esamina, richiede documenti, applica le regole ed emette una decisione. I sistemi per permessi e licenze ne sono una variante diffusa per permessi di costruire, licenze commerciali e abilitazioni professionali. La capacità più importante è un flusso di lavoro configurabile, così le modifiche alle regole dopo una nuova legge o un nuovo regolamento possono essere introdotte senza un nuovo sviluppo completo.

Piattaforme fiscali, per le entrate e per i sussidi

Le piattaforme fiscali, per le entrate e per i sussidi calcolano quanto una persona o un’impresa deve o deve ricevere e movimentano denaro reale, per cui precisione e verificabilità vengono prima di tutto. Spesso trattano informazioni fiscali federali, che comportano i controlli della IRS Publication 1075, o dati sanitari, che comportano l’HIPAA. Una capacità tipica è un motore di regole che codifica la logica di idoneità e di calcolo in una forma testabile e versionata, che revisori e responsabili delle politiche possono esaminare.

Procurement e gare telematiche

I sistemi di procurement e di gare telematiche pubblicano le opportunità, raccolgono le offerte, gestiscono le valutazioni e amministrano i contratti. Devono essere trasparenti e a prova di manomissione, perché una gara contestata può bloccare un programma per mesi. Le capacità fondamentali sono invii con marca temporale, gestione delle offerte in busta chiusa, dichiarazioni sul conflitto di interessi dei valutatori e un log di audit completo di ogni decisione.

Pubblica sicurezza e gestione delle emergenze

Il software per la pubblica sicurezza comprende il dispatch assistito da computer, la gestione dei registri per polizia e vigili del fuoco, l’allerta di emergenza e il coordinamento degli interventi. Qualsiasi sistema che tocchi informazioni di giustizia penale deve rispettare la CJIS Security Policy dell’FBI, che stabilisce requisiti per il controllo degli accessi, la cifratura e la verifica del personale. La disponibilità è il requisito dominante: questi sistemi hanno bisogno di failover collaudato e di modalità offline per le unità sul campo.

Registri, gestione documentale e FOIA

I sistemi di gestione dei registri e dei documenti acquisiscono, classificano, conservano ed eliminano gli atti pubblici secondo i piani di conservazione. Supportano anche le richieste ai sensi del Freedom of Information Act (FOIA) e le richieste di accesso agli atti, in cui contano rapidità e oscuramento accurato. Una capacità preziosa è il supporto automatizzato alla classificazione e all’oscuramento, con un revisore umano che approva ogni pubblicazione.

Piattaforme geospaziali, GIS e smart city

Le piattaforme geospaziali alimentano mappe urbanistiche, gestione degli asset, pianificazione dei trasporti e risposta alle emergenze, mentre i sistemi smart city aggiungono dati dai sensori di semafori, reti di servizi e monitoraggi ambientali. Combinano grandi set di dati con flussi in tempo reale, per cui sono l’architettura dei dati e gli standard aperti a decidere se scalano. Una capacità comune è un livello cartografico pubblico che i cittadini possono interrogare, supportato da livelli interni ad accesso riservato.

ERP, HR e contabilità interni per le agenzie

I sistemi interni di ERP, HR e contabilità gestiscono bilanci, buste paga, acquisti, contributi e personale. Queste esigenze sono di solito ben coperte da prodotti commerciali autorizzati, per cui il lavoro su misura si concentra in genere sulle integrazioni e sulle regole contabili specifiche dell’agenzia per contributi e fondi. La capacità chiave è un’integrazione affidabile con i sistemi di riferimento che alimentano i report per legislatori e revisori.

API open data e piattaforme di interoperabilità

Le piattaforme open data e di interoperabilità consentono alle agenzie di pubblicare set di dati e di scambiarsi informazioni tramite API documentate. Nell’UE, l’Interoperable Europe Act rende l’interoperabilità un requisito di progettazione previsto dalla legge per i servizi pubblici digitali transfrontalieri. Una capacità fondamentale è un catalogo di API governato, con versionamento, autenticazione, limiti di utilizzo e documentazione leggibile dalle macchine.

Quali funzionalità deve avere una piattaforma pubblica?

Ogni piattaforma pubblica ha bisogno di identità sicura, moduli accessibili, pagamenti, controllo degli accessi verificabile e un livello API, qualunque sia il servizio erogato. Queste capacità sono costose da aggiungere a posteriori, quindi appartengono alle prime decisioni architetturali anziché a un rilascio successivo:

• Identità e autenticazione. I servizi federali usano spesso Login.gov, che supporta la verifica dell’identità al NIST Identity Assurance Level 2 (IAL2); i servizi statali possono usare provider di identità statali o la verifica dell’identità commerciale; i servizi dell’UE devono prepararsi all’EUDI Wallet previsto da eIDAS 2.0. L’autenticazione a più fattori resistente al phishing è l’impostazione predefinita sicura per il personale.
• Moduli digitali e firma elettronica. Moduli intelligenti che precompilano i dati noti, convalidano mentre l’utente digita, salvano i progressi e accettano documenti dalla fotocamera del telefono riducono gli abbandoni e le rilavorazioni del personale.
• Pagamenti ed erogazioni. Riscossione di tariffe, rimborsi e pagamenti di sussidi richiedono la riconciliazione con i sistemi contabili, ricevute chiare e il supporto ai metodi di pagamento che i cittadini usano davvero.
• Accesso basato sui ruoli e audit trail. Ogni lettura e modifica di dati sensibili dovrebbe essere attribuibile a una persona e a un motivo, con log a prova di manomissione che supportino indagini e richieste di accesso agli atti.
• Notifiche e monitoraggio dello stato. Aggiornamenti via email, SMS e in-app sullo stato delle domande riducono il volume del call center; i modelli devono essere accessibili e disponibili nelle lingue supportate dall’agenzia.
• Ricerca in linguaggio chiaro e contenuti multilingue. I cittadini cercano attività, non nomi di uffici. Contenuti scritti in linguaggio chiaro, tradotti per le comunità linguistiche locali e testati con utenti reali fanno per i tassi di completamento più di qualsiasi rifinitura grafica.
• Analytics e livello API. Dashboard su tassi di completamento, tempi di elaborazione e punti di abbandono guidano il miglioramento, mentre API documentate consentono ad altre agenzie e a partner approvati di riutilizzare i dati senza screen scraping.

Quali regole di compliance si applicano al software pubblico?

Il software pubblico deve rispettare regole di autorizzazione di sicurezza come FedRAMP, GovRAMP e FISMA, regole specifiche per i dati come CJIS, HIPAA e IRS Publication 1075 e leggi sull’accessibilità come Section 508 e ADA Title II; i progetti nell’UE aggiungono GDPR, NIS2, eIDAS 2.0, l’Interoperable Europe Act e l’AI Act dell’UE. Quali regole si applichino dipende da chi è il cliente, da quali dati contiene il sistema e da dove è ospitato. La mappa della compliance qui sotto riassume i framework che la maggior parte dei progetti incontra nel 2026.

I controlli di sicurezza e le pratiche di sviluppo sicuro vanno progettati fin dall’inizio, non documentati a posteriori. La nostra guida al NIST SSDF spiega come le pratiche di sviluppo sicuro si collegano all’attestazione che gli acquirenti federali richiedono ora ai produttori di software.

FedRAMP 20x spiegato in parole semplici

FedRAMP 20x è l’iniziativa di FedRAMP per rendere più rapida l’autorizzazione dei servizi cloud, sostituendo lunghi documenti descrittivi con evidenze automatizzate e leggibili dalle macchine e con una validazione continua. Secondo FedRAMP, le Consolidated Rules 2026 (CR26) sono state lanciate il 25 giugno 2026 e hanno reso FedRAMP 20x ampiamente disponibile. Il programma ha rinominato i noti livelli di impatto Low, Moderate e High in Certification Classes B, C e D e ha aggiunto una nuova Class A a durata limitata.

L’introduzione è avvenuta per fasi. FedRAMP ha comunicato autorizzazioni pilota della Fase 2 al livello Moderate a partire dal 6 marzo 2026 e ha aperto la pipeline della Class C il 31 agosto 2026. A fine 2026 la lezione pratica per agenzie e fornitori è semplice: realizzare sistemi in grado di produrre automaticamente evidenze di sicurezza da infrastructure as code, log e scanner, perché è questa la direzione sia di FedRAMP sia degli ATO delle agenzie. Verifichi sempre i requisiti aggiornati su fedramp.gov prima di pianificare una richiesta.

FedRAMP si applica ai servizi cloud offerti alle agenzie federali. Il software su misura che un’agenzia ospita nel proprio ambiente cloud già autorizzato passa di solito invece attraverso il processo di ATO dell’agenzia stessa, ereditando i controlli dalla piattaforma autorizzata. Gli acquirenti statali e locali cercano per i prodotti cloud lo status GovRAMP (ex StateRAMP).

Accessibilità: progettare una volta sola per le WCAG 2.2 AA

La strategia di accessibilità più efficiente per il software pubblico è progettare e testare per le WCAG 2.2 livello AA fin dall’inizio, perché quest’unico obiettivo copre sia la Section 508 (WCAG 2.0 AA) sia la norma ADA Title II (WCAG 2.1 AA). Le versioni delle WCAG sono retrocompatibili, quindi soddisfare le 2.2 AA significa soddisfare anche le versioni precedenti richiamate dalla legge.

Per le amministrazioni statali e locali, le tempistiche sono cambiate nel 2026. La norma provvisoria del Dipartimento di Giustizia degli Stati Uniti pubblicata il 20 aprile 2026 ha spostato la data di conformità all’ADA Title II per gli enti che servono una popolazione di almeno 50.000 abitanti dal 24 aprile 2026 al 26 aprile 2027, e per gli enti più piccoli e i distretti speciali dal 26 aprile 2027 al 26 aprile 2028. Gli obblighi in sé non sono cambiati, quindi l’anno in più è tempo per correggere, non un motivo per aspettare.

Gli scanner automatici rilevano solo una parte dei problemi, quindi conviene pianificare test manuali con screen reader, navigazione da sola tastiera, ingrandimento e controllo vocale, e coinvolgere persone con disabilità nella ricerca sull’usabilità. La nostra guida all’accessibilità WCAG 2.2 elenca i criteri di successo che più spesso non vengono soddisfatti nelle applicazioni web. Gli acquirenti federali chiederanno inoltre un Accessibility Conformance Report basato sul modello VPAT, quindi conservi le evidenze dei test man mano.

In cosa differiscono i progetti federali, statali e locali?

I progetti per il settore pubblico federali, statali, locali e dell’UE differiscono soprattutto per l’autorizzazione richiesta, la legge sull’accessibilità applicabile, le modalità di acquisto e l’entità dei budget. Un fornitore che conosce bene un livello può comunque inciampare su un altro, quindi è opportuno mappare queste dimensioni prima di definire il perimetro di un progetto.

Ne derivano due conseguenze pratiche. Primo, un prodotto realizzato per uno Stato americano raramente può essere rivenduto a un altro senza modifiche a regole, moduli e integrazioni, quindi la configurabilità va prevista fin dall’inizio. Secondo, i progetti nell’UE comportano un esplicito obbligo di condivisione: in base all’Interoperable Europe Act (Regolamento (UE) 2024/903), dal 12 gennaio 2025 gli enti pubblici devono effettuare e pubblicare una valutazione di interoperabilità prima di fissare requisiti vincolanti nuovi o sostanzialmente modificati per i servizi pubblici digitali transeuropei, e devono condividere su richiesta con altri enti pubblici le soluzioni di interoperabilità, compreso il codice sorgente documentato.

Sviluppare, acquistare o personalizzare: cosa è adatto a un’agenzia pubblica?

La maggior parte delle agenzie dovrebbe acquistare software commerciale autorizzato per le funzioni standard, configurare una piattaforma low-code per la PA per i flussi di pratiche più comuni e riservare lo sviluppo su misura ai servizi definiti da leggi specifiche, a integrazioni profonde con sistemi legacy o a obblighi di condivisione open source. La risposta giusta è di solito un mix, deciso servizio per servizio anziché una volta per tutta l’agenzia.

Lo sviluppo su misura conviene quando la logica di idoneità o di calcolo è scritta nella legge e cambia spesso, quando il servizio dipende da dati bloccati in sistemi vecchi di decenni o quando l’agenzia deve pubblicare e condividere la soluzione. L’acquisto conviene per email, HR, buste paga, contabilità standard e altre funzioni in cui i processi sono simili tra organizzazioni. Il nostro framework sviluppare o acquistare illustra un modello di punteggio adattabile al portafoglio di un’agenzia.

Il processo di sviluppo software per la PA, passo dopo passo

Il processo di sviluppo software per la pubblica amministrazione si articola in otto fasi, e la differenza rispetto alla realizzazione commerciale è che autorizzazione di sicurezza e accessibilità attraversano ogni fase anziché attendere alla fine. Ciascuna fase qui sotto può essere usata come punto di controllo in un piano di progetto.

1. Discovery e mappatura delle norme. Il team mappa la legge, i regolamenti e le politiche che definiscono il servizio, il processo attuale, i dati coinvolti e i sistemi interessati. Il risultato è un backlog con priorità, un elenco dei vincoli giuridici e risultati misurabili come il tempo di elaborazione o il tasso di completamento digitale.
2. Ricerca con gli utenti, compresi gli utenti di tecnologie assistive. I ricercatori intervistano e osservano cittadini, imprese e personale di front office, comprese le persone che usano screen reader, ingranditori o controllo vocale e le persone con una conoscenza limitata della lingua inglese. Il personale di front office è spesso la fonte migliore sugli espedienti che il nuovo sistema deve eliminare.
3. Architettura e categorizzazione di sicurezza. Il sistema viene categorizzato in base all’impatto di una violazione, ad esempio secondo FIPS 199 per i sistemi federali, che fissa la baseline di controlli. Gli architetti scelgono un hosting con l’autorizzazione adeguata, progettano identità, logging e flussi di dati e decidono quali controlli ereditare dalla piattaforma.
4. Sviluppo agile per piccoli incrementi. Il lavoro viene rilasciato in sprint di due settimane, mostrando ogni volta software funzionante agli stakeholder. Un design system condiviso, come lo U.S. Web Design System (USWDS) per i servizi federali, mantiene le interfacce coerenti e accessibili per impostazione predefinita.
5. Test di sicurezza e accessibilità. Scansioni di sicurezza automatizzate, controlli delle dipendenze e penetration test procedono di pari passo con verifiche automatizzate dell’accessibilità e test manuali con tecnologie assistive. I difetti vengono tracciati come qualsiasi altro bug, con gravità e data di correzione.
6. Pacchetto di autorizzazione. Il team prepara il system security plan (SSP), i risultati della valutazione e il plan of action and milestones (POA&M) per i rischi aperti, e supporta la valutazione indipendente. Se le evidenze sono state raccolte automaticamente fin dal primo sprint, questa fase richiede settimane anziché mesi.
7. Rilascio graduale e migrazione dei dati. Il nuovo servizio viene lanciato prima per un gruppo pilota, una regione o un tipo di domanda, con i dati legacy migrati e riconciliati in prove ripetute. L’esercizio in parallelo con il vecchio sistema tutela i cittadini se qualcosa va storto.
8. Gestione e autorizzazione continua. Dopo il lancio, monitoraggio continuo, gestione delle vulnerabilità, test di regressione sull’accessibilità e rilasci regolari mantengono il sistema autorizzato e in miglioramento. Preveda un budget per questa fase fin dall’inizio: dura molto più a lungo dello sviluppo.

La tabella mostra una roadmap tipica di 12 mesi per un servizio ai cittadini di medie dimensioni. Riflette un modello comune nel settore, non un calendario fisso; procurement, qualità dei dati e percorso di autorizzazione possono spostare ogni fase.

È un ciclo di vita di sviluppo sicuro a rendere possibile questo ritmo senza scorciatoie. La nostra guida al ciclo di vita dello sviluppo software sicuro descrive nel dettaglio le pratiche alla base delle fasi da 3 a 8.

Come modernizzare i sistemi pubblici legacy senza interrompere i servizi?

I sistemi pubblici legacy si modernizzano al meglio per gradi, incapsulandoli prima con API e sostituendo poi le funzioni una alla volta, così i cittadini non perdono mai l’accesso a un servizio durante la transizione. Le sostituzioni «big bang» di sistemi che erogano sussidi o riscuotono tributi comportano il rischio più alto di un fallimento pubblico. Quattro strategie coprono la maggior parte delle situazioni:

• Incapsulare con API. Si colloca un livello API moderno davanti al sistema legacy, così nuovi portali e app possono leggere e scrivere dati senza toccare il vecchio codice. È indicato quando la logica di base funziona ma il problema è l’interfaccia; è il modo più rapido per migliorare l’esperienza dei cittadini.
• Rehost o replatform. Si sposta l’applicazione esistente in regioni cloud governative autorizzate, come AWS GovCloud o Azure Government, con modifiche minime al codice, oppure su un database o un runtime gestito. È indicato quando il problema è il data center, un contratto hardware sta per scadere o i costi operativi devono scendere rapidamente.
• Refactoring con il pattern strangler fig. Si ricostruisce una funzione alla volta come nuovo servizio, vi si indirizza il traffico e si dismette quella parte del sistema legacy, finché non ne resta nulla. È indicato per sistemi grandi e critici per l’attività, per i quali una riscrittura completa richiederebbe anni e comporterebbe troppi rischi.
• Ricostruire. Si progetta e si realizza un nuovo sistema da zero. È indicato quando il vecchio sistema non corrisponde più alle politiche, il codice non può essere compreso o manutenuto, o la piattaforma non è più supportata e non esiste un percorso di migrazione.

Qualunque strada si scelga, i dati sono di solito la parte più difficile. I vecchi sistemi contengono decenni di record incoerenti, codici che capisce solo il personale più anziano e regole di business nascoste nei job batch. Conviene profilare i dati presto, concordare le regole di riconciliazione con i responsabili di programma, provare le migrazioni su copie complete e far girare in parallelo vecchio e nuovo sistema finché i risultati non coincidono. La nostra guida alla modernizzazione dei sistemi legacy confronta queste strategie più in profondità, e la pagina dei nostri servizi di modernizzazione del software mostra come suddividiamo in fasi questo lavoro per organizzazioni che non possono permettersi interruzioni.

Dove l’IA è utile nel software pubblico e dove è ad alto rischio?

Nel software pubblico l’IA è più utile per attività ripetitive, ad alta intensità documentale e ad alto volume in cui la decisione finale spetta ancora a una persona, ed è ad alto rischio quando influenza decisioni sui diritti, sui sussidi o sulla libertà delle persone. Le agenzie che separano presto queste due categorie possono ottenere guadagni di produttività senza creare esposizione legale.

I casi d’uso più solidi nel 2026 sono pratici più che futuristici:

• Elaborazione intelligente dei documenti. Estrazione di dati da moduli caricati, documenti d’identità e documentazione di supporto e instradamento delle pratiche alla coda corretta.
• Assistenti per contact center e personale. Bozze di risposta basate su contenuti di policy approvati, da far rivedere agli operatori, e sintesi di lunghe cronologie delle pratiche.
• Rilevamento di frodi e anomalie. Segnalazione di richieste o pagamenti insoliti per un’indagine umana anziché per un rifiuto automatico.
• Traduzione e supporto al linguaggio chiaro. Prime bozze di traduzioni e avvisi semplificati che il personale qualificato poi verifica.

Le misure di salvaguardia contano quanto il modello. Mantenga un revisore umano su ogni decisione che riguarda una persona, registri input e output, spieghi il ragionamento in termini che un cittadino possa contestare e verifichi i bias tra i diversi gruppi demografici. In base all’AI Act dell’UE, i sistemi di IA usati per valutare l’idoneità a prestazioni pubbliche essenziali e molti usi in ambito di contrasto sono classificati ad alto rischio e richiedono gestione del rischio, governance dei dati, supervisione umana e documentazione. Le agenzie federali statunitensi pubblicano inventari dei propri casi d’uso dell’IA, quindi parta dal presupposto che l’uso dell’IA nel Suo sistema sarà visibile al pubblico. Se prevede funzionalità basate su modelli linguistici, il nostro team di integrazione dell’IA generativa le realizza con recupero da fonti approvate, logging di audit e revisione umana integrati, e la nostra checklist sull’AI Act dell’UE riassume gli obblighi per i fornitori.

Quanto costa lo sviluppo software per la pubblica amministrazione?

Il costo dello sviluppo software per la pubblica amministrazione dipende soprattutto dal perimetro, dal numero e dall’età dei sistemi da integrare e dall’impegno per autorizzazione e documentazione, che può far costare un progetto pubblico diverse volte di più di un’app commerciale con schermate simili. Gli intervalli di settore pubblicati nel 2026 variano molto perché descrivono progetti molto diversi, dai piccoli strumenti municipali alle piattaforme statali per i sussidi.

La tabella combina gli intervalli pubblicati nel 2026 da due società di sviluppo: Techanic Infotech, le cui cifre descrivono strumenti pubblici di scala municipale e PMI, e SISGAIN, le cui cifre descrivono sistemi più grandi di agenzie statunitensi. Li consideri come un orientamento di mercato, non come preventivi.

La distanza tra l’estremo basso e quello alto non è rumore. Un semplice strumento di prenotazione degli appuntamenti per un piccolo comune e un sistema statale di verifica dell’idoneità rientrano entrambi nel «software per la PA», ma il secondo comporta integrazioni legacy, regole federali sui dati, un’autorizzazione formale e migliaia di utenti interni. Quando confronta i preventivi, confronti il perimetro e le ipotesi di compliance che vi stanno dietro, non solo i totali. Per capire come si costruiscono in generale i budget del software su misura, consulti la nostra analisi dei costi di sviluppo software su misura; per una stima sul Suo perimetro, usi il modulo in fondo a questa pagina.

Cosa determina il costo del software pubblico?

Sette fattori incidono su una stima di software pubblico più del numero di schermate o funzionalità:

• Compliance e autorizzazione. Preparare un pacchetto ATO, FedRAMP o GovRAMP, le valutazioni indipendenti e il monitoraggio continuo può assorbire una quota consistente del budget.
• Integrazione legacy. Collegarsi a mainframe, file batch e interfacce non documentate richiede spesso più tempo della realizzazione della nuova interfaccia utente.
• Accessibilità. Progettazione, test manuali con tecnologie assistive e reporting di conformità costano meno se integrati fin dall’inizio, ma richiedono sempre tempo dedicato.
• Migrazione dei dati. Pulire, mappare, riconciliare e provare il trasferimento di decenni di record è un progetto a sé stante.
• Identità e accessi. Verifica dell’identità, single sign-on per il personale e permessi granulari aggiungono lavoro di integrazione e test.
• Hosting in ambienti autorizzati. Regioni cloud governative, conservazione dei log e strumenti di sicurezza costano più di un hosting commerciale standard.
• Oneri di procurement e documentazione. Offerte, reporting contrattuale, controllo delle modifiche e obblighi documentali aggiungono tempo sia per l’agenzia sia per il fornitore.

Come funzionano procurement, contratti e RFP per il software pubblico?

Il software pubblico si acquista tramite procedure di appalto formali, e il tipo di contratto e la struttura dell’RFP influenzano il risultato quanto il fornitore stesso. Le agenzie che acquistano per piccoli moduli con requisiti basati sui risultati ottengono prima software funzionante e mantengono la possibilità di cambiare direzione.

I tipi di contratto più comuni si adattano ciascuno a un diverso livello di certezza:

• Il prezzo fisso (firm-fixed-price) funziona per un perimetro ben definito e stabile, come la migrazione di un sistema noto, ma spinge i fornitori a prezzare il rischio e a resistere ai cambiamenti.
• I contratti time-and-materials o labor-hour sono adatti alla discovery e allo sviluppo agile in cui il perimetro evolverà, a condizione che l’agenzia gestisca attivamente il backlog e fissi dei tetti massimi.
• I blanket purchase agreement agili e i contratti IDIQ consentono alle agenzie statunitensi di prequalificare più fornitori ed emettere rapidamente ordini di lavoro più piccoli, favorendo una realizzazione iterativa.
• Gli schedule a livello governativo e i contratti cooperativi, come i multiple-award schedule federali o gli accordi statali di acquisto cooperativo, abbreviano il procurement per i servizi comuni.
• Le procedure UE previste dalle direttive sugli appalti pubblici comprendono procedure aperte e ristrette, il dialogo competitivo per esigenze complesse e il partenariato per l’innovazione per soluzioni non ancora disponibili sul mercato.

Il contracting modulare, ovvero l’acquisto di un grande sistema come una serie di parti più piccole messe a gara separatamente, riduce il rischio di un unico megacontratto fallito. Scriva gli RFP attorno ai risultati e alle esigenze degli utenti anziché a un lungo elenco di funzionalità, chieda ai fornitori di mostrare software funzionante o prototipi e includa round di sfida tecnica in cui i team risolvono un problema reale. La nostra guida alla stesura di un RFP per lo sviluppo software include un modello, e il nostro confronto tra prezzo fisso e time and materials aiuta a scegliere il modello commerciale.

Definisca presto la proprietà intellettuale. L’agenzia dovrebbe possedere, o detenere diritti illimitati su, codice su misura, dati, documentazione e infrastructure as code, con il codice sorgente consegnato in un repository controllato dall’agenzia per tutta la durata del progetto. Molti enti pubblici pubblicano ormai il codice su misura come open source e, nell’UE, l’Interoperable Europe Act fa della condivisione delle soluzioni di interoperabilità con altri enti pubblici un’aspettativa di legge.

Come scegliere un partner per lo sviluppo software per la PA?

Scelga un partner per lo sviluppo software per la pubblica amministrazione in base a evidenze di sistemi pubblici realizzati, a un’esperienza reale con le autorizzazioni e all’accessibilità integrata nel processo, non alla lunghezza di una brochure di presentazione. Quando confronta i servizi di sviluppo software per la PA, ponga a ogni fornitore le stesse sette domande:

1. Esperienza nel settore pubblico. Quali sistemi pubblici o regolamentati in produzione ha realizzato il team, ed è possibile parlare con una referenza?
2. Esperienza con le autorizzazioni. Il team ha preparato SSP, supportato valutazioni e gestito il monitoraggio continuo, e rispetto a quali baseline?
3. Accessibilità integrata. Il fornitore progetta per le WCAG 2.2 AA, testa manualmente con tecnologie assistive e fornisce un Accessibility Conformance Report basato sul VPAT?
4. Personale e residenza dei dati. Il fornitore è in grado di soddisfare requisiti come personale con status di US person, verifiche dei precedenti o trattamento dei dati solo nell’UE, laddove il Suo sistema li richieda?
5. Ciclo di vita dello sviluppo sicuro. Il fornitore può firmare l’attestazione sullo sviluppo di software sicuro e mostrare come le pratiche SSDF sono applicate nella sua pipeline?
6. Reporting agile trasparente. Vedrà software funzionante a ogni sprint, un backlog condiviso e un reporting onesto su velocità e rischi?
7. Condizioni di uscita e passaggio di consegne. Codice, dati, documentazione e infrastruttura risiederanno in account controllati dall’agenzia, con un piano scritto di passaggio di consegne?

Campanelli d’allarme nelle proposte di software per la PA

Cinque segnali di allarme indicano che una proposta costerà di più o renderà meno di quanto promette:

• Autorizzazione e accessibilità descritte in una riga o prezzate come extra opzionale.
• Un prezzo fisso per un servizio complesso senza fase di discovery né ipotesi elencate.
• Dichiarazioni di essere «conformi FedRAMP» o «certificati 508» senza un’iscrizione nell’elenco delle autorizzazioni o un rapporto di conformità a supporto.
• Framework proprietari che solo il fornitore è in grado di manutenere, o codice conservato nei repository del fornitore.
• Nessun piano per la migrazione dei dati, l’esercizio in parallelo o il rollback.

Le grandi agenzie combinano spesso un team GovTech specializzato con una capacità più ampia di sviluppo software enterprise per integrazioni, piattaforme dati e strumenti interni.

Quali sono gli errori più comuni e quali metriche dimostrano il successo?

La maggior parte dei progetti di software pubblico falliti fallisce per motivi prevedibili: lanciano tutto in una volta, lasciano accessibilità e autorizzazione alla fine o ignorano il personale che userà il sistema ogni giorno. La tabella abbina a ogni errore comune una prevenzione collaudata.

Il successo va misurato in risultati per cittadini e personale, non in funzionalità rilasciate. Cinque metriche funzionano per la maggior parte dei servizi:

• Tasso di completamento digitale: la quota di utenti che avviano un servizio online e lo completano senza telefonare o recarsi in un ufficio.
• Tempo alla decisione: il tempo mediano tra una domanda completa e la decisione.
• Difetti di accessibilità: problemi WCAG aperti per gravità, con tendenza a zero per quelli critici.
• Uptime rispetto all’obiettivo di livello di servizio: disponibilità e tempo di risposta misurati dal lato dell’utente.
• Costo per transazione: costo operativo totale diviso per le transazioni completate, confrontato con il canale legacy.

Domande frequenti

Pubblicato l’8 novembre 2026. Le date normative e i dettagli dei programmi riflettono le fonti pubbliche disponibili al momento della pubblicazione: GAO-25-107795 (2025), la norma provvisoria del Dipartimento di Giustizia degli Stati Uniti pubblicata nel Federal Register del 20 aprile 2026, gli annunci di FedRAMP su FedRAMP 20x e sulle Consolidated Rules 2026, GovRAMP, i Revised Section 508 Standards, il Regolamento (UE) 2024/1183 (eIDAS 2.0) e il Regolamento (UE) 2024/903 (Interoperable Europe Act). Verifichi sempre i requisiti aggiornati presso l’autorità competente. Gli intervalli di costo sintetizzano cifre pubblicate da società di sviluppo nel 2026 e sono puramente indicativi; non sono prezzi di YuSMP Group. YuSMP Group sviluppa secondo le baseline di controllo FedRAMP e GovRAMP e non dichiara di possedere un’autorizzazione FedRAMP o GovRAMP. I nomi di prodotti e programmi appartengono ai rispettivi proprietari.