Qué es la ingeniería de contexto y por qué importa más que el prompt

El prompt perfecto sobre información equivocada sigue dando una respuesta equivocada

Durante dos años la conversación empresarial sobre IA giró alrededor de cómo escribir la instrucción: cursos de prompts, librerías internas de frases mágicas, perfiles contratados para redactar plantillas. Y sin embargo, el patrón que veo cuando reviso un piloto que no funcionó es siempre el mismo: la instrucción está razonablemente escrita y aun así el modelo responde con información vieja, incompleta o inventada. No porque el modelo sea malo, sino porque nadie decidió qué información de la empresa iba a tener delante cuando le tocara responder.

El ejemplo se repite en todos los sectores. Un asistente comercial que cotiza con la lista de precios del año pasado, porque la nueva vive en un Excel que nadie conectó. Un agente de soporte que cita una política de devoluciones que legal cambió hace cuatro meses. Un asistente de operaciones que responde bien para una sucursal y mal para otra, porque nadie le explicó que las reglas cambian por región. Ninguno de esos tres casos se arregla reescribiendo el prompt.

Ahí está el desplazamiento que la mayoría todavía no vio: el valor que se le atribuía al prompt engineering se movió hacia arriba, al trabajo de decidir qué conocimiento de la empresa está disponible, ordenado y vigente en el momento en que el modelo lo necesita. Eso no es redacción, es arquitectura de información y disciplina operativa. Es mucho menos vistoso que escribir un prompt, razón por la cual casi nadie lo hace.

Qué es la ingeniería de contexto cuando se la baja a la operación real

La ingeniería de contexto es el trabajo de decidir tres cosas para cada tarea que le vas a dar a un modelo: qué información necesita ver, en qué momento del flujo la necesita y en qué forma se la entregas. Suena simple hasta que lo aterrizas a un caso concreto, porque responder “qué información necesita ver” exige saber qué documentos existen, cuál es la versión buena, quién la mantiene, qué se le puede mostrar a quién y qué pasa cuando dos fuentes se contradicen. Es un trabajo de negocio antes que de tecnología.

Anthropic lo plantea con una idea útil: el contexto es un recurso finito con rendimientos decrecientes. A más información irrelevante metida en la consulta, peor la señal y peor la respuesta. El objetivo es el conjunto más pequeño que alcance para resolver bien esa tarea, no el volcado del manual completo. En la práctica ese contexto se arma por capas: instrucciones del sistema, conocimiento estable de la empresa, datos vivos del caso puntual, herramientas que puede consultar y memoria de lo que ya pasó. Cada capa tiene un dueño y un ritmo de actualización distinto, y gobernar esas capas es el trabajo real.

Lo que de verdad hay que decidir antes de tocar una línea de código

Cuando entro a diagnosticar por qué un sistema de IA responde mal, no empiezo por el prompt. Empiezo levantando el mapa de qué información toca ese proceso y en qué estado está. Las preguntas son incómodas y casi nunca tienen respuesta inmediata dentro de la empresa:

• Qué fuentes alimentan esta respuesta. Si nadie puede listarlas en una hoja, el sistema está adivinando y el equipo todavía no lo sabe.
• Cuál es la versión buena. Qué documento manda cuando hay tres circulando. En la mayoría de empresas la versión buena vive en la cabeza de alguien, y eso es exactamente lo que un modelo no puede leer.
• Quién es el dueño de mantenerla. Un nombre, no un área. Sin dueño, la fuente se desactualiza y el sistema empieza a equivocarse con confianza a los pocos meses.
• Qué se le puede mostrar a quién. El contexto de un agente de cara al cliente no puede ser el mismo que el de un asistente interno de finanzas. El filtro de permisos es parte del diseño, no un parche posterior.
• Qué pasa cuando la información no existe. Lo correcto es que el sistema diga que no tiene el dato y escale, no que complete el hueco con una respuesta plausible.

Cuando esas preguntas tienen respuesta, la parte técnica se vuelve casi mecánica: recuperación por búsqueda, conexión a los sistemas donde vive el dato vivo, protocolos como MCP para que el modelo consulte herramientas internas de forma consistente en lugar de un puente distinto por cada integración. Lo difícil nunca fue la plomería. Lo difícil es que alguien de negocio se siente a decidir qué es verdad dentro de la empresa y quién responde por mantenerlo.

Dónde termina el contexto de una consulta y empieza la memoria de la empresa

El contexto resuelve una consulta, la memoria organizacional resuelve la continuidad. El contexto es lo que el modelo ve ahora para responder este caso; la memoria es lo que la empresa acumula y vuelve a poner disponible mañana: cómo se resolvió una objeción comercial que funcionó, qué excepción se aprobó para un cliente y por qué, con qué criterio operaciones priorizó un pedido sobre otro. Sin memoria, cada consulta empieza de cero y el sistema nunca mejora con el uso.

Qué no es la ingeniería de contexto y qué problemas no te va a resolver

