Il calendario di certificazione italiano a cui un fornitore di giochi deve adeguarsi

Il regolatore italiano del gioco ha smesso di trattare la certificazione come un’unica data. L’ha suddivisa in una sequenza, e l’ordine della sequenza è la parte che ridisegna la roadmap di un fornitore: il sistema di gioco deve essere certificato prima che gli operatori che intendono utilizzarlo possano completare i propri controlli.

L’Agenzia delle Dogane e dei Monopoli, ADM, aveva trascorso un anno a dire ai concessionari del gioco a distanza che il 13 novembre 2026 era la data entro cui il nuovo “Sistema del concessionario” doveva superare la verifica di conformità svolta da un organismo di verifica riconosciuto, un Organismo di Verifica, o ODV. Quella data non è stata rimossa. Le è stato assegnato un compito più ristretto. Secondo il calendario a tappe, il 13 novembre 2026 è la scadenza per i concessionari fornitori di servizi — service-provider concessionaires, noti come CFS — per depositare i risultati dei controlli di conformità sulle istanze che contengono sistemi di gioco offerti ad altri concessionari, insieme ai componenti che popolano la libreria condivisa. I concessionari che usano quei sistemi di gioco forniti dai CFS depositano poi entro il 13 gennaio 2027. Le verifiche tecnico-funzionali si concludono entro il 12 febbraio 2027, e il nuovo sistema di gioco entra in produzione dal 15 febbraio 2027.

Quel calendario a tappe è stato riportato dalla stampa di settore italiana il 7 ottobre 2026. Poggia su due documenti che costituiscono il quadro di tutto ciò che segue: la lettera di ADM del 27 febbraio 2026, che ha spostato la scadenza originaria di primavera al 13 novembre 2026, e le istruzioni operative di ADM del 7 agosto 2026 sulla certificazione del sistema del concessionario per le nuove licenze. Le date sono del regolatore; verificate il calendario vigente con l’Agenzia prima di pianificare un lancio su di esse.

Perché il fornitore va per primo

L’intero ordine a tappe deriva da una sola regola nelle linee guida di certificazione di ADM. Un concessionario che intende usare un sistema di gioco già certificato e reso disponibile da un concessionario fornitore di servizi è comunque tenuto a far verificare nel suo complesso il proprio sistema del concessionario. Ma in quel caso l’ODV è tenuto a verificare solo l’integrazione del sistema di gioco del CFS con gli altri componenti del sistema che viene verificato.

Questa singola deroga crea la dipendenza. Un concessionario utilizzatore non può dimostrare un’integrazione con un sistema di gioco che non detiene ancora il proprio risultato di verifica. Quindi i sistemi certificati devono esistere per primi ed essere visibili nella libreria, e solo allora gli operatori che li utilizzano possono concludere il proprio percorso. ADM ha poi ribadito il concetto: la verifica tecnico-funzionale di conformità si applica sempre al sistema del concessionario nella sua interezza, e non a singoli elementi considerati separatamente, e dove sono in uso uno o più sistemi forniti dai CFS l’organismo di controllo deve verificare anche la corretta integrazione tra i sistemi dei CFS e gli altri componenti.

Per uno studio, una piattaforma o un CFS che vuole fornire il mercato italiano, questo è il significato pratico del calendario. Il vostro lavoro di certificazione si trova sul percorso critico della scadenza di qualcun altro.

Che cosa esamina davvero l’Organismo di Verifica

Le istruzioni di agosto di ADM descrivono un esame più ampio di un controllo matematico. L’ODV parte da un rapporto tecnico che deve descrivere il sistema, i suoi componenti e come interagiscono, e poi controlla la documentazione e i componenti hardware e software, i file critici, i sistemi che verificano l’integrità del software e la comunicazione tra i diversi componenti e con il sistema centrale di ADM. Prove di conformità, analisi statistiche e controlli funzionali derivano dalle regole tecniche e dalla regolamentazione applicabile.

La disciplina del codice sorgente è la parte che sorprende i team abituati a una presentazione da laboratorio. Il sorgente consegnato per l’ispezione deve riportare, per ciascun file, modulo o funzione, il suo componente, una breve descrizione di ciò che fa e uno storico delle modifiche, con la versione certificata identificata univocamente tramite versione. I file critici sono identificati da un digest, e l’ODV deve essere in grado di dimostrare che i binari esaminati sono il risultato della compilazione del sorgente consegnato. Un log di build con i digest del sorgente e un timestamp fa parte della presentazione, e così pure lo script che ha prodotto il file dei digest.

È la stessa disciplina che la guida alla presentazione della certificazione richiede presso un laboratorio di prova, applicata a un’intera piattaforma e alla sua integrazione, ed è il punto in cui i requisiti di integrazione RGS incontrano la burocrazia di un regolatore invece dell’API di portafoglio di un altro operatore.

Gli obblighi ingegneristici che ricadono sul fornitore

Le linee guida impongono una serie di obblighi misurabili al sistema del concessionario, e in una catena di fornitura CFS la maggior parte di essi ricade su chi costruisce il sistema di gioco.

• Replica. Dati replicati sul sito secondario entro 120 secondi, con il sito secondario geograficamente distinto ma all’interno dello SEE, e il processo di disaster recovery stesso dimostrato. La disciplina della verifica di backup e ripristino è la prova generale giusta per quell’asserzione.
• Cloud. Le piattaforme cloud sono ammesse, ma solo da fornitori iscritti al registro tenuto dall’agenzia italiana per la cybersicurezza e che soddisfano i requisiti tecnici dell’agenzia digitale, con sovranità digitale dei dati e cifratura sia in transito sia a riposo. La questione della residenza dei dati e del trasferimento transnazionale qui non è una preferenza politica; è un input di certificazione.
• Finestre sui dati. Disponibilità in tempo reale delle informazioni di gioco e operative memorizzate per gli ultimi sei mesi; informazioni contabili e sulle transazioni su richiesta per gli ultimi due anni; archiviazione di cinque anni con integrità e leggibilità; e query personalizzate esportabili entro 48 ore da una richiesta.
• Rendicontazione in tempo reale. Transazioni di gioco, bonus ed esiti trasmessi al sistema centrale di ADM in tempo reale, con ogni fase del flusso di gioco tracciabile e ricostruibile.
• Integrità e accesso. Verifica automatica dell’integrità per i componenti, con il componente interessato bloccato quando la verifica fallisce, e autenticazione a più fattori per l’accesso al back-office — oggetto dei requisiti di controllo degli accessi al back-office.
• Divulgazione dell’IA. Dove gli esiti possono essere influenzati da processi decisionali automatizzati o da strumenti di calcolo esterni, le regole di gioco devono dichiararlo prima che il giocatore partecipi.

Il controllo di prima esecuzione avviene in produzione

La certificazione non è l’ultimo cancello. In una prima certificazione, ADM prevede una verifica tecnico-funzionale svolta nell’ambiente di produzione. Copre la configurazione effettivamente destinata alla concessione, si estende a tutti i sistemi di gioco inclusi nella domanda di certificazione e avviene alla prima partenza in produzione di ciascun tipo di gioco. I controlli sono operativi: la vendita, l’accettazione delle giocate, la contabilizzazione delle transazioni, l’accredito delle vincite, i pagamenti e lo scambio di informazioni con il sistema centrale di ADM. Per questo vengono predisposti cinque conti di test registrati a una persona giuridica e i relativi calendari pubblicati. Dove sono in uso sistemi forniti dai CFS, il CFS deve fornire supporto tecnico durante i controlli.

È una prova generale di prontezza alla produzione con un regolatore che osserva, ed è il punto in cui un’integrazione che ha sempre girato solo contro un mock viene smascherata.

Il controllo delle modifiche dopo il certificato

