La capa de contexto que nadie construyó

Casi todas las conversaciones sobre agentes son conversaciones sobre modelos. Cuál razona mejor, cuál es más barato, en cuál estandarizar. Es el sitio natural donde mirar, porque el modelo es la parte que parece nueva.

Solo que el modelo rara vez determina si un agente es útil dentro de tu empresa. Un agente vale lo que el contexto que puede alcanzar, y tu contexto no vive en el modelo. Vive repartido entre tus personas, procesos y sistemas: el CRM, el core, el repositorio documental, la cola de tickets, la persona que conoce la única excepción que importa. La mayoría de las organizaciones nunca construyó la capa que permite a un agente alcanzar ese contexto con seguridad. Así que el agente o no ve lo suficiente para ser útil, o se conecta con credenciales amplias y permanentes que ningún comité de seguridad aprobaría.

Esa capa ausente es la razón silenciosa por la que se atascan la mayoría de los proyectos. No es un problema de modelo. Es un problema de interoperabilidad e identidad, y es lo bastante poco glamuroso como para que casi nadie le reserve presupuesto hasta que choca con él.

La capa no es fontanería de integración

La tentación es entregarle esto a un equipo de integración y llamarlo fontanería. Resístete, porque cada decisión de diseño de esta capa es una decisión de seguridad, y tratarla como fontanería es cómo acaban construyendo los agujeros de seguridad personas a las que nunca se les pidió que pensaran en ellos.

La capa de contexto tiene tres partes, y cada una es donde divergen una arquitectura seria y una esperanzada.

Parte uno: capacidades tipadas, no un montón de claves de API

Un agente necesita leer y escribir en tus sistemas de registro. La forma perezosa de concederlo es un manojo de claves de API y acceso amplio. La forma correcta son capacidades explícitas y tipadas.

Piensa en cada capacidad como una puerta estrecha y con nombre: read_dossier, request_document, post_decision_for_review. Al agente se le conceden las puertas concretas que necesita para una tarea concreta, y nada más. Cada puerta queda registrada.

No es una diferencia cosmética. Cambia la frase que tu comité de seguridad tiene que evaluar. "El agente puede tocar nuestros sistemas" no es auditable, y nadie debería firmarlo. "El agente puede ejecutar estas siete acciones con nombre, cada una registrada" es un control que un comité puede aprobar. Las capacidades tipadas son lo que convierte una integración abierta en una superficie acotada y revisable.

Parte dos: identidad no humana, de corta duración y privilegio mínimo

Un agente no es una persona, y nunca debe usar las credenciales de una persona.

Esta es la forma más común en que los proyectos fracasan en el comité de seguridad, porque la vía rápida, correr el agente bajo el token personal de quien lo hizo con acceso permanente a producción, es exactamente el hallazgo que detiene el proyecto. Ese token es una llave maestra. No está acotado, no caduca rápido y no distingue las acciones del agente de las de la persona.

En una arquitectura correcta, cada agente corre bajo su propia identidad no humana, con credenciales de corta duración y privilegio mínimo y una allow-list de salida explícita. Merece la pena decir la consecuencia con claridad: una credencial de agente robada no vale casi nada. No hay secreto estático que robar, y la identidad solo puede hacer las pocas cosas para las que se acotó, hacia los pocos destinos que tiene permitidos. Uno de estos diseños pasa la homologación. El otro es el hallazgo que acaba con el proyecto.

La identidad es además lo que da sentido al rastro de auditoría. Cuando cada acción lleva la identidad propia del agente y sus capacidades acotadas, "¿quién hizo esto?" tiene respuesta precisa, y el registro que inspeccionan tus auditores reconstruye de verdad lo que pasó.

Parte tres: la frontera de contaminación, donde los datos no confiables no se convierten en privilegio

Esta es la parte que separa una arquitectura seria de una esperanzada, y merece cuidado, porque es la forma más común en que los agentes se ven comprometidos en producción.

Un agente lee contenido que no escribió: un correo de cliente, un contrato escaneado, un PDF de un tercero. Ese contenido no es de confianza. Si un documento envenenado contiene texto que se lee como una instrucción, y el agente lo trata como tal, el documento acaba de secuestrar a un agente con acceso a tus sistemas centrales. Es la prompt injection indirecta, y ningún prompt, filtro o ajuste de configuración la detiene con fiabilidad.

La respuesta estructural es una frontera de contaminación: los datos no confiables nunca se convierten en privilegio ejecutable. En la práctica se aplica separando los roles del agente, el patrón conocido como CaMeL, un diseño dual-LLM. Un planificador privilegiado decide qué hacer e invoca las herramientas tipadas, pero nunca lee directamente contenido no confiable en bruto. Un lector en cuarentena sí lee el contenido no confiable, pero no puede invocar herramientas ni actuar. Devuelve una referencia, no una instrucción. Ante cualquier ambigüedad, el sistema falla cerrado.

Hay un coste honesto. Separar los roles sacrifica unos pocos puntos de utilidad. Ese es el trato: un precio modesto en precisión a cambio de una garantía estructural de que un documento no puede tomar el control de un agente conectado a tus sistemas centrales. En trabajo regulado, la decisión no está reñida.

Ninguna capa aislada se considera suficiente. La frontera de contaminación vive dentro de una defensa en profundidad: spotlighting para encoger la superficie de ataque, aislamiento CaMeL, guardrails de detección y un punto de decisión de políticas por encima de todo. El spotlighting reduce la superficie de ataque. No la elimina, y por eso mismo nunca es la única capa.

Por qué merece la pena construir esta capa sobre tus procesos reales

No puedes comprar esta capa de catálogo, porque su forma viene de tus sistemas, tus identidades y tus fronteras de datos. Tiene que construirse sobre tus procesos reales, sobre el terreno, sobre el trabajo de verdad, no sobre un diagrama de referencia.

Por eso mismo es la capa que decide, en silencio, todo lo que viene después. El mejor modelo del mundo, enrutado por el gateway más portable, gobernado por la escalera de autonomía más rigurosa, es inútil si el agente no puede alcanzar con seguridad el contexto que necesita para actuar. Al contrario, cuando la capa de contexto existe, los agentes alcanzan solo lo que tienen permitido, actúan bajo sus propias identidades de privilegio mínimo y nunca pueden ser engañados para tratar datos no confiables como una instrucción, con un rastro completo que tus auditores pueden inspeccionar. Todo lo demás en una arquitectura agéntica asume que esta capa ya existe.

Así que el replanteamiento no es "¿qué modelo deberían usar nuestros agentes?". Es para cada sistema que nuestros agentes tienen que alcanzar, cuál es la capacidad tipada, qué identidad tiene el agente, y dónde está la frontera entre el contenido que lee y las acciones que puede ejecutar. Si no puedes responder a eso sistema por sistema, la elección del modelo todavía no importa. La capa que hay debajo no se ha construido.

Si quieres mapear la capa de contexto para un proceso crítico, reserva una reunión.