La crisis de datos en IA: pruebas con Simula, Euphan y Hermes

La crisis de datos en IA: pruebas con Simula, Euphan y Hermes

El artículo que me hizo detener todo lo que estaba haciendo la semana pasada no trataba sobre un nuevo modelo revolucionario. No era una filtración de benchmarks. Ni siquiera fue un anuncio, técnicamente hablando: se trató de una publicación de investigación de Google con un título tan insulso que la mayoría simplemente pasó de largo. “Orquestando conjuntos de datos sintéticos con razonamiento.” Yo casi hago lo mismo.

Pero entonces leí una frase que se me quedó grabada durante tres días: los modelos entrenados con datos sintéticos, en ocasiones, superaron a aquellos entrenados con conjuntos de datos reales. No igualaron. Superaron. En dominios especializados —ciberseguridad, razonamiento legal, medicina— donde los datos “reales” están bloqueados por leyes de privacidad o son demasiado costosos de recolectar, un equipo de Google construyó un sistema capaz de razonar hasta generar datos de entrenamiento mejores que los originales.

Ese artículo —que presentó un framework llamado Simula— constituye la mitad de lo que quiero desglosar en este post. La otra mitad son los lanzamientos recientes de OpenAI en el mismo periodo: una capa de interpretación de logs a la que los insiders llaman “Euphan”, y una plataforma de agentes persistentes bajo el nombre clave Hermes, que está esperando silenciosamente en los módulos preinstalados del frontend de ChatGPT, lista para activarse cuando levanten la bandera de lanzamiento.

Tres herramientas. Un cambio de fondo. Y ese cambio —el que sostengo es el fenómeno más relevante ahora mismo en IA— es que el verdadero cuello de botella ha cambiado. Ya no es el cómputo. Ni siquiera el tamaño de los modelos. Es el pipeline de datos que alimenta al modelo, la capa de observabilidad que supervisa al agente y el runtime que mantiene vivo al agente entre sesiones. Los tres están rotos. Los tres están siendo arreglados, simultáneamente, por los dos laboratorios que más perderían si no lo hicieran.

Esto es lo que descubrí al analizar cada uno: qué es realidad, qué es vaporware y qué significa esta combinación para cualquiera que construya sobre estos modelos en 2026.

Por qué la crisis de datos es peor de lo que la mayoría de los desarrolladores percibe

La narrativa convencional sobre el progreso de la IA es una narrativa de escalado. Modelos más grandes, más parámetros, más computación, mejores resultados. Esa historia funcionó hasta hace aproximadamente un año. Luego, algo cambió, y nadie en la prensa generalista realmente lo advirtió.

Los equipos que entrenan modelos frontera se quedaron sin internet de calidad. No en cantidad: sigue habiendo mucho texto en la red. Pero la relación señal-ruido de lo que queda por raspar se ha desplomado. El texto de alta calidad fue consumido en sesiones de entrenamiento anteriores. Lo que permanece es duplicado, generado por máquina o demasiado superficial para enseñarle algo a un modelo que no sepa ya.

Para los modelos de chat de propósito general como GPT, Gemini y Claude, esto se traduce en rendimientos decrecientes a medida que escalan. Cada duplicación de tokens de entrenamiento produce una mejora más pequeña que la anterior. La curva está cambiando de forma.

En los dominios especializados, el problema es estructuralmente diferente y mucho más grave. Si quieres entrenar un modelo que realmente sea bueno en razonamiento de ciberseguridad, necesitas datos que representen la taxonomía real de ataques, actores de amenazas, clases de vulnerabilidades y estrategias de mitigación. Esos datos existen, pero están fragmentados entre fuentes propietarias de inteligencia de amenazas, informes de incidentes cerrados y el conocimiento tácito de analistas senior que jamás lo documentarán.

¿Razonamiento legal? Sellado bajo privilegio, protegido por muros de pago o enterrado en jurisprudencia específica de jurisdicciones que ninguna fuente ha logrado agregar de forma limpia.

¿Medicina? La HIPAA existe por buenas razones. Los datos con los que querrías entrenar son exactamente los que no puedes usar legalmente a gran escala.

Esto lo he vivido en primera persona. Cuando he intentado que los modelos generalistas razonen con cuidado sobre vulnerabilidades de seguridad en frameworks específicos, producen respuestas con apariencia de confianza que se desmoronan bajo auditoría. No porque los modelos sean deficientes, sino porque los datos con los que fueron entrenados no cubren el terreno real. Aprendieron la versión Wikipedia de la ciberseguridad, no la versión en la que trabaja un pentester profesional.

Este es el muro. Y la forma de rodear ese muro — aquello en lo que cada laboratorio serio de IA ha estado trabajando durante dos años — es con datos sintéticos. Pero no la versión 2023 de datos sintéticos, que básicamente consistía en "pedirle a GPT-4 que escriba más ejemplos de entrenamiento y rezar para que funcione". Hablamos de la versión 2026, que es lo que representa Simula.

Simula: Cómo es realmente la generación de datos con razonamiento como eje central

Lo confieso: cuando hojeé por primera vez el artículo de Simula, pensé que sería otra variación del patrón “LLM genera ejemplos sintéticos, luego un LLM los filtra”. Ese patrón existe desde 2023 y tiene un fallo bien conocido: el generador colapsa en una distribución estrecha de ejemplos que parecen diversos pero en realidad cubren solo una pequeña parte del espacio posible. El término técnico es colapso de modos (mode collapse), y es la razón por la que la mayoría de los flujos de datos sintéticos rinden silenciosamente por debajo de los datos reales, a pesar de generar millones de ejemplos.

Simula no es eso. La arquitectura es genuinamente diferente y ahí es donde surgen las mejoras de rendimiento más interesantes. Aquí está el mecanismo real, en el orden en que lo ejecuta el framework.

Primer paso: mapeo estructurado del dominio. Antes de generar nada, Simula construye una taxonomía jerárquica del dominio objetivo. Para ciberseguridad, esa taxonomía incluye tipos de ataques (phishing, inyección, cadena de suministro, ingeniería social, etc.), categorías de actores de amenaza (estados-nación, crimen organizado, hacktivistas, internos), clases de vulnerabilidades (desbordamiento de búfer, fallo lógico, condición de carrera, mala configuración), y estrategias de mitigación. Cada rama tiene subramas. La taxonomía es el mapa de lo que implica una cobertura completa.

Este paso por sí solo aporta más estructura que la mayoría de los flujos de datos sintéticos existentes. La mayoría de pipelines asumen que el modelo generador producirá ejemplos diversos de manera natural. No lo hará. Generará ejemplos sesgados hacia aquello que estuvo sobrerrepresentado en sus propios datos de entrenamiento.

Segundo paso: muestreo controlado. En lugar de dejar que el generador elija temas de forma aleatoria, Simula toma muestras de manera deliberada a través de la taxonomía. Si ciberseguridad tiene 400 nodos, el muestreador garantiza que cada nodo esté adecuadamente representado —incluyendo los casos raros y complejos que un muestreo aleatorio visitaría solo una vez cada diez mil ejemplos. Esta es la antítesis del colapso de modos. No puedes colapsar a una distribución estrecha si el muestreador te obliga explícitamente a cubrir todo el espacio.

Tercer paso: generación de metaprompts. Aquí Simula se vuelve interesante. El sistema no genera ejemplos de entrenamiento directamente. Genera prompts que luego generarán ejemplos de entrenamiento. Estos metaprompts incluyen restricciones de formato, dificultad, ángulo y profundidad de razonamiento. La capa de metaprompt introduce una variación que un sistema de generación directa no puede igualar, porque los propios metaprompts son diversos.

Piensa en la diferencia. Generación directa: “Escribe una pregunta y respuesta de ciberseguridad sobre inyección SQL”. Obtienes mil variaciones que son, esencialmente, la misma respuesta. Generación de metaprompts: “Crea veinte plantillas de prompts diferentes que cada una dé lugar a un ejemplo de entrenamiento de alta calidad sobre inyección SQL —una desde la perspectiva de un investigador de incidentes, otra como una revisión de código, otra como auditoría de cumplimiento, otra como informe red-team, otra como la primera exposición de un ingeniero junior, etc.” Ahora el generador produce ángulos diversos por diseño, no por accidente.

Cuarto paso: parametrización de la complejidad. Simula trata la complejidad como un eje independiente de la diversidad. Puedes generar ejemplos simples que abarquen toda la taxonomía, ejemplos complejos que recorran toda la taxonomía, o una mezcla deliberada. Los investigadores de Google informaron que ajustar el parámetro de complejidad al alza proporcionó hasta un 10% de mejora en benchmarks de razonamiento matemático —siempre y cuando el modelo generador fuera lo suficientemente robusto para gestionar dicha complejidad. Generadores débiles con complejidad elevada producían ejemplos plausibles pero erróneos a gran escala, lo que en realidad perjudicaba al modelo estudiante.

Ese es un matiz crucial. La complejidad es un multiplicador, no una solución. Multiplica la calidad del generador —en ambos sentidos.

Quinto paso: control de calidad con doble crítico. Cada ejemplo generado pasa por dos evaluadores. El primero pregunta “¿esto es correcto?” El segundo, por separado, pregunta “¿esto es incorrecto?” La formulación importa aquí. Si al mismo crítico le preguntas dos veces “¿esto es correcto?”, obtendrás respuestas correlacionadas. Plantear la segunda evaluación como una contradicción obliga a un razonamiento independiente. Las dos respuestas se combinan en una puntuación de validación. Los ejemplos que pasan ambos filtros sobreviven. Los que uno de los críticos considera correctos y el otro incorrectos se marcan para revisión. Esta estructura de dos preguntas es la que detecta los outputs plausibles pero erróneos que los sistemas de un solo crítico no captan.

El equipo probó este pipeline utilizando Gemini 2.5 Flash como modelo docente y Gemma-3 4B como estudiante, generando hasta 512,000 datos por dominio y evaluando en cinco dominios distintos. El resultado destacado —que los datos sintéticos igualaron o superaron a los datos reales en dominios especializados— se sostuvo en múltiples evaluaciones.

La advertencia honesta que incluye el artículo, que nadie en Twitter citó: no existe una configuración óptima única. La relación entre los “buenos” datos sintéticos y el rendimiento del modelo final es lo que los investigadores llamaron profundamente idiosincrática. Cada dominio requiere diferentes mezclas de complejidad, distintas profundidades de taxonomía, distintos pesos en los críticos. Simula te da los mandos. No te dice dónde ponerlos.

Pero el punto no es que Simula sea una solución mágica. El punto es que el paradigma ha cambiado. Antes la pregunta era “¿cuántos datos puedes recolectar?” Ahora la pregunta es “¿qué tan bien puedes diseñar los datos?” Y los ganadores de la próxima ola de IA especializada no serán los laboratorios con más scrapers. Serán los laboratorios con los mejores taxónomos.

Euphan: Por qué OpenAI construyó silenciosamente un visor de logs

Permíteme hacer una pausa aquí, porque la segunda herramienta en esta historia necesita un contexto que la primera no requería.

Si nunca has construido un sistema de IA estilo agente, probablemente el concepto de "log" te suene a algo que encontrarías en un panel de control de un centro de datos. Algo aburrido. Algo de lo que se preocupan los equipos de operaciones. Permíteme corregir esa impresión, porque es un error que les está costando tiempo real a quienes construyen.

Un agente que ejecuta incluso una tarea moderadamente compleja — por ejemplo, investigar un tema, extraer datos estructurados, redactar un borrador y publicarlo en algún lugar — genera un log que no se parece en nada a un log tradicional de servidor. Es un árbol anidado de llamadas a herramientas, respuestas de modelos, rastros de razonamiento, salidas intermedias, intentos de reintento, concesiones de permisos y transiciones de estado. Una sola ejecución de agente puede producir miles de líneas de JSON. La mayoría es ruido. Un pequeño porcentaje es la historia real de lo que hizo el agente y por qué.

Cuando ese agente se comporta mal — y todos lo hacen tarde o temprano — tu trabajo como desarrollador es encontrar el punto en ese log donde el razonamiento falló. En un log bien estructurado, eso es tedioso. En un volcado crudo de JSON, son horas de desplazamiento. He pasado noches enteras usando grep en logs de agentes intentando entender por qué una llamada a herramienta que debía ejecutarse no lo hizo, o por qué un modelo se inventó un parámetro que no estaba en el prompt.

Este es el espacio de problemas que OpenAI ha estado llenando discretamente. El nombre interno que circula es Euphan, aunque públicamente la compañía ha lanzado la mayor parte de la funcionalidad a través del dashboard de trazabilidad del Agents SDK y la nueva interfaz workspace-agents en ChatGPT. Como sea que lo llames, el sistema subyacente hace una tarea específica e importante: toma logs crudos de agentes y los convierte en algo que un humano puede leer rápidamente.

Así es como funciona en la práctica:

• Cronologías estructuradas y limpias. En lugar de JSON anidado, obtienes una secuencia lineal de pasos, cada uno con una etiqueta de rol clara (planificador, recuperador, invocador de herramientas, respondedor), una marca de tiempo y un resumen en una línea. Haz clic en cualquier paso para expandir y ver el detalle completo. Recorre la cronología para encontrar el punto de inflexión.
• Inspección de roles y herramientas. Cada llamada a herramienta muestra qué agente la invocó, qué parámetros se pasaron, qué devolvió la herramienta y cuánto tiempo tomó. Si una herramienta devolvió un error 429 de límite de tasa cuarenta minutos después de iniciada la ejecución, la cronología lo resalta sin que tengas que buscarlo.
• Visibilidad del razonamiento en la toma de decisiones. Los agentes modernos emiten rastros de razonamiento — la justificación interna del modelo para elegir una acción sobre otra. Una interfaz de log legible presenta esos rastros como anotaciones en línea en la cronología, para que puedas ver no solo qué hizo el agente, sino por qué creyó que era la acción correcta.
• Edición directa del log. Esta es la función que más me sorprendió. Puedes editar una entrada del log, guardar el estado modificado y reproducir la ejecución desde ese punto en adelante. Es como un git rebase para el historial del agente. No he visto esta función implementada de manera limpia en ningún otro lado.
• Filtrado, búsqueda y consultas de metadatos. Cuando lidias con ejecuciones que duran horas y miles de pasos, grep no es suficiente. Necesitas consultas estructuradas. "Muéstrame todas las llamadas a herramientas con status != 200." "Muéstrame los rastros de razonamiento donde la confianza cayó por debajo de 0.6." Esa capa está presente.

La razón por la que sigo regresando a esta herramienta, aunque es menos llamativa que un nuevo modelo de frontera, es que resuelve un problema real al que me enfrento cada semana. Cuando construí mi propio stack de agentes usando el Anthropic Agent SDK, la parte más difícil no fue escribir el agente. Fue depurar el agente cuando se comportaba mal. Terminé construyendo un visor de logs casero en una base de datos de Notion porque no soportaba seguir leyendo JSON crudo. Si hubiera tenido algo como Euphan — o el equivalente para logs de Anthropic — habría lanzado la funcionalidad una semana antes.

Esto es infraestructura para desarrolladores. No es una función para el consumidor. No aparecerá en la presentación principal. Pero los equipos que lanzan agentes en producción verán las herramientas de interpretación de logs como el momento en que todo el flujo de trabajo se volvió manejable.

Ahora, la tercera pieza.

Hermes: El cambio de chatbot a compañero siempre activo

Hermes es el nombre en clave que se filtró de los entornos internos de OpenAI en las últimas semanas, y quiero ser cuidadoso aquí porque hay confusión de nombres en el mercado. La comunidad open-source ya tiene una herramienta llamada Hermes Agent de Nous Research — sobre la que he escrito combinándola con OpenClaw en un flujo de trabajo de dos agentes. El Hermes de OpenAI es algo completamente distinto. Mismo nombre, diferente empresa, diferente arquitectura. El contexto importa.

Hermes de OpenAI — al menos según los recursos frontend filtrados y los módulos precargados en la app web de ChatGPT — es una plataforma para agentes persistentes. No ejecutores de tareas únicas. No es “ejecuta esta tarea y devuelve el resultado.” Son agentes que defines una vez y que continúan existiendo entre sesiones, ejecutando tareas programadas, respondiendo a disparadores, manteniéndose conectados a herramientas externas y reportando cuando ocurre algo relevante.

Si eso te resulta familiar, es porque es la misma dirección arquitectónica en la que Anthropic avanzó con su superficie de agentes gestionados, y hacia donde una docena de empresas más pequeñas (incluyendo el Hermes Agent de Nous Research que mencioné antes) han estado construyendo. Los agentes persistentes no son una idea de un solo proveedor. Son el siguiente paso en consenso.

Lo que diferencia a OpenAI es su capacidad de distribución. ChatGPT tiene cientos de millones de usuarios. Cuando los agentes persistentes se integren en ese producto — no como un entorno aparte para desarrolladores, sino como una función que cualquier usuario Plus puede activar — el comportamiento por defecto de “chatear con una IA” cambiará de una forma que se sentirá común en retrospectiva y radical ahora mismo.

Por lo que espero que Hermes ofrezca cuando salga, basado en los recursos filtrados y en el patrón que han seguido todas las demás plataformas de agentes persistentes:

• Definiciones de agentes que persisten entre chats. Creas un agente una vez — le asignas un rol (“mi asistente de investigación”), un conjunto de habilidades, una lista de tareas, quizá algunos permisos de acceso. El agente es accesible desde cualquier conversación. No tienes que reinicializarlo cada vez.
• Ejecución programada y por disparador. El agente opera según su propio horario (cada mañana a las 7 a.m., resume las noticias nocturnas) o por disparadores (cuando aparece una nueva entrada en mi base de datos Notion, redacta una respuesta). Esto es el salto de lo reactivo a lo proactivo.
• Conexiones a herramientas que permanecen activas. Los agentes mantienen conexiones autenticadas a servicios externos — Gmail, Calendar, GitHub, Slack, cualquier cosa que permita el modelo de permisos. La herramienta no reautentica en cada ejecución. Ya está conectada.
• Memoria de largo plazo. Los agentes recuerdan ejecuciones previas, resultados anteriores, retroalimentación anterior. Si la semana pasada le dijiste al agente que prefieres resúmenes de tres viñetas en lugar de resúmenes en párrafo, el agente debería recordarlo siempre a menos que lo reinicies explícitamente.

No hay fecha de lanzamiento. La función sigue en pruebas internas, visible solo mediante inspección de recursos frontend. Dicho esto, OpenAI ha impulsado públicamente esta dirección — los agentes workspace se lanzaron en abril de 2026 para los planes Business, Enterprise y Edu, que comparten la mayoría de los supuestos arquitectónicos sobre los que se basaría Hermes. El patrón es claro. La pregunta es cuándo, no si.

Sin embargo, hay algo a lo que sigo regresando. Los agentes persistentes no funcionan sin las dos primeras piezas.

Los agentes persistentes necesitan capacidad especializada — un agente que opera continuamente en un dominio específico (investigación legal, monitoreo de seguridad, análisis financiero) necesita un modelo entrenado con datos de ese dominio. Los modelos generalistas fracasan en tareas especializadas de formas que se agravan cuando el agente opera sin supervisión. Ese es el problema de Simula.

Los agentes persistentes necesitan observabilidad — un agente operando 24/7 produce órdenes de magnitud más registros que un agente basado en sesiones. Sin una herramienta como Euphan, depurar un agente persistente en producción supone horas revisando logs cada vez que algo sale mal. Ese es el problema de Euphan.

Los agentes persistentes necesitan entorno de ejecución — que es lo que proporciona Hermes en sí mismo.

No se puede lanzar solo la tercera pieza. Las tres deben funcionar juntas o toda la pila colapsa por su propio peso. Y esto me lleva a lo que realmente quiero que te lleves de este artículo.

Qué significa realmente esta combinación para los desarrolladores

Toma perspectiva por un momento. Lo que estamos viendo, en tiempo real, es que toda la cadena de desarrollo de IA se está reconstruyendo desde la capa de datos hacia arriba.

La capa de datos se está reconstruyendo con sistemas como Simula, donde la generación sintética con razonamiento y muestreo basado en taxonomía produce datos de entrenamiento mejores que los que se pueden extraer de la web.

La capa de observabilidad se está renovando con herramientas de interpretación de logs como Euphan, donde rastros desordenados de múltiples agentes se convierten en líneas de tiempo comprensibles que realmente puedes depurar.

La capa de runtime se está rehaciendo con plataformas de agentes persistentes como Hermes, donde los agentes dejan de ser tareas de una sola vez y pasan a ser compañeros de equipo de larga duración.

Cada una de estas innovaciones tiene importancia por sí sola. Pero es la combinación lo que realmente importa.

Si estás construyendo algo serio sobre estos modelos en 2026 —un producto SaaS, una herramienta interna, un pipeline de contenido, una automatización—, aquí tienes la implicación práctica. Debes dejar de asumir que el cuello de botella es el modelo. Revisa tus suposiciones frente a estas tres preguntas:

1. ¿Mi caso de uso es lo suficientemente especializado como para que un modelo de propósito general rinda por debajo de lo esperado? Si la respuesta es sí, la solución no es cambiar al modelo más nuevo de frontera. La solución es esperar un modelo especializado entrenado con datos al estilo Simula, o construir uno tú mismo con generación sintética basada en tu propia taxonomía.
2. Cuando mi agente se comporta de forma anómala, ¿cuánto tardo en averiguar la causa? Si la respuesta es “horas” o “normalmente reinicio y espero lo mejor”, lo que necesitas es mejor observabilidad, no un mejor agente. Comienza a adoptar herramientas de interpretación de logs ahora, aunque sean primitivas, porque su valor aumenta con el tiempo.
3. ¿Estoy reconstruyendo el estado en cada sesión? Si todavía ejecutas agentes como conversaciones de chat puntuales, estás quedándote atrás. Comienza a diseñar para la persistencia incluso antes de que Hermes salga al mercado: desacopla el estado de tu agente de la interfaz de chat, almacénalo en un lugar duradero, y el coste de migración cuando lleguen las plataformas de agentes persistentes será prácticamente nulo.

Nada de esto es trivial. Yo mismo he estado enfrentando estas preguntas en mi propia stack —algunas de las cuales comenté en el post sobre entrenar habilidades de agentes de IA de forma autónoma— y las respuestas siempre me llevan hacia más infraestructura y menos magia. Más taxonomía, más registros (logs), más gestión del estado. Menos “lánzalo al modelo y veamos qué pasa”.

Lo que, pensándolo bien, es la misma lección que toda disciplina de ingeniería seria termina aprendiendo. La magia está en las partes aburridas.

Hablemos Claro: Dónde Creo Que Esto Falla

No quiero que te quedes con la impresión de que estas tres herramientas son la respuesta completa, porque no lo son. Esto es lo que señalaría como limitaciones genuinas y problemas abiertos.

Simula funciona porque los modelos subyacentes son lo suficientemente robustos. En el momento en que intentas aplicar la misma canalización con un generador más débil, la parametrización de complejidad amplifica los errores en lugar de la calidad. La mayoría de los equipos no tienen acceso a Gemini 2.5 Flash como modelo maestro. Qué aspecto tendrían las canalizaciones equivalentes a Simula con un presupuesto más ajustado es un problema aún sin resolver.

La interpretación de logs al estilo Euphan es tan buena como la estructura de los logs subyacentes. Si el framework de agentes que estás utilizando emite logs desordenados y sin estructura —y muchos aún lo hacen— ninguna capa de interpretación puede crear claridad a partir de basura. El propio formato del log debe diseñarse para la observabilidad desde el inicio.

Los agentes persistentes plantean una cuestión de seguridad para la que aún no existe una buena respuesta. Un agente que funciona 24/7 con conexiones autenticadas a tu Gmail, tu GitHub, tu calendario, representa una gran superficie de ataque. Si el razonamiento del agente puede ser manipulado —ya sea mediante una inyección de prompt en un correo entrante, o por un resultado de búsqueda contaminado— el daño potencial se extiende a toda la red autenticada. Todas las plataformas de agentes persistentes que he visto son conscientes de esto y ninguna lo ha resuelto por completo. Por eso las herramientas de seguridad para agentes de IA van a ser una categoría enorme, y por eso insisto tanto en ello.

El resumen honesto es que estas tres herramientas marcan la dirección a seguir, no el destino final. Los próximos dieciocho meses de desarrollo en IA se van a dedicar a descubrir cómo hacer que este stack funcione realmente de extremo a extremo en producción, para casos de uso que no se limiten a “genera un post de blog” o “resume un documento”. Trabajo real. Consecuencias reales. Exigencias reales de disponibilidad.

Y ese es exactamente el tipo de problema en el que quiero estar trabajando.

Lo que estoy observando a continuación

Estoy siguiendo tres aspectos específicos durante el próximo trimestre.

Primero, replicaciones open-source de Simula. El artículo es lo suficientemente detallado como para que un equipo motivado pueda reconstruir el pipeline fuera de la infraestructura de Google. Espero la primera implementación open-source seria en un plazo de 60 días, y quien lo logre de forma limpia se convertirá en la herramienta predeterminada para datos sintéticos de dominio especializado dentro del mundo open-source.

Segundo, estándares de interpretación de logs. Actualmente, cada framework de agentes tiene su propio formato de logs. El de OpenAI es diferente al de Anthropic, que es diferente al de LangChain, que difiere del de Nous Research. Esta fragmentación va a forzar algún tipo de estándar común de trazabilidad — probablemente algo basado en convenciones de OpenTelemetry — y el primer framework que logre una buena interoperabilidad ganará mucha aceptación entre los desarrolladores.

Tercero, la ventana de lanzamiento de Hermes. Le doy un 60% de probabilidad de que sea lanzado públicamente antes de finalizar el tercer trimestre de 2026, según lo avanzada que ya está la integración en el frontend. Si se lanza, el patrón de “agente siempre activo” pasará de ser algo de nicho para desarrolladores a convertirse en el estándar para cientos de millones de usuarios de ChatGPT en cuestión de semanas. Eso es un evento que redefine la categoría.

Presta atención a los tres. Probablemente, uno de ellos será la mayor noticia de IA del verano.

Aquel paper que mencioné al inicio — el paper de Simula que estuve a punto de pasar por alto — es la razón por la que ahora creo que el trabajo más importante en IA en 2026 no está sucediendo en la capa de modelos. Ocurre en el diseño de datos, la observabilidad y el runtime. Aburrido. Con forma de infraestructura. Enormemente trascendental.

Si solo lees una cosa de este post, relee esa frase. Luego revisa tu propio stack y pregúntate cuál de las tres capas es la más débil. Empieza corrigiendo esa. Todo lo demás vendrá después.

Preguntas Frecuentes

¿Qué es la generación de datos sintéticos en el entrenamiento de IA?

La generación de datos sintéticos es el proceso mediante el cual modelos de IA crean ejemplos de entrenamiento que no existían en el conjunto de datos original. Sistemas modernos como Simula de Google utilizan taxonomías basadas en razonamiento y validación dual de críticos para asegurar que los datos generados igualen o superen la calidad de los datos reales en dominios especializados. Para ver el mecanismo completo, consulta la sección de Simula arriba.

¿Por qué los datos sintéticos son mejores que los datos reales para dominios de IA especializados?

Los datos reales en dominios como ciberseguridad, legal y médico suelen estar protegidos por leyes de privacidad, fragmentados entre fuentes propietarias, o simplemente no existen en el volumen requerido para entrenamiento. Los datos sintéticos bien diseñados pueden cubrir toda la taxonomía del dominio —incluidos los casos raros— con calidad controlada. En los benchmarks de Simula de Google, los modelos entrenados con datos sintéticos superaron en ocasiones a los modelos entrenados con datos reales en tareas especializadas.

¿Qué es el colapso de modos en datos sintéticos y cómo se previene?

El colapso de modos ocurre cuando un modelo generador produce ejemplos repetitivos y restringidos que parecen diversos en la superficie pero solamente cubren una pequeña fracción de la distribución real. Simula lo previene muestreando a través de una taxonomía estructurada y utilizando metaprompts —prompts que generan prompts— para forzar variaciones genuinas en enfoque, formato y profundidad de razonamiento.

¿Cuándo saldrá la plataforma de agentes persistentes Hermes de OpenAI?

OpenAI no ha anunciado una fecha de lanzamiento para la función de agentes persistentes de Hermes. Recursos de frontend y módulos precargados detectados en la web app de ChatGPT indican un desarrollo activo, y funciones relacionadas como workspace agents ya se lanzaron en abril de 2026 para los planes Business, Enterprise y Edu. Según el patrón, parece probable un lanzamiento público de Hermes durante 2026.

¿Qué es un interpretador de logs de agentes de IA y por qué lo necesitan los desarrolladores?

Un interpretador de logs de agentes de IA es una herramienta que convierte logs crudos y anidados de agentes —llamadas a herramientas, trazas de razonamiento, reintentos, transiciones de estado— en líneas de tiempo estructuradas y legibles. La superficie tipo Euphan de OpenAI y el panel de monitoreo de Agents SDK muestran cada paso, el rol que lo ejecutó, las herramientas utilizadas y el razonamiento detrás de cada decisión. Sin esta capa, depurar un agente con problemas requiere desplazarse por miles de líneas de JSON sin procesar.

Colaboremos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

• Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de ciberseguridad): xcybersecurity.io