Un certificato descrive una versione, e le regole la seguono. Le istruzioni di agosto di ADM stabiliscono che le modifiche successive a un sistema già certificato che potrebbero interessare i componenti critici, le funzioni che sono state verificate o la conformità con le regole tecniche devono essere sottoposte all’organismo di verifica in anticipo. Un aggiornamento di emergenza necessario a ripristinare il corretto funzionamento è consentito prima che la domanda sia depositata, ma il concessionario deve comunque ottenere dall’ODV la certificazione di conformità della modifica, entro due settimane.

Sotto di esso si collocano altri due ritmi. Le autorizzazioni hanno validità di 12 mesi, dopo i quali gli audit verificano, per piattaforma e per gioco, che il sistema operativo corrisponda ancora a quanto certificato, che le modifiche che non toccano il generatore di numeri casuali o il software di generazione dei simboli siano conformi, e che il montepremi reale o il ritorno al giocatore effettivamente offerto corrisponda a quanto la grafica del gioco ha comunicato al giocatore — misurato rispetto ai dati di gioco dei 12 mesi precedenti. E le regole transitorie emanate da ADM a giugno 2026 mantengono le applicazioni di live-dealer, bingo, poker e betting exchange in movimento attraverso il percorso di certificazione esistente fino all’avvio delle nuove regole tecniche per quei verticali il 13 novembre 2026.

Che cosa significa per una commessa

Dal calendario derivano due decisioni, e sono commerciali prima che tecniche.

Da quale lato dell’integrazione vi trovate. Uno studio o una piattaforma che diventa concessionario fornitore di servizi certifica un sistema di gioco una volta sola e lo offre a concessionari che poi verificano solo l’integrazione. È il binario più precoce ed è quello in cui si popola la libreria condivisa. Un fornitore che invece colloca i propri titoli all’interno del sistema del concessionario di un singolo operatore eredita la data del 13 gennaio di quell’operatore e la verifica dell’intero sistema dell’operatore stesso — più economico per entrare, ma siete un passeggero sulla certificazione di qualcun altro.

Se la vostra evidenza è versionata. I digest del sorgente, il log di build, l’identificatore di versione certificata e la finestra di aggiornamento di emergenza presuppongono tutti che l’artefatto certificato sia l’artefatto in produzione. Una modifica di live-ops che viene distribuita senza un incremento di versione non è una piccola scorciatoia in questo quadro; è esattamente lo stato che la regola sul controllo delle modifiche è scritta per prevenire.

L’Italia non è l’unico mercato che lo richiede, ed è per questo che il lato sviluppo di giochi da casinò di una commessa e il suo lato certificazione e conformità sono più economici da tenere insieme dalla fase di progettazione che da riconciliare presso l’ODV.

Le decisioni che stanno su una sola pagina

1. Il percorso. Un CFS che certifica un sistema per più concessionari, oppure un fornitore che si integra nel sistema di un solo concessionario.
2. La data che possedete davvero. 13 novembre 2026, 13 gennaio 2027, 12 febbraio 2027 o 15 febbraio 2027.
3. Il deliverable. Rapporto tecnico, inventario dei componenti, digest dei file critici, log di build, script dei digest, identificatori di versione univoci.
4. Le asserzioni sull’infrastruttura. Replica in 120 secondi, disaster recovery nello SEE, un registro cloud approvato, cifratura a riposo e in transito.
5. Le finestre sui dati. Sei mesi in tempo reale, due anni su richiesta, cinque anni archiviati, esportazioni in 48 ore.
6. La prima esecuzione in produzione. Conti di test, calendari pubblicati e il supporto tecnico del CFS che deve essere presente.
7. La regola sulle modifiche. Le modifiche ai componenti critici o alle funzioni verificate vanno prima all’ODV; gli aggiornamenti di emergenza sono certificati entro due settimane.

Le domande che studi e piattaforme pongono

Le nuove date di certificazione valgono per tutto il mercato online in una volta sola?

