Sistema de IA de agentes multiusuario

Last reviewed 2026-10-16 UTC

En este documento, se proporciona una arquitectura de referencia para ayudarte a diseñar e implementar un sistema de IA de agentes multiusuario en Google Cloud. A medida que tu organización escala las implementaciones de IA generativa, las diferentes unidades de negocio requieren agentes de IA especializados que accedan a herramientas únicas, sigan reglas operativas específicas y procesen datos sensibles. Las unidades de negocio pueden desarrollar silos de aplicaciones fragmentados dentro de una organización, lo que puede causar una alta sobrecarga operativa, brechas de administración graves y un riesgo de exposición de datos. Esta arquitectura te muestra cómo crear un sistema centralizado que te permita potenciar a los equipos descentralizados con capacidades de IA autónomas mientras mantienes una seguridad y un cumplimiento unificados.

El público previsto para este documento incluye arquitectos, desarrolladores y administradores que crean y administran sistemas multiagente de nivel empresarial en la nube. En el documento, se supone que tienes conocimientos básicos sobre IA, AA y conceptos de LLM, y de IA de agentes.

En la sección Implementación de este documento, se proporciona una estrategia de implementación para ayudarte a compilar e implementar un sistema de IA de agentes multiusuario.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura para un sistema de IA de agentes multiusuario que sigue un modelo de concentrador y radio. Un modelo de concentrador y radio es un diseño de red en el que un entorno central, conocido como concentrador, se conecta a varios entornos aislados, conocidos como radios.

Una arquitectura que muestra un sistema de IA de agentes multiusuario.

La arquitectura consta de los siguientes componentes:

Controles del servicio de VPC
La arquitectura usa los Controles del servicio de VPC para configurar un perímetro de servicio a nivel de la organización. Este perímetro de servicio proporciona un límite de seguridad estricto y ayuda a evitar el robo de datos.
Centro de enrutamiento

El concentrador de enrutamiento actúa como el punto de entrada central de la arquitectura y contiene los siguientes componentes:

  • Balanceador de cargas de aplicaciones externo: Actúa como el punto de entrada central para los usuarios externos o internos. El balanceador de cargas ayuda a garantizar que solo el tráfico autenticado y seguro llegue al portal de frontend.
  • Google Cloud Armor y Model Armor: El balanceador de cargas integra Cloud Armor y Model Armor para inspeccionar y limpiar las instrucciones maliciosas en el perímetro de la red. El concentrador de enrutamiento usa Service Extensions en el balanceador de cargas de aplicaciones externo para integrar Model Armor directamente en el flujo de solicitudes.
  • Identity-Aware Proxy (IAP): Aplica un modelo de confianza cero para verificar la identidad y el contexto del usuario antes de que cualquier solicitud llegue a la aplicación.
  • Portal de frontend: Es una aplicación de Cloud Run sin servidores que actúa como un motor de enrutamiento para dirigir las solicitudes al proyecto de usuario aislado adecuado.
Centro de seguridad y administración centralizado

El centro de seguridad central es un proyecto dedicado Google Cloudque proporciona Identity and Access Management (IAM), registro, supervisión y seguridad centralizados para toda la plataforma. Este concentrador incluye los siguientes componentes:

  • Security Command Center: Es un servicio que supervisa todo el sistema de IA de agentes multiusuario para detectar riesgos de seguridad.
  • IAM: Es un framework de control de acceso que administra identidades y permisos en los concentradores compartidos y los proyectos de usuario. Este componente proporciona una administración centralizada para todas las identidades humanas y de máquinas.
  • Cloud Logging: Es un sistema que agrega registros de los concentradores compartidos y de los proyectos de usuario aislados en el concentrador central de administración y seguridad.
Proyectos de usuarios

Cada proyecto de usuario es un proyecto de Google Cloud dedicado para cada unidad de negocio. Los proyectos de usuario individuales son entornos aislados que incluyen los siguientes componentes:

Flujo de agentes

El sistema multiusuario de ejemplo de la arquitectura anterior tiene el siguiente flujo:

  1. La solicitud de un usuario se enruta a través de un balanceador de cargas de aplicaciones externo. Dentro del concentrador de enrutamiento, se completan estas verificaciones para garantizar que solo el tráfico autenticado y seguro llegue al portal de frontend:
    1. Cloud Armor aplica políticas de seguridad para absorber cualquier ataque de denegación de servicio distribuido (DSD) inicial basado en el protocolo de red de capa 4. Cloud Armor inspecciona la solicitud y filtra el tráfico malicioso, como la inyección de SQL (SQLi), las secuencia de comandos entre sitios (XSS) y las firmas de bots conocidas.
    2. Model Armor intercepta la carga útil para detectar y rechazar ataques de inyección de instrucciones o intenciones maliciosas.
    3. Si alguna de estas capas detecta una amenaza o un acceso no autorizado, el balanceador de cargas descarta la solicitud en el perímetro de la red.
    4. Si las capas de seguridad no detectan ninguna amenaza y validan el acceso del usuario, el balanceador de cargas enruta el tráfico al servicio de backend.
  2. Si la solicitud pasa todas las verificaciones, el balanceador de cargas la enruta a la plataforma de frontend, que realiza las siguientes acciones:
    1. Extrae la identidad del usuario, como la unidad de negocios o el ID de usuario.
    2. Usa IAP para verificar la identidad corporativa y el estado del dispositivo del usuario.
    3. Usa un registro mantenido de forma dinámica para identificar el inquilino de destino correcto.
  3. El portal de frontend enruta la solicitud al inquilino. Para garantizar que el agente no pueda acceder a otros proyectos de usuario ni a servicios de Google Cloud no autorizados, Agent Runtime usa una política de PAB para limitar los recursos a los que puede acceder el agente.
  4. Model Armor usa Sensitive Data Protection para inspeccionar y enmascarar de forma dinámica cualquier información de identificación personal (IIP) o contenido restringido. Model Armor realiza una verificación adicional de las inyecciones de instrucciones maliciosas de la solicitud para garantizar que el agente solo procese datos seguros.

  5. Gemini realiza las siguientes tareas para generar una respuesta:

    1. Realiza un pase de razonamiento inicial para comprender la intención del usuario.
    2. Si Gemini determina que carece de datos específicos, genera un plan para llamar a las herramientas de datos específicas del usuario:
      1. Para verificar si un usuario tiene permiso para acceder a los recursos de datos, el agente verifica la identidad del usuario y las vinculaciones de roles de IAM.
      2. Para recuperar el contexto, el agente ejecuta una llamada a la herramienta a través del servidor de MCP al almacén de datos del usuario.
      3. El agente crea una respuesta fundamentada combinando su lógica interna con los hechos específicos del usuario que acaba de recuperar.

    Si Gemini no necesita datos adicionales, genera una respuesta y la envía a Model Armor.

  6. Model Armor inspecciona y enmascara de forma dinámica cualquier IIP o contenido restringido, y envía la respuesta limpia al agente de usuario. Esta inspección final ayuda a garantizar que no se filtren datos sensibles en el resultado.

  7. La respuesta se enruta de vuelta al usuario, desde el agente de usuario, a través de la plataforma de frontend y, luego, a través del balanceador de cargas.

Productos usados

En esta arquitectura de referencia, se usan los siguientes productos y herramientas de código abierto y de Google Cloud , elegidos por su naturaleza sin servidores, escalabilidad y funciones de seguridad:

  • Controles del servicio de VPC: Es una funcionalidad de herramientas de redes administradas que minimiza los riesgos de robo de datos para tus recursos de Google Cloud .
  • Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.
  • Google Cloud Armor: Es un servicio de seguridad de redes que ofrece reglas de firewall de aplicación web (WAF) y ayuda a proteger contra ataques DSD y de aplicaciones.
  • Model Armor: Es un servicio que protege tus recursos de IA generativa y de agentes contra la inyección de instrucciones, las filtraciones de datos sensibles y el contenido dañino.
  • Identity-Aware Proxy (IAP): Es un servicio que habilita un modelo de acceso de confianza cero para tus aplicaciones y máquinas virtuales.
  • Identity and Access Management (IAM): Es un sistema que te permite crear y administrar permisos para los recursos de Google Cloud .
  • Cloud Run: Una plataforma de computación sin servidores que te permite ejecutar contenedores directamente sobre la infraestructura escalable de Google.
  • Gemini Enterprise Agent Platform: Es una plataforma integral que te permite crear, escalar, administrar y optimizar agentes de IA de nivel empresarial.
  • Gemini: Es una familia de modelos de IA multimodales desarrollados por Google.
  • Protocolo de contexto del modelo (MCP): Es un estándar de código abierto para conectar aplicaciones de IA a sistemas externos.
  • Cloud Logging: Un sistema de administración de registros en tiempo real con almacenamiento, búsqueda, análisis y alertas.

Caso de uso

Los sistemas de IA de agentes multiusuario son adecuados para las organizaciones empresariales que quieren escalar las implementaciones de IA generativa más allá de una sola aplicación. Para identificar los casos de uso para los que es adecuada esta arquitectura, analiza tus procesos empresariales y detecta los diferentes equipos que requieren sus propios agentes de IA especializados que accedan a herramientas únicas y datos sensibles. Este enfoque te ayuda a empoderar a los equipos descentralizados con capacidades de IA autónomas, mientras mantienes la seguridad unificada y el cumplimiento corporativo.

A continuación, se muestra un ejemplo de caso de uso de un sistema de IA de agentes multiusuario.

Atención al cliente en toda la empresa

Puedes adaptar esta arquitectura de referencia para proporcionar atención al cliente potenciada por IA en distintas divisiones empresariales. Por ejemplo, para admitir una división de electrónica y una división de artículos para el hogar, implementas un agente de electrónica y un agente de artículos para el hogar como dos agentes independientes en proyectos de usuario independientes. Estos agentes de IA especializados actúan como asistentes inteligentes que manejan consultas de asistencia específicas de cada división accediendo a especificaciones técnicas, garantías o políticas de devoluciones únicas. Esta automatización permite que los equipos de asistencia humana se enfoquen en derivaciones de clientes más complejas.

Para este caso de uso, la arquitectura proporciona los siguientes beneficios:

  • Aislamiento estricto de datos: El diseño multiusuario ayuda a garantizar que el conocimiento de asistencia de cada división esté estrictamente aislado. La política de PAB proporciona protecciones que ayudan a garantizar que una identidad de agente en un usuario no pueda acceder a los datos de otro usuario.
  • Conocimiento especializado del agente: Debido a que cada agente reside en un proyecto de usuario aislado, el agente solo recupera el contexto de su almacén de datos específico de la división. Esta recuperación segmentada ayuda a mejorar la precisión y evita que el agente confunda las políticas de diferentes unidades de negocio.
  • Menor riesgo entre dominios: La arquitectura ayuda a eliminar el riesgo de exposición de datos entre las unidades de negocio. Incluso si se vulnera la identidad de un agente, este no puede acceder a recursos de Google Cloud no autorizados.

Esta arquitectura es ideal para grandes organizaciones y empresas de venta minorista que administran varias marcas o unidades de negocios distintas y que requieren una soberanía de los datos estricta.

Alternativas de diseño

En esta sección, se presentan enfoques de diseño alternativos que puedes considerar para tu implementación de IA de agentes multiusuario en Google Cloud.

Implementación del acceso privado

En la arquitectura que se describe en este documento, los usuarios acceden al sistema de IA de agentes multiusuario a través de la Internet pública con un balanceador de cargas de aplicaciones externo expuesto de forma centralizada. Si tu organización requiere un sistema que permanezca inaccesible desde la Internet pública, puedes adaptar la arquitectura para usar una de las siguientes estrategias de acceso privado.

Bloquea el tráfico con políticas de seguridad perimetral

Para permitir el tráfico solo desde las direcciones IP corporativas verificadas de tu organización, puedes configurar las políticas de seguridad de Cloud Armor para rechazar cualquier otro tráfico. Esta regla de seguridad de alta prioridad bloquea todas las solicitudes no autorizadas en el perímetro de la red. Para tener una capa de seguridad adicional, puedes usar IAP para exigir una sesión de identidad corporativa válida y puedes configurar permisos de IAM para todos los usuarios.

Este enfoque te permite aprovechar las políticas de seguridad perimetral de Cloud Armor para descargar la mitigación de DSD y el filtrado de WAF, como SQLi y XSS, y proporciona una experiencia de confianza cero. Sin embargo, la dirección IP de frontend del balanceador de cargas de aplicaciones externo sigue siendo pública y es posible que no cumpla con los requisitos de cumplimiento de algunas organizaciones.

Enruta el tráfico a través de un balanceador de cargas de aplicaciones interno

La arquitectura de este documento usa un balanceador de cargas de aplicaciones externo, que proporciona políticas de Cloud Armor sólidas, funciones de seguridad más avanzadas y una menor complejidad operativa en comparación con los balanceadores de cargas internos. Sin embargo, el uso de un balanceador de cargas externo implica que el tráfico atraviesa la Internet pública.

Para mantener el tráfico por completo dentro de la red privada de Google, puedes usar un balanceador de cargas de aplicaciones interno. El uso de un balanceador de cargas de aplicaciones interno admite IAP para la verificación de identidad. Un balanceador de cargas de aplicaciones externo global evalúa las políticas de IAP en la capa perimetral. Por el contrario, un balanceador de cargas de aplicaciones interno evalúa las políticas en la capa de red interna. Debido a que el tráfico nunca recorre la Internet pública, el uso de un balanceador de cargas de aplicaciones interno te ayuda a cumplir con los requisitos estrictos de soberanía de los datos y de cero direcciones IP públicas.

Para mantener una latencia baja y cumplir con los requisitos regionales de residencia de datos, implementa un balanceador de cargas de aplicaciones interno regional en cada región principal. Con un balanceador de cargas de aplicaciones interno regional, enrutas el tráfico desde entornos locales a través de Cloud Interconnect o de Cloud VPN directamente a la dirección IP interna del balanceador de cargas. Un balanceador de cargas de aplicaciones interno regional admite Cloud Armor regional para la protección de WAF interna. Sin embargo, en comparación con un balanceador de cargas de aplicaciones externo, los balanceadores de cargas de aplicaciones internos regionales admiten un conjunto limitado de políticas de seguridad de Cloud Armor, carecen de funciones de seguridad avanzadas y aumentan la complejidad operativa.

Para minimizar aún más la latencia y garantizar la alta disponibilidad para cumplir con tus requisitos de recuperación ante desastres, puedes implementar un balanceador de cargas de aplicaciones interno entre regiones. Con un balanceador de cargas de aplicaciones interno entre regiones, usas Cloud DNS con políticas de enrutamiento de ubicación geográfica para resolver la URL interna de la aplicación en el balanceador de cargas de aplicaciones interno entre regiones en la región deGoogle Cloud que está más cerca del usuario. Sin embargo, una configuración interregional no admite ninguna integración de Cloud Armor.

Infraestructura de procesamiento

Para priorizar un enfoque que priorice las tecnologías sin servidores que proporcione una administración más sencilla y una menor sobrecarga operativa, la arquitectura de este documento usa Cloud Run para su infraestructura de procesamiento. También puedes ejecutar aplicaciones alojadas en contenedores en clústeres de GKE. Google Kubernetes Engine (GKE) es un motor de organización de contenedores que automatiza la implementación, el escalamiento y la administración de aplicaciones alojadas en contenedores. GKE es totalmente compatible con los balanceadores de cargas de aplicaciones internos y externos. Si deseas obtener información para elegir un servicio de procesamiento para tus cargas de trabajo en Google Cloud, consulta Aloja aplicaciones en Google Cloud.

Servidores de MCP locales y compartidos

Para permitir que los componentes de tu sistema de agentes interactúen, debes establecer protocolos de comunicación claros. El MCP es un protocolo abierto que proporciona una interfaz estandarizada para que los agentes accedan a las herramientas, los datos y otros servicios necesarios, y los usen.

Para conectar los agentes de tu usuario a tu almacén de datos, considera los requisitos de tu aplicación y elige entre las siguientes opciones de implementación del servidor de MCP. Cuando elijas entre implementaciones de MCP locales y compartidas, considera las compensaciones entre el aislamiento de datos y la eficiencia operativa.

  • Servidor de MCP local: Un servidor de MCP local o un servidor de MCP específico del inquilino es un servidor de MCP que implementas en cada proyecto de inquilino y que proporciona a los agentes acceso a los almacenes de datos y las herramientas específicos de esa unidad empresarial.

    A continuación, se indican las características y consideraciones clave de los servidores de MCP locales:

    • Red: Un perímetro de Controles del servicio de VPC a nivel del proyecto y la política de PAB proporcionan seguridad y aislamiento inherentes, lo que ayuda a garantizar que no haya acceso entre usuarios.
    • Administración: Los equipos de desarrolladores y operaciones individuales administran los proyectos de los usuarios de forma independiente. Este aislamiento proporciona autonomía para cada unidad de negocio.
    • Seguridad: Los límites fijos de IAM del proyecto de usuario ayudan a minimizar las superficies de riesgo lateral y no requieren asignaciones de identidad complejas.

    Los servidores de MCP locales ofrecen el máximo aislamiento y pueden controlar el acceso a datos altamente sensibles o regulados. Sin embargo, si implementas varios servidores de MCP locales, aumentarás tu carga operativa. Recomendamos los servidores de MCP locales para las aplicaciones que requieren acceso restrictivo a almacenes de datos que podrían contener información sensible.

  • Servidor de MCP compartido: Un servidor de MCP compartido o un servidor de MCP global es un servidor de MCP que implementas en un proyecto de servicios compartidos. Los servidores de MCP compartidos proporcionan acceso a herramientas y sistemas que son comunes en varios usuarios.

    A continuación, se indican las características y consideraciones clave para los servidores de MCP compartidos:

    • Red: Para garantizar que el tráfico no atraviese la Internet pública, los servidores de MCP compartidos requieren conectividad privada, como Private Service Connect o intercambio de tráfico entre redes de VPC.
    • Administración: Un equipo de operaciones centralizado administra la implementación para todo el sistema. Esta administración consolidada optimiza la eficiencia operativa y quita el requisito de duplicar las implementaciones locales en varios usuarios.
    • Seguridad: Propagas de forma segura la identidad del usuario final desde el agente en el proyecto de usuario al servidor de MCP compartido. Para garantizar que los usuarios solo puedan acceder a los datos que tienen permitido o modificarlos, el servidor de MCP compartido usa la identidad del usuario propagada para aplicar un control de acceso detallado en el sistema de backend.

    Los servidores de MCP compartidos centralizan la administración de las herramientas comunes, lo que reduce la duplicación y optimiza la eficiencia operativa. Aunque los servidores de MCP compartidos reducen la sobrecarga de administración, requieren una lógica sólida de propagación de identidad y autorización para mantener un acceso seguro. Recomendamos los servidores de MCP compartidos para las interacciones con sistemas y herramientas corporativos comunes, como las herramientas de informes de gastos, los sistemas de recursos humanos (RR.HH.), las bases de conocimiento de toda la empresa o los administradores de asistencia.

En esta arquitectura, usas servidores de MCP para estandarizar la conexión entre tus agentes de usuario y tus almacenes de datos. Según los requisitos de tu carga de trabajo, puedes usar otros tipos de herramientas de agentes para conectar tus agentes con APIs y sistemas externos específicos. Para obtener más información sobre las interacciones de las herramientas del agente, consulta Herramientas del agente.

Consideraciones del diseño

En las siguientes secciones, se describen los factores de diseño, las prácticas recomendadas y las recomendaciones que debes tener en cuenta cuando usas esta arquitectura de referencia para desarrollar una topología que cumpla con tus requisitos específicos de seguridad, confiabilidad, costo y rendimiento. La guía de esta sección no está completa. Según los requisitos de tu carga de trabajo, y los productos y funciones que uses, puede haber factores de diseño y compensaciones adicionales que deberías considerar.

Security, privacy, and compliance

En esta sección, se describen las consideraciones y recomendaciones de diseño para crear una topología en Google Cloud que cumpla con los requisitos de seguridad, privacidad y cumplimiento de tu carga de trabajo.

Consideraciones de seguridad para los agentes

Los agentes de IA presentan ciertos riesgos de seguridad únicos y críticos que las prácticas de seguridad convencionales y determinísticas podrían no mitigar de forma adecuada. Google recomienda un enfoque para agentes de IA seguros que combina las fortalezas de los controles de seguridad determinísticos con defensas dinámicas basadas en el razonamiento. Este enfoque se basa en tres principios fundamentales: la supervisión humana, la autonomía de los agentes definida con cuidado y la observabilidad. A continuación, se presentan recomendaciones específicas que se alinean con estos principios fundamentales:

  • Supervisión humana: En ocasiones, un sistema de IA de agentes puede fallar o no funcionar como se espera. Por ejemplo, el modelo podría generar contenido impreciso o un agente podría seleccionar herramientas inapropiadas. En los sistemas de IA de agentes esenciales para la empresa, incorpora un flujo con intervención humana para que los supervisores humanos puedan supervisar, anular y pausar a los agentes. Por ejemplo, los usuarios humanos pueden revisar el resultado de los agentes, aprobar o rechazar los resultados y proporcionar más orientación para corregir errores o tomar decisiones estratégicas. Este enfoque combina la eficiencia de los sistemas de IA de agentes con el pensamiento crítico y la experiencia en el dominio de los usuarios humanos.
  • Identidad del agente y acceso con privilegio mínimo:
    • Proporciona a cada agente una identidad vinculada a la carga de trabajo y basada en SPIFFE con la identidad del agente. Puedes usar la identidad del agente cuando implementes agentes en Agent Runtime o en Cloud Run.
    • Configura los permisos por agente con las políticas de acceso de IAM y el control de acceso de Agent Platform con IAM. Otorga a cada agente solo los permisos que necesita para realizar sus tareas y comunicarse con las herramientas y con otros agentes. Para aislar aún más cada agente y limitar el impacto potencial de una violación de la seguridad, vincula una política de PAB a la identidad del agente.
    • Cuando los agentes necesiten autenticarse en herramientas externas o en APIs de terceros, usa el administrador de autenticación de Agent Identity. Con este enfoque, puedes controlar de forma centralizada los tokens de OAuth y las claves de API, en lugar de tener que incorporar credenciales en el código o las instrucciones del agente.

  • Administración del tráfico de entrada y salida: Enruta el tráfico de agentes a través de Agent Gateway para aplicar políticas de seguridad del entorno de ejecución en los límites de entrada y salida. Para obtener información sobre las plataformas de Agent Runtime que admiten Agent Gateway, consulta Agent Runtime compatibles.

    • De cliente a agente (entrada): Implementa Agent Gateway antes de Agent Runtime. La puerta de enlace ayuda a autenticar a los emisores y a inspeccionar las instrucciones entrantes en tiempo real con Model Armor.

    • Del agente a cualquier lugar (salida):

      • Enrutar las solicitudes salientes de agente a agente (A2A) y de agente a herramienta (MCP) a través de Agent Gateway en modo de salida
      • Aplica políticas de acceso de denegación predeterminada con las políticas de acceso de IAM y la IAP.
      • Verifica que los agentes y las herramientas de destino estén registrados en Agent Registry.
      • Inspecciona las invocaciones y respuestas de las herramientas salientes con Model Armor para ayudar a evitar el robo de datos, la inyección de instrucciones indirectas y el uso inadecuado de las herramientas.

  • Supervisión: Supervisa el comportamiento de los agentes con capacidades de seguimiento integrales que te brindan visibilidad de cada acción que realiza un agente, incluidos su proceso de razonamiento, la selección de herramientas y las rutas de ejecución. Para obtener más información, consulta Registra un agente en Agent Runtime y Registra en ADK.

Para obtener más información sobre cómo proteger los agentes de IA, consulta Seguridad para agentes de IA.

Consideraciones de seguridad de la nube privada virtual (VPC)

En esta arquitectura, implementas cada usuario en un proyecto de Google Cloud dedicado. Para crear un límite de seguridad estricto, combina el aislamiento a nivel del proyecto de usuario con la política de PAB y los Controles del servicio de VPC a nivel de la organización.

Consideraciones de seguridad de IAM

Para implementar el principio de privilegio mínimo, usa un modelo de acceso basado en roles. Por ejemplo, puedes definir roles de IAM personalizados para garantizar que un desarrollador que compila un agente en un usuario no pueda acceder a los datos de otro usuario.

Consideraciones de seguridad de Cloud Armor

Cloud Armor proporciona seguridad y protección de WAF para defender el portal de frontend contra ataques DSD y vulnerabilidades web. Un balanceador de cargas de aplicaciones externo global admite el kit completo de funciones perimetrales avanzadas, como la administración de bots y la Protección adaptable de Google Cloud Armor.

Si implementas un balanceador de cargas de aplicaciones interno regional, Cloud Armor opera con un conjunto restringido de políticas de WAF estándar. El conjunto restringido de políticas se adapta a los límites de la red interna y, además, incluye políticas como la protección contra SQLi y XSS. Para obtener más información, consulta Integra Cloud Armor con otros productos de Google.

Consideraciones de seguridad de Agent Platform

Para garantizar que la configuración y el uso de Agent Platform cumplan con tus requisitos de seguridad, ten en cuenta las siguientes recomendaciones:

  • Responsabilidad compartida: La seguridad es una responsabilidad compartida. Agent Platform protege la infraestructura subyacente y proporciona herramientas y controles de seguridad para ayudarte a proteger tus datos, código y modelos. Eres responsable de configurar correctamente tus servicios, administrar los controles de acceso y proteger tus aplicaciones. Para obtener más información, consulta Responsabilidad compartida de la plataforma de agentes.
  • Controles de seguridad: Agent Platform admite Google Cloud controles de seguridad que puedes usar para cumplir con tus requisitos de residencia de datos, claves de encriptación administradas por el cliente (CMEK), seguridad de redes con Controles del servicio de VPC y Transparencia de acceso. Para obtener más información, consulta la siguiente documentación:
  • Seguridad: Los modelos de IA pueden producir respuestas dañinas, a veces en respuesta a instrucciones maliciosas.
    • Para mejorar la seguridad y mitigar el posible uso inadecuado del sistema de IA de agentes, puedes configurar filtros de contenido para que actúen como barreras contra las entradas y respuestas dañinas. Para obtener más información, consulta Filtros de seguridad y contenido.
    • Para inspeccionar y limpiar las solicitudes de inferencia, las instrucciones de los agentes, las llamadas a herramientas y las respuestas en busca de amenazas, como la inyección de instrucciones y el contenido dañino, puedes usar Model Armor para las llamadas directas a la API del modelo y para las solicitudes que se enrutan a través de Agent Gateway. Model Armor te ayuda a evitar entradas maliciosas, verificar la seguridad del contenido, proteger datos sensibles, mantener el cumplimiento y aplicar políticas de seguridad de manera coherente.
  • Acceso a modelos: Puedes configurar políticas de la organización para limitar el tipo y las versiones de los modelos de IA que se pueden usar en un proyecto de Google Cloud . Para obtener más información, consulta Controla el acceso a los modelos de Model Garden.
  • Protección de datos: Para descubrir y desidentificar datos sensibles en las instrucciones y respuestas, y en los datos de registro, usa la API de Cloud Data Loss Prevention. Para obtener más información, consulta este video: Protege datos sensibles en apps de IA.

  • Extremos de modelos compartidos: Para ayudar a evitar el abuso y garantizar un uso justo de los extremos de modelos compartidos, implementa una de las siguientes estrategias:

    • Límite de frecuencia a nivel de usuario: Aplica cuotas en el portal de frontend para cada usuario antes de que las solicitudes lleguen al extremo compartido. Para aplicar las cuotas, haz lo siguiente:

      1. Extrae la identidad del usuario del contexto de IAP.
      2. Realiza un seguimiento del uso en comparación con los límites predefinidos para cada usuario con un almacén externo, como Memorystore para Redis.
      3. Rechaza las solicitudes de los usuarios que superen sus límites.

    • API Gateway: Para aplicar cuotas por usuario con claves de API y planes de uso, implementa API Gateway antes del extremo compartido.

Consideraciones de seguridad del MCP

Para garantizar que tu implementación de MCP cumpla con tus requisitos de seguridad, ten en cuenta las siguientes recomendaciones:

  • Registro y descubrimiento de herramientas: Registra servidores y herramientas de MCP en Agent Registry para que los agentes solo se conecten a extremos de MCP inventariados y aprobados por el administrador.
  • Control de acceso e inspección de tráfico: Enruta el tráfico de agente a MCP a través de Agent Gateway en el modo Agent-to-Anywhere (salida) y protege los servidores de MCP (como los servidores de MCP alojados en Cloud Run) con IAP y políticas de acceso de IAM. Configura Model Armor o las políticas de administración semántica en Agent Gateway para inspeccionar las entradas y salidas de la herramienta de MCP en busca de exposición de datos sensibles y de inyección de instrucciones indirecta.
  • Seguridad general del MCP: Cuando configures tus agentes para que usen el MCP, asegúrate de que el acceso a los datos y las herramientas externos esté autorizado, implementa controles de privacidad, como la encriptación, aplica filtros para proteger los datos sensibles y supervisa las interacciones de los agentes. Para obtener más información, consulta MCP y seguridad.

Consideraciones de seguridad de Cloud Run

Para mejorar la postura de seguridad del portal de frontend, prioriza la renderización del servidor (SSR) sobre la renderización del cliente (CSR). En comparación con la CSR, la SSR ofrece los siguientes beneficios:

  • Ejecuta la lógica de la aplicación y administra los secretos dentro de un entorno Google Cloud controlado.
  • Reduce la superficie de ataque del cliente y ayuda a evitar que se filtren datos sensibles al navegador no confiable del usuario.
  • Limita la exposición de datos, ya que solo envía el HTML necesario al cliente.
  • Proporciona codificación de salida centralizada para defenderse de los ataques de secuencia de comandos entre sitios (XSS).

Consideraciones de seguridad de Security Command Center

Para supervisar las amenazas y aplicar políticas de seguridad, como la autenticación de varios factores (MFA) y la encriptación de datos, usa las herramientas de Security Command Center.

Más recomendaciones de seguridad

Confiabilidad

En esta sección, se describen las consideraciones y recomendaciones de diseño para compilar y operar una infraestructura confiable para tu implementación en Google Cloud.

Consideraciones de confiabilidad de Cloud Load Balancing

Un balanceador de cargas de aplicaciones externo global proporciona una sola dirección IP Anycast que enruta automáticamente el tráfico de los usuarios al perímetro de Google más cercano. Esta configuración reduce la latencia a través de la terminación perimetral de la capa de conexión segura (SSL). También ayuda a garantizar la alta disponibilidad si una región experimenta una interrupción, ya que redirecciona el tráfico de forma inteligente a backends regionales en buen estado.

Consideraciones sobre la confiabilidad de los usuarios

Para tolerar o controlar las fallas a nivel del agente, implementa agentes en proyectos de usuario aislados. Este aislamiento ayuda a garantizar que los problemas operativos o los incidentes de seguridad permanezcan dentro de una sola unidad de negocios y no afecten a otros recursos ni a otras unidades de negocios.

Consideraciones de confiabilidad de Agent Platform

Si la cantidad de solicitudes al modelo supera la capacidad asignada, el modelo devuelve el código de error 429. Para las cargas de trabajo que son fundamentales para la empresa y que requieren una alta capacidad de procesamiento constante, puedes reservar capacidad de procesamiento con la capacidad de procesamiento aprovisionada.

Consideraciones de confiabilidad de Agent Runtime

Para garantizar que la configuración y el uso de Agent Runtime cumplan con tus requisitos de confiabilidad, ten en cuenta las siguientes recomendaciones:

  • Escalabilidad sin servidores: Los agentes que se implementan en Agent Runtime se escalan de forma independiente según la demanda. Un aumento repentino en el uso de un usuario no agota los recursos de procesamiento ni afecta la disponibilidad de un agente en otro proyecto de usuario.
  • Manejo de errores: Para controlar errores transitorios, como los límites de frecuencia del código de error 429, la lógica de organización del agente usa la retirada exponencial. Si se supera un plazo de contexto, el agente realiza un cierre ordenado y, luego, informa el progreso parcial al usuario. Por ejemplo, se puede superar un plazo de contexto debido a llamadas lentas a herramientas, latencia de APIs de terceros, procesamiento de conjuntos de datos masivos o procesamiento con uso intensivo de procesamiento.

Para conocer los principios y las recomendaciones de confiabilidad específicos de las cargas de trabajo de IA y AA, consulta Perspectiva de IA y AA: Confiabilidad en el Well-Architected Framework.

Eficiencia operativa

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar una topología de Google Cloud que puedas operar de manera eficiente.

Consideraciones sobre Google Cloud Observability

Logging y Cloud Monitoring te permiten supervisar el estado y el rendimiento de toda la plataforma. Puedes configurar alertas para detectar y solucionar problemas de forma proactiva sin permitir el acceso a datos sensibles.

Consideraciones de eficiencia operativa para todos los productos de la arquitectura

El uso de Agent Platform dentro de un patrón de arquitectura de usuario estandarizado te permite establecer un modelo de referencia coherente cuando incorporas usuarios nuevos. Para reducir la carga operativa, automatiza el proceso de implementación con herramientas de infraestructura como código (IaC), como Terraform. Para obtener el código de Terraform que puedes usar para compilar e implementar un sistema de IA de agentes multiusuario, consulta la sección Implementación de este documento.

Para conocer los principios y las recomendaciones de excelencia operativa específicos de las cargas de trabajo de IA y AA, consulta Perspectiva de IA y AA: Excelencia operativa en el Well-Architected Framework.

Optimización de costos

En esta sección, se proporciona orientación para optimizar el costo de configurar y operar una topología de Google Cloud que compilas con esta arquitectura de referencia.

Consideraciones de costos de Agent Platform

Para garantizar que la configuración y el uso de Agent Platform cumplan con tus requisitos de costos, ten en cuenta las siguientes recomendaciones:

  • Consumo de tokens: Para administrar los costos y evitar que tu modelo de IA exceda las ventanas de contexto, usa las siguientes estrategias para administrar el contexto del modelo de IA:
    • Resumen de contexto: En lugar de guardar una conversación de sesión completa como contexto, usa un modelo de IA para resumir la conversación más antigua y la información menos crítica.
    • Elimina resultados: Identifica y quita las partes menos relevantes o detalladas de los resultados de la herramienta o el contexto recuperado. Por ejemplo, si solo necesitas los nombres de las columnas de tus datos, puedes quitar los metadatos excesivos de una recuperación de esquema de base de datos. Esta estrategia requiere una lógica personalizada que use heurística, filtrado o un modelo de lenguaje pequeño (SLM) para extraer la información más importante.
    • Límite máximo de tokens: Para ayudar a evitar bucles infinitos y controlar los costos, aplica un límite máximo de tokens por sesión.

  • Extremos de modelos: Para administrar las cuotas de la API y el uso de recursos, puedes implementar extremos de Agent Platform en una configuración dedicada o compartida:

    • Extremos dedicados: Cuando implementas extremos dentro de cada proyecto de usuario, proporcionas un aislamiento de cuota inherente. El uso de cada usuario se descuenta de sus propias cuotas de proyecto, lo que evita el impacto entre usuarios. En comparación con los extremos compartidos, los extremos dedicados ofrecen una administración de cuotas más sencilla. Sin embargo, los extremos dedicados te impiden aprovechar el ahorro potencial de costos de un extremo compartido.
    • Extremos compartidos: Para optimizar los costos, puedes alojar un extremo compartido en el centro de seguridad y administración central. Debido a que todos los usuarios comparten el mismo grupo de cuotas, para ayudar a prevenir ataques maliciosos, debes implementar estrategias de mitigación, como la límite de frecuencia a nivel de usuario o la aplicación de cuotas con API Gateway. En comparación con los extremos dedicados, los extremos compartidos son más rentables. Sin embargo, los extremos compartidos requieren un esfuerzo de ingeniería adicional y pueden generar latencia y sobrecarga de administración.

    Para obtener información sobre los costos en Agent Platform, consulta Costo de crear y, luego, implementar modelos de IA en Agent Platform.

Consideraciones de costos de Cloud Run

La instrumentación te permite supervisar el rendimiento, solucionar problemas y hacer un seguimiento del uso de recursos de cada usuario. Para identificar el usuario de cada solicitud, extrae la identidad del usuario del contexto que proporciona IAP. Para obtener información sobre cómo instrumentar tu aplicación, consulta Elige un enfoque de instrumentación.

Consideraciones de costos de Model Armor

Para aplicar una gobernanza estricta y una postura de confianza cero, esta arquitectura implementa Model Armor en dos capas: en el concentrador de enrutamiento y dentro de cada proyecto de usuario. Aunque este enfoque de dos capas ayuda a garantizar la soberanía de los datos, aumenta la latencia y los costos operativos. Para reducir los costos y la complejidad del sistema, filtra todas las instrucciones y respuestas implementando Model Armor exclusivamente en el centro de enrutamiento.

Consideraciones de costos para todos los productos de la arquitectura

Para asegurarte de que tu arquitectura cumpla con tus requisitos de costos, ten en cuenta las siguientes recomendaciones generales:

  • Infraestructura compartida: Los componentes de infraestructura principal compartidos, como el portal de frontend, el centro de seguridad y administración central, y Agent Platform, pueden reducir los costos en comparación con la creación de una pila personalizada independiente para cada agente.

  • Sobrecarga de la plataforma: Para distribuir los costos compartidos del centro de seguridad y administración central, usa un modelo de asignación que se ajuste a tus capacidades de seguimiento y patrones de uso. Te recomendamos que uses uno de los siguientes modelos de asignación de costos:

    • Asignación de división uniforme: Un modelo de división uniforme asigna los costos compartidos de manera equitativa entre todos los usuarios. Usa este modelo cuando la plataforma sea una utilidad de referencia o cuando la sobrecarga del seguimiento detallado supere los beneficios de costos.
    • Asignación proporcional: Un modelo proporcional o un proceso de devolución de cargo asigna los costos compartidos en función de la proporción de costos directos en los que incurre cada usuario. Usa este modelo cuando el consumo de los usuarios varíe de forma drástica y tengas una telemetría sólida, como las etiquetas de Resource Manager y el análisis de registros, para atribuir los costos con precisión.
    • Asignación fija: Un modelo fijo o por niveles asigna costos compartidos en función de coeficientes definidos por la empresa. Usa este modelo cuando los usuarios requieran diferentes acuerdos de nivel de servicio (ANS). Una asignación de modelo fija te permite cobrar tarifas fijas por las capacidades dedicadas premium en comparación con las capacidades compartidas estándar.

    Para obtener más información sobre cómo asignar costos de servicios compartidos, consulta Cloud FinOps: Asignación de costos de servicios compartidos.

  • Administración de costos centralizada: Para realizar un seguimiento preciso del costo total de propiedad (TCO) de tu sistema de IA de agentes y atribuir costos a unidades de negocio individuales, usa etiquetas y datos de exportación de Facturación de Cloud. Para obtener más información sobre cómo usar etiquetas para conocer los costos, consulta Fomenta una cultura de conocimiento de los costos.

Para estimar el costo de tus recursos de Google Cloud , usa la calculadora de precios deGoogle Cloud .

Para conocer los principios y las recomendaciones de optimización de costos específicos de las cargas de trabajo de IA y AA, consulta Perspectiva de IA y AA: Optimización de costos en el Well-Architected Framework.

Implementación

Para implementar esta arquitectura de referencia, usa el ejemplo de Terraform de IA de agentes multiusuario que está disponible en GitHub.

¿Qué sigue?

Colaboradores

Autores:

  • Shivank Awasthi | Arquitecto de soluciones de campo
  • Utkarsh Bhardwaj | Consultor de soluciones técnicas, IA de agentes, apps, plataformas de Cloud e infraestructura

Otros colaboradores: