Sistema de IA de agentes multiusuario

Last reviewed 2026-06-18 UTC

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

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

En la sección de 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 con agentes multiusuario que sigue un modelo de centro y radios. 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 múltiples multiusuario.

La arquitectura consta de los siguientes componentes:

Componente Descripción
VPC Service Controls 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 evita el robo de datos.
Central de rutas

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 usuarios externos o internos. El balanceador de cargas garantiza 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 centro 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: Una aplicación de Cloud Run sin servidores que actúa como motor de enrutamiento para dirigir las solicitudes al proyecto de usuario aislado adecuado.
Centro de seguridad y administración central

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

  • Security Command Center: Es un servicio que supervisa todo el sistema de IA con agentes de múltiples arrendatarios en busca de riesgos de seguridad.
  • IAM: Es un framework de control de acceso que administra identidades y permisos en los centros compartidos y los proyectos de usuarios. Este componente proporciona administración centralizada para todas las identidades humanas y de máquinas.
  • Cloud Logging: Un sistema que agrega registros de los hubs compartidos y de los proyectos de inquilinos aislados en el hub central de seguridad y administración.
Proyectos de usuarios

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

Flujo de agente

El sistema multiusuario de ejemplo en 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. En el centro 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 borde 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 inquilino del usuario.
    2. Usa IAP para verificar la identidad corporativa del usuario y el estado del dispositivo.
    3. Usa un registro que se mantiene de forma dinámica para identificar el arrendatario de destino correcto.
  3. El portal de frontend enruta la solicitud al arrendatario. Para garantizar que el agente no pueda acceder a otros proyectos de inquilinos ni a servicios Google Cloudno 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 (PII) 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 hechos específicos, genera un plan para llamar a las herramientas de datos específicas del arrendatario:
      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 en el almacén de datos del arrendatario.
      3. El agente crea una respuesta fundamentada combinando su lógica interna con los hechos específicos del inquilino recuperados recientemente.

    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 saneada al agente del arrendatario. Esta inspección final ayuda a garantizar que no se filtre ningún dato sensible en el resultado.

  7. La respuesta se enruta de vuelta al usuario, desde el agente del arrendatario 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, elegidos por su naturaleza sin servidores, escalabilidad y funciones de seguridad: Google Cloud

Caso de uso

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

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

Servicio de atención al cliente en toda la empresa

Puedes adaptar esta arquitectura de referencia para brindar atención al cliente potenciada por IA en diferentes divisiones comerciales. Por ejemplo, para brindar asistencia a una división de artículos electrónicos y una división de artículos para el hogar, implementas un agente de artículos electrónicos y un agente de artículos para el hogar como dos agentes separados en proyectos de inquilinos separados. Estos agentes de IA especializados actúan como asistentes inteligentes que manejan las consultas de asistencia específicas de la división, ya que acceden 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 las derivaciones de clientes más complejas.

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

  • Aislamiento estricto de los datos: El diseño multiusuario garantiza que el conocimiento de asistencia para cada división esté estrictamente aislado. La política de PAB proporciona parámetros de seguridad que ayudan a garantizar que la identidad de un agente en un arrendatario no pueda acceder a los datos de otro arrendatario.
  • 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 garantiza una alta precisión y evita que el agente confunda las políticas de diferentes unidades de negocios.
  • Menor riesgo entre dominios: La arquitectura ayuda a eliminar el riesgo de exposición de datos entre las unidades de negocios. Incluso si se vulnera la identidad de un agente, este no puede acceder a recursos Google Cloud no autorizados.

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

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 de acceso privado

En la arquitectura que se describe en este documento, los usuarios acceden al sistema de IA con agentes de múltiples arrendatarios a través de Internet pública a través de un balanceador de cargas de aplicaciones externo expuesto de forma centralizada. Si tu organización requiere un sistema que permanezca inaccesible desde 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 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 solicitar una sesión de identidad corporativa válida y configurar permisos de IAM para todos los usuarios.

Este enfoque te permite aprovechar las políticas de seguridad perimetrales 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.

Cómo enrutar 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 significa que el tráfico atraviesa la Internet pública.

Para mantener el tráfico completamente 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 del 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 atraviesa la Internet pública, el uso de un balanceador de cargas de aplicaciones interno te ayuda a cumplir con los estrictos requisitos de soberanía de los datos y de cero direcciones IP públicas.

Para mantener una latencia baja y cumplir con los requisitos de residencia de datos regionales, implementa un balanceador de cargas de aplicaciones interno regional en cada región principal. Con un balanceador de cargas de aplicaciones interno regional, puedes enrutar el tráfico desde entornos locales a través de Cloud Interconnect o 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 del WAF interno. 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 una alta disponibilidad que satisfaga 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 por 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ónGoogle Cloud más cercana al usuario. Sin embargo, una configuración entre regiones no admite ninguna integración de Cloud Armor.

Infraestructura de procesamiento

