Cosa certifica il DGOJ in Spagna: l'inventario dei componenti dietro una slot

In Spagna l’oggetto che arriva al regolatore non è un gioco. È un sistema tecnico descritto come un inventario di componenti software, ciascuno identificato per produttore, nome del prodotto e versione, e i componenti classificati come critici portano la propria impronta digitale. La Direzione Generale per l’Ordinamento del Gioco (DGOJ) omologa quel sistema, e il gioco viene certificato al suo interno. Uno studio che pianifica la presentazione come una build del gioco più un documento di regole produrrà un fascicolo che descrive l’oggetto sbagliato.

Questo articolo espone cosa il quadro spagnolo richiede davvero al fascicolo, perché l’inventario dei componenti è il documento che organizza la pratica e non un allegato, e cosa deve stabilire il brief di produzione perché l’inventario resti vero dopo il lancio. Segue il processo di omologazione pubblicato dal DGOJ e il modello del rapporto definitivo di certificazione della Risoluzione del 6 ottobre 2014 (BOE-A-2014-10303, testo consolidato aggiornato da ultimo il 3 novembre 2022).

La sequenza in due fasi, e perché la seconda è la più difficile

L’omologazione spagnola si svolge in due fasi distinte, con prove diverse in ciascuna. La prima è il controllo preventivo che accompagna la domanda di licenza. È prevalentemente documentale: il richiedente presenta un progetto tecnico insieme a un rapporto preliminare di certificazione del rispetto dei requisiti tecnici. Chi richiede una licenza generale presenta anche un rapporto di certificazione del proprio sistema di controllo interno. In questa fase il regolatore valuta il disegno del sistema e la credibilità del piano di prova, non il comportamento di un ambiente di produzione live.

La seconda fase inizia dopo il rilascio della licenza. Le licenze generali restano condizionate e quelle singolari sono provvisorie fino all’ottenimento dell’omologazione definitiva, che deve essere raggiunta entro sei mesi dalla licenza. L’operatore presenta quindi rapporti definitivi di certificazione sul sistema tecnico effettivamente utilizzato. Tali rapporti devono essere presentati entro il termine improrogabile di quattro mesi dalla notifica del rilascio della licenza. Solo dopo una valutazione favorevole del rapporto definitivo da parte del DGOJ il sistema viene omologato in via definitiva.

La conseguenza pratica per uno studio è che il rapporto preliminare è una promessa sul sistema e quello definitivo è la prova di quel sistema. Un fascicolo redatto per soddisfare la fase preliminare, senza un piano per produrre la prova definitiva dal sistema di produzione reale, lascia l’operatore con una licenza condizionata o provvisoria e un conto alla rovescia di quattro mesi già avviato. La sequenza appartiene al piano commerciale, non alla settimana prima della presentazione.

Il rapporto è un documento di inventario

L’allegato III della risoluzione fissa la struttura e il contenuto minimo del rapporto definitivo di certificazione della funzionalità. Si articola in nove sezioni: identificazione della certificazione; descrizione dell’oggetto della certificazione; sintesi esecutiva; dettaglio del rispetto di ciascun requisito tecnico; dettaglio delle analisi specifiche; dettaglio dei test di integrazione; luogo, attrezzature e date dei lavori di certificazione; descrizione degli ambienti di test diversi dall’ambiente effettivamente utilizzato; e descrizione del supporto digitale che accompagna il rapporto.

La seconda sezione è quella che cambia il modo in cui uno studio deve pensare la build. L’“oggetto della certificazione” è l’ambito del sistema tecnico, e la risoluzione richiede di identificare gli elementi software impiegati, con produttore, nome del prodotto e versione di ciascuno. Due elementi devono comparire in ogni caso: il capturatore e il magazzino. Il rapporto deve inoltre elencare i componenti qualificati come critici con le relative impronte digitali, identificare i centri di elaborazione dati in cui il sistema è installato ed elencare i canali di accesso certificati. Per una licenza singolare deve inoltre identificare i siti web e i nomi commerciali certificati, il ruolo dell’operatore come B2C, B2B o entrambi — compreso se un operatore B2B agisce come co-organizzatore di gioco —, l’offerta di gioco certificata con le sue varianti e le tecnologie di accesso certificate, come accesso web, client scaricabili o applicazioni native per dispositivi mobili.

Quell’elenco non è decorazione amministrativa. Definisce cosa valuterà un ente di certificazione e cosa l’operatore deve mantenere vero. Una build che incorpora un componente di terze parti non elencato, o che cambia un numero di versione senza aggiornare l’inventario, è un sistema che non corrisponde più alla sua certificazione. L’inventario deve essere prodotto dalla stessa fonte di verità della build, altrimenti diventa un documento corretto solo il giorno in cui viene firmato.

L’elenco dei componenti critici decide cosa deve avere un’impronta

I requisiti dell’area sicurezza delle informazioni includono un test specifico: l’ente di certificazione deve verificare che l’organizzazione abbia identificato i componenti critici del proprio sistema tecnico e che l’elenco comprenda una serie definita di categorie. Tali categorie sono il registro utente, il conto di gioco, l’elaborazione dei mezzi di pagamento, i componenti che trasmettono o elaborano numeri casuali e l’integrazione dei risultati del GNA nella logica del gioco, i componenti che memorizzano, manipolano o trasmettono informazioni sensibili dei clienti, quelli che memorizzano lo stato puntuale del gioco, le connessioni con il DGOJ, il capturatore e il magazzino del sistema di controllo interno, i punti di accesso e le comunicazioni da e verso tali componenti critici, e le reti di comunicazione che trasportano informazioni sensibili dei partecipanti.

Per una slot, diverse di queste categorie stanno dentro la build o immediatamente attorno ad essa: l’integrazione del GNA, il magazzino dello stato di gioco che consente di riprendere un round interrotto, i punti di accesso e il percorso di comunicazione tra client e server. Uno studio che tratta la certificazione come una revisione matematica non avrà classificato quei componenti, non avrà le loro impronte e non potrà dimostrare all’ente di certificazione che l’elenco è completo. Il brief deve assegnare ogni categoria a un responsabile e registrare dove viene prodotta la sua impronta.

La risoluzione consente inoltre a un’organizzazione con certificazione ISO 27001 valida di soddisfare l’area sicurezza delle informazioni, annotando “ISO 27001” nelle osservazioni. È utile per un operatore con un sistema di gestione consolidato, ma non elimina la necessità di identificare i componenti critici specifici del gioco né di ottenerne le impronte.

L’analisi del GNA è un insieme strutturato di prove

Quando una licenza singolare utilizza un generatore di numeri aleatori, il rapporto definitivo deve includere un’analisi del GNA con campi definiti: produttore del generatore; nome del prodotto e versione; impronta digitale del binario; se è hardware o software; se è aleatorio o pseudoaleatorio e, per una fonte aleatoria, il fenomeno fisico su cui si basa; se l’istanza del generatore è condivisa con altri giochi e, in tal caso, con quali; l’algoritmo e, per il software, le librerie o le chiamate di sistema su cui si basa; se esiste una procedura di riseminaggio; la lunghezza in bit dello spazio di numeri aleatori distinti; e l’elenco dei test statistici eseguiti.

È più specifico di “descrivi il tuo GNA”. È una richiesta dell’identità e provenienza del generatore nella stessa forma del resto dell’inventario dei componenti. Uno studio che usa un GNA concesso in licenza da terzi dovrebbe ottenere quei campi dal fornitore come parte dell’acquisto, non ricostruirli durante la certificazione. Uno studio che costruisce il proprio generatore dovrebbe registrarli nel progetto tecnico fin dal primo prototipo, perché la lunghezza dello spazio e il comportamento di riseminaggio sono proprietà di progetto, non di documentazione.

Pubblicazione dell’RTP e analisi della logica del gioco

Per i giochi con percentuale di ritorno, il rapporto registra la percentuale di ritorno al giocatore pubblicata per ciascun gioco e il luogo in cui è pubblicata. La percentuale non è solo un numero matematico: è una dichiarazione pubblicata la cui ubicazione fa parte della prova di certificazione. Una modifica alla cifra pubblicata o alla pagina in cui appare è una modifica alla rappresentazione certificata, e il brief deve registrare chi possiede quella pagina e come viene aggiornata.

