Mapear un flujo
Blog

Ejecutar agentes de IA dentro de tus propios muros, donde tus datos tienen permiso para residir

Una guía práctica para mantener tus agentes de IA dentro de tu propio entorno: tus prompts, documentos y un registro de cada paso se quedan en sistemas que tú controlas, y cada petición pasa por un único punto de control que puedes ver.

La mayoría de los despliegues de agentes que fracasan no fracasan por la calidad del modelo. Fracasan en la revisión de seguridad, cuando alguien pregunta a dónde van los datos y la respuesta es un diagrama con una línea de puntos que apunta a un tercero. La solución no es un mejor argumento de venta. Es un límite claro, trazado antes de que el primer prompt salga del edificio.

Este es el límite de confianza: la línea que separa lo que posees y controlas de lo que un proveedor simplemente da soporte. Trázalo bien y la revisión de seguridad se convierte en una lista de respuestas de una línea. Trázalo mal y cada pregunta se convierte en una renegociación.

Dos planos, una línea

La forma más limpia de trazar el límite es dividir el sistema en dos planos.

El plano de datos es propiedad del cliente. Los prompts, los documentos de origen, los embeddings, los índices de recuperación, las trazas de ejecución y los logs permanecen dentro de la infraestructura que el cliente controla. Esta es la carga regulada. Bajo el RGPD es donde residen los datos personales; bajo el Reglamento de IA de la UE es donde se generan los registros que prueban la conformidad. Si cualquier parte cruza el límite, tienes una transferencia que justificar, un encargado de tratamiento con quien contratar y una afirmación de residencia que defender.

El plano de control cuenta con el soporte del proveedor y transporta únicamente metadatos. Orquestación del despliegue, paneles de observabilidad, manifiestos de versiones, definiciones de políticas, comprobaciones de estado y contadores de uso agregados. El plano de control sabe que un flujo de trabajo se ejecutó, qué versión de prompt usó, si superó la política y cuánto tardó. No sabe qué contenía el documento ni qué escribió el usuario.

La disciplina está en la palabra “únicamente”. Un plano de control que envía prompts completos de vuelta al proveedor para “depuración” ha movido el límite en silencio. La prueba es concreta: si cortaras la conexión con el proveedor en la capa de red, el plano de datos debería seguir atendiendo solicitudes. La gobernanza podría pausarse. El servicio no debería.

Regla práctica: si perder el enlace con el proveedor te impide atender a tus clientes, tu plano de datos no es realmente tuyo.

Los siete componentes dentro del límite

Un plano de datos que mantiene la línea no es una sola cosa. Son siete componentes que encajan entre sí, y nombrarlos es lo que permite a un revisor de seguridad seguir una solicitud de principio a fin sin salir del límite.

  1. Una capa de modelos privada. La inferencia se ejecuta dentro del límite sobre modelos de pesos abiertos servidos por vLLM, TGI u Ollama, o sobre un modelo de frontera aprobado al que se accede a través de controles que el cliente posee. Los pesos y el runtime están en la cuenta del cliente, no en la de un proveedor.
  2. La puerta de enlace de IA. El único punto de política, detallado más abajo. Cada llamada pasa por ella.
  3. Una capa de conocimiento con recuperación consciente de permisos. Los agentes recuperan solo lo que el usuario o el flujo de trabajo que llama ya tiene permiso para ver.
  4. Un runtime de agentes. Cada agente es un objeto gobernado con un responsable, un propósito, herramientas permitidas, un presupuesto, un nivel de riesgo y una batería de evaluación, no un prompt suelto.
  5. Un trace lake. Cada ejecución se registra en el entorno del cliente bajo las convenciones semánticas de OpenTelemetry GenAI, de modo que la evidencia es portable y no el formato privado de un proveedor.
  6. Evaluación y reproducción. Las trazas reales se convierten en pruebas de regresión, de modo que puedes cambiar un prompt, un modelo, un recuperador o una herramienta y probar que el cambio es seguro antes de desplegarlo.
  7. Analítica de flujos de trabajo. Coste por flujo de trabajo, tasa de éxito, tasa de aprobación, tasa de automatización, tiempo ahorrado y razones de escalada, calculadas sobre el trace lake, que alimentan la decisión de promover un flujo de trabajo por la escalera de autonomía.