Para priorizar un enfoque que privilegie el uso de una arquitectura 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 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 en contenedores. GKE admite completamente los balanceadores de cargas de aplicaciones internos y externos. Para obtener información sobre cómo elegir un servicio de procesamiento para tus cargas de trabajo en Google Cloud, consulta Hosting de aplicaciones enGoogle Cloud.

Servidores del Protocolo de contexto del modelo (MCP)

Para permitir que los componentes de tu sistema basado en 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 arrendatario a tu almacén de datos, considera los requisitos de tu aplicación para elegir 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 los datos y la eficiencia operativa.

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

    A continuación, se indican las funciones y consideraciones clave para los servidores de MCP locales:

    • Red: Un perímetro de Controles del servicio de VPC a nivel del proyecto y una política de PAB proporcionan seguridad y aislamiento inherentes, lo que ayuda a garantizar que no haya acceso entre arrendatarios.
    • Administración: Los equipos individuales de desarrollo y operaciones administran los proyectos de inquilinos de forma independiente. Este aislamiento proporciona autonomía a cada unidad de negocio.
    • Seguridad: Los límites fijos de IAM del proyecto del arrendatario ayudan a minimizar las superficies de riesgo laterales 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 locales de MCP, aumentará tu carga operativa. Recomendamos usar servidores MCP locales para las aplicaciones que requieren acceso restrictivo a los almacenes de datos que pueden 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 MCP compartidos proporcionan acceso a herramientas y sistemas que son comunes en varios grupos de usuarios.

    Estas son las funciones y consideraciones clave para los servidores de MCP compartidos:

    • Red: Para garantizar que el tráfico no atraviese 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 de todo el sistema. Esta administración consolidada optimiza la eficiencia operativa y elimina 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 del arrendatario al servidor de MCP compartido. Para garantizar que los usuarios solo puedan acceder a los datos que tienen permiso para ver o modificar, 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. Si bien los servidores de MCP compartidos reducen la sobrecarga de administración, requieren una propagación de identidad y una lógica de autorización sólidas para mantener el acceso seguro. Recomendamos servidores de MCP compartidos para las interacciones con sistemas y herramientas corporativos comunes, como herramientas de informes de gastos, sistemas de recursos humanos (RR.HH.), bases de conocimiento en toda la empresa o administradores de asistencia.

En esta arquitectura, usas servidores de MCP para estandarizar la conexión entre los agentes de tu arrendatario y tus almacenes de datos. Según los requisitos de tu carga de trabajo, es posible que uses 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 con 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, es posible que debas considerar factores de diseño y compensaciones adicionales.

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.

Componente Consideraciones y recomendaciones de diseño
Nube privada virtual (VPC) Aislamiento de usuarios: 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 del arrendatario con la política de PAB y los Controles del servicio de VPC a nivel de la organización.
IAM Control de acceso: Para implementar el principio de privilegio mínimo, usa un modelo de acceso basado en arquetipos. Por ejemplo, puedes definir roles de IAM personalizados para garantizar que un desarrollador que crea un agente en un arrendatario no pueda acceder a los datos de otro arrendatario.
Cloud Armor

Protección de WAF interna y perimetral: 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 operará con un conjunto restringido de políticas estándar del WAF. 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 la inyección de SQL y la XSS. Para obtener más información, consulta Integra Cloud Armor con otros productos de Google.
Agent Platform

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

  • Limitación de frecuencia a nivel del arrendatario: Aplica cuotas en el portal de frontend para cada arrendatario antes de que las solicitudes lleguen al endpoint compartido. Para aplicar las cuotas, haz lo siguiente:
    1. Extrae la identidad del arrendatario del contexto de IAP.
    2. Realiza un seguimiento del uso en función de los límites predefinidos para cada arrendatario con un almacén externo, como Memorystore para Redis.
    3. Rechaza las solicitudes de los arrendatarios que superen sus límites.
  • API Gateway: Para aplicar cuotas por arrendatario con claves de API y planes de uso, implementa API Gateway antes del endpoint compartido.
Cloud Run

Renderización de contenido: Para mejorar la seguridad del portal de frontend, prioriza la renderización del servidor (SSR) por 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 evita las filtraciones de datos sensibles al navegador no confiable del usuario.
  • Limita la exposición de datos, ya que solo envía el código HTML necesario al cliente.
  • Proporciona codificación de salida centralizada para protegerse contra ataques de secuencia de comandos entre sitios (XSS).
Security Command Center Supervisión de seguridad centralizada: 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 del 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.

Componente Consideraciones y recomendaciones de diseño
Cloud Load Balancing Enrutamiento global: Un balanceador de cargas de aplicaciones externo global proporciona una sola dirección IP Anycast que enruta automáticamente el tráfico de usuarios al perímetro de Google geográfico más cercano. Esta configuración reduce la latencia a través de la terminación de la capa de conexión segura (SSL) perimetral. También garantiza la alta disponibilidad si una región experimenta una interrupción, ya que redirige el tráfico de forma inteligente a los backends regionales en buen estado.
Usuario Tolerancia a fallas: Para tolerar o controlar las fallas a nivel del agente, implementa agentes en proyectos de inquilinos 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 o unidades de negocios.
Agent Platform Planificación de la capacidad: 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 capacidad de procesamiento alta de forma constante, puedes reservar capacidad de procesamiento con la capacidad de procesamiento aprovisionada.
Agent Runtime

Escalabilidad sin servidores: Los agentes implementados en Agent Runtime se escalan de forma independiente según la demanda. Un aumento repentino en el uso de un arrendatario no agota los recursos de procesamiento ni afecta la disponibilidad de un agente en otro proyecto de arrendatario.

Manejo de errores: Para manejar errores transitorios, como los límites de frecuencia del código de error 429, la lógica de orquestación del agente usa la retirada exponencial. Si se supera el plazo de contexto, el agente realiza un cierre ordenado y informa al usuario sobre el progreso parcial. Por ejemplo, se puede superar un plazo de contexto debido a llamadas a herramientas lentas, latencia de la API de terceros, procesamiento de conjuntos de datos masivos o procesamiento que requiere mucha capacidad de procesamiento.

Para conocer los principios y las recomendaciones de confiabilidad específicos de las cargas de trabajo de IA y AA, consulta la perspectiva de IA y AA: Confiabilidad en 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.

Componente Consideraciones y recomendaciones de diseño
Google Cloud Observability Supervisión centralizada: Logging y 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.
Todos los productos de la arquitectura Implementaciones estandarizadas: Usar la 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 código de Terraform que puedes usar para compilar e implementar un sistema de IA de agentes de múltiples arrendatarios, 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 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 a través de esta arquitectura de referencia.

Componente Consideraciones y recomendaciones de diseño
Agent Platform

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 contextual: En lugar de guardar toda la conversación de una sesión como contexto, usa un modelo de IA para resumir conversaciones anteriores y la información menos importante.
  • Eliminar salidas: Identifica y quita las partes menos pertinentes o detalladas de las salidas de herramientas o del contexto recuperado. Por ejemplo, si solo necesitas los nombres de las columnas de tus datos, puedes quitar el exceso de metadatos de una recuperación del esquema de la base de datos. Esta estrategia requiere lógica personalizada que utilice heurísticas, filtrado o un modelo de lenguaje pequeño (SLM) para extraer la información más importante.
  • Límite máximo de tokens: Para evitar bucles infinitos y controlar los costos, aplica un límite máximo de tokens por sesión.

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

  • Extremos dedicados: Cuando implementas extremos dentro de cada proyecto de usuario, proporcionas un aislamiento inherente de la cuota. El uso de cada arrendatario se contabiliza en función de las cuotas de su propio proyecto, lo que evita el impacto entre arrendatarios. En comparación con los extremos compartidos, los extremos dedicados ofrecen una administración de cuotas más simple. Sin embargo, los extremos dedicados impiden que aproveches los posibles ahorros de costos de un extremo compartido.
  • Extremos compartidos: Para optimizar los costos, puedes alojar un extremo compartido en el centro central de seguridad y administración. Dado que todos los arrendatarios comparten el mismo grupo de cuotas, para evitar ataques maliciosos, debes implementar estrategias de mitigación, como la límite de frecuencia a nivel del arrendatario 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.
Cloud Run Instrumentación: La instrumentación te permite supervisar el rendimiento, solucionar problemas y hacer un seguimiento del uso de recursos para cada usuario. Para identificar el inquilino 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.
Model Armor Filtrado de instrucciones centralizado: Para aplicar una administración estricta y una postura de confianza cero, esta arquitectura implementa Model Armor en dos capas: en el centro de enrutamiento y dentro de cada proyecto de usuario. Si bien 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.
Todos los productos de la arquitectura

Infraestructura compartida: Los componentes de infraestructura principal compartidos, como el portal de frontend, el centro central de administración y seguridad, 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 forma equitativa entre todos los inquilinos. 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 proceso de devolución de cargos, asigna los costos compartidos según la proporción de costos directos en los que incurre cada usuario. Usa este modelo cuando el consumo del arrendatario varíe de forma drástica y tengas telemetría sólida, como etiquetas de Resource Manager y análisis de registros, para atribuir los costos con precisión.
  • Asignación fija: Un modelo fijo o por niveles asigna los costos compartidos según los coeficientes definidos por la empresa. Usa este modelo cuando los arrendatarios requieran diferentes acuerdos de nivel de servicio (ANS). Una asignación de modelo fija te permite cobrar tarifas fijas por las capacidades premium dedicadas en comparación con las capacidades compartidas estándar.

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

Administración centralizada de costos: Para hacer un seguimiento preciso del costo total de propiedad (TCO) de tu sistema de IA de agentes y atribuir los costos a las unidades de negocios individuales, usa etiquetas y datos de exportación de la Facturación de Cloud. Para obtener más información sobre cómo usar etiquetas para comprender los costos, consulta Fomenta una cultura de conciencia 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 para 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 IA con agentes de Terraform para múltiples arrendatarios que está disponible en GitHub.

¿Qué sigue?

Colaboradores

Autores:

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

Otros colaboradores: