O que o DGOJ certifica em Espanha: o inventário de componentes por trás de um jogo de slot

Em Espanha, o objeto que chega ao regulador não é um jogo. É um sistema técnico descrito como um inventário de componentes de software, cada um identificado por fabricante, nome de produto e versão, e os componentes classificados como críticos transportam a sua própria impressão digital. A Direção-Geral de Ordenação do Jogo (DGOJ) homologa esse sistema, e o jogo é certificado dentro dele. Um estúdio que planeia a submissão como uma build do jogo mais um documento de regras produzirá um dossiê que descreve o objeto errado.

Este artigo expõe o que o quadro espanhol exige realmente ao dossiê, porque o inventário de componentes é o documento organizador e não um anexo, e o que o brief de produção tem de resolver para que o inventário continue verdadeiro depois do lançamento. Segue o processo de homologação publicado pelo DGOJ e o modelo do relatório definitivo de certificação da Resolução de 6 de outubro de 2014 (BOE-A-2014-10303, texto consolidado atualizado pela última vez a 3 de novembro de 2022).

A sequência em duas fases, e porque a segunda é a mais difícil

A homologação espanhola decorre em duas fases distintas, com evidência diferente em cada uma. A primeira é o controlo prévio que acompanha o pedido de licença. É fundamentalmente documental: o requerente apresenta um projeto técnico juntamente com um relatório preliminar de certificação do cumprimento dos requisitos técnicos. Quem pede uma licença geral apresenta ainda um relatório de certificação do seu sistema de controlo interno. Nesta fase o regulador avalia o desenho do sistema e a credibilidade do plano de evidência, não o comportamento de um ambiente de produção em direto.

A segunda fase começa depois de concedida a licença. As licenças gerais ficam condicionadas e as singulares são provisórias até à obtenção da homologação definitiva, que deve ser alcançada nos seis meses seguintes à licença. O operador apresenta então relatórios definitivos de certificação sobre o sistema técnico efetivamente utilizado. Esses relatórios devem ser apresentados no prazo improrrogável de quatro meses a contar da notificação da concessão da licença. Só depois de o DGOJ avaliar favoravelmente o relatório definitivo é que o sistema fica homologado de forma definitiva.

A consequência prática para um estúdio é que o relatório preliminar é uma promessa sobre o sistema e o definitivo é a prova desse sistema. Um dossiê redigido para satisfazer a fase preliminar, sem um plano para produzir a evidência definitiva a partir do sistema de produção real, deixa o operador com uma licença condicionada ou provisória e um relógio de quatro meses a correr. A sequência pertence ao plano comercial, não à semana anterior à submissão.

O relatório é um documento de inventário

O anexo III da resolução fixa a estrutura e o conteúdo mínimo do relatório definitivo de certificação da funcionalidade. Tem nove secções: identificação da certificação; descrição do objeto de certificação; resumo executivo; detalhe do cumprimento de cada requisito técnico; detalhe das análises específicas; detalhe dos testes de integração; local, equipamento e datas dos trabalhos de certificação; descrição dos ambientes de teste diferentes do ambiente efetivamente utilizado; e descrição do suporte digital que acompanha o relatório.

A segunda secção é a que muda a forma como um estúdio deve pensar a build. O “objeto de certificação” é o âmbito do sistema técnico, e a resolução exige a identificação dos elementos de software utilizados, com fabricante, nome de produto e versão de cada um. Dois elementos têm de constar em todos os casos: o capturador e o armazém. O relatório deve também relacionar os componentes qualificados como críticos com as respetivas impressões digitais, identificar os centros de processamento de dados onde o sistema está instalado e enumerar os canais de acesso certificados. Para uma licença singular deve identificar ainda os sites e nomes comerciais certificados, o papel do operador como B2C, B2B ou ambos — incluindo se um operador B2B atua como coorganizador de jogo —, a oferta de jogo certificada com as suas variantes e as tecnologias de acesso certificadas, como acesso web, clientes descarregáveis ou aplicações nativas para telemóvel.

Essa lista não é decoração administrativa. Define o que uma entidade de certificação vai avaliar e o que o operador tem de manter verdadeiro. Uma build que incorpora um componente de terceiros não listado, ou que muda um número de versão sem atualizar o inventário, é um sistema que já não corresponde à sua certificação. O inventário tem de ser produzido a partir da mesma fonte de verdade que a build, ou torna-se um documento correto apenas no dia em que é assinado.

A lista de componentes críticos decide o que deve ter impressão digital

Os requisitos da área de segurança da informação incluem um teste concreto: a entidade de certificação deve verificar que a organização identificou os componentes críticos do seu sistema técnico e que a relação inclui um conjunto definido de categorias. Essas categorias são o registo de utilizador, a conta de jogo, o processamento dos meios de pagamento, os componentes que transmitem ou processam números aleatórios e a integração dos resultados do GNA na lógica do jogo, os componentes que armazenam, manipulam ou transmitem informação sensível de clientes, os que armazenam o estado pontual do jogo, as ligações com o DGOJ, o capturador e o armazém do sistema de controlo interno, os pontos de acesso e as comunicações de e para esses componentes críticos, e as redes de comunicação que transportam informação sensível de participantes.

