🏠Inicio 📚Certificaciones 📱Aplicaciones Móviles

🎓Información del examen

✍️Blog 📊Progreso 📅Calendario 💬Soporte

Política de Privacidad Términos de Uso Contáctenos Política de Cookies Aviso Legal Accesibilidad DMCA / Derechos de Autor

Ir al contenido

AIP-C01Guía

Guía

AWS Certified Generative AI Developer - Professional

Última revisión: mayo de 2026

Una referencia escaneable de patrones arquitectónicos que evalúa el examen AIP-C01. Lee de arriba a abajo o salta a una sección.

Secciones

Integración de modelos fundacionales, gestión de datos y cumplimiento31 entradas
Implementación e integración33 entradas
Seguridad, protección y gobernanza de la IA24 entradas
Eficiencia operativa y optimización13 entradas
Pruebas, validación y resolución de problemas12 entradas

Integración de modelos fundacionales, gestión de datos y cumplimiento

Seleccione un modelo fundacional de Bedrock para un caso de uso.

Razonamiento de contexto largo + uso de herramientas → Claude (Sonnet/Opus). Chat optimizado para costos → Claude Haiku o Titan Text Lite. Código → Claude o Llama. Embeddings → Titan Embeddings V2 o Cohere Embed. Generación de imágenes → Titan Image, Stable Diffusion o Nova Canvas. Pesos abiertos con control de autoalojamiento → Llama, Mistral o Custom Model Import.

Por qué: Ningún modelo es el mejor en costos, latencia, capacidad y términos de licencia. Haga coincidir la clase de modelo con el cuello de botella.

La fuente de la KB son preguntas frecuentes (FAQs) cortas y autocontenidas o descripciones de productos (~100–500 palabras cada una).

Fragmentación de tamaño fijo con tamaño de token predeterminado (300) y superposición (20%).

Por qué: Las unidades autocontenidas no se benefician de la fragmentación sensible a los límites. El tamaño fijo es lo más simple y económico.

Los documentos tienen cambios de tema naturales dentro de los párrafos; las divisiones de tamaño fijo rompen las oraciones a mitad de idea.

Fragmentación semántica. Las bases de conocimiento de Bedrock agrupan oraciones consecutivas cuyos embeddings son similares, dividiendo en límites de significado.

Por qué: Preserva ideas coherentes dentro de un fragmento → recuperación más limpia, mayor calidad de respuesta.

Manuales técnicos largos con referencias cruzadas entre secciones; las preguntas requieren síntesis en todo un documento.

Fragmentación jerárquica. Bedrock construye fragmentos padre (grandes) + hijo (pequeños); recupera con embeddings de hijo, devuelve el contexto padre.

Por qué: Los fragmentos pequeños proporcionan una recuperación precisa; el contexto padre preserva las referencias cruzadas y los detalles circundantes.

Los archivos de origen ya están fragmentados o cada archivo es intencionalmente una unidad lógica.

Ninguna estrategia de fragmentación. Cada archivo se convierte en un fragmento en la KB.

La fuente PDF contiene texto + diagramas; los usuarios hacen preguntas que requieren comprender los diagramas.

Habilite el análisis avanzado de Bedrock KB con un modelo fundacional (Claude/Nova) como analizador. Los diagramas y tablas se describen mediante visión y luego se incrustan (embedded).

Por qué: El análisis predeterminado es solo texto. El análisis multimodal convierte el contenido visual en texto descriptivo antes de la incrustación (embedding).

Elija Titan Embeddings G1 vs V2.

V2 admite dimensiones configurables (256/512/1024) y supera a G1 en benchmarks multilingües. G1 tiene un tamaño fijo de 1536. Elija V2 para casos de uso con limitaciones de almacenamiento o no ingleses; G1 solo para compatibilidad heredada.

Catálogo de productos de 500K: títulos cortos (50 palabras) + especificaciones largas (500 palabras). Optimizar la calidad de búsqueda + el costo.

Incruste cada elemento una vez (campos combinados o separados). Use Titan Embeddings V2 con dimensiones reducidas (256 o 512) para el costo; incruste la consulta y el documento con el mismo modelo.

Por qué: Mezclar modelos de embedding o omitir la normalización rompe la búsqueda de similitud. Dimensiones más bajas reducen el almacenamiento y el costo de consulta con una pérdida marginal de calidad.

Elija un almacén de vectores para Bedrock Knowledge Bases.

Configuración predeterminada / más rápida → Amazon OpenSearch Serverless (autoadministrado). Sub-ms con actualizaciones frecuentes de esquema + uniones relacionales → Aurora PostgreSQL con pgvector. Cliente existente de Pinecone / MongoDB Atlas / Redis → manténgalo. KB pequeña (<10K documentos) optimizada para costos → Aurora pgvector o Neptune Analytics.

Por qué: OpenSearch Serverless es el valor predeterminado más fácil. Aurora pgvector gana cuando necesita transacciones o uniones en metadatos.

La KB devuelve documentos semánticamente relevantes, pero son de versiones desactualizadas o de una región incorrecta.

Agregue metadatos a los archivos de origen (`version`, `region`, `effective_date`) y aplique filtros de metadatos en el momento de la consulta a través de `retrievalConfiguration.vectorSearchConfiguration.filter`.

Por qué: La similitud de vectores pura ignora la actualidad y la autoridad. El filtrado de metadatos reduce el grupo de candidatos antes de la clasificación.

RAG omite consultas que contienen identificadores exactos (SKUs, códigos de error, números de regulación) porque la búsqueda semántica sobrepondera el texto de significado similar.

Habilite la búsqueda híbrida en la KB (semántica + palabra clave/BM25). Combina la similitud de vectores con la coincidencia léxica para IDs, códigos y nombres propios.

Top-k=5 recupera 5 fragmentos, pero el más relevante a menudo se clasifica en tercer o cuarto lugar.

Aumente `numberOfResults` a 20 y luego habilite un modelo de reranking (Cohere Rerank o Amazon Rerank) para reordenar por relevancia a la consulta original.

Por qué: La similitud de embedding ≠ relevancia de la tarea. Los rerankers de codificación cruzada ven la consulta + fragmento juntos y puntúan con precisión.

Las preguntas de los usuarios son conversacionales, de varias partes o contienen pronombres/seguimientos; la calidad de la recuperación de la KB disminuye.

Habilite la reformulación de consultas de Bedrock KB. El modelo reescribe consultas complejas en múltiples subconsultas enfocadas antes de la recuperación.

Los documentos de origen de S3 se actualizan con frecuencia; la KB debe reflejar siempre las últimas versiones sin sincronización manual.

Configure la fuente de datos de la KB para la sincronización automatizada a través de notificaciones de eventos de S3 → EventBridge → StartIngestionJob, o use la sincronización programada de la KB. Evite depender del botón manual "Sync" de la consola.

El modelo de QA de documentos largos alucina sobre preguntas cuyas respuestas están en el medio del documento.

No pase documentos completos en el prompt — fragmente + recupere a través de RAG para que solo los fragmentos relevantes lleguen al modelo. Si el documento completo es obligatorio, use un modelo con una fuerte recuperación de contexto largo (Claude Sonnet 200K) y coloque la pregunta después del documento.

Por qué: La mayoría de los LLMs exhiben una degradación de la recuperación por "perdido en el medio". RAG lo evita; la colocación ayuda cuando RAG no está disponible.

Elija la personalización más económica que cumpla con el estándar de calidad.

Pruebe en orden: (1) ingeniería de prompt, (2) RAG con KB, (3) fine-tuning, (4) preentrenamiento continuo, (5) Custom Model Import. Deténgase en el primero que cumpla el estándar.

Por qué: El esfuerzo y el costo continuo aumentan en cada paso. El fine-tuning + Provisioned Throughput es mucho más caro que RAG.

Ajuste (fine-tune) un modelo de Bedrock con ejemplos de tareas etiquetados.

Archivo JSONL en S3 con un ejemplo por línea: `{"prompt": "...", "completion": "..."}` (o el equivalente en formato de chat para la familia de modelos).

Por qué: Cada familia de modelos (Titan, Claude, Llama) tiene un esquema específico; verifique la documentación de fine-tuning del modelo antes de formatear.

Adapte un modelo fundacional a vocabulario especializado (legal, médico, científico) utilizando una gran cantidad de texto de dominio sin etiquetar.

Preentrenamiento continuo en el corpus de dominio sin etiquetar. Diferente del fine-tuning de instrucciones (que necesita pares prompt-completion).

Por qué: El preentrenamiento continuo actualiza la comprensión del lenguaje; el fine-tuning de instrucciones enseña el comportamiento de la tarea. Forma de datos diferente, objetivo diferente.

Los datos de interacción del cliente para el fine-tuning contienen nombres, correos electrónicos, números de teléfono.

Limpie o tokenice la PII antes de subir el conjunto de datos de entrenamiento a S3. Una vez que los pesos absorben la PII, el filtrado de salida no puede enmascararla de forma fiable.

Por qué: El modelo ajustado puede regurgitar fragmentos de datos de entrenamiento. La limpieza en la capa de datos es la única mitigación duradera.

Importar un modelo Llama o Mistral autoajustado (self-fine-tuned) y servirlo a través de la API unificada de Bedrock.

Custom Model Import. Suba los pesos a S3, regístrelos con Bedrock, invóquelos a través del entorno de ejecución de Bedrock con IAM y registro unificados.

Por qué: Le permite reutilizar Bedrock Guardrails, KBs y Agents en sus propios pesos sin levantar endpoints de SageMaker.

Sirva un modelo Bedrock ajustado (fine-tuned) en producción.

Compre Provisioned Throughput. Los modelos personalizados (ajustados, con preentrenamiento continuo, importados) no se pueden invocar bajo demanda.

Una aplicación Claude de alto tráfico alcanza las cuotas por región durante los picos; se necesita un mayor rendimiento sin comprar Provisioned Throughput.

Perfiles de inferencia entre regiones (Cross-region inference profiles). Bedrock enruta las invocaciones a través de múltiples regiones de forma transparente para aumentar las cuotas efectivas de TPM/RPM.

Por qué: Las cuotas bajo demanda de una sola región se agotan durante los picos; los perfiles entre regiones multiplican aproximadamente las cuotas sin cambios en el código de la aplicación más allá de usar el ARN del perfil de inferencia.

Los usuarios de APAC experimentan una latencia significativamente mayor que los usuarios de US/EU en una aplicación de Bedrock desplegada en us-east-1.

Despliegue endpoints regionales de Bedrock en ap-northeast-1 / ap-southeast-1 / ap-south-1 (donde el modelo esté GA). Enrute a los usuarios a través de políticas de latencia o geolocalización de Route 53.

Por qué: El viaje de ida y vuelta del LLM domina para contextos largos; el RTT transpacífico por sí solo es de 150 a 250 ms.

Una aplicación regulada por HIPAA necesita resumir PHI con Bedrock.

Use solo modelos fundacionales elegibles para HIPAA (según la lista de servicios elegibles para HIPAA). Firme un BAA con AWS. Cifre los prompts/respuestas con claves KMS administradas por el cliente. Deshabilite el registro de invocación del modelo o delimítelo a un bucket S3 privado con acceso restringido.

Decida qué datos pueden fluir a Bedrock según la sensibilidad (público / confidencial / restringido).

Público → sin restricciones. Confidencial → solo a través de VPC endpoints + CMK + registro de invocación en buckets privados. Restringido (secretos comerciales, PHI/PCI regulados) → bloquear completamente de Bedrock o usar un régimen de cumplimiento elegible para Bedrock + redactar antes de invocar.

Una organización de múltiples cuentas quiere que la Cuenta A comparta un modelo Bedrock personalizado con la Cuenta B sin copiar los pesos.

Compartir modelos personalizados a través de AWS RAM. El propietario comparte el ARN del modelo personalizado; las cuentas de los consumidores lo invocan a través del entorno de ejecución estándar de Bedrock con entidades principales de IAM entre cuentas en la política de recursos.

Por qué: Evita costos redundantes de fine-tuning y centraliza el ciclo de vida del modelo. RAM controla quién puede consumir el recurso compartido.

Necesita un modelo de terceros de nicho (por ejemplo, un LLM especializado en atención médica) que no está en el catálogo estándar de Bedrock.

Amazon Bedrock Marketplace. Suscríbase al modelo desde el catálogo de Marketplace, despliéguelo en un endpoint de Bedrock, invóquelo a través de la API de tiempo de ejecución estándar.

Por qué: Unifica la facturación de terceros, IAM, KMS y la observabilidad con los modelos de Bedrock de primera parte.

Una aplicación de búsqueda de alto volumen reincrusta los mismos documentos en cada actualización de consulta; el costo de embedding domina.

Precalcule los embeddings al ingerir el documento, almacene el vector en DynamoDB o OpenSearch con clave por id de documento + hash de contenido. Reincruste solo cuando cambie el hash de contenido.

Por qué: Incrustar el mismo texto repetidamente es el costo evitable más común. Un caché con clave hash es un salto O(1).

Derecho al olvido de GDPR en un modelo ajustado (fine-tuned): el usuario solicita la eliminación de su PII de los datos de entrenamiento.

Elimine los registros del corpus de entrenamiento y luego ajuste un nuevo modelo base desde cero. No se pueden eliminar datos de forma fiable de los pesos existentes; el filtrado de salida no es suficiente.

Por qué: Una vez que los pesos absorben los datos de entrenamiento, el enmascaramiento en la inferencia no es fiable. La vía defendible es el reentrenamiento completo sin los registros afectados.

Una KB compartida sirve a varios equipos; cada equipo solo debe ver sus propios documentos.

Etiquete cada fragmento con metadatos `tenant_id` / `team_id` / `clearance` durante la ingesta. En el momento de la consulta, configure `retrievalConfiguration.vectorSearchConfiguration.filter` con los valores permitidos del llamador desde la sesión de IAM o el contexto de la aplicación.

Por qué: La similitud de vectores ignora el control de acceso; el filtrado de metadatos es la única forma duradera de aislamiento por inquilino en una KB compartida.

Un cliente de la UE requiere que los prompts y los embeddings de la KB nunca salgan de eu-west-1.

Despliegue Bedrock + KB + S3 source bucket en eu-west-1. Fije las invocaciones a través del ARN del perfil de inferencia con ámbito en eu-west-1; SCP `aws:RequestedRegion` deniega en otras regiones para `bedrock:*`.

Implementación e integración

Un flujo de trabajo de varios pasos necesita razonamiento LLM, llamadas a APIs/bases de datos externas y síntesis.

Amazon Bedrock Agent. Defina instrucciones, grupos de acciones (Lambda + esquema OpenAPI) y una KB opcional. El agente planifica, invoca herramientas y une los resultados.

Por qué: Evita escribir el bucle de orquestación usted mismo. Incluye traza, memoria de sesión y hooks de retorno de control.

El agente de Bedrock debe llamar a tres APIs internas (CRM, inventario, pagos).

Defina un grupo de acciones por API. Cada grupo de acciones tiene un esquema OpenAPI que describe sus operaciones y una función Lambda (o endpoint de retorno de control) que ejecuta las llamadas.

El agente debe realizar operaciones de alto riesgo (eliminación de cuenta, grandes reembolsos) solo después de la confirmación humana/empresarial.

Configure el grupo de acciones con Return of Control (RoC). Bedrock devuelve la acción propuesta a la aplicación en lugar de invocarla; la aplicación controla la ejecución detrás de una aprobación y vuelve a enviar los resultados.

Por qué: Mantiene los pasos de alto riesgo fuera del entorno de ejecución del agente para que puedan ser auditados o confirmados por humanos antes de ejecutarse.

El agente debe recordar el contexto en diferentes turnos dentro de una sesión de usuario.

Utilice los atributos de sesión incorporados del agente y los atributos de sesión de prompt. Pase `sessionId` a InvokeAgent — Bedrock retiene el estado de la conversación durante el tiempo de espera de inactividad configurado.

El agente debe recordar hechos sobre un usuario recurrente entre sesiones (preferencias, historial) y resumir intercambios anteriores.

Habilite la memoria de Bedrock Agent. El agente persiste el historial de sesión resumido por `memoryId` y lo reproduce como contexto en futuras invocaciones.

El flujo de trabajo necesita agentes especializados (investigación, código, facturación) coordinados por un planificador de alto nivel.

Colaboración multi-agente de Bedrock Agents: defina un agente supervisor y varios agentes colaboradores. El supervisor delega subtareas basándose en las descripciones de los colaboradores y sintetiza los resultados.

Necesita un pipeline de varios pasos: extraer → clasificar → enrutar → resumir, con ramificaciones condicionales.

Amazon Bedrock Prompt Flows. Flujo de trabajo visual con nodos de prompt, nodos de condición, nodos de KB, nodos de Lambda; versionado e invocable como una sola API.

Por qué: Reemplaza los Step Functions hechos a mano para pipelines de prompt y expone un único punto de entrada.

SaaS multi-inquilino: prompts del sistema por inquilino, preferencias de modelo y versionado.

Amazon Bedrock Prompt Management. Almacene los prompts como activos versionados y parametrizados; referencie por ARN en tiempo de ejecución; A/B diferentes versiones por inquilino.

La aplicación debe funcionar con Claude, Llama, Titan y Cohere con una única superficie de API estilo chat.

Use la API Bedrock Converse. Formato unificado de lista de mensajes, uso de herramientas y prompts del sistema en todas las familias de modelos. Evite InvokeModel JSON específico del modelo cuando la portabilidad sea importante.

El chatbot debe mostrar respuestas token a token para reducir la latencia percibida.

ConverseStream (o InvokeModelWithResponseStream). Combine con API Gateway WebSocket o suscripciones de AppSync para distribuir tokens al navegador.

Chat de atención al cliente en tiempo real: transmisión de respuestas, 500 usuarios concurrentes, historial de conversación.

Navegador ↔ API Gateway WebSocket ↔ Lambda ↔ Bedrock ConverseStream. Persista la conversación en DynamoDB con clave `sessionId` y recárguela en cada turno.

Por qué: WebSocket evita el sondeo HTTP; el almacén de sesiones de DynamoDB sobrevive a la naturaleza sin estado de Lambda.

Necesita que el modelo decida cuándo llamar a funciones (búsqueda en base de datos, calculadora, API).

Use el uso de herramientas de la API Converse (`toolConfig`) — declare herramientas con nombre + esquema JSON; el modelo emite bloques `toolUse`; la aplicación ejecuta y devuelve `toolResult`. Funciona con Claude, Llama, Mistral, Cohere Command R.

Nuevo ticket en un sistema de terceros → análisis automático de Bedrock (sentimiento, urgencia, categoría) → enrutamiento.

Webhook → API Gateway → EventBridge → Lambda target → Bedrock. EventBridge desacopla productores de consumidores y proporciona reintentos + DLQ de forma gratuita.

Múltiples microservicios envían solicitudes de generación de Bedrock; los consumidores no necesitan resultados de inmediato.

Productores → SQS → Consumidor Lambda (o ECS) → Bedrock InvokeModel → almacene el resultado en S3/DynamoDB. SQS suaviza los picos y reintenta los fallos dentro de las cuotas de servicio.

Generar descripciones para 100.000 SKUs cada noche; tolerante a la latencia; quiere el costo más bajo.

Amazon Bedrock Batch Inference. Envíe el JSONL de entrada en S3, Bedrock ejecuta el trabajo con un costo por token hasta un 50% menor que bajo demanda, escribe la salida JSONL.

Por qué: Batch sacrifica la latencia por el costo. Úselo siempre que los resultados no se necesiten en tiempo real.

API Gateway delante de Lambda + Bedrock devuelve 504 Gateway Timeout en generaciones largas.

El timeout de integración de API Gateway REST tiene un límite de 29 segundos. Cambie a un patrón asíncrono (devuelva el id del trabajo, consulte a través de un segundo endpoint) o a API Gateway WebSocket + ConverseStream para que los tokens parciales fluyan antes de la ventana de timeout.

Generar descripciones de productos a partir de una imagen de producto + texto breve.

Utilice un modelo con capacidad de visión en Bedrock (Claude 3+ Sonnet, Nova) a través de la API Converse con bloques de contenido de `image` junto con texto.

Traducción de mensajes a inglés en menos de un segundo con alta calidad.

Modelo fundacional (Claude Haiku o Llama pequeño) a través de Bedrock para matices, O Amazon Translate para velocidad/costo cuando la traducción literal es suficiente. Bedrock para contexto; Translate para transaccional.

Cambiar gradualmente el tráfico de producción del Modelo A al Modelo B con capacidad de "kill-switch".

Bandera de características de AWS AppConfig que contiene el identificador del modelo activo y la división de tráfico. Lambda lee la bandera por invocación y enruta en consecuencia. Revierte instantáneamente a través del rollback de despliegue de AppConfig.

Decidir entre Bedrock y SageMaker JumpStart para alojar un modelo fundacional.

Bedrock cuando desea inferencia administrada, API unificada, KB/Agents/Guardrails. SageMaker JumpStart cuando necesita un endpoint privado alojado en VPC con control completo de red/IAM o un modelo de pesos abiertos no disponible en Bedrock.

Elija el estilo de definición del grupo de acciones: especificación OpenAPI 3.0 vs esquema de función.

OpenAPI cuando la API subyacente ya tiene una especificación OpenAPI 3.0 o necesita semántica HTTP completa (rutas, métodos, tipos de parámetros). Esquema de función para acciones en línea/ligeras definidas mediante declaraciones de propiedades JSON simples.

Por qué: OpenAPI es canónico para APIs REST existentes. El esquema de función es más rápido para nuevos asistentes internos del agente.

El agente debe realizar cálculos precisos, análisis estadísticos o ejecutar pequeños fragmentos de Python para responder preguntas.

Habilite el intérprete de código de Bedrock Agents. El agente ejecuta Python en un sandbox administrado; los resultados vuelven a la síntesis de la respuesta.

Por qué: Los LLMs no son fiables en matemáticas exactas; un entorno de ejecución aislado proporciona resultados numéricos deterministas sin escribir grupos de acciones personalizados.

Los prompts predeterminados del agente producen respuestasLARGAS; se necesita ajustar el prompt de orquestación para producción.

Configure las anulaciones de la plantilla de prompt en el agente para cada paso (preprocesamiento, orquestación, generación de respuesta de KB, postprocesamiento). Las anulaciones se versionan con el agente.

Iterar en un agente en desarrollo mientras el tráfico de producción se mantiene en una versión estable.

Use versiones y aliases de agente. `DRAFT` para ediciones activas; publique versiones numeradas; enrute a través de aliases (`prod` → versión 7, `dev` → DRAFT). Promocione actualizando el alias.

El agente elige el grupo de acciones incorrecto; se necesita depurar el razonamiento paso a paso.

Habilite el trace en InvokeAgent (`enableTrace: true`). El flujo de respuesta incluye bloques `preProcessingTrace`, `orchestrationTrace`, `postProcessingTrace` y `failureTrace` que muestran el razonamiento del modelo, la selección de herramientas y las entradas.

Construir un Flow de Bedrock para "extraer entidades → buscar en KB → resumir → enviar correo electrónico".

Componga nodos: nodo de prompt (extraer), nodo de knowledge base (buscar), nodo de prompt (resumir), nodo de Lambda (enviar correo electrónico a través de SES). Use nodos de entrada/salida de S3 para flujos por lotes; nodos de condición para ramificaciones.

Elija Bedrock Flows vs Step Functions para un pipeline GenAI de varios pasos.

Bedrock Flows cuando los pasos son principalmente primitivas de Bedrock (prompts, KBs, agentes) — invocación de una sola API, sin pegamento IAM adicional. Step Functions cuando el flujo de trabajo abarca muchos servicios de AWS con reintentos, ramificaciones paralelas, manejo de errores complejos o esperas de larga duración.

Implementar un bucle de chat donde el modelo llama iterativamente a herramientas, luego formula la respuesta final.

Patrón: enviar mensaje de usuario → el modelo devuelve `toolUse` → la aplicación ejecuta la herramienta → la aplicación envía `toolResult` de vuelta a través de Converse → bucle hasta que el modelo devuelve el texto final. Limite las iteraciones para evitar desbordamientos.

Por qué: El modelo decide cuándo tiene suficiente información para detenerse; la aplicación debe controlar el bucle y aplicar un límite máximo de pasos.

El modelo necesita buscar cliente + pedido + inventario; las llamadas secuenciales a herramientas añaden 3× latencia.

Los modelos que admiten el uso de herramientas paralelas (Claude 3+, Nova) emiten múltiples bloques `toolUse` en un turno. Ejecútelos concurrentemente en la aplicación y devuelva todos los `toolResult` antes de la siguiente inferencia.

Persistir el estado del chat de múltiples turnos a través de invocaciones de Lambda sin estado con limpieza automática de sesiones obsoletas.

Tabla DynamoDB con clave `sessionId` que almacena `messages` + `lastActivity`. Establezca el atributo TTL (`expiresAt`) para eliminar automáticamente las sesiones con más de 24 horas de antigüedad. Lambda lee/escribe por turno.

El chat ve ~1000 QPS; las lecturas de DynamoDB por turno sobre el historial de sesión son un punto caliente.

Frente a DynamoDB con ElastiCache para Redis. Almacene en caché los últimos N mensajes por sesión en un hash de Redis; escritura directa a DynamoDB para durabilidad. Claves TTL de Redis para limitar la memoria.

Un reintento en una llamada a Bedrock InvokeModel corre el riesgo de facturar dos veces la misma solicitud lógica.

Genere una clave de idempotencia por solicitud lógica (por ejemplo, UUID v5 de entrada + usuario). Almacene en caché la respuesta con clave por idempotencia en DynamoDB o ElastiCache; devuelva la respuesta en caché en el reintento.

Por qué: Bedrock en sí mismo no es idempotente — la misma entrada se factura en cada llamada. El almacenamiento en caché a nivel de aplicación es la única historia de idempotencia.

Ejecute dos versiones de modelos en producción durante la migración sin cambiar a todos los usuarios a la vez.

Divida el ID de usuario en N cubos; enrute el cubo i al modelo A o al modelo B según una bandera de características (AppConfig / Parameter Store). Monitoree las métricas lado a lado; cambie la asignación de cubos para avanzar o retroceder.

Seguridad, protección y gobernanza de la IA

Un chatbot de cara al cliente debe bloquear contenido dañino, temas denegados, fuga de PII.

Amazon Bedrock Guardrails. Configure temas denegados, filtros de contenido (odio, violencia, sexual, insultos, mala conducta), filtros de palabras, filtros de información sensible (redacción de PII) y comprobaciones de fundamentación contextual. Aplique a la entrada y salida de InvokeModel.

Por qué: Los Guardrails son agnósticos al modelo y se aplican en ambas direcciones; sobreviven a cualquier cambio de modelo.

El Guardrail bloquea respuestas financieras legítimas que mencionan montos en dólares.

Reduzca el nivel de sensibilidad en el filtro de contenido afectado (por ejemplo, `MEDIUM` → `LOW`) y/o elimine frases de temas denegados demasiado amplias. Vuelva a probar con un conjunto de prompts de benchmark antes de volver a desplegar.

Una aplicación de resumen médico no debe inventar hechos más allá de los documentos fuente.

Habilite la comprobación de fundamentación contextual de Bedrock Guardrails con un umbral alto de relevancia + fundamentación. Las respuestas por debajo del umbral se bloquean o se reemplazan con un mensaje predeterminado seguro.

Por qué: El RAG puro sigue alucinando cuando el modelo sobregeneraliza a partir de los fragmentos recuperados. La fundamentación contextual califica la alineación respuesta-fuente por cada respuesta.

Una aplicación de Bedrock recibe prompts que contienen PII del cliente; necesita enmascaramiento automático antes de registrar o usarla en operaciones posteriores.

Configure los filtros de PII de Guardrails con acciones `BLOCK` o `ANONYMIZE` para tipos de entidades PII (SSN, correo electrónico, teléfono, dirección). El filtrado ocurre en la entrada y salida de forma independiente.

Una aplicación pública toma la entrada del usuario concatenada en un prompt del sistema; debe resistir la inyección de prompt.

Defensa en profundidad: (1) Guardrails (temas denegados + detección de jailbreak), (2) prompt del sistema reforzado que enmarca la entrada del usuario como datos y rechaza meta-instrucciones, (3) validación de salida contra el esquema esperado, (4) permisos de herramientas de privilegio mínimo para que un prompt comprometido no pueda activar acciones destructivas.

Por qué: Ninguna mitigación única es suficiente; las defensas por capas limitan el radio de explosión.

El equipo rojo descubre que el modelo puede ser forzado a producir resultados dañinos mediante un encuadre de juego de roles ("pretende que eres una IA sin restricciones").

Habilite el filtro de contenido de detección de jailbreak de Guardrails. Agregue temas denegados explícitos para intentos de juego de roles. Vuelva a probar después de cada cambio con el mismo conjunto de prompts del equipo rojo.

Todos los datos de Bedrock deben estar cifrados en tránsito y en reposo con claves administradas por el cliente.

TLS 1.2+ se aplica en tránsito. En reposo: configure claves KMS administradas por el cliente para la personalización de modelos de Bedrock, embeddings de KB + datos de origen de S3, destinos de registro de invocación. Aplique a través de SCP que impida las claves administradas por AWS.

Organización multi-equipo: cada equipo debe acceder solo a modelos fundacionales específicos.

Políticas basadas en identidad de IAM que permiten `bedrock:InvokeModel` en ARNs de recursos con ámbito para los IDs de modelo permitidos. Combine con condiciones `aws:RequestedRegion` para bloquear la región.

Por qué: El permiso de nivel de recurso `Allow` en `arn:aws:bedrock:*::foundation-model/<id>` es la única forma duradera de aplicar el acceso a nivel de modelo. No dependa de la restricción a nivel de aplicación.

Lambda invoca solo Claude 3.5 Sonnet en us-east-1.

Permita `bedrock:InvokeModel` con `Resource: arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-*` y una `Condition: aws:RequestedRegion = us-east-1`. Rechace todos los demás modelos y regiones.

La aplicación de Bedrock no debe salir a la internet pública.

Bedrock con VPC interface endpoints (PrivateLink) para la API de tiempo de ejecución. Bloquee los endpoints públicos de Bedrock a través de SCP. Agregue una política de endpoint que limite las acciones al conjunto aprobado.

El regulador requiere un registro de auditoría completo de cada invocación de modelo de Bedrock: prompt, respuesta, versión del modelo, marca de tiempo.

Habilite el registro de invocación de modelos de Bedrock en CloudWatch Logs o S3. Captura el prompt completo + respuesta + ID del modelo + marca de tiempo. Combine con CloudTrail para la capa de metadatos de llamadas a la API (quién/cuándo/desde dónde).

Por qué: CloudTrail captura solo metadatos; el registro de invocaciones captura contenido. El cumplimiento generalmente requiere ambos.

Determine la parte de responsabilidad de seguridad de la empresa para una implementación de Bedrock.

Matriz de alcance de seguridad de AWS Generative AI. Alcance 1 (SaaS de consumo) → Alcance 5 (modelo autoentrenado con datos privados). Bedrock con modelos fundacionales bajo demanda es típicamente Alcance 2; KB/Agent + RAG empuja hacia el Alcance 3; fine-tuning Alcance 4; Custom Model Import Alcance 5.

Proteja el endpoint de la API GenAI detrás de API Gateway de abusos.

AWS WAF con reglas basadas en tasas (por IP), conjunto de reglas administrado de control de bots y una regla de coincidencia de cadena personalizada en frases sospechosas de jailbreak. Bloquee patrones comunes de LLM-DDoS (inundaciones de prompts largos).

Encontrar PII u otros datos sensibles en los corpus de origen de S3 antes de que entren en una KB o un trabajo de fine-tuning.

Trabajo de descubrimiento programado de Amazon Macie en los buckets S3 relevantes. Los hallazgos van a Security Hub / EventBridge para una redacción de seguimiento.

Detectar imágenes generadas por IA downstream para la procedencia del contenido.

Use Titan Image Generator (o Nova Canvas) — las salidas incluyen una marca de agua invisible. Verifique con la API de detección de marca de agua de Bedrock.

El chatbot de marketing no debe nombrar a la competencia y no debe hacer afirmaciones sin fundamento.

Temas denegados de Guardrails: lista explícita de nombres de competidores + "afirmaciones de productos no verificadas" a nivel de tema. Agregue un filtro de palabras para afirmaciones absolutas ("garantizado", "mejor", "100%").

Aplicar un Guardrail de Bedrock a las salidas de un modelo que no es de Bedrock (por ejemplo, un endpoint de SageMaker autoalojado).

Llame a la API `ApplyGuardrail` independiente con el texto + ID de guardrail + versión. Devuelve si el contenido fue bloqueado o modificado, y qué filtros se activaron.

Por qué: Desacopla los guardrails del modelo. Úselo como una verificación previa en la entrada del usuario o una verificación posterior en cualquier salida del modelo.

Una única política de Guardrail debe aplicarse en us-east-1, eu-west-1 y ap-southeast-1.

Recree el mismo guardrail (misma configuración) en cada región. Los Guardrails son recursos regionales; use IaC (CloudFormation / CDK / Terraform) para mantener las configuraciones sincronizadas.

Por qué: No hay replicación administrada entre regiones para guardrails. IaC es la única forma duradera de garantizar la consistencia.

Un atacante envenena documentos en una KB pública para que el agente filtre el prompt del sistema o datos al recuperarlos.

Trate el contenido de la KB recuperado como no confiable: habilite Guardrails en las entradas Y salidas, limpie los fragmentos recuperados mediante detección de inyección de prompt o coincidencia de patrones, imponga el privilegio mínimo en los grupos de acciones del agente para que un prompt comprometido no pueda escalar.

Por qué: La inyección indirecta evita el filtrado de entrada — el prompt malicioso llega a través del contexto recuperado, no del mensaje del usuario.

Necesita acceso a modelos por usuario en una aplicación multi-inquilino con un único rol de backend.

Pase los atributos de usuario como etiquetas de sesión durante AssumeRole. Refiérase a ellos a través de condiciones `aws:PrincipalTag/<key>` en la política de identidad de Bedrock para restringir `bedrock:InvokeModel` por usuario.

Elija el destino para el registro de invocación de Bedrock.

CloudWatch Logs para prompts/respuestas cortas, consultas rápidas de Logs Insights, aplicaciones a menor escala. S3 para alto volumen, cargas útiles grandes (rastros de KB + agente), retención a largo plazo, análisis downstream con Athena/Glue. Use S3 si alguna respuesta individual puede exceder los 256 KB.

Por qué: CloudWatch Logs tiene límites de tamaño por evento; S3 no tiene ninguno. Elija según el tamaño de la carga útil y el patrón de análisis.

Proteja una API de chat pública de ataques DDoS y abusos de inundación de tokens a gran escala.

AWS Shield Standard está activado por defecto; habilite Shield Advanced en endpoints críticos para protecciones de capa 7 + soporte SRT 24/7. Combínelo con reglas basadas en tasas de WAF y CloudFront para absorción en el borde.

La aplicación de generación de imágenes debe bloquear imágenes sexualmente explícitas, violentas u odiosas.

Filtros de contenido de imagen de Bedrock Guardrails en la entrada (imágenes cargadas) y salida (imágenes generadas). Los filtros clasifican el contenido visual con umbrales HIGH/MEDIUM/LOW.

Flujo de trabajo antes de ajustar (fine-tuning) un modelo de Bedrock en transcripciones de soporte al cliente.

Pipeline: S3 source → trabajo de descubrimiento de Macie para identificar PII → detección + redacción de PII con Comprehend (o Glue con regex) → conjunto de datos limpiado a un prefijo S3 separado → fine-tune de Bedrock. Las fallas de Macie activan EventBridge → SNS a seguridad de guardia.

Por qué: Una vez que los datos entran en los pesos, la eliminación requiere reentrenamiento. La redacción previa al vuelo es mucho más barata que el reentrenamiento posterior al incidente.

Eficiencia operativa y optimización

Elija entre bajo demanda (on-demand) y Provisioned Throughput.

Tráfico variable / desconocido → bajo demanda. Gran volumen constante con SLA de rendimiento garantizado → Provisioned Throughput (unidades de modelo, compromiso de 1 o 6 meses). Modelos personalizados (ajustados, importados) → Provisioned Throughput es obligatorio.

Por qué: Bajo demanda es por token, sin compromiso. PT es por hora, capacidad dedicada, aproximadamente un 50% más barato por token con alta utilización.

La aplicación reutiliza el mismo prompt del sistema de 4.000 tokens en todas las interacciones del usuario; solo cambia el mensaje del usuario.

Habilite el prompt caching de Bedrock. Marque el prefijo estático como cacheable; las invocaciones posteriores omiten su reprocesamiento durante un TTL de caché de ~5 minutos, reduciendo el costo por llamada en ~90% en los tokens cacheados.

Muchos usuarios hacen preguntas similares pero no idénticas; quieren almacenar en caché las respuestas a través de paráfrasis.

Incruste la consulta del usuario y busque los vecinos más cercanos en un caché de vectores (DynamoDB + ElastiCache, o OpenSearch) por encima de un umbral de similitud. Acierto de caché → devuelve la respuesta almacenada. Fallo de caché → invoca Bedrock y escribe de nuevo.

Por qué: Las cachés estándar de clave-valor omiten las paráfrasis. La similitud semántica captura la intención.

Reducir el costo por llamada en una aplicación de Bedrock.

Ajuste el prompt del sistema, elimine ejemplos redundantes de few-shot, establezca `maxTokens` explícitos en la salida, use secuencias de detención para terminar antes. Elija un modelo más pequeño si la calidad lo permite.

Por qué: El costo es aproximadamente proporcional al total de tokens procesados. Los tokens de salida suelen tener un precio más alto que los tokens de entrada, por lo que limitar la salida es muy efectivo.

Completado de código: latencia sub-segundo, costo equilibrado, alto volumen de solicitudes.

Claude Haiku (o Nova Micro / Llama pequeño) en Bedrock. Evite Opus o Llama grande para rutas de finalización de tokens sensibles a la latencia.

La KB tiene 500K documentos pero solo ~200 consultas/día; minimizar el costo.

Aurora PostgreSQL Serverless v2 con pgvector. Escala a ACUs casi cero en inactividad; el modelo de pago por consulta supera los límites mínimos de OCU de OpenSearch Serverless siempre activo a bajas QPS.

OpenSearch Serverless KB tiene una latencia de consulta de 800ms; se necesita <200ms.

Aumente el nivel mínimo de OCU en la colección de búsqueda (más computación = más vectores en caché). Reduzca la dimensión de embedding, aumente top-k de forma ajustada, pode metadatos, habilite el almacenamiento en caché de resultados en la capa de la aplicación.

Trabajos de fine-tuning de larga duración que toleran interrupciones; minimizar el costo.

Para el fine-tuning de SageMaker use Managed Spot Training (hasta un 90% de descuento). El fine-tuning nativo de Bedrock es solo bajo demanda — elija SageMaker JumpStart para entrenamiento personalizado elegible para Spot cuando el presupuesto sea lo más importante.

Asignar el gasto de Bedrock entre equipos o líneas de productos.

Aplique etiquetas de asignación de costos a los recursos de Bedrock (Provisioned Throughput, modelos personalizados, pilas de aplicaciones). Active las etiquetas en Facturación → Etiquetas de asignación de costos. Los informes se desglosan por etiqueta.

Monitorear la latencia de invocación de Bedrock, el volumen de tokens y los errores.

Métricas de CloudWatch bajo `AWS/Bedrock`: `InvocationLatency`, `InputTokenCount`, `OutputTokenCount`, `Invocations`, `InvocationClientErrors`, `InvocationServerErrors`, `InvocationThrottles`. Establezca alarmas para la latencia p95 y las tasas de error.

~100 conversaciones/día, FAQ simple; minimizar el costo.

Bedrock bajo demanda con el modelo competente más pequeño (Titan Text Lite, Claude Haiku o Nova Micro). Lambda + API Gateway HTTP API. Sin KB si las FAQ caben en el prompt del sistema; KB pequeña en Aurora pgvector si es necesario.

Dimensionar el Provisioned Throughput para una carga de trabajo de Bedrock en estado estable.

Mida los tokens de entrada + salida por segundo pico en el tráfico de sombra. Bedrock publica el rendimiento por unidad de modelo; provisione `ceil(pico TPS / TPS por unidad)` unidades. Valide con tráfico de sombra antes de comprometerse.

Por qué: La provisión insuficiente causa throttling; la sobreprovisión desperdicia el compromiso por hora. El dimensionamiento empírico en el tráfico de sombra es el único enfoque fiable.

Asignar el costo de Bedrock por aplicación o equipo en una cuenta compartida.

Cree perfiles de inferencia de aplicación por aplicación, adjunte etiquetas de asignación de costos (ej. `application=chatbot-X`, `team=marketing`). Cada invocación hace referencia al ARN del perfil; Cost Explorer desglosa el gasto por etiqueta.

Pruebas, validación y resolución de problemas

Comparar tres modelos fundacionales en una tarea de resumen; se necesita una evaluación automatizada y reproducible.

Trabajos de evaluación de modelos de Amazon Bedrock (automáticos). Proporcione un conjunto de datos de prompts; Bedrock ejecuta cada modelo e informa BLEU, ROUGE, BERTScore más toxicidad / precisión cuando corresponda.

Las puntuaciones ROUGE parecen altas pero los lectores humanos dicen que los resúmenes omiten puntos clave.

Cambie a la evaluación basada en humanos de Bedrock con métricas personalizadas (relevancia, completitud, fidelidad). Defina una rúbrica, dirija una muestra a una fuerza de trabajo, agregue puntuaciones.

Por qué: Las métricas de superposición léxica (BLEU, ROUGE) omiten la fidelidad semántica. La evaluación humana es la verdad fundamental para tareas subjetivas.

Necesita una evaluación escalada y reproducible, pero la revisión solo humana es demasiado lenta/cara.

Evaluación "LLM como juez" de Bedrock. Un modelo potente puntúa las respuestas contra una rúbrica; los resultados se correlacionan bien con los revisores humanos y se ejecutan en minutos en lugar de días.

Los resúmenes de carteras generados deben coincidir exactamente con las cifras del documento fuente.

Restrinja la generación: baja temperatura (0–0.2), instrucciones estrictas en el prompt ("cite los números textualmente de la fuente"), verificación de fundamentación contextual de Guardrails en la salida, regex/analizador post-generación que valida números versus la fuente.

Por qué: Incluso con RAG fundamentado, los modelos parafrasean números. Múltiples capas (prompt + fundamentación + analizador) capturan los casos residuales.

RAG a menudo devuelve "No tengo suficiente información" incluso para temas cubiertos en la KB.

Inspeccione las trazas de recuperación: puntuaciones de fragmentos, recuento de fragmentos recuperados, alineación de consulta a fragmento. Soluciones comunes: habilitar búsqueda híbrida, aumentar top-k, ajustar el tamaño del fragmento, cambiar a fragmentación semántica, habilitar la reformulación de consultas, reducir el umbral de relevancia.

El agente devuelve precios desactualizados incluso después de una sincronización reciente de la KB; la fuente de datos es S3 con versionado.

Confirme que el último IngestionJob `status: COMPLETE` y `documentsModified` reflejan los nuevos objetos. El versionado significa que las versiones no actuales aún pueden ser indexadas si la fuente de datos no está restringida solo a las versiones actuales — verifique el filtro de la fuente de datos y vuelva a sincronizar.

El agente de RRHH ocasionalmente revela información salarial sobre otros empleados cuando se le pregunta astutamente.

Ajuste las instrucciones del agente ("solo responda sobre los datos del usuario que realiza la solicitud"), restrinja el grupo de acciones mediante atributos de sesión que incluyan el ID de usuario, limite el IAM en la Lambda que respalda el grupo de acciones para que solo consulte los registros del propio usuario, agregue un tema denegado de Guardrails para consultas salariales entre usuarios.

Las invocaciones de Bedrock tienen picos intermitentes de latencia p95.

Verifique `InvocationThrottles` (hits de límite de tasa) y `ModelLatency` en CloudWatch; active el trazado de AWS X-Ray en la Lambda llamante; inspeccione CloudWatch Logs Insights para llamadas a herramientas o recuperación de KB lentas. Mitigue mediante inferencia entre regiones, modelo más pequeño, almacenamiento en caché de prompts o procesamiento por lotes.

Migrar de Claude v2 a Claude 3.5 Sonnet sin regresiones.

Ejecute un trabajo de evaluación de Bedrock comparando ambos en un conjunto de prompts representativo. Luego tráfico de sombra en producción: envíe la misma entrada a ambos, compare las salidas fuera de línea. Promueva con la bandera de características de AppConfig al 10% → 50% → 100%.

Ejecutar Bedrock Model Evaluation como parte de CI/CD en cada cambio de configuración del modelo.

Use la API `CreateEvaluationJob`. Defina el conjunto de datos en S3, los evaluadores (incorporados o personalizados) y los modelos de destino. Sondee el estado del trabajo; promueva en `COMPLETED` con métricas por encima de los umbrales.

Por qué: La UI de Studio es para casos únicos; la API es el único camino hacia puertas de evaluación automatizadas y repetibles.

Evitar regresiones de calidad al actualizar el modelo fundacional en producción.

Mantenga un conjunto de pruebas de regresión curado: 100-500 prompts representativos con salidas esperadas (o rúbricas). Ejecute a través de Bedrock Model Evaluation en cada intercambio de modelo. Bloquee la promoción si las puntuaciones caen por debajo de un umbral definido.

Medir si el modelo elige la herramienta correcta con los argumentos correctos en el chat con uso de herramientas.

Construya un conjunto etiquetado: prompt + bloque(s) `toolUse` esperado(s). Ejecute a través de un evaluador personalizado que compare el nombre de la herramienta real vs. esperado + argumentos JSON. Rastree la precisión/recall por herramienta.

Por qué: Las métricas léxicas (BLEU) no detectan si el agente invocó la acción correcta. La precisión del uso de herramientas es la métrica correcta para cargas de trabajo agenticas.