Los componentes del uno al seis viven en el plano de datos. Solo los agregados del siete, despojados de carga, son el tipo de metadatos que el plano de control tiene permiso para ver.

La puerta de enlace de IA como único punto de política

Dentro del plano de datos, la arquitectura necesita un único lugar donde se decida la política, en lugar de dispersarla por el código de la aplicación. Ese lugar es la puerta de enlace de IA. Cada llamada de agente, recuperación e invocación de herramienta pasa por ella, lo que la convierte en el único componente que un revisor de seguridad puede leer para entender qué se está aplicando.

Una puerta de enlace que merezca ser desplegada gestiona, como mínimo:

  • Enrutamiento. Qué modelo atiende qué solicitud, por tarea, inquilino o clase de sensibilidad. Pesos abiertos para clasificación masiva, un modelo de frontera aprobado para los casos que lo necesiten.
  • Autenticación y RBAC. Autorización consciente de la identidad en cada llamada, de modo que una solicitud herede los permisos de quien la realiza en lugar de los del agente.
  • Presupuestos. Límites de gasto y de tasa por inquilino y por flujo de trabajo, aplicados antes de la llamada, no reconciliados en la factura.
  • Redacción de PII. Detección y enmascaramiento a la entrada y a la salida, de modo que los campos sensibles nunca lleguen a un modelo que no los necesita.
  • Versionado de prompts. Cada prompt fijado a una versión, registrado junto con la respuesta, de modo que un cambio en el comportamiento se corresponda con un cambio que puedas nombrar.
  • Caché. Prefijos repetidos y contexto recuperado con frecuencia pagados una vez, no una vez por llamada.
  • Registro. Cada llamada escrita en el trace lake, de modo que la puerta de enlace es también el punto donde se genera la evidencia.
  • Respaldo (fallback). Comportamiento definido cuando un modelo es lento, está caído o devuelve una infracción de política: reintentar, degradar o rechazar. Nunca un fallo silencioso.

Centralizar todo esto convierte la gobernanza en algo que configuras y auditas en un único archivo, no en una propiedad que esperas que se mantenga en cuarenta puntos de llamada.

Recuperación consciente de los permisos

La recuperación es donde se ocultan la mayoría de las fugas de datos. Una configuración RAG ingenua indexa todo y deja que el agente recupere la coincidencia más cercana, lo que significa que un agente puede mostrar un documento que el usuario nunca tuvo permiso para leer. El índice se convierte en un canal lateral que rodea tus controles de acceso.

La recuperación consciente de los permisos lo cierra. El paso de recuperación filtra según la identidad de quien llama y el alcance del flujo de trabajo antes del ranking por similitud, de modo que el conjunto de candidatos solo contiene documentos que el usuario ya puede ver. La lista de control de acceso viaja con la consulta. Un agente que actúa en nombre de un analista junior no puede recuperar el dossier del consejo, porque el dossier del consejo se filtra antes de que se le pida siquiera al modelo razonar sobre él. Esta es la diferencia entre un agente que respeta tus permisos existentes y uno que los esquiva por debajo.

Elegir un destino de despliegue

Dónde se ejecuta físicamente el plano de datos depende del perfil regulatorio y de amenazas del equipo. No hay una única respuesta correcta, solo una defendible.

VPC (nube privada virtual). La opción por defecto para la mayoría de los equipos regulados en finanzas, sanidad y seguros. El plano de datos se ejecuta dentro de la propia cuenta de nube del cliente, bajo sus claves KMS, su política de red, su registro de auditoría. El proveedor accede a través de una conexión de plano de control acotada que transporta metadatos. Esto satisface la mayoría de las expectativas de control operativo de DORA y NIS2 sin renunciar a la economía de la nube gestionada.

On-premise o con aislamiento físico (air-gapped). Para defensa, infraestructura crítica y el trabajo de inteligencia e industrial más sensible. El plano de datos se ejecuta en hardware propiedad del cliente, a menudo sin ninguna ruta de salida a internet. El plano de control, si existe, se sincroniza a través de un diodo controlado o mediante exportación manual. La capa de modelos privada importa más aquí, porque un sistema con aislamiento físico no puede llamar a una API de frontera alojada y depende de pesos abiertos servidos localmente.

