Índice de contenidos
Claves de la noticia
- eSafety publica una revisión de Roblox, Fortnite, Minecraft y Steam que encuentra diferencias importantes en sus sistemas de protección infantil.
- Los datos abarcan de octubre de 2025 a marzo de 2026: las mejoras posteriores deben leerse por separado.
- Una tabla del informe permite medir una brecha de 17 puntos entre la detección de imágenes dañinas de Roblox y la revisión humana evaluada.
El regulador australiano eSafety ha pedido este 2 de octubre que cuatro grandes proveedores de videojuegos refuercen la protección de menores. Su nuevo informe no se limita a comprobar si tienen controles parentales: examina cómo detectan daños, identifican edades y reaccionan a las señales de abuso. La distinción importa porque una cuenta con restricciones y un sistema eficaz de moderación resuelven problemas diferentes.
Una fotografía de seis meses, publicada hoy
El comunicado oficial presenta hoy Playing it safe, elaborado a partir de respuestas obligatorias de Roblox, Epic Games, Mojang Studios y Valve. El período analizado va del 1 de octubre de 2025 al 31 de marzo de 2026. Son datos históricos sobre servicios utilizados por menores australianos, no una prueba realizada esta mañana ni una medición específica de usuarios españoles.
La documentación llegó mediante requerimientos emitidos el 1 de abril. El resumen de resultados distingue enfoques muy distintos: Epic revisaba las islas de Fortnite antes de hacerlas accesibles; Roblox empleaba varias herramientas para detectar experiencias perjudiciales después de su publicación. En Minecraft, algunos servidores de terceros quedaban fuera de la moderación proactiva de Mojang. Steam tenía revisión previa, pero dependía de denuncias de usuarios para localizar juegos publicados con material ilícito.
Esa comparación permite separar dos preguntas que una etiqueta de «juego seguro» suele mezclar: qué se controla antes de publicar una experiencia y qué se vigila cuando ya está disponible. Una revisión inicial puede impedir que aparezca cierto contenido; la vigilancia posterior necesita detectar cambios, comunicaciones y conductas que no existían al aprobarlo. Ninguna de esas fases puede deducirse simplemente del número de filtros anunciado.
El 51 % de Roblox necesita denominador
La tabla 11 del informe completo recoge la evaluación declarada por Roblox de Image Auto-mod. Su tasa de detección, o recall, era del 51 %, frente al 68 % de los revisores humanos comparados. Roblox explicó que utilizó una muestra aleatoria de imágenes etiquetadas por expertos. La misma tabla atribuye decisiones automáticas a aproximadamente el 98,5 % de las imágenes subidas.
| Sistema | Recall | Complemento hasta el 100 % |
|---|---|---|
| Image Auto-mod | 51 % | 49 % |
| Revisión humana comparada | 68 % | 32 % |
| Diferencia | 17 puntos porcentuales | 17 puntos porcentuales |
La última columna es un cálculo propio: 100 menos cada tasa publicada. Describe la fracción de positivos que no detectaría cada sistema en esa evaluación. No significa que el 49 % de todas las imágenes de Roblox sea dañino, ni mide cuántas llegaron a menores. Tampoco demuestra que sustituir automáticamente el filtro por humanos produjera esas cifras a escala real. La conclusión defendible es más concreta: una cobertura automática muy extensa coexistía con una capacidad de detección sensiblemente inferior a la referencia humana presentada.
Steam muestra un problema distinto al de Roblox
El comunicado señala que Valve no utilizaba comparación de huellas digitales para localizar material dañino ya conocido. También describe protecciones limitadas en Steam Chat: fuera de un detector de enlaces orientado principalmente a estafas, no empleaba herramientas proactivas para identificar esos daños en las conversaciones. Son observaciones del regulador sobre el período estudiado, no una afirmación de que cada conversación contuviera abusos.
El resumen añade que Valve no participaba en iniciativas de intercambio de señales entre proveedores. Aquí el fallo que merece atención no es un porcentaje bajo de un clasificador, sino la ausencia de ciertas capas de detección y colaboración. Comparar ambos casos con una única puntuación escondería esa diferencia: mejorar un modelo existente y desplegar un mecanismo inexistente requieren intervenciones distintas.
Agosto cambió el calendario de Roblox
Hay un antecedente posterior a los datos que modifica su lectura. El 20 de agosto, eSafety aceptó compromisos exigibles judicialmente de Roblox. Incluían impedir contactos de adultos desconocidos con menores sin consentimiento parental, reforzar la privacidad por defecto y recurrir a una auditoría independiente. La empresa disponía de tres meses para implementar cambios y sostenía que cumplía sus obligaciones.
Al cruzar las fechas, el informe publicado hoy llega dentro de ese plazo, después del compromiso y antes de que transcurran los tres meses. Por tanto, las deficiencias documentadas no permiten declarar cumplido ni incumplido el paquete de agosto. Sí justifican exigir resultados verificables: prometer una auditoría y demostrar una mejora son hitos separados. El seguimiento también tiene interés fuera de Australia, como muestra el antecedente del control europeo sobre Roblox.
La protección empieza por reconocer la cuenta infantil
Para las familias españolas, la comprobación práctica consiste en revisar qué cuenta utiliza el menor y qué comunicaciones tiene habilitadas. La documentación de Epic sobre cuentas limitadas ofrece un ejemplo: cuando un jugador declara una edad inferior al umbral aplicable, ciertas funciones quedan bloqueadas hasta el consentimiento parental. Puede seguir jugando a Fortnite, pero el chat de voz y el texto libre están desactivados mientras espera autorización.
El informe recuerda el límite de esa arquitectura: si la edad inicial depende de lo que escribe el usuario, declarar una edad adulta puede cambiar las protecciones que se aplican. Una familia puede comprobar ajustes y permisos de su cuenta; no puede verificar desde el menú la calidad de todos los filtros de la plataforma. La seguridad exige ambas capas: restricciones adecuadas para la cuenta y detección eficaz de daños dentro del servicio. La existencia de una no acredita el funcionamiento de la otra.
