Este artículo ofrece un método para compras y gobernanza de proyectos. No constituye asesoramiento jurídico ni sustituye una revisión profesional de cumplimiento para un mercado objetivo.

La respuesta breve

«La API devuelve el juego», «el producto admite este idioma o moneda» y «existe un informe de laboratorio» no pueden demostrar por separado que un juego pueda lanzarse en un mercado objetivo. Una unidad de verificación fiable incluye, como mínimo:

mercado × juego × versión del juego × versión del modelo matemático × objeto y alcance de la certificación × moneda × idioma × versión de la topología de integración × alcance de la entidad operadora

Cuando cambian el juego, la versión, el modelo matemático, el RGS o agregador, la plataforma, la entidad operadora, la marca o el dominio, una conclusión anterior puede dejar de aplicar. El propósito de la matriz no es etiquetar el contenido como «legal en todo el mundo». Es vincular cada decisión de lanzamiento del proyecto con un objeto definido, un alcance definido, evidencia vigente y un responsable.

Por qué las seis dimensiones básicas no pueden fusionarse

Dimensión Pregunta que debe verificarse Error habitual
Mercado ¿Qué país o alcance regulatorio, entidad operadora, marca y dominio? Tratar «global» o «América Latina» como un alcance ejecutable
Juego ¿Cuáles son el código de juego del proveedor y el ID estable del registro de catálogo? Hacer coincidir solo el nombre mostrado o la apariencia
Versión ¿Cuáles son las versiones del juego, modelo matemático, RGS, agregador y plataforma? Tratar como equivalentes todas las versiones del mismo título
Certificación ¿Quién probó qué objeto, requisitos y alcance, y la evidencia sigue vigente? Tratar una norma de laboratorio o un informe como aprobación global
Moneda ¿Qué monedas y precisiones se aplican a visualización, apuestas, liquidación e informes? Tratar el soporte técnico de moneda como permiso de mercado
Idioma ¿Qué idiomas se aplican a reglas del jugador, ayuda, interfaz y comunicación operativa? Tratar una traducción como prueba de preparación para el mercado

El idioma, la moneda y la conectividad de API son dimensiones necesarias del producto y de la tecnología, pero no constituyen legalidad de mercado. A la inversa, la autorización de una entidad operadora en un mercado no demuestra que cada juego, versión o topología de integración cumpla los requisitos.

Un proceso de verificación por capas

Capa 1: conectividad técnica

Confirme las versiones de interfaz, identidades, modelo de monedero, devoluciones de llamada, rondas y recorrido de transacciones entre proveedor, RGS o agregador y plataforma, en el entorno especificado. La conectividad demuestra que los componentes probados pueden interactuar. Por sí sola no dice nada sobre derechos de contenido ni admisión en el mercado.

Capa 2: identidad y versión del contenido

Identifique un juego mediante el código de juego del proveedor, no por su nombre mostrado. Registre la versión del juego, la versión del modelo matemático, la compilación del cliente, las notas de cambios y la fecha de verificación. Una apariencia, clon o juego del mismo tipo no puede heredar otra conclusión sin evidencia.

Capa 3: idioma y moneda

Verifique por separado el texto de interfaz, las reglas del juego, el contenido de ayuda, la precisión de las apuestas y liquidaciones, los informes, la conciliación de registros y el tratamiento de excepciones. Superar una comprobación de idioma o moneda solo significa que superó el alcance funcional probado, no la dimensión de mercado.

Capa 4: objeto y alcance de la certificación

Registre el ID del informe o certificado, el organismo emisor o de pruebas, los requisitos, el objeto probado, la versión, la topología de integración, el estado vigente y los desencadenantes de una repetición de pruebas. Confirme que el organismo elegido está actualmente aceptado en el mercado objetivo y que su alcance reconocido cubre el objeto del proyecto.

Capa 5: alcance operativo y de mercado

Los responsables adecuados deben verificar las normas del mercado objetivo, la entidad operadora, la marca, el dominio, los derechos de contenido, las restricciones y los registros regulatorios vigentes. No sustituya una conclusión específica del proyecto por declaraciones genéricas de un proveedor, agregador o laboratorio.

Capa 6: decisión de producción del proyecto

Los responsables de tecnología, contenido, certificación, comercial y cumplimiento validan sus respectivas áreas. Solo cuando cada capa requerida cuenta con evidencia vigente, el registro del proyecto puede pasar a approved_for_project. Ese estado no es permanente ni global.

Una plantilla de matriz

