Ieri la G.U. ha pubblicato questo decreto: se qualcuno più informato può spiegare in due righe la questione avrà una moltitudine di ringraziamenti :))
DECRETO 23 febbraio 2026 Disciplina delle modalita’ di funzionamento della Piattaforma di gestione deleghe. (26A01855) (GU Serie Generale n.94 del 23-04-2026 - Suppl. Ordinario n. 16)
Grazie per la segnalazione.
E’ da un po’ che si aspettava. Sarebbbe “l’attrezzo” previsto dall’articolo 64-ter del CAD da quasi 5 anni.
A prima lettura pare che si deleghi l’uso di tutti tutti tutti i servizi online, senza possibilità di graduare la cosa. Ma devo leggere meglio, perché così mi pare un po’ eccessivamente semplicistico…
Finalmente esiste una data: 15 ottobre 2026 per l’avvio di questa piattaforma molto importante!
Oggi, 17 settembre, ANCI e Dipartimento per la trasformazione digitale hanno tenuto il webinar “Piattaforma Gestione Deleghe: istruzioni per l’uso per i Comuni”, circa 45 minuti, dedicato all’onboarding dei Comuni e ai passaggi tecnici e amministrativi necessari per integrare la PGD. È rivedibile pubblicamente, insieme alle slide, dalla pagina dell’evento ANCI: Webinar ANCI-DTD del 17 settembre 2026 . La stessa presentazione dell’evento parla espressamente di passaggi sia tecnici sia amministrativi.
Sono intervenuti Mauro Savini @MauroSavini (che prego di far registrare anche i seguenti a forum.italia.it) , Giulia Simonelli , Francesco Antonio Marino e Luca Mariotti, coinvolti sul versante ANCI, DTD e IPZS. Secondo me vale la pena guardarlo: ben fatto, piuttosto tecnico, un po’ meno approfondito sul versante amministrativo/applicativo e probabilmente troppo breve, ma in meno di un’ora chiarisce parecchio sull’architettura e soprattutto su cosa deve materialmente fare un Comune per aderire.
Visto che avete aperto parecchie porte interessanti, diciamo che ora vi abbiamo anche trovato qualcosa a cui pensare nel weekend. 
Semplificando molto, mi pare che sia stata realizzata bene soprattutto la parte “a monte”. La piattaforma nazionale gestisce la delega e, quando un cittadino entra in un servizio, il gestore dell’identità digitale può interrogare la PGD per verificare se quel soggetto abbia una delega valida e per conto di chi possa operare. Questo meccanismo è descritto piuttosto precisamente dall’art. 9 del decreto.
Il punto che a me sembra adesso molto interessante è però quello immediatamente successivo: una volta che il Comune sa che Tizio è legittimato a operare per Caio, cosa deve concretamente consentirgli di fare dentro il singolo servizio? E come deve farlo?
Qui non si tratta di un dettaglio. Il decreto dice esplicitamente che ogni PA deve classificare e mantenere aggiornati i propri servizi ai fini della delega, valutando presupposti normativi, contesto, finalità e dati trattati. E rimane responsabilità della singola PA determinare le conseguenti logiche di autorizzazione, compresa l’eventuale limitazione delle funzionalità utilizzabili dal delegato.
Questa, secondo me, è una parte enorme del lavoro.
La PGD può dirmi in maniera affidabile chi può rappresentare chi. Ma da lì in avanti bisogna decidere cosa significhi concretamente “rappresentare” dentro centinaia di tipologie diverse di servizio: consultare, compilare, modificare, inviare, integrare, ritirare, pagare, firmare, cambiare coordinate bancarie, vedere lo storico, ricevere comunicazioni, ecc.
Ed è proprio qui che sarebbe utile intervenire molto presto e molto a livello nazionale, prima che inizi la stagione del “ogni fornitore faccia una scelta ragionevole”, perché sappiamo già come finisce quella stagione.
Su questo abbiamo anche un precedente da non ripetere.
Con pagoPA, la tassonomia ufficiale dei servizi di incasso è stata adottata solo dal 1° marzo 2021, quando la piattaforma aveva già una storia e molte integrazioni alle spalle. Successivamente, con gli interventi PNRR, la corretta associazione del codice tassonomico è diventata addirittura condizione verificata per considerare correttamente attivato un servizio. In pratica si è dovuto ricondurre e riallineare un patrimonio di servizi già esistenti a una classificazione comune, con attività effettuate dagli enti e molto spesso dai relativi fornitori. Oggi la tassonomia è ben strutturata, versionata e machine-readable, ma sarebbe stato decisamente più efficiente partire così fin dall’inizio.
Con App IO il fenomeno è stato, almeno in parte, ancora più evidente: una metodologia ufficiale della Presidenza del Consiglio del 2024 scriveva esplicitamente che IO, a differenza di pagoPA, non disponeva in quel momento di una tassonomia ufficiale e di un sistema di classificazione dei servizi. Oggi invece esistono cataloghi strutturati per Comuni, Regioni, sanità, università, con nomi, descrizioni e codici comuni. Benissimo, ma anche qui lo standard è arrivato dopo che il sistema conteneva già centinaia di migliaia di servizi.
Ecco, con la PGD sarebbe bello non fare il terzo giro della stessa giostra.
Eviterei soprattutto di far ricostruire a migliaia di enti e decine di software house, magari in modi diversi, classificazioni, tassonomie, ontologie, livelli di autorizzazione, terminologia e pattern di interfaccia che possono invece essere studiati una volta sola, bene, a livello nazionale.
Oggi gli strumenti ci sono tutti: cataloghi machine-readable, metadati strutturati, vocabolari controllati, versionamento, API, Design System, pattern UX, matrici di autorizzazione e test automatici di conformità. Qui gli ingegneri hanno davvero tutti gli strumenti per accelerare il processo e farlo bene. Non avrebbe senso spendere N volte soldi e ore-uomo per risolvere N volte lo stesso problema, per poi spendere altre risorse fra tre anni per riallineare ciò che nel frattempo si è frammentato.
Perché appena si scende dal diagramma architetturale al servizio vero, le domande diventano rapidamente meno banali. Cinque esempi:
Temporalità: se ricevo oggi una delega, posso vedere anche pratiche, documenti e comunicazioni del delegante precedenti alla data della delega o soltanto ciò che nasce da quel momento in poi?
Sequenzialità: una pratica viene iniziata dal delegante, proseguita dal delegato e poi la delega viene revocata prima della conclusione. Chi può completarla e quali effetti rimangono delle operazioni già effettuate?
Granularità: una delega alla “consultazione” permette solo di vedere oppure anche di scaricare documenti? E una delega operativa consente anche di ritirare un’istanza, accettare un provvedimento o cambiare l’IBAN sul quale deve arrivare un rimborso?
Concorrenza: cosa succede se delegante e delegato intervengono quasi contemporaneamente sulla stessa pratica con azioni incompatibili? Quale prevale e come viene rappresentata chiaramente la responsabilità delle singole azioni?
Operazioni asincrone: il delegato avvia un’operazione mentre la delega è valida, ma questa viene revocata prima che il procedimento automatico termini. Conta l’autorizzazione al momento dell’avvio, dell’elaborazione o della produzione dell’effetto amministrativo?
Sono casi un po’ estremi volutamente. Ma è proprio nei casi limite che si capisce se il modello è sufficientemente definito oppure se abbiamo soltanto risolto l’autenticazione.
Alcuni casi di ciclo di vita sono invece già definiti molto bene a livello centrale, ed è positivo. Ad esempio, in caso di decesso del delegante o del delegato, non è lasciato nulla all’interpretazione del Comune: la PGD acquisisce giornalmente da ANPR i dati dei soggetti deceduti e procede al blocco tempestivo delle deleghe in corso di validità interessate; l’art. 10 prevede poi la revoca automatica sulla base di queste verifiche. Sono disciplinati anche perdita della responsabilità genitoriale, raggiungimento della maggiore età, cessazione di tutela/curatela/amministrazione di sostegno, revoca e rinuncia.
Questo è esattamente il livello di precisione che sarebbe bello ritrovare anche nelle regole applicative comuni.
Altro aspetto interessante, esplicitato anche nel webinar: il perimetro attuale non comprende le deleghe professionali. Il decreto esclude espressamente i mandati conferiti a professionisti e intermediari abilitati. Quindi oggi non stiamo parlando, ad esempio, di un sistema generale con cui un professionista incaricato possa operare tramite PGD nei classici scenari SUAP. È un confine importante, che secondo me merita di essere molto evidente anche nella futura documentazione.
Il decreto contiene poi una previsione che trovo particolarmente importante: DTD, Regioni e Province autonome promuovono iniziative volte a favorire la corretta e uniforme classificazione dei servizi in rete da parte delle PA.
Ottimo. Però a questo punto la speranza è: facciamolo subito e, per quanto possibile, una volta sola a livello nazionale.
Se venti Regioni elaborano venti strutture simili, poi migliaia di enti le reinterpretano e ogni software house costruisce il proprio mapping, abbiamo moltiplicato il lavoro prima ancora di cominciare. Meglio aprire presto un tavolo nazionale e produrre cataloghi, tassonomie, decision tree, casi limite, modelli di autorizzazione e pattern UX abbastanza precisi da essere realmente riusabili.
E la questione non nasce certo oggi in Italia. Anzi, qui sarebbe molto interessante capire quanto benchmark e quanta collaborazione con gli altri Stati europei sia già stata fatta, perché molti Paesi (ben più in alto di noi italiani sull’indice di digitalizzazione DESI) stanno iniziando adesso e su deleghe, granularità e rappresentanza digitale hanno già anni di esperienza concreta alle spalle.
Qualche esempio che secondo me vale la pena studiare seriamente:
Finlandia, Suomi.fi e-Authorizations: cittadini, imprese e organizzazioni possono delegare altri soggetti scegliendo le specifiche materie sulle quali possono operare e il periodo di validità; i servizi verificano le deleghe nel registro nazionale. Suomi.fi e-Authorizations
Danimarca, Digital Fuldmagt: le deleghe sono normalmente delimitate alla singola attività/area, sono gestite con MitID e il sistema prevede perfino percorsi cartacei per chi ha difficoltà digitali; nei servizi il delegato sceglie esplicitamente per conto di chi sta operando. Digital Fuldmagt, Danimarca
Paesi Bassi, DigiD Machtigen: si autorizza una persona o anche un’impresa per uno specifico compito e per un periodo determinato; esiste una vista centralizzata delle autorizzazioni, con revoca. DigiD Machtigen
Norvegia, Altinn: stanno addirittura passando da vecchi ruoli troppo ampi a circa 120 access packages più granulari; per i singoli servizi le autorizzazioni possono distinguere azioni come read, write, sign. Digdir spiega apertamente che i vecchi ruoli erano troppo larghi e potevano attribuire più diritti del necessario. Altinn, access packages Altinn, single services e read/write/sign
Belgio, CSAM: esiste una soluzione trasversale nazionale per identificazione, autenticazione, autorizzazione e gestione dei mandati, con un Self Service Mandates utilizzato da più servizi pubblici e mandati collegati a specifiche applicazioni. CSAM, gestione dei mandati
Non dico che vadano copiati identici, ma non partiamo da un foglio bianco.
Sarebbe quindi utile sapere se nel disegno/roadmap dettagliata (che spesso manca nei progetti nazionali, sarà pubblicata e manutenuta?) della PGD sia già stato fatto un confronto strutturato con queste esperienze e, soprattutto, se il lavoro comune europeo riguardi anche la semantica dei permessi e la UX, non soltanto protocolli e interoperabilità.
Mi viene poi in mente il Modello Comuni: il PNRR ha portato a una diciamo abbastanza forte standardizzazione di interfacce, architettura dell’informazione e servizi.
Ora è molto probabile che parecchi di quei servizi debbano essere nuovamente messi mano per introdurre correttamente l’operatività in delega.
E qui la differenza sarà enorme: possono essere messi mano bene, una volta, seguendo regole e pattern condivisi; oppure ognuno può aggiungere il proprio piccolo strato di logica, grafica e autorizzazioni. Nel secondo caso fra qualche anno rischiamo una bellissima infrastruttura centrale con sopra un mosaico applicativo difficilissimo da riallineare.
Nel Q&A del webinar mi ha colpito anche un altro aspetto. C’erano evidentemente parecchi dipendenti comunali non tecnici e, fra le domande, ne è comparsa persino una del tipo: “per le chiamate API, che numero devo chiamare?”
La cosa fa sorridere, ma neanche troppo: secondo me non fa affatto male che anche chi non è tecnico intraveda cosa c’è sotto, perché aiuta a capire che l’integrazione non è un semplice flag amministrativo.
Ho però avuto l’impressione opposta: questo webinar forse non è arrivato a tutti i CED/servizi informatici dei Comuni ai quali sarebbe tornato molto utile. Nella presentazione si parlava correttamente di “passaggi tecnici e amministrativi”, ma forse un inciso ancora più esplicito sul target, tipo “consigliato anche a responsabili IT/CED, RTD e fornitori applicativi”, avrebbe aiutato chi doveva decidere se partecipare o meno.
Del resto attorno alla PGD gravitano parecchi stakeholder, con domande molto diverse:
Sono prospettive diverse, ed è proprio per questo che secondo me serve uno spazio nel quale si incontrino prima che le decisioni vengano cristallizzate nei singoli software.
Sul Forum, a oggi, trovo sostanzialmente due discussioni dedicate specificamente al tema: questo thread, e il precedente “Sistema Gestione Deleghe” del novembre 2024, aperto da @pi6502 e rimasto senza risposta.
È curioso perché qui i contenuti sono quasi inesistenti, mentre sotto la superficie l’argomento è enorme ( magari racchiusi in temi di CIE o SPID, es: Delega completa per identità SPID )
. E fra poco le domande operative arriveranno inevitabilmente.
La tempistica rende il tema ancora più attuale: il decreto stabilisce che i servizi di presentazione della delega siano resi progressivamente disponibili a decorrere dal 15 ottobre 2026. Non quindi un unico “big bang” quel giorno, ma l’inizio del rilascio progressivo, con le ulteriori date da pubblicare sul portale.
Il decreto identifica come portale ufficiale deleghedigitali.gov.it .
Ad oggi, 17 settembre, provando ad aprirlo non restituisce ancora una pagina utilizzabile/non risponde, quindi naturalmente non c’è ancora quel patrimonio pubblico di manuali, FAQ applicative, casi d’uso e strumenti di consultazione che immagino dovrà comparire prima dell’avvio. Anche il decreto prevede espressamente la pubblicazione sul portale di un manuale e di una guida utente.
Mi auguro arrivi presto anche la parte più “facile da consumare”: non soltanto specifiche tecniche, ma esempi concreti e tutti i riferimenti pubblici direttamente interrogabili, API/OpenAPI, metadati, cataloghi e magari ambienti/esempi che consentano a enti e fornitori di capire velocemente cosa devono implementare.
Piccola nota terminologica, perché può confondere anche cercando documentazione storica: originariamente il CAD e il progetto parlavano di Sistema di gestione deleghe, SGD; la disciplina attuale parla invece di Piattaforma di gestione deleghe, PGD. Quindi non sono, per quanto capisco, due sistemi diversi che devono convivere: PGD è l’assetto attuale di quello che nei documenti precedenti veniva indicato come SGD.
Per questo chiederei anche a DTD / staff di Forum Italia, ad esempio @A13x e @dptd , se non valga la pena aprire una categoria o almeno uno spazio stabile dedicato alla PGD, eventualmente coinvolgendo ANCI, IPZS e le persone che stanno lavorando direttamente alla piattaforma.
Forum Italia nasce proprio come spazio di confronto sui servizi pubblici digitali e oggi ha già categorie specifiche per SPID, CIE, ANPR, IO ecc.; una PGD che sta per entrare concretamente nella vita dei servizi mi sembra candidata naturale.
Non tanto come help desk, ma come posto in cui far sedimentare casi d’uso, dubbi, decisioni progettuali, esempi e buone pratiche comuni prima che ogni ente e ogni fornitore risolva isolatamente gli stessi problemi.
La piattaforma centrale sembra ormai molto concreta. Adesso, secondo me, viene la parte forse meno visibile ma altrettanto importante: fare in modo che “delega” significhi davvero la stessa cosa quando un cittadino passa da un servizio pubblico all’altro.