Sus agentes heredan su residencia de datos

Un patrón que encuentro repetidamente en la banca canadiense: la revisión de arquitectura no falla por la calidad del modelo. Falla en un mapa. ¿Adónde va el prompt, adónde va el contexto y qué frontera cruza en el camino?

La mayoría de las arquitecturas de referencia multiagente asumen tácitamente que cada agente puede llamar a una API fronteriza en otra jurisdicción. En industrias reguladas, esa suposición muere en la primera reunión. Los datos del cliente no pueden salir. A veces ni siquiera pueden salir del segmento de red.

El patrón que sobrevive es un límite de privacidad entre agentes. Los agentes de datos sensibles se ejecutan localmente, contra modelos alojados localmente. Los agentes de datos públicos (investigación de mercado, búsqueda de documentos, cualquier cosa que ya esté fuera del muro) pueden ejecutarse donde resida el mejor modelo. La unión de protocolo entre ellos transporta descripciones de tareas y conclusiones, no registros brutos. Escribí la mecánica en la guía de campo A2A.

Dos notas prácticas de la construcción de esto. Primero, la elección del modelo se convierte en una decisión de soberanía, no solo de calidad, por eso construí un conector Cohere para la orquestación de procesos: un modelo robusto con opciones de despliegue que encajan dentro del muro. Segundo, el límite debe ser impuesto por la capa de orquestación, no por el prompt del agente. Una instrucción que dice “no envíe datos del cliente externamente” es un deseo. Una topología donde el agente externo nunca recibe el registro es un control.

La soberanía no es una preocupación canadiense de nicho. Está llegando a toda arquitectura que trata “llamar a la mejor API” como una acción libre.