Primero, qué significa "entrenar" aquí
En este artículo "entrenar un modelo" no significa hacer fine-tuning de un transformer en tu notebook. Significa algo más previo y más difícil: producir las demostraciones que una máquina necesita para aprender a decidir en los casos donde la respuesta fácil es la equivocada.
Un modelo que ya sabe tomar decisiones básicas no necesita más datos de lo mismo. Lo que le falta son miles de ejemplos de criterio: instancias donde la acción correcta es detenerse, esperar, pedir permiso o no cobrar dos veces. Esos ejemplos casi nunca se generan solos, porque en producción pasan una vez cada varios meses y nunca quedan grabados con su causa.
Personnn TrainGames produce ese material. La definición del producto, en palabras de su sitio: "Microgames where you do a real job — a counter, a delivery drone, a factory floor, a store exit — and every decision is recorded as a demonstration: what the machine saw, what you chose, and what it cost."
El problema concreto para una empresa tech/SaaS
Tu equipo quiere un modelo que tome decisiones dentro de tu operación: el agente que prioriza tickets, la IA que opera un chat con escalamiento, el sistema que enruta, clasifica o autoriza. Y no quieres construir ese modelo desde cero con un equipo de ML que no tienes.
El camino habitual tiene tres cuellos de botella:
1. No tienes los datos de los casos difíciles
Los casos que enseñan criterio (un cliente que pide algo que no debería, una alarma que ignoraste y después quema un brazo, un cobro duplicado) son raros por definición. No vas a esperar un año juntándolos en producción.
2. Recopilar datos reales tiene costos que no quieres pagar
Si las demostraciones vienen de operaciones reales, implican datos de clientes, presión operativa y una vez que ocurrió el error. Un dato de entrenamiento que llega tarde sirve poco.
3. Sin formato, los datos no sirven
Grabar lo que hizo un operador no basta. Lo que la máquina necesita es la secuencia completa: qué vio antes de decidir, qué eligió hacer y qué costó esa decisión, incluso las consecuencias que llegaron después. Sin el "qué costó" pegado a la causa, el modelo aprende a acertar sin aprender por qué.
Cómo funciona TrainGames en la práctica
Cuatro microjuegos, cuatro oficios reales
La suite tiene 4 juegos (dato del sitio de TrainGames, consultado el 27 de octubre de 2026):
| Juego | El trabajo que haces |
|---|---|
| El Turno | Un robot detrás del mostrador. Ocho clientes, uno con una condición particular. |
| El Dron | Una entrega a través de la ciudad. Aterrizar significa ver, pero hay cosas que no se deben ver. |
| La Fábrica | Tú eres el Personnn que corre la planta. Ocho horas, una sola máquina que no puede fallar. |
| El Guardia | La salida de un supermercado. La puerta de alarma suena, la radio susurra. |
Cada turno se juega en el navegador y se publica como turno del día (por ejemplo, /traingames/turno-20261027). No necesitas cuenta: el sitio indica "sin cuenta / nada sale de tu navegador".
La decisión es tuya y la consecuencia viene con su causa
En El Dron, el sitio reporta 60 decisiones por segundo y un mapa de 168 edificios y 3 zonas. La dificultad no es mover el dron: es que cada decisión tenga un costo asociado.
La regla de diseño que hace esto útil es explícita: "cada consecuencia llega con su causa escrita al lado". Si ignoras la alarma de las 10:00 y no pasa nada, el juego no te deja creer que fuiste afortunado: a las 12:00 se quema el brazo y el registro dice qué decisión lo causó.
Y el reverso también está diseñado: "lo que no alcanza a pasar antes del cierre no desaparece: queda para el turno de mañana". Las consecuencias tardías se acumulan en el turno siguiente.
La trayectoria: el formato que las máquinas aprenden de
Cada partida es una demostración. El sitio lo define así: "It's the format machines learn from".
Cada registro es una trayectoria con tres partes:
- Lo que vio — la observación: qué estaba delante de ti justo antes de decidir (lo que dijo el cliente, la altura del dron, las unidades contra la meta).
- Lo que hiciste — la acción, siempre de una lista cerrada. El sitio lo explica así: "Always from a closed list. What's not on the list, the robot can't do it: that's how you bound a machine".
- Lo que costó — la consecuencia, con su causa escrita al lado.
Al terminar puedes descargar la trayectoria como archivo y repetirla al milímetro. Ese es el artefacto: no una conclusión ni un reporte, sino la secuencia de decisiones con sus consecuencias.
Por qué esto le sirve a una empresa tech/SaaS
Produces demostraciones sin operar tu producto real
No necesitas interrumpir producción, no necesitas datos de clientes, no necesitas esperar a que ocurra el error. La operación ocurre en el microjuego.
El material es formato de entrenamiento, no un reporte
La trayectoria es la unidad que consume un pipeline de entrenamiento o un modelo existente. Tu equipo de producto y de operaciones puede generar ese material sin depender de un equipo de ML, y sin saber si va a terminar en un modelo o en un sistema de reglas: el registro es el mismo.
Reproducible y auditable
Como el juego corre con reglas fijas, dos partidas del mismo día son comparables. Eso permite medir criterio antes y después de un cambio, y comparar el desempeño de tu equipo entre turnos.
Sin fuga de datos
El sitio es explícito: "nothing leaves your browser", con 0 datos enviados y 0 veces la IA decide. El juego corre en tu navegador y, al final, descargas tú la trayectoria. Nada se envía a menos que tú decidas compartirlo.
"Simula tu empresa": del microjuego a tu operación
TrainGames no se queda en los cuatro juegos. El sitio ofrece la ruta "Simulate my company" (disponible en /partners), que describe el proceso completo:
"We simulate your operation with the hard situations that actually happen, your team plays them, and their decisions become the bar a Personnn has to meet before touching your operation."
Ese es el encaje para una empresa tech/SaaS: defines tu operación, se simulan los escenarios difíciles reales, tu equipo juega, y las decisiones de tu equipo quedan fijadas como la vara que cualquier IA debe cumplir antes de operar en tu nombre.
Guía de implementación: 5 pasos para tu empresa tech
Paso 1: Define la decisión que quieres transferir
No "IA para clientes" en general. Una decisión concreta y repetible: qué hacer cuando el cliente pide algo fuera de política, cuando la alarma se activa, cuando el pago está duplicado. Sin esa decisión clara, no hay demostración posible.
Paso 2: Identifica el microjuego más cercano
Los cuatro juegos cubren mostrador, entrega, planta y salida con alarma. Si tu operación se parece a alguno, parte por ahí. Si no, el punto de partida es "Simulate my company" con tu equipo.
Paso 3: Haz jugar al equipo, no al diseñador
El valor está en el criterio de tus operadores, no en la calidad de un anotador. Juega el turno completo, incluso los turnos donde no pasa nada: los casos que nosticks también son parte del set.
Paso 4: Descarga y consolida las trayectorias
Cada partida termina en un archivo descargable. Consolídalos en un corpus de demostraciones: son tu dataset, con la ventaja de que está etiquetado con consecuencias y causas desde el origen.
Paso 5: Define la vara antes de que la IA toque producción
Con el set de demostraciones en la mano, defines el criterio de aceptación: qué decisiones la IA puede repetir, cuáles debe consultar y cuáles no debe tomar sola. Esa vara sale de tu equipo, no de un benchmark genérico.
Qué NO hace TrainGames (para no prometer de más)
- La IA no decide nada. El sitio reporta 0 veces: la IA decide. Lo que pasa lo deciden reglas fijas, iguales para todos los que juegan ese día. Un modelo puede después darle voz a los personajes, pero nunca decidirá el resultado.
- No es fine-tuning. TrainGames produce el material de entrenamiento (trayectorias), no el modelo final. El entrenamiento del modelo es un paso posterior, con el pipeline que uses.
- No es un simulador de tu producto. Es un conjunto de microjuegos con reglas fijas que generan demostraciones de criterio. La correlación con tu operación se construye en "Simulate your company".
- No saca datos de tu sistema. No se conecta a tu SaaS ni captura tráfico de usuarios.
Fuentes y alcance de lo verificado
Todo lo anterior sale de la landing oficial del producto (personnn.com/traingames, consultada el 27 de octubre de 2026), que es la fuente primaria de estas afirmaciones: los 4 juegos, las 60 decisiones por segundo de El Dron, los 168 edificios y 3 zonas, los 0 datos enviados, las 0 veces que la IA decide, la definición de trayectoria y la oferta "Simulate my company".
Las cifras de mercado sobre IA aplicada o densidad de incidentes no se usan en este artículo porque no son necesarias para explicar el producto y no son verificables en fuente primaria.
Próximos pasos
Si tu empresa tech/SaaS quiere un modelo propio que sepa cuándo detenerse, y no tiene equipo de ML, empieza por definir una decisión concreta y probar el turno del día. Es sin cuenta y nada sale de tu navegador.
Fuente primaria: sitio de Personnn TrainGames (personnn.com/traingames), consultado el 27 de octubre de 2026. Juegos "El Turno", "El Dron" (personnn.com/traingames/dron-20261027), "La Fábrica" y "El Guardia". Ruta "Simulate my company" en personnn.com/partners.