Utilice una fila para una combinación precisa. Si un juego tiene dos modelos matemáticos o dos versiones de RGS, use dos filas.

Grupo de campos Campos sugeridos Regla de entrada
Alcance del proyecto market_code, operator_entity, brand, domain_scope Nombre el objeto específico; nunca escriba «global»
Identidad del juego provider_id, provider_game_code, catalog_record_id Vincule al catálogo mediante IDs estables
Versiones game_version, math_model_version, rgs_version, aggregator_version, platform_version Reevalúe el impacto después de cada cambio
Certificación certificate_or_report_id, test_body, requirements_ref, tested_object, scope, status Almacene la cobertura, no solo un PDF
Localización currency_code, language_code, rules_language Registre por separado la verificación técnica y de contenido
Evidencia evidence_ref, issued_at, last_verified_at, next_review_at Conserve la fuente y la fecha
Decisión decision_status, conditions, owner, approved_at Se aplica solo a esta combinación de proyecto

Utilice estados de decisión controlados como:

  • evidence_missing: falta un objeto o fuente críticos;
  • pending_review: el material ha llegado, pero el responsable no ha completado la revisión;
  • conditional: el trabajo puede continuar solo bajo las condiciones indicadas;
  • approved_for_project: la aprobación se aplica solo a la combinación de esta fila;
  • expired_or_recheck: la evidencia venció o un cambio activó una nueva revisión;
  • withdrawn: se retiró una decisión de proyecto y se conserva su motivo histórico.

Evite un único valor booleano sin alcance, como legal, certified o available.

Ejemplo de Brasil: traducir reglas de fuentes primarias en campos de la matriz

Los puntos siguientes demuestran el método de verificación. No constituyen una conclusión de admisión para ningún proyecto.

  • Las preguntas frecuentes técnicas de la Secretaría de Premios y Apuestas (SPA) del Ministerio de Hacienda de Brasil distinguen objetos de evidencia que pueden incluir el sistema de apuestas, RGS o agregador, la integración entre la plataforma y el RGS o agregador y el proveedor de juegos, juegos individuales y estudios en vivo. Registre cada objeto y conexión en vez de escribir solamente «plataforma certificada».
  • El punto 71 de las preguntas frecuentes de SPA trata la evidencia de conformidad para juegos, apariencias o juegos clon y los certificados de integración. También indica que SPA no proporciona una única lista pública de juegos certificados que sustituya la verificación del proyecto. Almacene el informe y su cobertura frente a cada juego o grupo aplicable.
  • El punto 94 de las preguntas frecuentes incluye componentes críticos, como RGS y agregadores, en el debate sobre la certificación de integración. Cuando un componente o versión cambie, reevalúe si la evidencia existente cubre la nueva topología.
  • El punto 84 de las preguntas frecuentes trata el idioma de la información proporcionada a los jugadores. El idioma pertenece a la matriz, pero el texto en portugués por sí solo no establece la entidad operadora, la versión del juego ni la topología de integración.
  • Compruebe tanto la lista vigente de organismos de certificación reconocidos por SPA como el alcance de cada organismo. Figurar en la lista no significa que cada informe emitido por el organismo cubra cada objeto o versión.

Ejemplos del Reino Unido y GLI: norma, pruebas y decisiones de mercado son diferentes

Las normas técnicas de juego remoto de la Comisión de Juego del Reino Unido identifican obligaciones para los licenciatarios aplicables, mientras que su Estrategia de Pruebas organiza los requisitos en torno a procedimientos de prueba, pruebas anuales de juegos, supervisión de RTP y actualizaciones mayores y menores. Esto ilustra por qué repetir pruebas tras un cambio de versión depende de las normas vigentes del mercado objetivo y de la categoría real del cambio. AG no puede proporcionar una única respuesta global universal.

GLI-19 puede ser una referencia de laboratorio o una aportación para conversaciones sobre pruebas. Por sí sola no equivale a admisión en una jurisdicción ni sustituye el alcance de reconocimiento de un regulador, la autorización de la entidad operadora, la versión concreta del juego o la evidencia de integración del proyecto. Almacene «norma técnica utilizada» por separado de «evidencia aceptada por el mercado objetivo».

Cambios que activan una nueva verificación

Como mínimo, mueva una fila a expired_or_recheck cuando cambie cualquiera de los siguientes elementos:

  • software del juego, modelo matemático, uso de RNG o reglas del juego;
  • RGS, agregador, plataforma o una versión de interfaz crítica;
  • modelo de monedero, flujo de transacciones, precisión de moneda o idioma de la información del jugador;
  • alcance del informe, reconocimiento del organismo de pruebas o vigencia de la evidencia;
  • entidad operadora, marca, dominio, derechos de contenido o normas del mercado objetivo.

Términos como «actualización mayor», «actualización menor» y «cambio de componente crítico» deben seguir las normas vigentes del mercado objetivo, el alcance del organismo de pruebas y los registros de cambios. No los clasifique únicamente a partir de un número de versión.

Nota de alcance no verificado para RTP 0–1000 Este intervalo numérico necesita definiciones de su unidad y significado, versión del modelo matemático, permisos de acceso, material de pruebas y certificación, mercado objetivo y presentación. No debe tratarse como una conclusión de RTP verificada para una versión de juego o de mercado, ni como una promesa sobre un resultado individual o retorno para el jugador.

Qué puede evaluarse actualmente en este sitio

  • Este artículo ofrece un método por capas para mercado, juego, versión, certificación, moneda e idioma.
  • El catálogo de juegos actual es una instantánea a nivel de nombre y no puede completar por sí solo la matriz.
  • El material público de la API ayuda a definir la topología de integración, pero los protocolos de producción, permisos y versiones del proyecto aún requieren confirmación.
  • Los ejemplos de SPA de Brasil, UKGC y GLI, así como la nota de alcance RTP 0–1000, no establecen certificación ni admisión de mercado para un proyecto.
  • Las fuentes primarias se citan únicamente para explicar los campos de la matriz y los pasos de verificación.

Límites que deben tenerse presentes

  • Esta página no promete que AG, un proveedor, un juego o una versión estén autorizados o certificados para un mercado.
  • Una norma de laboratorio, certificado, idioma, moneda, API conectada o catálogo de proveedor no prueba una admisión mundial.
  • Esto no constituye asesoramiento jurídico para Brasil, el Reino Unido u otra jurisdicción; las normas y alcances de reconocimiento vigentes deben volver a comprobarse en el momento de la decisión.
  • No se promete disponibilidad en tiempo real, fecha fija de lanzamiento, rendimiento, SLA ni alcance de suministro comercial.

Preguntas frecuentes

¿Por qué revisar la ruta de integración si el proveedor tiene un certificado de juego?

Un certificado de juego puede cubrir únicamente un objeto y una versión de juego especificados, mientras que la entrega también involucra un RGS, agregador y plataforma. Un mercado objetivo puede exigir evidencia de integración de sistemas o componentes, por lo que debe comparar el objeto del informe con la topología real.

¿El soporte de moneda e idioma locales significa que se puede atender al mercado?

No. Son dimensiones técnicas y de contenido. La entidad operadora, el alcance de marca o dominio, los derechos de contenido, la versión del juego, la certificación y las normas de mercado requieren confirmación independiente.

¿Puede utilizarse un informe GLI-19 en todos los mercados?

No puede suponerse. GLI-19 es una referencia de una norma de laboratorio. Que un mercado acepte la evidencia, qué objeto y versión cubre y si se requiere evidencia adicional depende de las normas vigentes y del alcance del proyecto.

¿Una actualización del juego invalida un certificado anterior?

El número de versión por sí solo no permite responder. Registre los cambios reales y, a continuación, use las normas del mercado objetivo, el alcance del informe y los requisitos del organismo de pruebas para decidir si se necesita evaluación de impacto, pruebas complementarias, reemisión o una nueva aprobación.

Lecturas relacionadas y próximos pasos

Antes de utilizar la sección «Contáctenos», prepare el mercado objetivo, el alcance de la entidad operadora o la marca, los juegos y versiones candidatos, la topología de integración, las monedas y los idiomas. AG podrá entonces organizar la evidencia específica del proyecto que aún requiera verificación. Proporcionar material o completar una prueba técnica no constituye una promesa de admisión de mercado.

Fuentes y alcance

Páginas relacionadas:

Fuentes regulatorias y de normas primarias:

La página RTS de UKGC mostraba una fecha de actualización del 29 de enero de 2026, su Estrategia de Pruebas del 31 de octubre de 2025 y el índice de preguntas frecuentes de SPA del 21 de mayo de 2026. El material citado era accesible el 9 de agosto de 2026. Las normas, los organismos reconocidos y los alcances cambian; vuelva a comprobar las fuentes primarias antes de tomar una decisión de proyecto.

¿Quiere convertir esta guía en un plan de proyecto?

Esta guía apoya la evaluación y no sustituye la validación técnica, contractual, de certificación ni de requisitos locales.

Contactar