Para um jogo de slot, várias dessas categorias estão dentro da build ou imediatamente à volta dela: a integração do GNA, o armazém do estado de jogo que permite retomar uma ronda interrompida, os pontos de acesso e o caminho de comunicação entre cliente e servidor. Um estúdio que trata a certificação como uma revisão matemática não terá classificado esses componentes, não terá as suas impressões digitais e não conseguirá mostrar à entidade de certificação que a lista está completa. O brief deve atribuir cada categoria a um responsável e registar onde a sua impressão digital é produzida.

A resolução também permite que uma organização com certificação ISO 27001 válida satisfaça a área de segurança da informação, anotando “ISO 27001” nas observações. É útil para um operador com um sistema de gestão estabelecido, mas não elimina a necessidade de identificar os componentes críticos específicos do jogo nem de obter as suas impressões digitais.

A análise do GNA é um conjunto estruturado de evidência

Quando uma licença singular utiliza um gerador de números aleatórios, o relatório definitivo deve incluir uma análise do GNA com campos definidos: fabricante do gerador; nome de produto e versão; impressão digital do binário; se é hardware ou software; se é aleatório ou pseudoaleatório e, no caso de uma fonte aleatória, o fenómeno físico em que se baseia; se a instância do gerador é partilhada com outros jogos e, em caso afirmativo, com quais; o algoritmo e, para software, as bibliotecas ou chamadas do sistema operativo em que se apoia; se existe procedimento de ressemeadura; o comprimento em bits do espaço de números aleatórios distintos; e a relação de testes estatísticos realizados.

Isto é mais específico do que “descreve o teu GNA”. É um pedido da identidade e proveniência do gerador na mesma forma que o resto do inventário de componentes. Um estúdio que usa um GNA licenciado de terceiros deve obter esses campos do fornecedor como parte da compra, não reconstruí-los durante a certificação. Um estúdio que constrói o seu próprio gerador deve registá-los no desenho técnico desde o primeiro protótipo, porque o comprimento do espaço e o comportamento de ressemeadura são propriedades de desenho, não de documentação.

Publicação do RTP e análise da lógica do jogo

Para os jogos com percentagem de retorno, o relatório registra a percentagem de retorno ao jogador publicada para cada jogo e o local onde é publicada. A percentagem não é apenas um número matemático: é uma declaração publicada cuja localização faz parte da evidência de certificação. Uma alteração ao número publicado ou à página onde aparece é uma alteração à representação certificada, e o brief deve registar quem é dono dessa página e como é atualizada.

A análise da lógica do jogo cobre as regras particulares do jogo, se o operador usa um sistema de gestão de risco próprio ou um produto para apostas de contrapartida, se são auditadas as alterações de configuração desse sistema, se são auditadas as alterações feitas pelo pessoal do operador sobre as apostas, a relação de eventos aleatórios e se são pré-sorteados, e se são auditadas as alterações de configuração da lógica do jogo. Para um jogo de slot, a lista de eventos aleatórios é onde o modelo de estado da mecânica se torna visível para o certificador: que eventos retiram do gerador e se os resultados são determinados antes da ronda ou durante ela. O guia de especificação de regras de jogos de casino explica como redigir o documento de regras que sustenta esta análise; o relatório espanhol acrescenta a exigência de enumerar os eventos aleatórios e o rasto de auditoria em torno da configuração.

Testes de integração e paridade de ambientes

O relatório deve detalhar os testes de integração realizados, qualificados por área de requisitos face aos testes do anexo VI, com os testes adicionais nomeados a começar por “X”. Deve também descrever o local, o equipamento e as datas dos trabalhos de certificação, e descrever qualquer ambiente de teste diferente do ambiente que o operador usa efetivamente em produção.

A resolução é explícita sobre o que exige um ambiente diferente. Para certificações realizadas no contexto de uma alteração substancial, os testes de integração podem ser realizados num ambiente diferente do sistema de produção. Quando isso acontece, a entidade de certificação deve certificar, sob a sua responsabilidade, que os resultados obtidos no ambiente de teste são extrapoláveis para o sistema de produção, após analisar se as diferenças entre ambos afetam a qualidade do resultado. Para um estúdio, isso significa que o ambiente de teste deve ser documentado como uma réplica controlada, não como um servidor de staging improvisado, e as diferenças devem ser conhecidas e registadas antes de executar os testes.

A gestão de alterações continua após a homologação

A obrigação que mais surpreende os estúdios é a que começa depois da homologação. O operador deve dispor de um procedimento documentado de gestão de alterações que controle as alterações dos equipamentos e componentes do sistema técnico efetivamente utilizado. Deve enviar ao DGOJ um relatório trimestral que descreva as alterações realizadas no período e mantenha atualizada a descrição do sistema. O DGOJ pode exigir que esse relatório trimestral inclua uma impressão digital dos binários.