No. Il calendario a tappe assegna la data più precoce, il 13 novembre 2026, ai concessionari fornitori di servizi che depositano i risultati di conformità per le istanze che contengono sistemi di gioco offerti ad altri concessionari, più i componenti che popolano la libreria condivisa. I concessionari che usano quei sistemi di gioco forniti dai CFS seguono entro il 13 gennaio 2027, le verifiche tecnico-funzionali si concludono entro il 12 febbraio 2027, e il nuovo sistema entra in produzione dal 15 febbraio 2027. Le date sono state riportate dalla stampa di settore italiana il 7 ottobre 2026; confermate il calendario vigente con ADM.

Se un concessionario usa un sistema di gioco già certificato, che cosa deve ancora essere verificato?

Il sistema del concessionario, nel suo complesso. Le linee guida consentono a un concessionario di usare un sistema di gioco certificato reso disponibile da un concessionario fornitore di servizi, ma resta l’obbligo di far verificare il proprio sistema nella sua interezza; ciò che cambia è che l’organismo di verifica è tenuto a verificare solo l’integrazione del sistema di gioco del CFS con il resto del sistema in esame. Le istruzioni di agosto 2026 di ADM ripetono che la verifica di conformità copre il sistema nella sua interezza anziché singoli elementi considerati separatamente.

Che cosa ispeziona un organismo di verifica?

Un rapporto tecnico che descrive il sistema, i suoi componenti e le loro interazioni; la documentazione più i componenti hardware e software; i file critici; i meccanismi automatici di verifica dell’integrità; e le comunicazioni tra i componenti e con il sistema centrale di ADM. Prove di conformità, analisi statistiche e controlli funzionali seguono le regole tecniche. Il codice sorgente deve riportare una descrizione e uno storico delle modifiche per ciascun file o modulo, la versione certificata deve essere identificata univocamente, e il revisore deve poter dimostrare che i binari corrispondono al sorgente compilato, con un log di build e i digest dei file critici.

Quali sono gli obblighi sull’infrastruttura?

Replica dei dati su un sito secondario geograficamente distinto all’interno dello SEE in un massimo di 120 secondi, con il processo di disaster recovery dimostrato; fornitori cloud iscritti al registro dell’agenzia italiana per la cybersicurezza e che soddisfano i requisiti tecnici dell’agenzia digitale, con cifratura dei dati in transito e a riposo; disponibilità in tempo reale delle informazioni di gioco per gli ultimi sei mesi; dati contabili e sulle transazioni su richiesta per due anni; archiviazione di cinque anni; e risultati di query personalizzate esportabili entro 48 ore da una richiesta.

Che cosa accade dopo che un sistema è già stato certificato?

Le modifiche che potrebbero interessare i componenti critici, le funzioni che sono state verificate o la conformità con le regole tecniche devono essere sottoposte all’organismo di verifica in anticipo. Un aggiornamento di emergenza necessario a ripristinare il corretto funzionamento può essere applicato prima che la domanda sia depositata, ma la certificazione di conformità della modifica deve comunque essere ottenuta dall’organismo di verifica entro due settimane. Le autorizzazioni hanno validità di 12 mesi e sono rinnovate tramite un audit che confronta il sistema operativo con la versione certificata e verifica il montepremi reale o il ritorno al giocatore rispetto ai 12 mesi di dati di gioco.

Esiste un controllo dopo la certificazione, prima che i giochi vadano live?

Sì, in una prima certificazione. Una verifica tecnico-funzionale avviene nell’ambiente di produzione, sulla configurazione effettivamente destinata alla concessione, coprendo tutti i sistemi di gioco nella domanda di certificazione e svolgendosi alla prima partenza in produzione di ciascun tipo di gioco. Esercita vendite, accettazione delle giocate, contabilità, accredito delle vincite, pagamenti e scambio di informazioni con il sistema centrale di ADM, e utilizza cinque conti di test registrati a una persona giuridica con calendari pubblicati. Dove sono in uso sistemi forniti dai fornitori di servizi, il CFS deve fornire supporto tecnico durante quei controlli.