IA en producción en AWS: Amazon Bedrock y AgentCore en una configuración privada

En AWS, las piezas para un agente en producción han cambiado más en los últimos doce meses que en los tres años anteriores: Bedrock Agents pasó a ser Agents Classic, AgentCore tomó el relevo como plataforma de agentes y Bedrock tiene ahora cuatro niveles de inferencia. Esta es la configuración que montaría hoy para un agente que debe superar una revisión de seguridad: IAM de mínimo privilegio, PrivateLink en lugar de internet, una base de conocimiento gestionada, guardrails en entrada y salida, evaluaciones en el pipeline y cada invocación registrada. Todos los datos enlazan con la documentación de AWS.

Dominik Heinrich

7 de noviembre de 202611 min de lectura

1. Cuándo AWS es el lugar adecuado y el estado de Bedrock a finales de 2026

AWS es la opción evidente cuando tus datos y cargas ya viven allí: buckets de S3 con los documentos, Aurora o DynamoDB con los datos de negocio, IAM y Organizations como columna vertebral de seguridad. Un agente que corre junto a esos datos necesita menos integraciones y hereda controles que ya auditas.

El panorama de productos ha cambiado. Amazon Bedrock es la capa de modelos e inferencia, y Amazon Bedrock AgentCore es la plataforma para construir, desplegar y operar agentes de forma segura y a escala, con cualquier framework y modelo fundacional. La guía de usuario de Bedrock indica ya que no es posible darse de alta en Amazon Bedrock Agents, que AWS llama ahora Agents Classic; quien ya lo usa puede seguir, y los nuevos agentes definidos por código se dirigen a AgentCore. Varias piezas de AgentCore llegaron a disponibilidad general en 2026, por ejemplo Evaluations el 31 de marzo de 2026 y el harness gestionado de agentes el 17 de junio de 2026.

Para las decisiones de arquitectura uso como lista de control la AWS Well-Architected Generative AI Lens. Cubre lo mismo que este artículo, desde la protección de datos hasta los costes, y es un buen documento para un comité de seguridad o arquitectura.

2. Cuentas e IAM: mínimo privilegio para personas, apps y agentes

Separa no producción y producción en cuentas de AWS distintas bajo AWS Organizations. Así el acceso a modelos, las cuotas, los guardrails y los logs difieren por cuenta, y un experimento no puede tocar datos de producción por accidente.

Da a cada componente su propio rol de IAM con un alcance estrecho. El rol de la aplicación puede invocar uno o dos modelos concretos, el de la base de conocimiento puede leer un prefijo de S3 y nada recibe bedrock:* sobre todos los recursos. Para las personas y sistemas en cuyo nombre actúa tu agente, AgentCore Identity gestiona la identidad, el acceso y la autenticación del agente y funciona con proveedores de identidad existentes como Amazon Cognito, Okta, Microsoft Entra ID o Auth0, sin migrar usuarios ni rehacer el inicio de sesión.

El control más sencillo y valioso es una lista explícita de IDs de modelo en IAM. Impide que alguien cambie producción a un modelo caro con una sola línea y da al equipo de seguridad un único lugar para revisar qué modelos se usan.

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeOnlyApprovedModels",
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": [
        "arn:aws:bedrock:eu-central-1::foundation-model/<approved-model-id>"
      ]
    }
  ]
}

Consejo práctico

Muchos modelos actuales se llaman mediante inference profiles para inferencia entre regiones. Comprueba el ARN exacto que indica la documentación del modelo antes de escribir la política, o la llamada fallará con AccessDenied.

3. Red privada: endpoints de PrivateLink y AgentCore en modo VPC

Con AWS PrivateLink accedes a Amazon Bedrock como si estuviera en tu VPC, sin internet gateway, NAT, VPN ni Direct Connect. La documentación de Bedrock enumera endpoints de interfaz separados por familia de API: bedrock para el plano de control, bedrock-runtime para inferencia, bedrock-agent y bedrock-agent-runtime para las API de agentes y bases de conocimiento, bedrock-mantle y variantes FIPS. Crea los que tu aplicación llama de verdad, activa el DNS privado y añade una política de endpoint que solo permita tus roles.

El agente también debe vivir en tu red. AgentCore Runtime y sus herramientas integradas, como Code Interpreter, pueden ejecutarse en modo VPC: les das tus subredes y un grupo de seguridad y llegan a tus bases de datos y API internas de forma privada. El tráfico saliente sigue entonces tu enrutamiento de VPC, y un filtro central de salida decide a qué hosts externos puede llegar un agente.

Aquí se decide también la residencia de datos. Elige la región a conciencia y comprueba si un modelo solo se ofrece mediante inferencia entre regiones antes de prometer a un cliente que los datos nunca salen de una geografía.

bash

# Interface endpoint for inference (repeat for bedrock-agent-runtime etc.)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.eu-central-1.bedrock-runtime \
  --subnet-ids subnet-0123456789abcdef0 subnet-0123456789abcdef1 \
  --security-group-ids sg-0123456789abcdef0 \
  --private-dns-enabled

# AgentCore Runtime in VPC mode (network part; add your agent artifact and role)
aws bedrock-agentcore-control create-agent-runtime \
  --agent-runtime-name "MyAgentRuntime" \
  --network-configuration '{
    "networkMode": "VPC",
    "networkModeConfig": {
      "subnets": ["subnet-0123456789abcdef0", "subnet-0123456789abcdef1"],
      "securityGroups": ["sg-0123456789abcdef0"]
    }
  }'

Arquitectura en AWS: los usuarios llegan a la aplicación por un Application Load Balancer; dentro de una VPC, la app y AgentCore Runtime en modo VPC llaman a los modelos de Amazon Bedrock por endpoints de interfaz; el agente usa AgentCore Gateway, Memory y una base de conocimiento gestionada de Bedrock sobre S3; Bedrock Guardrails revisa entrada y salida; IAM y AgentCore Identity controlan el acceso; CloudWatch y AgentCore Evaluations observan al agente. — Configuración de referencia en AWS: AgentCore Runtime en modo VPC, Bedrock por PrivateLink, una base de conocimiento gestionada, guardrails en cada llamada y evaluaciones en CloudWatch.

4. Tus datos: primero una base de conocimiento gestionada, después un pipeline RAG propio

Amazon Bedrock Knowledge Bases ofrece dos tipos. Con una base de conocimiento gestionada, Bedrock se encarga de la ingesta, la indexación, el almacenamiento y la recuperación, incluidos datos multimodales, almacenamiento con autoescalado y recuperación agéntica para preguntas de varios saltos; AWS recomienda este tipo por precisión y facilidad de operación. Con una base gestionada por el cliente, ejecutas tu propio almacén vectorial, como Amazon OpenSearch Serverless, Amazon Aurora o Amazon Neptune, y controlas tú el parsing, la indexación y el almacenamiento.

Para una primera versión elijo por defecto el tipo gestionado. La mayoría de los problemas de RAG que veo no vienen de la base de datos vectorial, sino de documentos desactualizados, permisos que faltan en las fuentes y fragmentos que parten una tabla por la mitad. Invierte el tiempo ahorrado en los datos: un responsable claro por fuente, un calendario de sincronización y un conjunto de preguntas de prueba en el que sabes qué documento contiene la respuesta.

Pasa a un almacén gestionado por ti cuando haya un motivo concreto: un clúster de OpenSearch existente con tu ajuste de búsqueda, un caso de grafos para Neptune o requisitos regulatorios sobre dónde y cómo se guarda el índice.

5. Modelos y capacidad: Standard, Flex, Priority, Reserved o aprovisionado

Bedrock y AgentCore ofrecen una amplia elección de modelos, entre ellos Claude de Anthropic, Amazon Nova, Meta Llama y Mistral, y AgentCore funciona también con modelos de OpenAI y Google Gemini. Elige por paso: un modelo pequeño para clasificar y extraer, uno más potente donde importa el razonamiento, y mantén la elección detrás de la lista de IAM del paso 2.

Para la capacidad, Bedrock ofrece ahora cuatro niveles de servicio. Standard es el valor por defecto para el día a día. Flex da un descuento para cargas que toleran tiempos de proceso más largos, como evaluaciones, resúmenes o trabajos de agentes en segundo plano. Priority ofrece las respuestas más rápidas con recargo y se fija por petición con el parámetro service_tier. Reserved reserva capacidad en tokens por minuto durante uno o tres meses, apunta a un 99,5 % de disponibilidad, desborda a Standard cuando necesitas más y empieza en 100.000 tokens de entrada y 10.000 de salida por minuto.

Provisioned Throughput con model units es un mecanismo aparte, sobre todo para modelos personalizados, sin compromiso o con plazos de uno o seis meses. Mi regla: empezar con Standard, pasar ya los trabajos batch y de evaluación a Flex y reservar capacidad solo tras unas semanas de datos de tráfico reales.

Consejo práctico

Al dimensionar la capacidad Reserved, AWS advierte que el consumo de tokens por minuto incluye los tokens de entrada de escritura en caché si usas prompt caching. Suma ambas métricas en CloudWatch o la reserva se quedará corta.

6. El agente en AgentCore: runtime, gateway, memoria y herramientas

AgentCore es modular y solo usas lo que necesitas. El Runtime es un entorno serverless para desplegar y escalar agentes y herramientas, con aislamiento de sesión, identidad integrada y soporte para trabajo largo y asíncrono. El harness gestionado define un agente por configuración, con modelo, prompt de sistema y herramientas en línea, y ejecuta cada sesión en una microVM aislada. Gateway convierte tus API, funciones Lambda y servicios existentes en herramientas compatibles con MCP y se conecta a servidores MCP existentes. Memory aporta memoria a corto plazo para una conversación y a largo plazo entre sesiones. Code Interpreter y Browser son herramientas aisladas, y Observability muestra cada paso del recorrido de ejecución de un agente.

El Gateway es la parte que diseñaría con más cuidado. Cada herramienta que expones es una acción que el agente puede ejecutar con permisos reales. Expón herramientas estrechas y con un propósito, por ejemplo consultar un pedido por ID, en lugar de una consulta genérica a la base de datos, y da al backend de la herramienta su propio rol de mínimo privilegio.

El framework lo eliges tú: AgentCore funciona con frameworks de código abierto como Strands Agents, LangGraph, LangChain o LlamaIndex. Elige el que tu equipo sepa depurar a las dos de la madrugada, no el que tiene más estrellas.

Amazon Bedrock AgentCore: Deploy & Operate AI Agents in Minutes, Amazon Web Services (YouTube). Se carga desde YouTube solo cuando haces clic.

7. Guardrails: ataques de prompt, datos personales y comprobación de fundamentación

Amazon Bedrock Guardrails reúne varias salvaguardas en un guardrail que asocias a las llamadas al modelo o aplicas por separado. Los filtros de contenido cubren odio, insultos, contenido sexual, violencia, mala conducta y ataques de prompt, cada uno con su intensidad. Los temas denegados bloquean asuntos de los que tu aplicación nunca debe hablar. Los filtros de información sensible bloquean o enmascaran datos personales como nombres, direcciones o números de identificación y admiten expresiones regulares propias. Las comprobaciones de fundamentación contextual marcan respuestas que no están respaldadas por la fuente recuperada o no responden a la pregunta, la comprobación de alucinaciones más barata para una app RAG. Las comprobaciones de Automated Reasoning validan respuestas contra reglas lógicas que defines.

Hay dos niveles. El nivel Standard amplía la detección, por ejemplo a contenido dañino escondido en comentarios de código o nombres de variables, y requiere inferencia entre regiones; el nivel Classic no. Decídelo a conciencia si la residencia de datos es estricta.

Construye el guardrail como código, versiónalo y dale su propio conjunto de prompts de ataque. El ejemplo de abajo bloquea ataques de prompt en la entrada, enmascara correos y teléfonos y comprueba la fundamentación y la relevancia de las respuestas.

bash

aws bedrock create-guardrail \
  --name support-agent-guardrail \
  --blocked-input-messaging "Sorry, I can't help with that request." \
  --blocked-outputs-messaging "Sorry, I can't answer that." \
  --content-policy-config '{
    "filtersConfig": [
      {"type": "PROMPT_ATTACK", "inputStrength": "HIGH", "outputStrength": "NONE"},
      {"type": "MISCONDUCT", "inputStrength": "HIGH", "outputStrength": "HIGH"}
    ]
  }' \
  --sensitive-information-policy-config '{
    "piiEntitiesConfig": [
      {"type": "EMAIL", "action": "ANONYMIZE"},
      {"type": "PHONE", "action": "ANONYMIZE"}
    ]
  }' \
  --contextual-grounding-policy-config '{
    "filtersConfig": [
      {"type": "GROUNDING", "threshold": 0.8},
      {"type": "RELEVANCE", "threshold": 0.7}
    ]
  }'

Consejo práctico

El filtro de ataques de prompt se aplica a la entrada; pon su intensidad de salida en NONE como en el ejemplo. Ajusta el umbral de fundamentación con tu propio conjunto de pruebas: demasiado alto bloquea buenas respuestas, demasiado bajo deja pasar las inventadas.

8. Evaluar, registrar cada invocación, vigilar el coste y comparar las nubes

AgentCore Evaluations está disponible de forma general desde el 31 de marzo de 2026. Evalúa agentes de forma continua con tráfico de producción y en flujos de prueba, con 13 evaluadores integrados de calidad de respuesta, seguridad, cumplimiento de tareas y uso de herramientas, además de ground truth como respuestas de referencia, aserciones de comportamiento y secuencias esperadas de herramientas. Úsalo como puerta de regresión en tu pipeline de CI/CD: un cambio en instrucciones, herramientas o modelo no debe bajar las puntuaciones de la última release aceptada.

Para auditoría y depuración, activa el registro de invocaciones del modelo. Recoge logs de invocación con la entrada y salida del modelo de todas las llamadas a Bedrock de una cuenta y región, en CloudWatch Logs, S3 o ambos. Trata estos logs como datos sensibles: cifrado, retención y acceso tan estrictos como para los documentos de origen. AgentCore Observability añade la vista a nivel de agente, con trazas de cada paso, sobre CloudWatch.

Los fallos que más veo: IAM con comodín en bedrock:*, agentes con salida a internet sin filtro, un guardrail que nunca se probó con prompts de ataque, logs de invocación legibles por todos y capacidad Reserved comprada antes de medir el tráfico. La misma configuración en Microsoft Azure está en /blog/azure-ai-foundry, y en Google Cloud en /blog/google-vertex-ai.

Conclusión
En AWS, la receta para producción es IAM de mínimo privilegio, PrivateLink y modo VPC para la privacidad, una base de conocimiento gestionada para tus datos, guardrails como código y AgentCore Evaluations como puerta que cada cambio debe pasar.

Proyectos reales relacionados

Pruébalo tú mismo

Listo para producción

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos