Certificación de tragamonedas: qué prueban de verdad los laboratorios

Guides · 2026-05-23 · 5 min read · By CROCO Games

Qué cubre la certificación de RNG y RTP bajo pruebas al estilo GLI-19, qué garantiza y qué no garantiza un certificado, y qué exigir a un proveedor.

Un certificado de tragamonedas es la declaración firmada de un laboratorio de que una versión específica de un juego específico cumple un estándar técnico definido: lo más común, que su RNG sea estadísticamente sólido y que su RTP medido coincida con su RTP declarado. Es evidencia, no una garantía, y saber exactamente qué cubre (y qué deja fuera deliberadamente) es lo que separa la diligencia debida real de archivar un PDF que nunca leíste. Este artículo recorre lo que prueban los laboratorios acreditados bajo estándares al estilo GLI-19, los límites de lo que garantiza un certificado y los documentos específicos que exigir antes de integrar.

Qué prueban realmente los laboratorios

Las casas de pruebas independientes —GLI, iTech Labs, eCOGRA, BMM y otras— evalúan el software de los juegos frente a estándares publicados. GLI-19 es el estándar más referenciado para sistemas de juego interactivo; los criterios específicos de RNG se repiten también en GLI-11 y en las reglas de jurisdicción. El núcleo de lo que examinan:

• Aleatoriedad e imprevisibilidad del RNG. Baterías de pruebas estadísticas (distribución uniforme, independencia, ausencia de correlación serial) ejecutadas sobre muestras enormes para confirmar que los resultados no son predecibles ni sesgados.
• Escalado y mapeo del RNG. Que convertir números aleatorios en bruto en paradas de rodillo o cartas repartidas no introduce sesgo: un RNG correcto puede arruinarse con un mal mapeo.
• Verificación del RTP. Que el retorno simulado y/o medido a lo largo de millones de rondas coincide con el RTP declarado dentro de la tolerancia, para el modelo matemático exacto presentado.
• Integridad de las reglas del juego. Que la tabla de pagos, las funciones y la ganancia máxima se comportan como declara la pantalla de reglas, y que el juego no puede pagar fuera de su rango definido.
• Memoria crítica y recuperación. Que una desconexión a mitad de función se resuelve correctamente y no se estafa al jugador: relevante para Hold and Win y las rondas de crash en especial.

Un aprobado significa: en esta versión, la matemática es honesta y la aleatoriedad es real.

Qué NO garantiza un certificado

Aquí es donde los operadores se confían. Un certificado es estrecho por diseño:

• No cubre una versión distinta. La certificación es por versión de juego y por modelo matemático. Una versión del 96% y una del 92% se certifican por separado; una versión parcheada necesita volver a probarse. El certificado que te mostraron puede no coincidir con el binario que estás a punto de ejecutar.
• No garantiza que el juego tenga licencia en tu mercado. La certificación técnica y la aprobación jurisdiccional son puertas distintas. Un juego certificado por GLI puede seguir sin estar aprobado en Ontario, por ejemplo.
• No dice nada sobre la integración. El certificado cubre el juego; tu monedero, el flujo de sesión y los informes son una preocupación de certificación aparte (ver pruebas de integración más abajo).
• No es una promesa de justicia para el jugador en lenguaje llano. «Certificado» no significa «generoso»: un juego del 92% certificado está certificado para quedarse con el 8%. La certificación trata sobre la honestidad de la matemática declarada, no sobre lo favorable que sea para el jugador.
• No prueba que el juego esté ejecutando la versión certificada en producción. Eso requiere comparación de hash de versión y controles de plataforma, no solo un PDF.

Trata un certificado como necesario e insuficiente. Descarta una clase de riesgo (matemática amañada o rota) y calla sobre varias otras.

El conjunto de documentos que exigir

No aceptes «nuestros juegos están certificados» como respuesta. Pide detalles y compruébalos:

Los certificados se comparten con frecuencia bajo NDA en esta industria: eso es normal y no es una señal de alarma por sí mismo. El RNG de CROCO se prueba de forma independiente con certificados disponibles bajo NDA; la prueba es si un proveedor producirá de verdad el documento correspondiente a la versión específica cuando lo pidas, no si agita la palabra «certificado». Un proveedor que no puede mapear un certificado a la versión exacta que despliegas es el que debe preocuparte.

Leer un certificado: los campos que importan

Cuando llegue el PDF, no lo archives sin más: lee cinco campos. El nombre y la versión/ID de compilación del juego deben coincidir con lo que despliegas, carácter por carácter. El modelo de RTP debe coincidir con la variante que seleccionaste. El laboratorio y el estándar deberían ser una casa reconocida y un estándar con nombre (GLI-19, GLI-11, o el propio de la jurisdicción). La fecha de emisión debería ser lo bastante reciente para corresponder a la versión actual, no a una superada de hace dos años. Y la declaración de alcance te dice qué se probó: solo RNG, RNG más RTP, o la lógica completa del juego. Un certificado que cubre «RNG» pero no la matemática específica del juego es un documento más estrecho de lo que parece. Si alguno de estos cinco no cuadra, vuelve al proveedor antes de integrar; un desajuste aquí es exactamente lo que un auditor encontrará más tarde.

Cómo encaja la certificación en tu onboarding

Integra la certificación en una puerta de onboarding repetible en lugar de tratarla como algo puntual:

1. Preintegración: reúne los certificados de cada título y modelo de RTP, confirma el laboratorio y el estándar, comprueba las fechas contra las versiones actuales.
2. Comprobación de jurisdicción: contrasta cada juego con tus mercados con licencia; un juego certificado que no estás aprobado para ofrecer sigue siendo una infracción.
3. Certificación de integración: asegúrate de que la propia integración de la plataforma y el monedero está probada: muchas jurisdicciones certifican la conexión operador-proveedor, no solo los juegos.
4. Control de cambios: consigue un compromiso por escrito de que las versiones parcheadas se vuelven a certificar y de que se te notificarán los cambios de versión.
5. Verificación en producción: donde tu plataforma lo permita, verifica que la versión en ejecución coincide con la certificada.

Esta puerta lleva una tarde por proveedor y te salva de los dos peores desenlaces: enviar una versión no certificada a un mercado regulado, o descubrir durante una auditoría que tu papeleo no coincide con tus binarios.

Preguntas frecuentes

¿Un solo certificado cubre todas las variantes de RTP de un juego?

No. La certificación es por versión de juego y por modelo matemático, así que una versión del 96% y una del 92% se certifican por separado, y una versión parcheada necesita volver a probarse. Pide el certificado que corresponde a la versión y el modelo de RTP exactos que vas a desplegar, no una declaración general de que el portfolio está certificado.

¿Es una señal de alarma que los certificados solo se compartan bajo NDA?

No, los certificados bajo NDA son normales en esta industria. La prueba que importa es si el proveedor produce de verdad el documento correspondiente a la versión específica que despliegas cuando se lo pides. Un proveedor que no puede mapear un certificado a tu versión es el que debe preocuparte.

¿Un certificado técnico significa que el juego es legal en mi mercado?

No. La certificación técnica y la aprobación jurisdiccional son puertas distintas: un juego certificado por GLI puede seguir sin estar aprobado en un mercado como Ontario. Contrasta cada título con tus mercados con licencia y pide la lista de aprobaciones jurisdiccionales del proveedor junto con el certificado.

¿Qué debo comprobar cuando llega el PDF del certificado?

Lee cinco campos antes de archivarlo: el nombre y la versión o ID de compilación del juego, el modelo de RTP, el laboratorio y el estándar con nombre, la fecha de emisión y la declaración de alcance que dice qué se probó. Si alguno no cuadra con la versión que despliegas, vuelve al proveedor antes de integrar.

Conclusiones clave

• La certificación prueba que el RNG es sólido y que el RTP medido coincide con el RTP declarado para una versión y un modelo matemático específicos.
• No prueba la licencia de mercado, la solidez de la integración, lo favorable que sea para el jugador, ni que producción ejecute la versión certificada.
• Exige el certificado para la versión y el RTP exactos que despliegas, más el laboratorio, el estándar, la fecha y la lista de jurisdicciones: no un genérico «estamos certificados».
• Los certificados bajo NDA son normales; la prueba real es si un proveedor mapea un certificado a tu versión específica cuando se lo pides.
• Haz de la certificación una puerta de onboarding repetible que cubra juegos, jurisdicción, integración y control de cambios.

Colabora con CROCO Games