Faltaban diez minutos para que terminara su turno cuando el gerente a cargo del sistema de atención al cliente vio llegar ese correo de escalamiento.

Un cliente había preguntado por chat si podía consultar también el pedido de un amigo. El AI Agent de atención al cliente, recién lanzado por la empresa, respondió entregando el historial completo de pedidos y los datos de contacto de otro cliente distinto. El equipo de seguridad desactivó la función en menos de dos horas, y el área legal exigió un informe del incidente: ¿quién aprobó que este Agent saliera en producción? ¿Por qué tenía acceso a datos que no debía ver?

(El escenario anterior es ilustrativo, para describir un patrón que ya se observa en la industria; no corresponde a un caso real de un cliente específico.)

Esto no es una hipótesis alarmista. Bernard Marr, observador de estrategia empresarial y conductor de un podcast sobre negocios y tendencias tecnológicas, señala directamente que este tipo de incidentes ya ocurre en el mundo real: "Hemos visto Agents de IA borrar datos operativos críticos y filtrar información comercial que no debía compartirse, simplemente porque ciertas salvaguardas no estaban en su lugar, y terminaron entregando datos de clientes." En ese mismo episodio invitó a Masimo Merlo, de Elastic, para desmenuzar juntos la verdadera raíz de este tipo de fallas: no es que los modelos no sean lo suficientemente inteligentes, sino que la mayoría de las empresas ha pasado por alto una pieza llamada context engineering.

Crees que el problema es el modelo, pero en realidad es la base

Masimo va directo al grano: la fase experimental de la IA empresarial ya terminó. La mayoría de las organizaciones ya probó sus pilotos, y ahora enfrentan la brecha incómoda entre lo que la IA prometía y lo que realmente entrega.

Ubica la causa en una línea de tiempo más larga: el software empresarial se construyó, capa sobre capa, a lo largo de cuatro o cinco décadas: capa de datos, capa de contexto, capa de lógica de aplicación, capa de experiencia de usuario. Y esta vez, la IA está reorganizando todas esas capas al mismo tiempo. Si una empresa cree que basta con conectar el modelo a los sistemas existentes para que ocurra la magia, pronto descubrirá que sus flujos de datos nunca se diseñaron pensando en IA, y que su gobernanza no alcanza a seguirle el ritmo. Conectar un modelo muy capaz a una base que no está ordenada no produce transformación: produce, en palabras de Masimo, una versión más segura de sí misma del mismo problema de siempre. Lo que la IA hace muy bien es entregar respuestas equivocadas con mucha eficiencia cuando se le alimenta con información incorrecta.

Si la IA es el cerebro, el contexto es la memoria

Entonces, ¿qué resuelve exactamente el context engineering? Masimo ofrece una analogía que escuchó en algún lugar y le parece muy acertada: si la IA es el cerebro, el contexto es la memoria. Por rápido que procese un cerebro, sin memoria —sin experiencia, sin camino recorrido— no puede decidir qué hacer en el momento presente.

Lo mismo aplica a las empresas: un modelo entrenado con datos públicos de todo el mundo no entiende automáticamente a tu empresa; no conoce a tus clientes, tus políticas, lo que te ha pasado antes, tu tolerancia al riesgo ni tus objetivos. Solo procesa datos y entrega una respuesta que suena razonable, pero que en el fondo es genérica. El context engineering es precisamente la disciplina de convertir "conectar los datos correctos con el modelo correcto en el momento correcto" en un método sistemático: definir qué puede ver el modelo y construir barreras de contención para que lo que produce sea confiable y accionable.

De molesto a peligroso: cuando la IA empieza a decidir por su cuenta

Masimo subraya un punto de inflexión: cuando la IA solo responde preguntas, equivocarse es apenas una molestia que puedes corregir en el momento; pero cuando la IA se convierte en un Agent capaz de recomendar, decidir y actuar por su cuenta, ese mismo tipo de error cambia por completo de naturaleza y puede transformarse directamente en un riesgo comercial, una exposición regulatoria o un incidente de seguridad.

Pone dos ejemplos concretos. El primero es un Agent dentro de un centro de operaciones de seguridad (SOC): necesita ver inteligencia de amenazas en tiempo real, el historial de incidentes previos y protocolos de escalamiento claros; sin cualquiera de estos elementos, su criterio se distorsiona. El segundo es un Agent de detección de fraude: no basta con que vea la transacción actual, también necesita conocer el historial del cliente, las políticas aplicables, el umbral de riesgo que la organización tolera, quién tiene autoridad para actuar y qué rastro de evidencia debe quedar después. Quitarle todo eso pero darle poder total de acción no produce un Agent con menos capacidad: produce un pasivo real —exactamente la lógica detrás del incidente del Agent de atención al cliente con el que abrió este artículo.

Por qué mover todos los datos junto al modelo es una trampa

Siguiendo esta lógica, la conversación pasa al papel de los datos en tiempo real. Masimo es directo: un sistema de IA solo es tan actual como los datos que puede ver. Si sus decisiones se basan en una versión del mundo de hace dos años o más, el resultado no es simplemente menos útil: es sencillamente incorrecto.

La reacción instintiva de muchas empresas es centralizar los datos y moverlos junto al modelo, pero Masimo considera que esto es poco realista en la práctica: el volumen de datos empresariales es demasiado grande, demasiado sensible y está demasiado disperso como para soportar movimientos constantes. Lo más inteligente es dejar que la IA acceda, de forma gobernada y confiable, a los datos donde ya están almacenados, en lugar de mudar los datos mismos.

Esto también explica por qué la búsqueda, o retrieval, no quedó obsoleta con la llegada de la IA generativa, sino que se volvió aún más crítica. En los primeros días, el mercado se preguntaba: si el modelo puede generar respuestas directamente, ¿para qué se necesita la búsqueda? Masimo dice que ocurrió justo lo contrario: la capa de recuperación y contexto es la infraestructura que encuentra la información correcta, entiende su significado y la entrega en el momento en que la IA la necesita; es lo que determina si el resultado de la IA es realmente confiable o simplemente suena convincente.

Un buen Context Engineering no empieza por elegir el modelo

Entonces, ¿cómo se hace esto en la práctica? Masimo propone un criterio muy concreto: el error más común en los proyectos de IA es tratar el paso a producción como un problema de modelo, cuando casi siempre es un problema de flujo de trabajo y de datos. Las organizaciones que realmente lo hacen bien no preguntan primero qué modelo deben usar, sino qué necesita ver este modelo: parten del flujo de trabajo, entienden de qué datos depende ese proceso, definen los permisos con claridad y dejan un rastro auditable de todo el proceso para poder ver qué hace realmente la IA en producción. Sin esa base, dice Masimo sin rodeos, lo que tienes es apenas un chatbot que se ve genial.

Bernard y Masimo coinciden en este punto: el modelo en sí no genera ventaja competitiva, porque todos tienen acceso a modelos muy similares; lo que realmente marca la diferencia es la calidad de los datos que tu organización ha acumulado internamente y tu capacidad para rediseñar los flujos de trabajo. Esto conecta con la analogía que Masimo mencionó antes sobre la migración a la nube: cuando muchas empresas trasladaron sus sistemas existentes a la nube sin cambiar nada, esperando que los problemas se resolvieran solos, terminaron generando más problemas de los que tenían. La misma trampa se está repitiendo ahora con la IA: conectar un modelo muy potente a un flujo de trabajo fragmentado y llamarlo estrategia casi siempre termina en fracaso.

El giro: resolviste si algo va a salir mal, pero quizás no notaste que estás pagando otro precio

En toda la entrevista no se mencionó ni una sola vez la palabra token, pero detrás de la lógica del context engineering hay una realidad que ninguna empresa que adopte IA generativa puede evitar. Esta es una observación que extendemos desde la perspectiva de la gobernanza de Token, y no son palabras textuales del entrevistado.

Cuanto más completo es el contexto que le das a un modelo —historial, documentos de política, rastros de auditoría, datos en tiempo real—, más contenido tiene que procesar la IA en cada llamada del lado de entrada, y ahí es exactamente donde se origina el consumo y el costo de Tokens. Por eso la gobernanza no puede quedarse solo en los niveles de seguridad y precisión: un contexto que no ha sido depurado suele significar meter todos los datos posibles de una sola vez, lo que produce una entrada enorme y desordenada, donde cada llamada termina pagando por información repetida, obsoleta o irrelevante; en cambio, un contexto verdaderamente gobernado, que conserva solo lo que esa tarea específica realmente necesita ver en ese momento, suele ser al mismo tiempo más compacto y más preciso. En otras palabras, hacer bien el context engineering suele resolver a la vez dos problemas: si la respuesta es confiable y cuánto cuesta esa llamada, solo que el segundo problema se pasa por alto fácilmente, porque la factura normalmente la ve el área de finanzas hasta el mes siguiente.

La próxima vez que evalúes un proyecto de IA, pregunta primero qué necesita ver el modelo

La proyección de Masimo para los próximos tres a cinco años es que la IA empresarial se volverá más agentic, integrándose más profundamente en operaciones de seguridad, observabilidad, atención al cliente e incluso en el desarrollo de software de primera línea. Pero las organizaciones que realmente tomen la delantera no serán las que desplieguen más rápido, sino las que tengan la disciplina de construir primero la base: los cimientos de datos, la capa de contexto, la arquitectura de gobernanza. Observa que el mercado ya se dividió en dos caminos: uno es el de fuerza bruta, que sigue resolviendo a golpe de llamadas al modelo caras y repetitivas problemas que podrían resolverse de forma más inteligente con mejor infraestructura de contexto; el otro pone el esfuerzo en extraer significado de los datos y trata el context engineering como prioridad número uno, dejando que el sistema se vuelva más preciso y más valioso con el tiempo, en lugar de repetir el mismo trabajo pesado cada vez desde cero. La base de este segundo camino acumula ventaja con el tiempo, y hace que a los que llegan después les resulte cada vez más difícil alcanzarlo.

Volviendo a la escena con la que abrió este artículo: si ese gerente de atención al cliente, antes de lanzar la función, hubiera preguntado primero no qué tan inteligente es este Agent, sino qué puede ver, quién aprobó que pudiera verlo y si eso se probó, ese correo de escalamiento probablemente nunca habría llegado. Esta pregunta pesa mucho más que elegir qué modelo usar, y define, de forma más directa de lo que la mayoría cree, cómo se verá la factura del próximo mes.

Preguntas frecuentes (FAQ)

P1: ¿Qué es Context Engineering? Según explica Masimo Merlo, de Elastic, en la entrevista, es la disciplina de conectar los datos correctos, con el modelo correcto, en el momento correcto: definir qué datos empresariales puede ver un modelo de IA (historial de clientes, políticas, eventos pasados, etc.) y construir barreras de contención para que su resultado sea confiable y se pueda ejecutar con seguridad.

P2: ¿Context Engineering es lo mismo que RAG? Están muy relacionados, pero no son exactamente lo mismo. La capa de recuperación y contexto mencionada en la entrevista es una de las piezas clave de infraestructura para que la IA obtenga datos correctos en tiempo real; pero el context engineering abarca un alcance mayor, incluyendo diseño de permisos, gobernanza de datos, monitoreo de procesos y construcción de barreras de contención: es una disciplina de ingeniería a nivel organizacional, no solo una técnica puntual.

P3: ¿Por qué un AI Agent necesita cuidar más el contexto que un chatbot normal? Porque cuando un chatbot se equivoca, el usuario lo nota de inmediato y puede corregirlo, lo cual es apenas una molestia; pero cuando la IA puede recomendar, decidir y actuar por su cuenta, ese mismo error puede convertirse directamente en un riesgo comercial, una exposición regulatoria o un incidente de seguridad. La entrevista describe esto como el punto en que se pasa de molesto a peligroso.

P4: ¿Cuál es el primer paso para que una empresa adopte Context Engineering? Según el criterio que propone Masimo en la entrevista, el primer paso no es elegir un modelo, sino partir del flujo de trabajo: entender de qué datos depende ese proceso, definir permisos de acceso claros, y dejar todo el proceso auditable, para poder ver en cualquier momento qué está haciendo realmente la IA en producción.

P5: ¿Context Engineering aumenta o reduce el costo de Tokens de la IA? La entrevista en sí no aborda el costo de Tokens, pero, como extensión del tema —y esta es una observación del equipo editorial, no una afirmación del entrevistado—, ambos efectos son posibles: si simplemente se mete al contexto todo el dato posible sin criterio, el volumen de contenido de cada llamada se dispara y el costo sube con él; pero si, siguiendo la lógica del artículo, solo se conserva lo que la tarea actual realmente necesita, cada llamada suele volverse más compacta y más precisa, mejorando al mismo tiempo la confiabilidad de la respuesta y la eficiencia de costos.

Declaración de fuentes

Este artículo es una adaptación e interpretación de un episodio del podcast de negocios y tendencias tecnológicas conducido por Bernard Marr, titulado "Why Context Is The Missing Piece In Enterprise AI", con la participación de Masimo Merlo, de Elastic, publicado el 2 de julio de 2026, con 79.830 visualizaciones (dato verificado en la plataforma Apify al momento de extraer la transcripción de este artículo, viewCountVerified). Video original: https://www.youtube.com/watch?v=mNSJC7UEbxc. Las descripciones sobre la definición de context engineering, los casos empresariales y las tendencias futuras se basan en una adaptación de la transcripción de la entrevista; la sección "El giro: resolviste si algo va a salir mal, pero quizás no notaste que estás pagando otro precio" y la pregunta P5 de las FAQ son una observación extendida del equipo editorial de AI Token King a partir del contenido de la entrevista, y no corresponden a palabras textuales del entrevistado, lo cual se aclara expresamente aquí.

Para seguir leyendo

Si te interesa este tema, en nuestro sitio en chino hemos publicado artículos relacionados sobre qué es OpenAI Codex y en qué se diferencia de ChatGPT y Claude Code, sobre por qué los Tokens de IA resultan tan caros al desglosar el funcionamiento autorregresivo detrás de los Coding Agents, sobre por qué cada vez más software está migrando a modelos de precio por Token y qué significa eso para la lógica de compra y la gobernanza de costos en la era de los Agents de IA, y sobre el dilema de que, cada vez que un modelo se vuelve más fuerte, algunos productos de IA corren el riesgo de ser devorados por él.

Prueba gratis

Entender qué necesita ver el modelo es solo el primer paso; el siguiente, el que casi nadie revisa a tiempo, es cuánto termina costando en la práctica cada una de esas llamadas. Prueba gratis AI Token King → (https://aitokenking.com.tw/home) y reúne en un mismo panel el consumo y el gasto de los distintos modelos de IA que usas con una sola clave, para no tener que esperar hasta que llegue la factura del próximo mes para verlo por primera vez.