Tre liste, non una: ciò che abbiamo già costruito, ciò che integriamo su richiesta e a quali condizioni, e ciò che non facciamo.

No, nessuno è attivo in produzione, e facciamo distinzione per ciascuno. Per l’autenticazione federata abbiamo scritto da zero un fornitore di servizi, con le difese specifiche implementate e con test automatici; è disattivato da un interruttore, e il test predefinito verifica proprio che lo stato disattivato non faccia trapelare nulla. Per la firma elettronica abbiamo un client completo, con trasporto su certificato reciproco; il nostro documento interno dice, testualmente, „disattivata, ma completa”. Per la piattaforma di pagamenti, la dorsale di interoperabilità e il gabinetto del cittadino non abbiamo alcuna riga di codice e non proponiamo altro.

Quattro cose, tutte fuori dal codice, e le elenchiamo perché possano essere pianificate: l’indirizzo di produzione del servizio, che non è pubblico; la descrizione tecnica dell’interfaccia, che richiede credenziali; il certificato di sistema rilasciato dall’operatore dell’infrastruttura dello Stato; e la registrazione del nostro indirizzo di produzione presso l’autorità di e-government, più il contratto e la tariffa annuale corrispondenti. In un progetto reale, questi passaggi sono una fase con una durata propria, non una casella spuntata al lancio.

La variante self-service, che funziona oggi: il cittadino firma il documento sul portale ufficiale dello Stato e lo ricarica nella piattaforma. Non è comoda come la firma nel flusso, e lo diciamo, ma è una strada reale, senza contratto e senza certificato — e quando l’integrazione si attiverà, la forma del dossier non cambierà.

No, fino al 6 settembre 2026. La pipeline è costruita, testata e fatta passare deliberatamente attraverso una gate umana — un dossier passa nello stato „inviato” solo dopo che la busta è partita effettivamente, il trasporto ha ritentativi, pause crescenti, log per tentativo, l’identificatore del messaggio salvato e distinzione tra rifiuto permanente ed errore temporaneo. Ma in produzione c’erano 14 dossier pronti e zero invii. Non esiste alcun processo automatico che faccia scattare il primo invio: è una decisione di una persona, non l’effetto di una pubblicazione.

No. È un mockup funzionale, pubblicato pubblicamente e contrassegnato come tale su ogni pagina, con istruzione di non indicizzazione per i motori di ricerca. Il contenuto reale è migrato e ricategorizzato — 573 comunicati, otto categorie — ma le immagini sono ancora collegate al sito sorgente, nessuna delle 2.464 ha testo alternativo, la versione in inglese dell’archivio non è tradotta, il pannello di amministrazione non è costruito, e i colori e i segni distintivi sono provvisori. Li elenchiamo perché la differenza tra un mockup convincente e un lancio è esattamente questa lista.

Come un rischio, non come un dettaglio. Gli elementi identificativi passano nel dossier interno e non compaiono pubblicamente. La posizione pubblica è arrotondata. La fotografia grezza resta una prova privata, e pubblicamente arriva solo un derivato redatto, approvato da una persona diversa da chi ha redatto. Ogni termine di conservazione è nel database con il testo pubblicato e il fondamento giuridico accanto, e la cancellazione reale richiede un argomento esplicito — una funzione che cancella in silenzio è una modalità di errore, non una funzionalità.

L’abbiamo progettata per essa, non l’abbiamo gestita al suo interno. In un dossier per un’istituzione ho scritto i requisiti di hosting sulla piattaforma statale conformemente alla decisione governativa applicabile, e il repository del codice del progetto ha come obiettivo una macchina su quella infrastruttura. Ma il sistema non gira lì: l’autenticazione al suo interno è un sostituto dichiarato esplicitamente nel codice come provvisorio, e gli adattatori verso le istituzioni sono stub di prima fase. È corretto dirlo così.

No. Non ne abbiamo costruito nessuno, non abbiamo un team con questa esperienza e non faremo offerte su di essi come se l’avessimo. Il nostro ambito è il rapporto dell’istituzione con il pubblico: ricezione e instradamento delle richieste, pubblicazione delle informazioni, monitoraggio delle scadenze e protezione dei dati nel flusso. Quando un’istituzione ha bisogno di un registro di base di dati statale, ha bisogno di un altro fornitore.

Non abbiamo certificazioni di gestione della qualità o di sicurezza delle informazioni e non siamo registrati come fornitore governativo in alcun programma internazionale. La procedura di appalto, i requisiti di ammissibilità e i documenti richiesti si stabiliscono con l’istituzione, e se un requisito di ammissibilità ci esclude, è meglio che si veda all’inizio. Non compensiamo la mancanza di un certificato con una formulazione che faccia sembrare che lo abbiamo.