Como toda idea que empieza a circular, esta ya se está vendiendo como la solución a todo. Conviene marcar el límite antes de que alguien te cotice un proyecto grande con esta etiqueta encima.

• No es RAG con otro nombre. RAG es una técnica de recuperación; la ingeniería de contexto es decidir qué merece recuperarse y hasta cuándo sigue siendo válido. Un RAG bien montado sobre documentación muerta responde mal con precisión impecable.
• No es una herramienta que se compra. Hay productos para recuperar y versionar, pero la decisión de qué es verdad dentro del negocio no se terceriza.
• No arregla procesos que nunca estuvieron definidos. Si comercial no tiene claro cuándo se aprueba un descuento, ningún contexto va a hacer que el modelo lo sepa. La IA no reemplaza una mala definición de proceso, la expone más rápido.
• No sustituye la gobernanza de datos. Decidir qué ve el modelo es también decidir qué no debe ver, y eso toca controles de acceso reales, no una instrucción pidiéndole al modelo que sea discreto.
• No elimina los errores del modelo. Reduce mucho las respuestas inventadas porque le da dónde apoyarse, pero sigue haciendo falta verificación donde equivocarse cuesta caro.

Y una advertencia de costo que nadie menciona en la etapa de venta: más contexto no es gratis. Cada consulta que arrastra información innecesaria cuesta más, tarda más y suele responder peor. La disciplina no es acumular, es elegir. Los equipos que entienden esto terminan con sistemas más baratos y más precisos que los que volcaron el drive completo de la empresa dentro del modelo.

Cuándo invertir en esto en serio y cuándo todavía es prematuro

Cuándo sí, y con prioridad alta

• Cuando ya tienes un piloto funcionando y el reclamo recurrente es que “responde cosas que no son” o “no sabe de lo nuestro”. Ese síntoma es de contexto, no de modelo.
• Cuando el proceso depende de información que cambia seguido: precios, stock, políticas, condiciones comerciales, normativa del sector.
• Cuando el conocimiento crítico vive en pocas personas y la empresa ya sintió el golpe de que una de ellas se fuera.
• Cuando distintas áreas dan respuestas distintas al mismo caso. Ese desorden sale amplificado en cualquier sistema de IA que montes encima.

Cuándo todavía es prematuro

• Cuando no hay un caso de uso definido y el equipo sigue explorando. Ordenar contexto sin saber para qué proceso es ordenar un almacén sin saber qué se va a vender.
• Cuando la tarea es genérica de redacción o resumen y no depende de conocimiento interno.
• Cuando la empresa quiere ordenar todo su conocimiento antes de poner nada en producción. Ese proyecto no termina nunca y se come el presupuesto que debía financiar el primer resultado.
• Cuando nadie del negocio está dispuesto a hacerse dueño de mantener las fuentes.

Errores que veo una y otra vez en empresas reales

• Volcar todo el repositorio documental adentro y llamarlo base de conocimiento. Sin curaduría ni control de versiones, el sistema cita el manual de hace siete años con la misma seguridad que el vigente.
• Dejar el contexto en manos del área técnica sola. Sistemas puede construir la recuperación, pero no puede saber cuál de las tres versiones de la política comercial está vigente.
• Tratar el contexto como una carga inicial y no como algo vivo. Se arma bien el primer mes, nadie lo mantiene, y a los seis meses responde con información que la empresa ya cambió.
• Confundir volumen con calidad. Sumar documentos “para que sepa más” suele empeorar la respuesta y encarecer cada consulta, porque el modelo tiene que abrirse paso entre ruido.
• Copiar el contexto de un proceso a otro sin revisarlo. Lo que sirve para soporte técnico rara vez sirve para cobranzas, aunque los documentos se parezcan.

Cómo saber si el trabajo de contexto está funcionando de verdad

Esto se mide, y no con la sensación del equipo de que “ahora responde mejor”. Se mide comparando el mismo conjunto de casos reales antes y después de ordenar el contexto, con las respuestas revisadas por quien conoce el proceso. Las señales que sirven son operativas, no de vitrina:

• Tasa de respuestas correctas sobre un banco fijo de casos reales, evaluadas por el dueño del proceso y no por quien construyó el sistema.
• Frecuencia de respuestas con información desactualizada, que delata si las fuentes tienen mantenimiento real o solo tuvieron una carga inicial.
• Porcentaje de consultas que el sistema escala correctamente en vez de inventar una respuesta cuando no tiene el dato.
• Tiempo que le toma al equipo verificar una respuesta antes de usarla. Si es igual que hacerlo a mano, el sistema todavía no aporta.
• Cuántas fuentes tienen dueño asignado y fecha de última revisión. Es la métrica menos vistosa y la que mejor predice si el sistema va a seguir sirviendo dentro de un año.

Si a los tres meses ninguna de estas señales mejoró, el diagnóstico rara vez es que faltaba un modelo más potente. Casi siempre es que el conocimiento del proceso seguía sin estar ordenado, sin dueño y sin vigencia clara, y que el sistema hizo visible un desorden que la empresa venía arrastrando desde mucho antes de que apareciera la IA.