La capa de contexto: qué ve tu IA, de dónde y con qué permisos
La capa de contexto es todo lo que un sistema de IA tiene delante en el momento de responder: qué fuentes ve, de dónde salen, en qué orden se le presentan y bajo qué permisos. La disciplina de diseñar eso se llama ingeniería de contexto. No va del modelo, ni del prompt. Va de la información que llega hasta el modelo antes de que escriba una sola palabra.
Es la parte que decide si la respuesta sirve. Un modelo excelente con el contexto equivocado te da una respuesta impecable y falsa. Un modelo mediano con el contexto correcto te da algo que puedes usar.
Hasta aquí, la definición. El resto de este artículo es la parte que casi nadie está escribiendo: qué significa esto si diriges una consultoría de cuarenta personas en España y no tienes equipo de datos.
¿No es eso lo mismo que RAG?
No. RAG —recuperación aumentada— consiste en buscar documentos parecidos a la pregunta en el momento de la consulta y pasárselos al modelo. Funciona, y es la base de casi todos los asistentes del mercado. Pero es una pieza, no el sistema.
La ingeniería de contexto contiene esa pieza y cuatro más: qué recuerda el sistema de lo anterior, qué calidad tiene el dato que entra, qué políticas se aplican al recuperarlo y cómo se ensambla todo antes de responder. Atlan lo separa así: RAG contesta a «¿qué documentos se parecen a esta pregunta?»; la ingeniería de contexto contesta a «¿qué necesita saber este sistema, ahora, para acertar?».
La diferencia se ve mejor con un caso. Alguien pregunta: «¿qué descuento le aplicamos a este cliente?». RAG devuelve los tres documentos donde más aparece la palabra descuento. Puede que uno sea la política vigente, otro un borrador de hace dos años y el tercero el correo de un comercial negociando una excepción puntual. Los tres se parecen a la pregunta. Solo uno es la respuesta. Decidir cuál manda, cuál está caducado y quién tiene derecho a ver cuál: eso es la capa de contexto.
¿Y la memoria del chatbot no hace ya eso?
Se confunden mucho, y separarlas es probablemente lo más útil de este artículo.
La memoria tiene alcance de agente. Hace que un asistente sea más listo con un usuario, en una conversación. Recuerda que trabajas en operaciones y que ayer preguntaste por el mismo proveedor. Es una mejora real y se nota enseguida.
La capa de contexto tiene alcance de negocio. Hace que todos los sistemas de la empresa acierten más con el tiempo, porque comparten la misma versión de qué es verdad aquí dentro. Que «cliente activo» signifique lo mismo cuando lo pregunta ventas que cuando lo pregunta administración.
Una empresa puede tener memoria en cinco herramientas distintas y seguir sin tener capa de contexto. De hecho es lo normal. Cinco asistentes que recuerdan cinco cosas distintas y se contradicen entre ellos no son una memoria viva de tu empresa: son cinco memorias sueltas.
¿Por qué te importa si no tienes equipo de datos?
Aquí está el problema con casi todo lo publicado sobre esto. Quienes están poniéndole nombre a la categoría —Atlan, Snowflake, Tellius— le venden a empresas que tienen director de datos, catálogo y linaje documentado. Escriben para ese lector, y hacen bien. Pero ese no eres tú.
La traducción es corta: tú no tienes que montar una capa de contexto. Tienes que saber que existe para poder preguntar por ella. El trabajo de contexto se hace igual en tu empresa, lo llame alguien así o no. O lo hace el proveedor por diseño, o lo acabas haciendo tú a mano cada vez que corriges una respuesta mala, reenvías el documento bueno y le explicas a alguien que ese PDF ya no vale.
Esa segunda opción también cuesta dinero. Lo que pasa es que no aparece en ninguna factura.
¿Qué pasa exactamente cuando falta contexto?
Pasa lo peor que puede pasar: el sistema responde igual de rápido, con la misma seguridad, y se equivoca. No falla en voz alta. Falla en voz normal.
Las cifras que circulan sobre esto vienen del material de los propios proveedores que están definiendo la categoría —Atlan y Tellius, entre otros. Ahí se lee que un 57% de las empresas rastreó alguna respuesta segura pero incorrecta hasta un contexto empresarial ausente o incoherente, y que un 38% usaba la recuperación de documentos como vía por defecto para obtener ese contexto. También que la confianza declarada en agentes plenamente autónomos cayó del 43% al 27% en un año, y que solo un 7% dice tener sus datos listos para IA.
Aviso, porque va en serio: eso son encuestas de proveedor, no estudios independientes auditados, y quien las publica vende la solución al problema que miden. No te las doy como hechos. Te las doy porque apuntan todas en la misma dirección y esa dirección coincide con lo que se ve en cualquier implantación real. Si alguien te enseña el 57% en una diapositiva sin decirte de dónde sale, desconfía de la diapositiva.
Las predicciones van por el mismo camino. Snowflake sostiene que el contexto del agente, y no el modelo, será el producto principal a medida que los modelos se comoditicen. Gartner calcula que en 2028 la ingeniería de contexto estará presente en el 80% de las herramientas de IA empresarial. Son predicciones, no mediciones: valen como señal de hacia dónde va el sector, no como dato sobre el que decidir nada.
¿Por qué los permisos van dentro de la definición?
Vuelve a la primera frase: qué ve el sistema, de qué fuentes, en qué orden y bajo qué permisos. Ese último inciso no suele aparecer en las definiciones ajenas, y es el que más caro sale omitir.
Un contexto se construye buscando lo más relevante para la pregunta. Relevante no significa permitido. Si el permiso se comprueba después de armar el contexto, el fragmento restringido ya ha viajado desde la base de datos hasta la aplicación y todo lo que te queda es confiar en un filtro escrito en código. El mecanismo, con su ejemplo, está desmontado en por qué los asistentes de IA filtran información.
Por eso «bajo qué permisos» no es una coletilla de cumplimiento pegada al final. Forma parte de qué es un contexto bien construido. Un contexto que incluye la tabla salarial no es un contexto correcto al que le falta un filtro: es un contexto mal hecho.
¿De dónde sale el contexto de una empresa de cuarenta personas?
De donde ya está. Nadie va a sentarse a escribir el manual de la casa: eso no ha funcionado nunca y no va a empezar ahora.
El contexto de una pyme vive repartido en tres sitios. Los documentos que ya existen. Las conversaciones de trabajo donde se resuelven las cosas de verdad. Y las cabezas de tres o cuatro personas, que es donde está lo bueno y lo que nunca se ha escrito. Los dos primeros se pueden capturar sin pedirle nada a nadie. El tercero es el difícil, y es donde se decide si tienes un sistema que aprende o un buscador con chat. Lo conté en gestión del conocimiento con IA; aquí lo que me interesa es el encaje. Ese trabajo es construir una capa de contexto, aunque nadie lo llame así al venderlo.
Y hay una parte que no vas a poder delegar. Cuando dos documentos se contradicen, decidir cuál manda es una decisión de negocio, no técnica. Ninguna herramienta la va a tomar por ti, y la que te diga que sí, miente. Lo que sí puede hacer una herramienta es enseñarte los choques en lugar de esconderlos debajo de una respuesta bien redactada.
¿Y el día que la IA actúe en vez de responder?
El arco es previsible. Primero el sistema recupera contexto. Luego aconseja con él. Y algún día ejecuta: emite el pedido en vez de explicarte cómo se emite.
Ese salto no es solo técnico. En cuanto un sistema actúa en lugar de contestar, cambia su encaje regulatorio y cambia quién responde de sus errores. Un asistente que se equivoca produce una respuesta mala que alguien puede revisar. Un agente que se equivoca produce un hecho consumado.
Lo menciono porque conviene tenerlo en la cabeza al elegir hoy, no porque sea lo que hacemos. Savia responde, no ejecuta. No hay agentes autónomos, no hay acciones sobre tus sistemas y no te voy a prometer una hoja de ruta que todavía no existe. En qué casilla del Reglamento europeo de IA cae este servicio, con los artículos delante, está en la página de seguridad.
¿Qué preguntar, entonces?
Todo esto se reduce a una pregunta que puedes hacer sin saber nada de arquitectura, en una reunión, delante de quien te lo vende: «enséñame qué vio el sistema para responder esto».
Si te enseñan los fragmentos concretos, de qué documento salen, de qué fecha son y por qué esa persona tenía derecho a verlos, hay una capa de contexto detrás. Si te enseñan solo la respuesta, tienes una demo. Las demos son fáciles de hacer y muy difíciles de mantener seis meses.
Si lo tuyo es la parte de ingeniería, hay una guía práctica en español sobre llevar ingeniería de contexto a producción. Pero si tu trabajo es decidir y no implementar, con la pregunta de arriba tienes de sobra.