Región soberana. Para la residencia de datos del RGPD, donde el requisito es que los datos personales permanezcan dentro de una jurisdicción específica. El plano de datos se ejecuta en un despliegue dentro de la región, de modo que no se necesitan Cláusulas Contractuales Tipo para una transferencia de la UE hacia otro lugar, porque no hay transferencia. La afirmación de residencia es estructural, no contractual.

Edge o en el dispositivo. Para visión por computador, robótica y trabajo de campo donde la latencia, la conectividad intermitente o el ancho de banda descartan un viaje de ida y vuelta a un clúster central. La inferencia se ejecuta en el dispositivo o en un nodo edge cercano. El plano de datos es el propio dispositivo; el plano de control recopila metadatos cuando la conectividad lo permite. Los modelos de pesos abiertos más pequeños se ganan su lugar aquí por tamaño y latencia.

El límite se mantiene en los cuatro casos. Lo que cambia es hasta dónde puede llegar el proveedor y cuánto del plano de control sobrevive. El plano de datos siempre es tuyo.

Una postura agnóstica al modelo

Nada de esto presupone un único proveedor de modelos, y no debería. La puerta de enlace enruta hacia lo que mejor atienda la solicitud: pesos abiertos donde encajan por calidad, coste o desplegabilidad, y un modelo de frontera aprobado donde la tarea realmente lo exige. El límite de confianza hace que esto sea práctico. Como la puerta de enlace es el punto de política y el plano de datos es tuyo, cambiar de modelo es un cambio de enrutamiento detrás del límite, no una nueva evaluación de transferencia de datos. El componente de evaluación y reproducción es lo que hace que el cambio sea seguro: ejecutas el modelo candidato contra casos trazados reales y lees la regresión antes de hacer el cambio. La dependencia de un único modelo es un pasivo de gobernanza antes que uno comercial.

Qué pregunta realmente la revisión de seguridad

Una revisión de seguridad real no es abstracta. Es una lista de preguntas puntuales, y una arquitectura dentro del límite responde a cada una en una línea.

  • ¿Dónde residen nuestros datos? En tu VPC, on-premise o región soberana. El plano de datos nunca sale de ahí.
  • ¿Qué ve el proveedor? Solo metadatos: versiones, tiempos, resultados de política, recuentos agregados. Ningún prompt, ningún documento.
  • ¿Puede un agente leer datos que el usuario no puede? No. La recuperación filtra según los permisos de quien llama antes del ranking.
  • ¿Qué pasa si un modelo está caído? La puerta de enlace recurre a un respaldo según una política definida: reintentar, degradar o rechazar. El servicio continúa.
  • ¿Cómo hacemos una transferencia transfronteriza bajo el RGPD? No la hacemos. El despliegue en región soberana implica que no se necesitan SCC.
  • ¿Puedes probar qué hizo un prompt el martes pasado? Sí. Cada prompt está versionado y registrado con su respuesta en tu trace lake.
  • ¿Cuál es el radio de impacto si el proveedor sufre una brecha? El plano de control. Tus datos no están en él.
  • ¿Quién custodia las claves de cifrado? Tú, en tu KMS. El proveedor no puede descifrar tu plano de datos.
  • ¿Estáis monitorizando a nuestros empleados? No. Las trazas instrumentan agentes y flujos de trabajo. Los datos personales que contienen se redactan en la puerta de enlace, y el Anexo III del Reglamento de IA de la UE trata la monitorización laboral como de alto riesgo, así que el diseño optimiza flujos de trabajo, no personas.

Si tu arquitectura no puede responder a estas preguntas en frases de una sola línea, la revisión lo pondrá de manifiesto, normalmente tarde, después de la construcción. El límite de confianza es el diseño que hace que las respuestas sean cortas. Traza la línea primero, ejecuta la gobernanza a través de una única puerta de enlace, mantén los datos donde tienen permiso para residir, y el resto del despliegue deja de ser una discusión y empieza a ser una lista de comprobación.