Context engineering para empresas: la guía práctica

El context engineering no es un concepto académico. Es la diferencia práctica entre un sistema de IA que decepciona y uno que funciona.

La mayoría de las empresas que "no consiguen resultados con la IA" tienen el mismo problema: están usando el modelo correcto con el contexto equivocado.

Qué es el context engineering en términos de negocio

El context engineering es el proceso de diseñar qué información recibe el modelo, en qué formato y en qué momento, para que produzca los resultados que necesitas.

En términos concretos: es decidir qué va en el system prompt, qué documentos recuperas de tu base de conocimiento, cómo estructuras el historial de conversación, y qué herramientas tienes disponibles.

La intuición clave: el modelo no es la variable. El mismo modelo con contexto diferente produce resultados radicalmente distintos.

Los 4 componentes del contexto empresarial

1. El sistema de instrucciones

Es el system prompt. Pero en un entorno empresarial tiene capas:

• Identidad: Quién es el sistema, para quién trabaja, cuál es su objetivo
• Conocimiento de empresa: Qué sabe del negocio, los productos, los procesos
• Reglas de negocio: Qué puede y no puede hacer, qué temas están fuera de alcance
• Formato de salida: Cómo debe responder (tono, longitud, estructura)

Un system prompt empresarial típico tiene 500-2000 tokens. Menos y falta contexto; más y el modelo se confunde con instrucciones contradictorias.

2. El conocimiento recuperado

Todo lo que sabe tu empresa que el modelo no sabe de base: políticas, productos, procedimientos, datos de clientes, historial de decisiones.

Este conocimiento entra en el contexto a través de RAG o de herramientas de búsqueda. La calidad de tu base de conocimiento determina directamente la calidad de las respuestas.

El error más común: Indexar documentos internos sin procesarlos. Los documentos internos están escritos para humanos con contexto previo. El modelo necesita documentos limpios, sin acrónimos sin explicar, sin referencias a "lo que acordamos en la reunión de enero".

3. El historial y el estado

Lo que ha pasado en la conversación o el proceso actual. Incluye:

• Mensajes anteriores del usuario
• Acciones que el agente ha tomado
• Resultados intermedios de herramientas
• Preferencias del usuario aprendidas

La gestión del historial es un problema de ingeniería real: la context window tiene límite. Necesitas decidir qué recortar cuando se llena.

4. Las herramientas disponibles

Qué puede hacer el sistema: buscar en base de datos, consultar una API, ejecutar código, enviar un email.

Cada herramienta que añades aumenta la capacidad del sistema pero también la superficie de posibles errores. Más herramientas no siempre es mejor.

El proceso de context engineering

Paso 1: Define el caso de uso con precisión

"Mejorar el servicio al cliente con IA" no es suficiente.

Necesitas: "El agente responde preguntas sobre políticas de devolución a clientes del segmento B2C, usando nuestra política vigente, en máximo 3 párrafos, sin comprometerse a excepciones no autorizadas."

Cuanto más específico es el caso de uso, más específico puede ser el contexto, y mejor funciona el sistema.

Paso 2: Mapea qué información necesita el modelo

Para cada tarea, pregunta: ¿qué debería saber un empleado nuevo competente para resolver esto?

Esa respuesta define qué va en el contexto. Si un humano necesita leer la política de devoluciones para responder, el modelo también la necesita.

Paso 3: Estructura el contexto

No toda la información tiene el mismo valor. Prioriza:

1. Instrucciones del sistema (siempre presentes)
2. Conocimiento crítico para la tarea actual (recuperado según relevancia)
3. Historial reciente (los últimos N turnos)
4. Información de apoyo (si hay espacio)

El orden importa. Pon lo más importante donde el modelo le prestará más atención.

Paso 4: Mide y ajusta

Define qué es una buena respuesta antes de construir el sistema. Después mide:

• Tasa de respuestas correctas en tu eval set
• Tasa de escalado a humano (si es muy alta, el sistema no está funcionando)
• Satisfacción del usuario si tienes feedback
• Costo por consulta

Ajusta el contexto basándote en los fallos reales, no en intuición.

Errores empresariales típicos

Usar el modelo como oráculo — El modelo solo puede hablar de lo que sabe. Si no le das la información, la inventa o dice que no sabe. Toda empresa necesita una base de conocimiento bien mantenida.

System prompt como lista de reglas — "No hagas X, no hagas Y, no hagas Z..." Mejor: describe el rol con precisión. Un rol bien descrito implica las restricciones sin enumerarlas todas.

Un sistema para todo — Un solo agente "de empresa" para soporte, ventas, RRHH y legal. Cada dominio necesita su propio contexto especializado. Un agente por caso de uso claro supera siempre a uno genérico.

Ignorar el mantenimiento — Los sistemas de IA degradan con el tiempo. Las políticas cambian, los productos se actualizan, los procesos evolucionan. Si no actualizas el contexto, el sistema da respuestas desactualizadas.

No tener humano en el loop — Para decisiones con consecuencias reales (compromisos de precios, excepciones de política, escalados), siempre debe haber una persona que aprueba.

Cómo evaluar la madurez de context engineering de un equipo

Nivel 1 — Sin estructura: El equipo escribe prompts ad hoc sin metodología. Los resultados son inconsistentes.

Nivel 2 — System prompts básicos: Hay un system prompt para cada caso de uso. Se actualiza cuando algo falla claramente.

Nivel 3 — RAG integrado: El conocimiento empresarial está indexado y se recupera automáticamente según la consulta.

Nivel 4 — Eval-driven: Hay un conjunto de pruebas que se ejecuta antes de cada cambio. Las mejoras se miden, no se asumen.

Nivel 5 — Ciclo continuo: El sistema aprende de los fallos reales, el contexto se actualiza con frecuencia, hay métricas de calidad en tiempo real.

La mayoría de las empresas están en el Nivel 1-2. El salto del 2 al 3 (RAG) es el que más impacto tiene en calidad percibida. El salto del 3 al 4 (evals) es el que permite escalar con confianza.

Por dónde empezar

1. Elige un caso de uso específico con valor de negocio claro
2. Construye el sistema mínimo que resuelve ese caso
3. Define 50 casos de prueba que representen el uso real
4. Mide la calidad actual con esos casos
5. Itera el contexto hasta alcanzar el nivel de calidad necesario
6. Despliega con monitoreo activo
7. Usa el siguiente caso de uso para aplicar lo aprendido

El error es intentar construir la plataforma completa antes de tener un caso de uso funcionando. El context engineering se aprende haciendo.