Cómo OpenAI construyó un agente de datos con solo dos ingenieros y hoy atiende a miles de empleados
Imagina necesitar encontrar una información específica en un mar de 70.000 datasets, escribir queries SQL a mano, validar schemas de tablas y además armar gráficos presentables para mostrar los resultados. Hasta hace poco, esa era la rutina diaria de los analistas de OpenAI. Un simple comparativo de ingresos entre regiones geográficas y segmentos de clientes podía consumir horas de trabajo pesado. Hoy, ese mismo analista abre Slack, escribe una pregunta en inglés sencillo y recibe un gráfico listo en minutos. La herramienta detrás de esta transformación fue construida por apenas dos ingenieros en tres meses, tuvo un 70% del código escrito por inteligencia artificial y ahora es utilizada diariamente por miles de empleados de la empresa.
En una entrevista exclusiva con VentureBeat, Emma Tang, líder de infraestructura de datos de OpenAI, abrió los entretelones del sistema y explicó cómo funciona, dónde falla y qué señala sobre el futuro de los datos corporativos. La conversación, junto con el blog post oficial de la empresa sobre la herramienta, revela algo que toda organización va a tener que enfrentar pronto: el cuello de botella para tener empresas más inteligentes no son modelos mejores. Son datos mejores.
Una interfaz en lenguaje natural para 600 petabytes de datos corporativos
Para entender por qué OpenAI decidió construir este sistema, es necesario dimensionar el tamaño del problema. La plataforma de datos de la empresa abarca más de 600 petabytes distribuidos en 70.000 datasets diferentes. Solo encontrar la tabla correcta para responder una pregunta podía consumir horas del tiempo de un científico de datos experimentado. El equipo de Data Platform de Emma Tang, que forma parte de la infraestructura de la empresa y se encarga de sistemas de big data, streaming y la capa de herramientas de datos, atiende una base interna impresionante.
OpenAI tiene alrededor de 5.000 empleados actualmente. Más de 4.000 de ellos usan herramientas de datos proporcionadas por el equipo de Tang. Eso significa que más del 80% de la empresa depende directamente de esta infraestructura en su día a día.
El agente fue construido sobre GPT-5.2 y está disponible donde los empleados ya trabajan: Slack, una interfaz web, IDEs, el Codex CLI y la aplicación interna de ChatGPT. El usuario escribe una pregunta en lenguaje natural y recibe de vuelta gráficos, dashboards interactivos e informes analíticos completos. El equipo estima que cada consulta ahorra entre dos y cuatro horas de trabajo. Pero Tang se aseguró de destacar que la ganancia más difícil de medir es también la más importante: el agente les da a las personas acceso a análisis que simplemente no podrían realizar antes, sin importar cuánto tiempo tuvieran disponible.
Ingenieros, equipos de growth, producto e incluso equipos no técnicos que no conocen todos los detalles de los sistemas de datos y schemas de las tablas ahora pueden extraer insights sofisticados por cuenta propia 🎯
De comparativos de ingresos a debugging de latencia, un único agente lo hace todo
Tang presentó varios casos de uso concretos que ilustran la versatilidad del sistema. El equipo de finanzas de OpenAI usa el agente para comparar ingresos entre regiones geográficas y segmentos de clientes. En sus palabras, basta enviar la pregunta en texto simple y el agente responde con gráficos, dashboards y todo tipo de visualización.
Pero el poder real aparece en los análisis estratégicos con múltiples etapas. Tang describió un caso reciente en el que un usuario identificó discrepancias entre dos dashboards que rastreaban el crecimiento de suscriptores Plus. El agente de datos logró generar un gráfico mostrando, posición por posición, exactamente cuáles eran las diferencias. Resultaron ser cinco factores distintos causando la divergencia. Para un humano, esa investigación llevaría horas o incluso días. El agente lo resolvió en pocos minutos.
Product managers usan la herramienta para entender la adopción de funcionalidades. Ingenieros la usan para diagnosticar regresiones de performance — preguntando, por ejemplo, si un componente específico de ChatGPT realmente se volvió más lento que el día anterior y, si es así, qué componentes de latencia explican el cambio. El agente puede detallar todo y comparar con períodos anteriores a partir de un único prompt.
Lo que hace a este sistema especialmente diferente es que opera a través de fronteras organizacionales. La mayoría de los agentes de IA corporativos existentes hoy quedan aislados dentro de departamentos específicos — un bot para finanzas aquí, otro para recursos humanos allá. El agente de OpenAI corta horizontalmente toda la empresa. Tang explicó que el lanzamiento se hizo departamento por departamento, con memoria y contexto curados para cada grupo, pero que en determinado momento todo converge hacia la misma base de datos. Un líder senior puede combinar datos de ventas con métricas de ingeniería y analytics de producto en una única consulta.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Cómo Codex resolvió el problema más difícil de los datos corporativos
Encontrar la tabla correcta entre 70.000 datasets es, según la propia Tang, el mayor desafío técnico que su equipo enfrenta. Y es exactamente ahí donde Codex — el agente de programación de OpenAI — desempeña su papel más ingenioso.
Codex cumple tres funciones en el sistema. Primero, los usuarios acceden al agente de datos a través de Codex vía MCP. Segundo, el equipo usó Codex para generar más del 70% del código del propio agente, permitiendo que dos ingenieros entregaran el proyecto en tres meses. Pero la tercera función es la más fascinante desde el punto de vista técnico: un proceso diario y asíncrono en el que Codex examina tablas de datos importantes, analiza el código de los pipelines que alimentan esas tablas y determina dependencias upstream y downstream, propiedad, granularidad, claves de unión y tablas similares para cada una de ellas.
Tang explicó el proceso de forma directa: el equipo proporciona un prompt, Codex examina el código y responde con la información necesaria, que luego se persiste en la base de datos. Cuando un usuario pregunta sobre ingresos, el agente busca en una base de datos vectorial para encontrar qué tablas Codex ya mapeó para ese concepto.
Este proceso, llamado Codex Enrichment, es una de las seis capas de contexto que el agente utiliza. Las capas van desde metadatos básicos de schema y descripciones curadas por especialistas hasta conocimiento institucional extraído de Slack, Google Docs y Notion, además de una memoria de aprendizaje que almacena correcciones de conversaciones anteriores. Cuando no existe información previa, el agente recurre a consultas en vivo contra el data warehouse.
El equipo también clasifica patrones de consultas históricas por niveles de relevancia. Tang explicó que todo historial de queries incluye muchos comandos simples del tipo select star limit 10, que no son realmente útiles. Dashboards canónicos e informes ejecutivos — donde los analistas invirtieron esfuerzo significativo para determinar la representación correcta de los datos — se marcan como fuente de verdad. Todo lo demás se desprioriza.
El prompt que obliga a la IA a desacelerar y pensar antes de actuar
Incluso con seis capas de contexto sofisticadas, Tang fue notablemente honesta sobre la mayor falla comportamental del agente: exceso de confianza. Es un problema que cualquier persona que haya trabajado con large language models va a reconocer de inmediato.
Tang describió el escenario así: lo que el modelo suele hacer es sentirse demasiado confiado. Dice que encontró la tabla correcta y sale generando análisis de inmediato. Y ese enfoque apresurado es justamente el camino equivocado.
La solución vino a través de ingeniería de prompt que obliga al agente a permanecer más tiempo en una fase de descubrimiento. Tang explicó que, cuanto más tiempo pasa el agente explorando escenarios posibles y comparando qué tabla usar — simplemente invirtiendo más tiempo en la fase de descubrimiento — mejores son los resultados. El prompt funciona casi como orientar a un analista junior: antes de salir corriendo con un análisis, el sistema recibe instrucciones de hacer más validaciones sobre si esa es realmente la tabla correcta y verificar más fuentes antes de generar datos concretos.
El equipo también descubrió, mediante evaluaciones rigurosas, que menos contexto puede generar mejores resultados. Tang explicó que es muy tentador volcar todo lo que se tiene disponible y esperar que el modelo se desempeñe mejor. Pero en las evaluaciones, el equipo descubrió lo opuesto. Cuanta menos información proporcionas, siempre que esté curada y sea precisa, mejor el desempeño del agente.
Para construir confianza con los usuarios, el agente transmite su razonamiento intermedio en tiempo real, muestra qué tablas seleccionó y por qué, y proporciona enlaces directos a los resultados de las queries. Los usuarios pueden interrumpir al agente en medio del análisis para redirigirlo. El sistema también crea checkpoints del progreso, permitiendo retomar el trabajo después de fallos. Y al final de cada tarea, el modelo evalúa su propio desempeño. El equipo le pregunta al modelo cómo cree que le fue, si el resultado quedó bien o mal. Y según Tang, el modelo es sorprendentemente bueno evaluando su propia performance.
Guardrails simples que funcionan sorprendentemente bien
Cuando el tema es seguridad, Tang adoptó un enfoque pragmático que puede sorprender a empresas que esperan técnicas sofisticadas de AI alignment.
Su filosofía es directa: a veces necesitas guardrails hasta medio simples. El sistema posee control de acceso riguroso. Siempre usa el token personal del empleado, así que cada persona solo tiene acceso exactamente a lo que sus permisos ya le permitían antes. El agente funciona puramente como una capa de interfaz, heredando los mismos permisos que ya gobiernan los datos de OpenAI.
El agente nunca aparece en canales públicos — solo en canales privados o en la interfaz individual del usuario. El acceso de escritura está restringido a un schema temporal de pruebas que se borra periódicamente y no se puede compartir. Tang también enfatizó que el sistema no tiene permiso para escribir aleatoriamente en otros sistemas.
El feedback de los usuarios cierra el ciclo. Los empleados señalan resultados incorrectos directamente, y el equipo investiga. La autoevaluación del modelo añade una capa más de verificación. A largo plazo, Tang dijo que el plan es migrar hacia una arquitectura multi-agente, donde agentes especializados monitorean y asisten unos a otros. Pero incluso en su estado actual, el sistema ya avanzó bastante.
Por qué OpenAI no va a vender esta herramienta, pero quiere que tú construyas la tuya
A pesar del potencial comercial obvio, OpenAI confirmó a VentureBeat que no tiene planes de transformar su agente de datos interno en un producto. La estrategia es proporcionar los bloques de construcción y dejar que las empresas creen sus propias soluciones. Tang dejó claro que todo lo que su equipo usó para construir el sistema ya está disponible externamente.
En sus palabras: el equipo usa las mismas APIs disponibles públicamente — la Responses API, la Evals API. No existe un modelo fine-tuned. Simplemente usan GPT-5.2. Así que sí, cualquier empresa puede construir algo similar.
Este mensaje está alineado con la estrategia más amplia de OpenAI para el mercado corporativo. La empresa lanzó OpenAI Frontier a principios de febrero, una plataforma completa para que las empresas construyan y gestionen agentes de IA. Desde entonces, firmó alianzas con McKinsey, Boston Consulting Group, Accenture y Capgemini para ayudar a vender e implementar la plataforma. AWS y OpenAI están desarrollando en conjunto un Stateful Runtime Environment para Amazon Bedrock, que replica algunas de las capacidades de contexto persistente que OpenAI construyó en su agente de datos. Y Apple recientemente integró Codex directamente en Xcode.
Según datos compartidos con VentureBeat, Codex es usado por el 95% de los ingenieros de OpenAI y revisa todos los pull requests antes de ser mergeados. La base de usuarios activos semanales globales se triplicó desde principios de año, superando el millón. El uso general creció más de cinco veces.
Tang describió un cambio en la forma en que los empleados usan Codex que va mucho más allá de la programación. Según ella, Codex ya no es solo una herramienta de codificación. Equipos no técnicos lo usan para organizar ideas, crear presentaciones y generar resúmenes diarios. Una de sus gerentes de ingeniería configuró Codex para revisar sus notas todas las mañanas, identificar las tareas más importantes, traer mensajes de Slack y DMs, y redactar borradores de respuestas. El sistema está literalmente operando en su nombre de varias formas.
El prerrequisito nada glamuroso que va a definir quién gana la carrera de los agentes de IA
Cuando se le preguntó qué deberían aprender otras empresas de la experiencia de OpenAI, Tang no señaló las capacidades de los modelos ni la ingeniería de prompt sofisticada. Señaló algo mucho más mundano.
Herramientas que usamos a diario
Sus palabras fueron directas: la gobernanza de datos es extremadamente importante para que los agentes de datos funcionen bien. Los datos necesitan estar lo suficientemente limpios y anotados, y tiene que existir una fuente de verdad en algún lugar para que el agente pueda navegar.
La infraestructura subyacente — almacenamiento, cómputo, orquestación y capas de business intelligence — no fue reemplazada por el agente. Todavía necesita todas esas herramientas para hacer su trabajo. Pero funciona como un punto de entrada fundamentalmente nuevo para la inteligencia de datos, más autónomo y accesible que cualquier cosa que existía antes.
Tang cerró la entrevista con una advertencia para las empresas que dudan. Según ella, las organizaciones que adopten este tipo de solución van a cosechar beneficios muy rápidamente. Y las que no lo hagan se van a quedar atrás. La distancia entre los dos grupos va a aumentar. Las empresas que usen esta tecnología van a avanzar muy, muy rápido.
Cuando se le preguntó si esa aceleración preocupaba a sus propios colegas — especialmente después de una ola reciente de despidos en empresas como Block — Tang hizo una pausa y respondió: lo mucho que OpenAI logra hacer como empresa se aceleró significativamente, pero eso todavía no llega ni cerca de corresponder a las ambiciones de la compañía.
Las lecciones prácticas para quien quiera replicar este modelo
El caso de OpenAI trae aprendizajes valiosos para cualquier organización que esté pensando en construir agentes de datos internos. El primero y más importante es que la calidad de los datos importa más que la sofisticación del modelo. De nada sirve tener acceso al modelo más avanzado del mercado si tus datasets están desorganizados, mal documentados y sin una fuente de verdad clara.
El segundo aprendizaje es que equipos pequeños pueden entregar resultados enormes cuando están respaldados por herramientas de IA adecuadas. Dos ingenieros en tres meses, con un 70% del código generado por inteligencia artificial, produjeron un sistema que atiende a miles de personas. Esto redefine completamente lo que es posible en términos de velocidad de desarrollo.
El tercer punto es sobre la importancia de obligar al agente a desacelerar. La tendencia natural de los LLMs es responder rápido y con confianza, incluso cuando deberían estar investigando más. Invertir en prompts que incentiven una fase de descubrimiento más larga y cuidadosa puede ser la diferencia entre respuestas útiles y respuestas peligrosamente erróneas.
Por último, los guardrails no necesitan ser complejos para ser eficaces. Control de acceso basado en tokens personales, restricción de escritura, operación solo en canales privados y feedback continuo de los usuarios forman una capa de seguridad simple, pero que funciona en la práctica. La sofisticación puede — y debe — venir con el tiempo, pero no necesita ser un prerrequisito para empezar.
Estamos entrando en una era donde el rol del analista de datos cambia radicalmente. Menos tiempo escribiendo SQL y más tiempo formulando las preguntas correctas, interpretando resultados y garantizando que la infraestructura de datos esté saludable. El agente no reemplaza personas, pero transforma profundamente lo que se espera de ellas 🚀
