En muchas empresas, la conversación sobre IA suele centrarse en modelos cada vez más potentes. OpenAI, en cambio, ha puesto el foco en un cuello de botella bastante terrenal: el tiempo que se pierde buscando datos, entendiendo tablas parecidas y evitando errores silenciosos en consultas. En una entrada publicada el 29 de enero de 2026 por Bonnie Xu, Aravind Suresh y Emma Tang, la compañía cuenta cómo construyó un agente de datos interno para su propia plataforma, diseñado para que empleados de equipos muy distintos pasen “de pregunta a insight” en minutos, no en días, usando lenguaje natural como interfaz.
La escala explica la urgencia. Según la propia OpenAI, su plataforma de datos da servicio a más de 3.500 usuarios internos y almacena más de 600 petabytes repartidos en decenas de miles de conjuntos de datos. En un entorno así, localizar la tabla correcta puede ser como entrar en un hipermercado gigante a por “leche” sin saber si la buscas en refrigerados, en productos sin lactosa, en bebidas vegetales o en una marca concreta que alguien renombró la semana pasada. Esa ambigüedad se vuelve cara cuando hay decisiones de producto, finanzas o investigación esperando una cifra.
Por qué un agente y por qué “a medida”
OpenAI insiste en algo importante: no es un producto para vender, es una herramienta interna creada alrededor de sus permisos, su cultura de trabajo y su “lenguaje de pasillo”. El objetivo no es solo ejecutar SQL, sino reducir fricción en tareas que se repiten: diferenciar tablas casi idénticas, elegir filtros correctos (por ejemplo, incluir o excluir usuarios no logueados), entender relaciones entre tablas y evitar errores típicos de análisis como uniones muchos-a-muchos, filtros mal aplicados o nulos que cambian resultados sin avisar.
Aquí la metáfora útil es la de cocinar siguiendo una receta larga. Puedes tener ingredientes de sobra, pero si no entiendes qué hace cada paso, es fácil estropear el plato con un detalle pequeño: un “join” mal planteado funciona como echar sal dos veces porque la cucharilla era de otro tamaño. En una organización grande, ese tipo de fallo no solo es un bug: puede contaminar informes, debates y decisiones.
Cómo funciona: un compañero que entra por Slack, por web y hasta por el IDE
El agente se apoya en GPT-5.2 y se ofrece donde la gente ya trabaja: Slack, una interfaz web, dentro de IDEs, en la Codex CLI mediante MCP y también en la app interna de ChatGPT con un conector MCP. El detalle no es anecdótico: la adopción sube cuando la herramienta no te obliga a “mudarte” de entorno. Pedir datos desde Slack se siente como preguntar a alguien del equipo, con la diferencia de que el agente puede inspeccionar esquemas, ejecutar consultas y resumir hallazgos en el mismo flujo.
OpenAI describe un comportamiento clave: no sigue un guion rígido. Si un resultado intermedio “huele raro” —por ejemplo, una consulta devuelve cero filas por un filtro incorrecto— el agente intenta diagnosticar qué falló, ajusta el enfoque y vuelve a probar. Es una especie de “modo detective” que reduce la carga de iteración del usuario. En la práctica, se parece a cuando estás buscando un fallo en una hoja de cálculo y vas comprobando supuestos uno a uno, pero automatizado y con memoria contextual.
El corazón del sistema: contexto, contexto y más contexto
La idea central del post es que los modelos, por buenos que sean, se equivocan con facilidad si no están bien anclados. Para evitar estimaciones disparatadas o interpretaciones incorrectas de términos internos, el agente se construye sobre capas de contexto que se recuperan según la pregunta. OpenAI lo presenta como una pirámide, y tiene sentido: cuanto más cerca estás de la realidad de la empresa, más “peso” tiene la respuesta.
La primera capa se apoya en metadatos: nombres de columnas, tipos, linaje de tablas y patrones de uso en consultas históricas. Esto ayuda a inferir qué tablas se suelen unir y cómo se calculan métricas de manera habitual. La segunda capa introduce anotaciones humanas: descripciones curadas por expertos que añaden intención y advertencias que un esquema no revela. Es la diferencia entre leer “columna: status” y saber “este status cambió de significado tras el lanzamiento X”.
La tercera capa es especialmente interesante: Codex se usa para enriquecer el entendimiento a nivel de código. OpenAI sostiene que el significado real de una tabla “vive” en el pipeline que la genera, no en su forma final. Si una tabla parece igual que otra, el código puede revelar matices críticos: granularidad, claves primarias, frescura, exclusiones, reglas de negocio, alcance de tráfico. Dicho en sencillo: mirar solo la tabla es ver el plato servido; mirar el código es entrar en la cocina y entender por qué se cocinó así.
La cuarta capa suma conocimiento institucional desde herramientas como Slack, Google Docs o Notion, con ingestión y almacenamiento con permisos. Aquí entran lanzamientos, incidentes, nombres en clave y definiciones canónicas de métricas. La quinta capa es la memoria, pensada para capturar correcciones no obvias: filtros exactos para un experimento, condiciones que evitan sesgos, restricciones que no se deducen de esquemas. Y la sexta capa es el contexto en tiempo de ejecución: si falta información o está obsoleta, el agente puede lanzar consultas “en vivo” para inspeccionar tablas y validar suposiciones.
Todo eso se empaqueta en un proceso offline diario que normaliza señales y crea representaciones vectoriales con embeddings, recuperadas luego vía RAG (generación aumentada por recuperación). En la práctica, es como tener una biblioteca enorme y, en vez de recorrer pasillo por pasillo, pedirle a un bibliotecario que te traiga justo los libros y post-its relevantes para tu pregunta.
Mantener la confianza: evaluaciones como pruebas unitarias de analítica
Un agente que cambia con el tiempo tiene un riesgo claro: hoy funciona, mañana “deriva”. OpenAI lo aborda con un sistema de evaluación continua basado en la Evals API. La mecánica recuerda a pruebas unitarias: conjuntos curados de preguntas con una consulta SQL “dorada” que representa el resultado esperado. Se genera SQL desde la pregunta, se ejecuta, y se compara el resultado con el de referencia. No se queda en comparar texto: contempla que dos consultas diferentes pueden ser correctas si producen el mismo resultado relevante, y se apoya en un calificador que juzga equivalencia y variaciones aceptables.
Este enfoque es importante porque traslada el control de calidad del “me parece que está bien” a un marco repetible. Es la diferencia entre probar un puente con una inspección visual y someterlo a pruebas de carga cada vez que cambias una pieza.
Seguridad y permisos: el agente no abre puertas, solo sostiene el pomo
Otro punto que OpenAI recalca es el control de acceso. El agente opera como una capa de interfaz que hereda permisos: si un usuario no puede consultar una tabla, el agente tampoco. En caso de falta de acceso, lo señala o busca alternativas autorizadas. Esta filosofía de “passthrough” es clave para que la herramienta no se convierta en un atajo peligroso.
La transparencia también entra en el paquete: el agente muestra supuestos y pasos de ejecución, y enlaza a resultados subyacentes para que el usuario pueda verificar. En un contexto corporativo, esa trazabilidad es casi tan importante como la respuesta, porque permite debatir sobre hechos con un rastro auditable.
Lecciones de diseño: menos herramientas, objetivos claros y el código como fuente de verdad
Entre las lecciones que comparte OpenAI hay tres que funcionan como advertencias generales para quien quiera construir agentes internos. La primera: “menos es más” en herramientas disponibles; demasiadas funciones solapadas confunden al agente. La segunda: conviene guiar el objetivo, no dictar el camino; prompts demasiado prescriptivos empujan a rutas incorrectas cuando cambia un detalle del caso. La tercera: el significado de los datos está en el código que los produce, y capturar esa dimensión mejora drásticamente el uso seguro de tablas que, a simple vista, parecen idénticas.
Detrás de todo, el mensaje es práctico: un agente de datos no sirve solo para “hacer consultas por ti”, sino para encapsular conocimiento colectivo, reducir errores silenciosos y convertir la analítica en algo más accesible para equipos que no viven en SQL. La promesa no es magia; es ingeniería aplicada a un punto de dolor cotidiano, con memoria, contexto enriquecido y evaluación continua como pilares.