En España, el objeto que llega al regulador no es un juego. Es un sistema técnico descrito como un inventario de componentes de software, cada uno identificado por fabricante, nombre de producto y versión, y los componentes clasificados como críticos llevan su propia huella digital. La Dirección General de Ordenación del Juego (DGOJ) homologa ese sistema, y el juego se certifica dentro de él. Un estudio que planifica el envío como una build del juego más un documento de reglas producirá un expediente que describe el objeto equivocado.
Este artículo expone qué exige realmente el marco español al expediente, por qué el inventario de componentes es el documento organizador y no un anexo, y qué debe resolver el brief de producción para que el inventario siga siendo cierto después del lanzamiento. Sigue el proceso de homologación publicado por el DGOJ y el modelo del informe de certificación definitiva de la Resolución de 6 de octubre de 2014 (BOE-A-2014-10303, texto consolidado actualizado por última vez el 3 de noviembre de 2022).
La secuencia en dos fases, y por qué la segunda es la más difícil
La homologación española se desarrolla en dos fases distintas con evidencia diferente en cada una. La primera es el control previo que acompaña a la solicitud de licencia. Es fundamentalmente documental: el solicitante presenta un proyecto técnico junto con un informe preliminar de certificación del cumplimiento de los requisitos técnicos. Quien solicita una licencia general presenta además un informe de certificación de su sistema de control interno. En esta fase el regulador evalúa el diseño del sistema y la credibilidad del plan de evidencia, no el comportamiento de un entorno de producción en vivo.
La segunda fase comienza después de otorgada la licencia. Las licencias generales quedan condicionadas y las singulares son provisionales hasta obtener la homologación definitiva, que debe lograrse en los seis meses siguientes a la licencia. El operador presenta entonces informes definitivos de certificación sobre el sistema técnico realmente utilizado. Esos informes deben presentarse en el plazo improrrogable de cuatro meses desde la notificación del otorgamiento de la licencia. Solo cuando el DGOJ valora favorablemente el informe definitivo, el sistema queda homologado de forma definitiva.
La consecuencia práctica para un estudio es que el informe preliminar es una promesa sobre el sistema y el definitivo es la prueba de ese sistema. Un expediente redactado para satisfacer la fase preliminar, sin un plan para producir la evidencia definitiva desde el sistema de producción real, deja al operador con una licencia condicionada o provisional y un reloj de cuatro meses en marcha. La secuencia pertenece al plan comercial, no a la semana previa al envío.
El informe es un documento de inventario
El anexo III de la resolución fija la estructura y el contenido mínimo del informe definitivo de certificación de la funcionalidad. Consta de nueve apartados: identificación de la certificación; descripción del objeto de certificación; resumen ejecutivo; detalle del cumplimiento de cada requisito técnico; detalle de los análisis específicos; detalle de las pruebas de integración; lugar, equipo y fechas de los trabajos de certificación; descripción de los entornos de prueba distintos del entorno realmente utilizado; y descripción del soporte digital que acompaña al informe.
El segundo apartado es el que cambia la forma en que un estudio debe pensar la build. El “objeto de certificación” es el alcance del sistema técnico, y la resolución exige identificar los elementos de software empleados, con fabricante, nombre de producto y versión de cada uno. Dos elementos deben aparecer en todo caso: el capturador y el almacén. El informe también debe relacionar los componentes calificados como críticos con sus huellas digitales, identificar los centros de proceso de datos donde está instalado el sistema y enumerar los canales de acceso certificados. Para una licencia singular debe identificar además los sitios web y nombres comerciales certificados, el rol del operador como B2C, B2B o ambos —incluido si un operador B2B actúa como coorganizador de juego—, la oferta de juego certificada con sus variantes y las tecnologías de acceso certificadas, como acceso web, clientes descargables o aplicaciones nativas para móvil.
Esa lista no es decoración administrativa. Define qué evaluará una entidad de certificación y qué debe mantener cierto el operador. Una build que incorpora un componente de terceros no listado, o que cambia un número de versión sin actualizar el inventario, es un sistema que ya no coincide con su certificación. El inventario tiene que producirse desde la misma fuente de verdad que la build, o se convierte en un documento correcto solo el día en que se firma.
La lista de componentes críticos decide qué debe llevar huella
Los requisitos del área de seguridad de la información incluyen una prueba concreta: la entidad de certificación debe verificar que la organización ha identificado los componentes críticos de su sistema técnico y que la relación incluye una serie de categorías definidas. Esas categorías son el registro de usuario, la cuenta de juego, el procesamiento de los medios de pago, los componentes que transmiten o procesan números aleatorios y la integración de los resultados del GNA en la lógica del juego, los componentes que almacenan, manipulan o transmiten información sensible de clientes, los que almacenan el estado puntual del juego, las conexiones con el DGOJ, el capturador y el almacén del sistema de control interno, los puntos de acceso y las comunicaciones de y hacia esos componentes críticos, y las redes de comunicación que transportan información sensible de participantes.
Para una tragaperras, varias de esas categorías están dentro de la build o inmediatamente alrededor: la integración del GNA, el almacén del estado de juego que permite reanudar una ronda interrumpida, los puntos de acceso y la ruta de comunicación entre cliente y servidor. Un estudio que trata la certificación como una revisión matemática no habrá clasificado esos componentes, no tendrá sus huellas y no podrá mostrar a la entidad de certificación que la lista está completa. El brief debe asignar cada categoría a un responsable y registrar dónde se produce su huella.
La resolución también permite que una organización con certificación ISO 27001 vigente satisfaga el área de seguridad de la información, anotando “ISO 27001” en las observaciones. Es útil para un operador con un sistema de gestión establecido, pero no elimina la necesidad de identificar los componentes críticos específicos del juego ni de obtener sus huellas.
El análisis del GNA es un conjunto estructurado de evidencia
Cuando una licencia singular utiliza un generador de números aleatorios, el informe definitivo debe incluir un análisis del GNA con campos definidos: fabricante del generador; nombre de producto y versión; huella digital del binario; si es hardware o software; si es aleatorio o pseudoaleatorio y, en el caso de una fuente aleatoria, el fenómeno físico en que se basa; si la instancia del generador se comparte con otros juegos y, en su caso, con cuáles; el algoritmo y, para software, las librerías o llamadas del sistema operativo en que se apoya; si existe procedimiento de resemillado; la longitud en bits del espacio de números aleatorios distintos; y la relación de tests estadísticos realizados.
Esto es más específico que “describe tu GNA”. Es una petición de la identidad y procedencia del generador en la misma forma que el resto del inventario de componentes. Un estudio que usa un GNA licenciado de terceros debería obtener esos campos del proveedor como parte de la compra, no reconstruirlos durante la certificación. Un estudio que construye su propio generador debería registrarlos en el diseño técnico desde el primer prototipo, porque la longitud del espacio y el comportamiento de resemillado son propiedades de diseño, no de documentación.
Publicación del RTP y análisis de la lógica del juego
Para los juegos con porcentaje de retorno, el informe registra el porcentaje de retorno al jugador publicado para cada juego y el lugar donde se publica. El porcentaje no es solo una cifra matemática: es una declaración publicada cuya ubicación forma parte de la evidencia de certificación. Un cambio en la cifra publicada o en la página donde aparece es un cambio en la representación certificada, y el brief debe registrar quién es dueño de esa página y cómo se actualiza.
El análisis de la lógica del juego cubre las reglas particulares del juego, si el operador usa un sistema de gestión de riesgos propio o un producto para apuestas de contrapartida, si se auditan los cambios de configuración de ese sistema, si se auditan los cambios que el personal del operador hace sobre las apuestas, la relación de sucesos aleatorios y si son presorteados, y si se auditan los cambios de configuración de la lógica del juego. Para una tragaperras, la lista de sucesos aleatorios es donde el modelo de estado de la mecánica se hace visible para el certificador: qué eventos toman del generador y si los resultados se determinan antes de la ronda o durante ella. La guía de especificación de reglas de juegos de casino explica cómo redactar el documento de reglas que sostiene este análisis; el informe español añade la exigencia de enumerar los sucesos aleatorios y la traza de auditoría alrededor de la configuración.
Pruebas de integración y paridad de entornos
El informe debe detallar las pruebas de integración realizadas, calificadas por área de requisitos frente a las pruebas del anexo VI, con las pruebas adicionales nombradas comenzando por “X”. También debe describir el lugar, el equipo y las fechas de los trabajos de certificación, y describir cualquier entorno de prueba distinto del que el operador usa realmente en producción.
La resolución es explícita sobre lo que exige un entorno diferente. Para certificaciones realizadas en el contexto de un cambio sustancial, las pruebas de integración pueden realizarse en un entorno distinto del sistema de producción. Cuando eso ocurre, la entidad de certificación debe certificar, bajo su responsabilidad, que los resultados obtenidos en el entorno de prueba son extrapolables al sistema de producción, tras analizar si las diferencias entre ambos afectan a la calidad del resultado. Para un estudio, eso significa que el entorno de prueba debe documentarse como una réplica controlada, no como un servidor de staging improvisado, y las diferencias deben conocerse y registrarse antes de ejecutar las pruebas.
La gestión de cambios continúa tras la homologación
La obligación que más sorprende a los estudios es la que empieza después de la homologación. El operador debe disponer de un procedimiento documentado de gestión de cambios que controle los cambios de los equipos y componentes del sistema técnico realmente utilizado. Debe enviar al DGOJ un informe trimestral que describa los cambios realizados en el periodo y mantenga actualizada la descripción del sistema. El DGOJ puede exigir que ese informe trimestral incluya una huella digital de los binarios.
Las modificaciones sustanciales que afecten a componentes críticos requieren autorización previa antes de su puesta en producción, tras la presentación del correspondiente informe de certificación. El DGOJ resuelve la autorización en el plazo de un mes desde la recepción de la solicitud. Si considera sustancial un cambio realizado en un componente crítico, puede requerir al operador que lo homologue y puede requerir la retirada del cambio hasta obtener la homologación. Ante emergencias extraordinarias de seguridad debidamente acreditadas y comunicadas al DGOJ, el operador puede introducir cambios sustanciales en componentes críticos y solicitar la autorización posteriormente, presentando un informe que acredite las circunstancias excepcionales y el riesgo para la seguridad.
Un estudio que lanza un juego de servicio continuo en España no termina en la homologación. Cada parche que toque un componente crítico debe pasar por una decisión de clasificación, y la clasificación debe ser defendible. El brief debe definir qué cambios son rutinarios, cuáles son sustanciales y quién toma esa decisión, antes del primer parche posterior al lanzamiento y no después de que el regulador pregunte por qué cambió un binario.
Qué debe registrar el brief de producción
El expediente español es manejable cuando el brief lo trata como un plan de configuración y evidencia. Seis decisiones pertenecen al brief antes de empezar el desarrollo.
- El inventario de componentes y su responsable. Una relación nominal de elementos de software con fabricante, nombre de producto y versión, incluidas las librerías de terceros y el capturador y el almacén del sistema de control interno, con un responsable de mantenerla actualizada.
- El mapa de componentes críticos. Qué componentes caen en cada categoría que exige la resolución, dónde se produce cada huella y cómo un cambio de versión actualiza tanto la huella como el inventario.
- El estado de homologación de los proveedores. La homologación española se adhiere al sistema del operador, y la resolución describe ese sistema como el conjunto de proveedores de software —software de plataforma, software de juego, software de agregador y software de almacén— previamente homologados o autorizados mediante los procedimientos de homologación o de cambio sustancial. Un estudio que suministra un juego a un operador español debería establecer, antes de contratar, si ya es un proveedor de software homologado o si su integración requiere una autorización de cambio sustancial.
- El plan de evidencia en dos fases. Qué afirmará el informe preliminar, qué probará el definitivo, qué sistema de producción generará la evidencia definitiva y quién es responsable de presentarla dentro del plazo de cuatro meses.
- La regla de clasificación de cambios. Qué cambios cuentan como sustanciales para cada componente crítico, quién aprueba la clasificación y cómo se arma el informe trimestral desde los registros de build en lugar de reconstruirlo al final del trimestre.
- El registro de paridad de entornos. Cómo se mantiene el entorno de prueba equivalente a producción, qué diferencias se aceptan y quién certifica la extrapolación cuando los entornos difieren.
Ninguna de estas decisiones exige un diseño de juego distinto. Cambian lo que el estudio registra mientras construye, y por eso pertenecen al brief y no a la fase de certificación. Un publisher o estudio que prepare un envío español puede solicitar una cotización con el tipo de licencia y el alcance de mercado previstos.
Preguntas frecuentes
¿El DGOJ certifica el juego o el sistema técnico del operador?
Homologa el sistema técnico del operador, y el juego se certifica dentro de ese sistema. El informe definitivo de funcionalidad describe el alcance del sistema, incluidos los elementos de software y sus versiones, los componentes críticos y sus huellas digitales, los centros de datos, los canales de acceso, la oferta de juego certificada y el rol del operador. El software de un proveedor de juegos pasa a formar parte de ese sistema descrito, por eso el estado de homologación del proveedor importa antes de contratar.
¿Qué ocurre entre el informe preliminar y la homologación definitiva?
El informe preliminar de certificación acompaña a la solicitud de licencia y se evalúa documentalmente. Una vez otorgada la licencia —condicionada para una licencia general y provisional para una singular— el operador debe presentar los informes definitivos de certificación en el plazo de cuatro meses desde la notificación y obtener la homologación definitiva en seis meses. El informe definitivo cubre el sistema realmente en producción, así que la evidencia debe proceder del entorno vivo y no de los documentos de diseño.
¿Un cambio en el juego tras el lanzamiento exige automáticamente una nueva certificación?
No automáticamente, pero puede requerir autorización previa. Una modificación sustancial que afecte a un componente crítico necesita autorización antes de la producción, con un informe de certificación, y el DGOJ responde en el plazo de un mes. El operador también presenta un informe trimestral de cambios. Si el DGOJ considera sustancial un cambio en un componente crítico, puede exigir la homologación y la retirada hasta obtenerla. La regla de clasificación debería acordarse antes del primer parche.
¿Puede usarse un entorno de prueba en lugar del sistema de producción?
La resolución permite pruebas de integración en un entorno distinto de producción en el contexto de un cambio sustancial, pero la entidad de certificación debe certificar que los resultados son extrapolables al sistema de producción y analizar si las diferencias entre entornos afectan al resultado. El expediente debe describir el entorno de prueba y sus diferencias conocidas, no solo nombrarlo.
