Pides a un asistente que prepare una propuesta comercial. La redacción parece correcta, pero utiliza una tarifa antigua y ofrece un servicio que ya no vendes. Puedes corregir la frase del encargo; seguirás teniendo un problema mientras el sistema consulte los documentos equivocados. El context engineering aborda esa selección de información dentro de los sistemas de inteligencia artificial: qué necesitan saber, dónde lo obtienen y qué conservan durante el trabajo.
Su utilidad aparece especialmente cuando pasas de una conversación ocasional a un asistente que trabaja con información de tu empresa. Un buen resultado exige localizar la versión vigente, entender sus límites y mantener las decisiones tomadas. También exige saber cuándo falta un dato y detener la tarea correspondiente.
Qué es el context engineering
La ingeniería de contexto consiste en organizar la información que recibe un modelo de lenguaje en cada paso. Incluye las instrucciones, los documentos recuperados, el historial relevante y los resultados de las herramientas. El prompt es una parte de ese conjunto.
Anthropic describe esta práctica como una gestión continua del contexto disponible. En tareas largas propone recuperar información cuando hace falta, mantener notas estructuradas y resumir el historial con cuidado. Son técnicas de diseño: su eficacia debe comprobarse para cada aplicación.
En el ejemplo comercial, el trabajo empieza por identificar el catálogo autorizado y su fecha. Después se incorpora la necesidad del cliente, se consulta la tarifa aplicable y se genera un borrador. El sistema no necesita recibir de entrada todas las conversaciones comerciales de los últimos cinco años.
La diferencia respecto al prompt
El prompt puede pedir: «Prepara una propuesta de mantenimiento para este cliente, con alcance, precio y exclusiones». La ingeniería de contexto debe resolver cuestiones que esa frase deja abiertas: cuál es el cliente, qué instalación tiene, qué tarifa corresponde y qué condiciones puede ofrecer el comercial.
Una instrucción excelente tampoco proporciona un documento que nunca se ha adjuntado ni concede acceso a una base de datos desconectada. Antes de dedicar otra hora a retocar el encargo, conviene revisar el recorrido que sigue la información.
| Elemento | Decisión de diseño | Ejemplo comercial |
|---|---|---|
| Instrucción | Definir el resultado esperado | Borrador con alcance, precio y exclusiones |
| Fuente | Elegir el documento autorizado | Tarifa vigente de mantenimiento |
| Datos del caso | Recuperar los campos necesarios | Tipo de instalación y servicio solicitado |
| Estado del trabajo | Conservar decisiones confirmadas | El cliente ha descartado la atención nocturna |
| Control | Limitar las acciones permitidas | Preparar la propuesta sin enviarla |
Un caso práctico de principio a fin
Tomemos un caso hipotético: una empresa de climatización quiere preparar presupuestos de mantenimiento con ayuda de IA. El equipo dispone de fichas de clientes, tarifas, partes técnicos y correos. Para el piloto, elegimos un solo servicio y dejamos el envío en manos del comercial.
Primero se prepara una ficha breve del encargo: instalación, número de equipos, ubicación, cobertura solicitada y plazo de respuesta. Si falta alguno de los datos necesarios para calcular el precio, el asistente debe señalarlo. Inventar un número de equipos para completar el presupuesto sería un fallo, aunque el documento quedara impecable.
Después se determina la fuente para cada decisión. El precio sale de una tarifa identificada; las intervenciones incluidas, del catálogo del servicio; las particularidades de la instalación, de la ficha técnica. Un correo antiguo puede aportar antecedentes, pero no debería sustituir las condiciones vigentes sin una confirmación expresa.
La salida solicitada contiene el borrador y una tabla interna de comprobación: concepto, fuente utilizada y dato pendiente. Esa tabla permite al comercial detectar una tarifa equivocada antes de enviar nada. Puede mantenerse fuera del documento que recibe el cliente.
Por último, se conserva un registro de decisiones: «cobertura de lunes a viernes», «sin urgencias nocturnas» y «pendiente de confirmar el número de unidades». Son anotaciones de trabajo. No deben transformarse en reglas generales para otros clientes ni guardarse indefinidamente por defecto.
Documentos, versiones y recuperación
Para organizar un primer piloto, proponemos acompañar cada documento operativo de cinco datos: título, responsable, versión, fecha de vigencia y ámbito de aplicación. Es una convención de trabajo que el equipo debe poder mantener. Una fecha reciente, por sí sola, no acredita que un archivo esté aprobado.
También conviene distinguir los documentos sustituidos. Si conservas dos tarifas con nombres casi idénticos y ninguna indicación de cuál manda, el asistente recibe una ambigüedad que antes soportaban las personas. El proyecto de IA hará visible ese desorden, pero resolverlo corresponde al responsable del proceso.
La recuperación puede ser manual al principio: adjuntas la tarifa correcta y la ficha del caso. Cuando crece el volumen, una aplicación puede buscar fragmentos relevantes en un repositorio. Esta combinación de recuperación de información y generación se conoce como RAG, por las siglas inglesas de generación aumentada por recuperación. El resultado necesita comprobación: encontrar un texto parecido al encargo no demuestra que sea la fuente adecuada.
Si dos documentos autorizados se contradicen, es preferible que el asistente presente ambas referencias y deje pendiente esa decisión. Elegir silenciosamente la condición más favorable o la más reciente puede producir un presupuesto que nadie está autorizado a ofrecer.
Herramientas y memoria de trabajo
Una herramienta bien delimitada facilita la consulta. Para preparar una propuesta puede bastar con buscar un cliente por su identificador y recuperar los campos permitidos. Descargar toda la base de clientes añade información ajena al encargo.
La documentación de Anthropic sobre herramientas recomienda describir claramente su función y devolver resultados útiles, evitando respuestas voluminosas e irrelevantes. La descripción debe permitir distinguir, por ejemplo, una consulta de disponibilidad de una operación que confirma una reserva.
En nuestro piloto, separaríamos tres capacidades: consultar la ficha técnica, obtener la tarifa y guardar el borrador. El asistente no necesitaría una función de cobro. Una búsqueda sin resultados debería devolver ese estado de forma explícita, para que el sistema no lo confunda con una instalación sin incidencias.
La memoria de trabajo merece su propio diseño. Proponemos guardar decisiones confirmadas, referencias de documentos y pendientes. Los resúmenes deben conservar las excepciones que afectan al resultado: eliminar «precio pendiente de validación» cambia sustancialmente el significado de una propuesta.
Privacidad y permisos
Reunir contexto también concentra información sensible. En el caso comercial, el asistente puede necesitar características técnicas y condiciones contratadas; probablemente no necesita datos bancarios ni conversaciones personales. Define qué campos recibe y comprueba la configuración del servicio utilizado antes de incorporar documentos internos.
Los permisos efectivos deben limitarse en la aplicación. Una frase que diga «no envíes correos» no sustituye un control que impida enviarlos. Para el piloto, una cuenta con acceso de lectura y un espacio de borradores ofrece un alcance más ajustado al trabajo propuesto.
OWASP documenta la inyección de instrucciones a través de contenido externo: un archivo o una página puede intentar alterar el comportamiento del modelo. Recomienda controles de acceso mínimos, validación y supervisión. Recuperar documentos mediante RAG no elimina esa vulnerabilidad.
Un documento adjunto que ordene revelar información de otros clientes debe tratarse como contenido del documento, no como autorización. El diseño debe contemplar este caso y probar que las herramientas rechazan operaciones fuera de los permisos concedidos.
Cómo comprobar si funciona
Antes de ampliar el piloto, prepara una pequeña colección de casos con una respuesta esperada. Incluye solicitudes completas, datos ausentes, documentos antiguos, condiciones contradictorias y un archivo con instrucciones ajenas a la tarea. La diversidad importa más que reunir muchas variantes del mismo presupuesto sencillo.
Compara el proceso actual con la nueva configuración sobre esos mismos casos. Registra qué tarifa utiliza, qué condiciones incorpora, qué preguntas hace y cuánto trabajo de revisión deja al comercial. Anota también el tiempo de respuesta y el coste, cuando puedas obtenerlo.
Repite las pruebas que tengan consecuencias relevantes. Un acierto aislado no acredita que el sistema se comporte igual con otra redacción del encargo. Si cambia el modelo, la herramienta de búsqueda o el catálogo, vuelve a ejecutar los casos afectados.
Para este ejemplo, definiríamos tres condiciones mínimas de aceptación: ningún precio sin fuente identificada, ninguna exclusión contractual omitida y ningún envío automático. Son criterios propuestos para el piloto de climatización; otro proceso necesitará sus propios umbrales y revisión.
Por dónde empezar
Escoge una tarea repetida que termine en un borrador revisable. Identifica los documentos que realmente utiliza una persona competente, retira versiones sustituidas del recorrido habitual y prueba el asistente con casos que conozcas. Así podrás atribuir los errores a una causa concreta: fuente incorrecta, dato ausente, interpretación o permiso mal definido.
Si quieres desarrollar estas capacidades y aplicarlas a proyectos de negocio, puedes consultar el Máster en Inteligencia Artificial de IEBS y solicitar orientación sobre su encaje con tu perfil.