L’analisi della logica del gioco copre le regole particolari del gioco, se l’operatore usa un sistema di gestione del rischio proprio o un prodotto per le scommesse di contropartita, se sono auditati i cambi di configurazione di quel sistema, se sono auditati i cambi effettuati dal personale dell’operatore sulle scommesse, l’elenco degli eventi aleatori e se sono pre-sorteggiati, e se sono auditati i cambi di configurazione della logica del gioco. Per una slot, l’elenco degli eventi aleatori è il punto in cui il modello di stato della meccanica diventa visibile al certificatore: quali eventi attingono dal generatore e se i risultati sono determinati prima del round o durante. La guida alla specifica delle regole dei giochi da casinò spiega come redigere il documento delle regole che sostiene questa analisi; il rapporto spagnolo aggiunge l’obbligo di enumerare gli eventi aleatori e la traccia di audit attorno alla configurazione.

Test di integrazione e parità degli ambienti

Il rapporto deve dettagliare i test di integrazione eseguiti, qualificati per area di requisiti rispetto ai test dell’allegato VI, con i test aggiuntivi denominati a partire da “X”. Deve inoltre descrivere il luogo, le attrezzature e le date dei lavori di certificazione, e descrivere qualsiasi ambiente di test diverso dall’ambiente che l’operatore usa effettivamente in produzione.

La risoluzione è esplicita su cosa richiede un ambiente diverso. Per le certificazioni effettuate nel contesto di una modifica sostanziale, i test di integrazione possono essere eseguiti in un ambiente diverso dal sistema di produzione. In tal caso l’ente di certificazione deve certificare, sotto la propria responsabilità, che i risultati ottenuti nell’ambiente di test sono estrapolabili al sistema di produzione, dopo aver analizzato se le differenze tra i due ambienti incidono sulla qualità del risultato. Per uno studio ciò significa che l’ambiente di test deve essere documentato come una replica controllata, non come uno staging improvvisato, e le differenze devono essere note e registrate prima di eseguire i test.

La gestione delle modifiche continua dopo l’omologazione

L’obbligo che sorprende più spesso gli studi è quello che inizia dopo l’omologazione. L’operatore deve disporre di una procedura documentata di gestione delle modifiche che controlli i cambi di attrezzature e componenti del sistema tecnico effettivamente utilizzato. Deve inviare al DGOJ un rapporto trimestrale che descriva le modifiche effettuate nel periodo e mantenga aggiornata la descrizione del sistema. Il DGOJ può richiedere che quel rapporto trimestrale includa un’impronta digitale dei binari.

Le modifiche sostanziali che interessano componenti critici richiedono autorizzazione preventiva prima della messa in produzione, previa presentazione del relativo rapporto di certificazione. Il DGOJ si pronuncia sull’autorizzazione entro un mese dalla ricezione della richiesta. Se ritiene sostanziale una modifica effettuata su un componente critico, può chiedere all’operatore di omologarla e può chiedere il ritiro della modifica fino all’ottenimento dell’omologazione. In situazioni di emergenza straordinaria per la sicurezza, debitamente comprovate e comunicate al DGOJ, l’operatore può introdurre modifiche sostanziali ai componenti critici e chiedere l’autorizzazione successivamente, presentando un rapporto che comprovi le circostanze eccezionali e il rischio per la sicurezza.

Uno studio che lancia un gioco live-service in Spagna non finisce con l’omologazione. Ogni patch che tocchi un componente critico deve passare attraverso una decisione di classificazione, e la classificazione deve essere difendibile. Il brief deve definire quali modifiche sono ordinarie, quali sono sostanziali e chi prende quella decisione, prima della prima patch post-lancio e non dopo che il regolatore chiede perché è cambiato un binario.

Cosa deve registrare il brief di produzione

Il fascicolo spagnolo è gestibile quando il brief lo tratta come un piano di configurazione e prova. Sei decisioni appartengono al brief prima dell’inizio dello sviluppo.

• L’inventario dei componenti e il suo responsabile. Un elenco nominativo di elementi software con produttore, nome del prodotto e versione, comprese le librerie di terze parti e il capturatore e il magazzino del sistema di controllo interno, con un responsabile che lo mantenga aggiornato.
• La mappa dei componenti critici. Quali componenti rientrano in ciascuna categoria richiesta dalla risoluzione, dove viene prodotta ogni impronta e come un cambio di versione aggiorni sia l’impronta sia l’inventario.
• Lo stato di omologazione dei fornitori. L’omologazione spagnola aderisce al sistema dell’operatore, e la risoluzione descrive quel sistema come l’insieme dei fornitori di software — software di piattaforma, software di gioco, software di aggregatore e software di magazzino — precedentemente omologati o autorizzati tramite le procedure di omologazione o di modifica sostanziale. Uno studio che fornisce un gioco a un operatore spagnolo dovrebbe stabilire, prima di stipulare il contratto, se è già un fornitore di software omologato o se la sua integrazione richiede un’autorizzazione di modifica sostanziale.
• Il piano di prova in due fasi. Cosa affermerà il rapporto preliminare, cosa proverà quello definitivo, quale sistema di produzione produrrà la prova definitiva e chi è responsabile di presentarla entro la finestra di quattro mesi.
• La regola di classificazione delle modifiche. Quali modifiche contano come sostanziali per ciascun componente critico, chi approva la classificazione e come il rapporto trimestrale viene costruito dai registri di build invece di essere ricostruito alla fine del trimestre.
• Il registro di parità degli ambienti. Come l’ambiente di test viene mantenuto equivalente alla produzione, quali differenze sono accettate e chi certifica l’estrapolazione quando gli ambienti differiscono.

Nessuna di queste decisioni richiede un disegno del gioco diverso. Cambiano ciò che lo studio registra mentre costruisce, ed è per questo che appartengono al brief e non alla fase di certificazione. Un publisher o uno studio che prepara una presentazione spagnola può richiedere un preventivo con il tipo di licenza e l’ambito di mercato previsti.

Domande frequenti

Il DGOJ certifica il gioco o il sistema tecnico dell’operatore?

Omologa il sistema tecnico dell’operatore, e il gioco viene certificato all’interno di quel sistema. Il rapporto definitivo di funzionalità descrive l’ambito del sistema, compresi gli elementi software e le loro versioni, i componenti critici e le loro impronte digitali, i centri dati, i canali di accesso, l’offerta di gioco certificata e il ruolo dell’operatore. Il software di un fornitore di giochi diventa parte di quel sistema descritto, ed è per questo che lo stato di omologazione del fornitore conta prima di stipulare il contratto.

Cosa succede tra il rapporto preliminare e l’omologazione definitiva?

Il rapporto preliminare di certificazione accompagna la domanda di licenza ed è valutato documentalmente. Dopo il rilascio della licenza — condizionata per una licenza generale e provvisoria per una singolare — l’operatore deve presentare i rapporti definitivi di certificazione entro quattro mesi dalla notifica e ottenere l’omologazione definitiva entro sei mesi. Il rapporto definitivo copre il sistema realmente in produzione, quindi la prova deve venire dall’ambiente live e non dai documenti di progetto.

Una modifica al gioco dopo il lancio richiede automaticamente una nuova certificazione?

Non automaticamente, ma può richiedere autorizzazione preventiva. Una modifica sostanziale che interessi un componente critico necessita di autorizzazione prima della produzione, con un rapporto di certificazione, e il DGOJ risponde entro un mese. L’operatore presenta anche un rapporto trimestrale delle modifiche. Se il DGOJ ritiene sostanziale una modifica a un componente critico, può chiedere l’omologazione e il ritiro fino a ottenerla. La regola di classificazione dovrebbe essere concordata prima della prima patch.

Si può usare un ambiente di test invece del sistema di produzione?

La risoluzione consente test di integrazione in un ambiente diverso dalla produzione nel contesto di una modifica sostanziale, ma l’ente di certificazione deve certificare che i risultati siano estrapolabili al sistema di produzione e analizzare se le differenze tra gli ambienti incidono sul risultato. Il fascicolo deve descrivere l’ambiente di test e le sue differenze note, non solo nominarlo.