# Piattaforma di gestione deleghe **URL:** \ **Category:** ANPR - Anagrafe Nazionale\ **Created:** [24 Aprile 2026, 5:35pm UTC](https://forum.italia.it/t/piattaforma-di-gestione-deleghe/48935 "2026-04-24T17:35:49Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![KibGim](https://forum.italia.it/user_avatar/forum.italia.it/kibgim/32/330_2.png) [@KibGim](https://forum.italia.it/u/KibGim)\ **Post date:** [17 Settembre 2026, 11:36am UTC](https://forum.italia.it/t/piattaforma-di-gestione-deleghe/48935/4 "2026-09-17T11:36:14Z")
**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](https://sistemacomunidigitali.anci.it/webinar/piattaforma-gestione-deleghe-istruzioni-per-luso-per-i-comuni/) . 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: 1. **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? 2. **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? 3. **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? 4. **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? 5. **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](http://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](https://www.suomi.fi/e-authorizations/received-mandates) - **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](https://www.borger.dk/samfund-og-rettigheder/fuldmagter/digital-fuldmagt) - **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](https://www.digid.nl/aanvragen-en-activeren/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](https://info.altinn.no/en/help/access-managment/access-packages/) [Altinn, single services e read/write/sign](https://info.altinn.no/en/help/access-managment/single-services/) - **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](https://www.csam.be/en/management-mandates.html) 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: - **responsabile del procedimento:** chi ha fatto cosa, effetti della revoca e responsabilità delle azioni; - **CED / IT / software house:** API, integrazione, errori, audit e continuità del servizio; - **responsabile funzionale del servizio:** quanta granularità concedere e quali operazioni rendere delegabili; - **UX / service design / accessibilità:** pattern nazionali, cambio del soggetto rappresentato, chiarezza su “stai operando per conto di…”; - **DPO / legale:** minimizzazione, dati storici, operazioni sensibili e tracciamento; - **cittadino / caregiver:** dove vedo in un posto solo chi può fare cosa per me, cosa ha già fatto e come glielo tolgo? 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](https://forum.italia.it/t/delega-completa-per-identita-spid/3460)** ) . 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.** --- _[View the full topic](https://forum.italia.it/t/piattaforma-di-gestione-deleghe/48935)._