As modificações substanciais que afetem componentes críticos requerem autorização prévia antes da entrada em produção, após a apresentação do correspondente relatório de certificação. O DGOJ decide a autorização no prazo de um mês a contar da receção do pedido. Se considerar substancial uma alteração feita a um componente crítico, pode exigir ao operador que a homologue e pode exigir a retirada da alteração até obter a homologação. Em emergências extraordinárias de segurança devidamente comprovadas e comunicadas ao DGOJ, o operador pode introduzir alterações substanciais em componentes críticos e pedir autorização posteriormente, apresentando um relatório que comprove as circunstâncias excecionais e o risco para a segurança.

Um estúdio que lança um jogo de serviço contínuo em Espanha não termina na homologação. Cada patch que toque num componente crítico tem de passar por uma decisão de classificação, e a classificação tem de ser defensável. O brief deve definir que alterações são rotineiras, quais são substanciais e quem toma essa decisão, antes do primeiro patch pós-lançamento e não depois de o regulador perguntar porque mudou um binário.

O que o brief de produção deve registar

O dossiê espanhol é gerível quando o brief o trata como um plano de configuração e evidência. Seis decisões pertencem ao brief antes de começar o desenvolvimento.

• O inventário de componentes e o seu responsável. Uma relação nominal de elementos de software com fabricante, nome de produto e versão, incluindo bibliotecas de terceiros e o capturador e o armazém do sistema de controlo interno, com um responsável por a manter atualizada.
• O mapa de componentes críticos. Que componentes caem em cada categoria exigida pela resolução, onde é produzida cada impressão digital e como uma alteração de versão atualiza tanto a impressão como o inventário.
• O estado de homologação dos fornecedores. A homologação espanhola adere ao sistema do operador, e a resolução descreve esse sistema como o conjunto de fornecedores de software — software de plataforma, software de jogo, software de agregador e software de armazém — previamente homologados ou autorizados através dos procedimentos de homologação ou de alteração substancial. Um estúdio que fornece um jogo a um operador espanhol deve estabelecer, antes de contratar, se já é um fornecedor de software homologado ou se a sua integração exige uma autorização de alteração substancial.
• O plano de evidência em duas fases. O que afirmará o relatório preliminar, o que provará o definitivo, que sistema de produção gerará a evidência definitiva e quem é responsável por apresentá-la dentro do prazo de quatro meses.
• A regra de classificação de alterações. Que alterações contam como substanciais para cada componente crítico, quem aprova a classificação e como o relatório trimestral é montado a partir dos registos de build em vez de ser reconstruído no fim do trimestre.
• O registo de paridade de ambientes. Como o ambiente de teste é mantido equivalente à produção, que diferenças são aceites e quem certifica a extrapolação quando os ambientes diferem.

Nenhuma destas decisões exige um desenho de jogo diferente. Mudam o que o estúdio registra enquanto constrói, e por isso pertencem ao brief e não à fase de certificação. Um publisher ou estúdio que prepare uma submissão espanhola pode solicitar um orçamento com o tipo de licença e o âmbito de mercado previstos.

Perguntas frequentes

O DGOJ certifica o jogo ou o sistema técnico do operador?

Homologa o sistema técnico do operador, e o jogo é certificado dentro desse sistema. O relatório definitivo de funcionalidade descreve o âmbito do sistema, incluindo os elementos de software e as suas versões, os componentes críticos e as suas impressões digitais, os centros de dados, os canais de acesso, a oferta de jogo certificada e o papel do operador. O software de um fornecedor de jogos passa a fazer parte desse sistema descrito, e é por isso que o estado de homologação do fornecedor importa antes de contratar.

O que acontece entre o relatório preliminar e a homologação definitiva?

O relatório preliminar de certificação acompanha o pedido de licença e é avaliado documentalmente. Depois de concedida a licença — condicionada para uma licença geral e provisória para uma singular — o operador deve apresentar os relatórios definitivos de certificação no prazo de quatro meses a contar da notificação e obter a homologação definitiva em seis meses. O relatório definitivo cobre o sistema realmente em produção, pelo que a evidência tem de vir do ambiente vivo e não dos documentos de desenho.

Uma alteração ao jogo depois do lançamento exige automaticamente uma nova certificação?

Não automaticamente, mas pode exigir autorização prévia. Uma modificação substancial que afete um componente crítico precisa de autorização antes da produção, com um relatório de certificação, e o DGOJ responde no prazo de um mês. O operador apresenta também um relatório trimestral de alterações. Se o DGOJ considerar substancial uma alteração num componente crítico, pode exigir a homologação e a retirada até a obter. A regra de classificação deve ser acordada antes do primeiro patch.

Pode usar-se um ambiente de teste em vez do sistema de produção?

A resolução permite testes de integração num ambiente diferente da produção no contexto de uma alteração substancial, mas a entidade de certificação deve certificar que os resultados são extrapoláveis para o sistema de produção e analisar se as diferenças entre ambientes afetam o resultado. O dossiê deve descrever o ambiente de teste e as suas diferenças conhecidas, não apenas nomeá-lo.