Agentes, Flows y orquestación en Amazon Bedrock

Todo lo de este curso hasta ahora ha sido sobre una sola llamada al modelo: escribe un prompt, obtén una completion, evalúala. La IA en producción rara vez es una llamada. Es una secuencia, buscar algo, comprobar una condición, llamar a una API, hacer una pregunta de seguimiento al usuario, intentarlo de nuevo, y el examen tiene un vocabulario dedicado para quién es dueño de esa secuencia: tú (el código de tu aplicación), el modelo (un agente que elige acciones en tiempo de ejecución), un grafo que dibujaste (Amazon Bedrock Flows), o una máquina de estados (AWS Step Functions). La Lección 11 trata sobre esa decisión de propiedad, y sobre los servicios de AWS que implementan cada respuesta.

Al final de esta lección podrás:

• nombrar los cuatro componentes de construcción que todo agente necesita y los opcionales que AWS lista a su lado;
• recorrer el bucle en tiempo de ejecución, preprocesamiento, orquestación, postprocesamiento, y decir cuál de las cuatro plantillas de prompt base es editable en cada fase;
• elegir entre un esquema OpenAPI y function details, y entre un ejecutor Lambda y RETURN_CONTROL;
• enunciar el contrato de InvokeAgent: parámetros obligatorios, el techo de 2.048 caracteres de inputText, los ámbitos de sessionState y qué pasa con inputText en una reinscripción de retorno de control;
• describir la memoria del agente (SESSION_SUMMARY, 1 to 365 días) y las cuotas de gestión de sesiones;
• configurar la colaboración multi-agente (≤ 10 alias de colaboradores, dos modos) y explicar por qué la orquestación personalizada es incompatible con ella;
• listar los 16 tipos de nodo de Flows, los dos tipos de conexión y los límites de ejecución (1 h síncrono, 5 min/nodo y 24 h asíncrono en vista previa);
• defender el veredicto comparativo: agente frente a prompt simple frente a workflow frente a código.

---

1. Tres nombres, tres servicios: Agents Classic, AgentCore y Flows

1.1 Los renombramientos que deciden el examen

Dos renombramientos llevan más puntos que cualquier otro hecho de esta lección:

1. «Amazon Bedrock Agents» / «Agents for Amazon Bedrock» → Amazon Bedrock Agents Classic. AWS lo colocó bajo Servicios que pasan a mantenimiento en su Actualización de Disponibilidad de Servicios del 30 de junio de 2026: cerrado a clientes nuevos desde el 30 de julio de 2026, sin características nuevas, y un catálogo de modelos fundacionales congelado el 30 de julio de 2026. Los clientes existentes no se ven afectados, y los modelos de Amazon Bedrock, Knowledge Bases y Guardrails están explícitamente no afectados. No hay excepciones al corte de clientes nuevos.
2. «Prompt Flows» → Amazon Bedrock Flows, disponible generalmente el 22 de noviembre de 2024, que añadió visibilidad de ejecución por paso y soporte de Guardrails en los nodos de prompt y de base de conocimiento. El nombre antiguo solo sobrevive en algunas listas de alcance de certificación.

El destino de migración documentado para Agents Classic es Amazon Bedrock AgentCore: un conjunto de seis componentes (Runtime, Gateway, Identity, Memory, Observability y Harness) que se vio en vista previa en julio de 2025, alcanzó GA en nueve regiones y siguió publicándose durante 2026 (Managed Knowledge Base GA en junio de 2026, Agent Registry GA en agosto de 2026).

📚 ¿Sabías que…? AgentCore no es un agente renombrado: es una descomposición. Sus seis componentes mapean a piezas que solían vivir dentro de un único agente: Runtime (el bucle de invocación), Gateway (exposición de herramientas/APIs), Identity, Memory, Observability (trazas y telemetría) y Harness (empaquetado). Esa es la razón por la que la guía de migración de AWS habla de mover capacidades, no de una actualización con un clic de un ID de agente existente.

1.2 Qué pregunta oficialmente el examen sobre agentes

La guía del examen AIF-C01 es la autoridad para el alcance, y su contenido agéntico se sitúa en dos lugares:

Se publicaron dos cambios de alcance para esta versión del examen: se añadieron AgentCore, Kiro, Strands Agents, Amazon Q, SageMaker JumpStart y AWS Transform, y se eliminó Amazon MemoryDB. Amazon A2I, una vez listado en la guía del examen v1.4 (2024), ya no está en la lista de alcance actual.

---

2. Anatomía de un agente

2.1 El mínimo de construcción

La propia formulación de AWS sobre lo que está hecho un agente es precisa y merece memorizarse como una frase: un modelo fundacional, instructions, opcionalmente plantillas de prompt base o avanzadas, y al menos uno de: action groups o knowledge bases. La memoria, Guardrails, la interpretación de código y la colaboración multi-agente son todos complementos opcionales.

Dos filas merecen énfasis propio. Primero, alias: InvokeAgent requiere agentAliasId, nunca un ID de agente desnudo: un agente en borrador que nunca has preparado y aliasado no puede llamarse. Segundo, function details frente a OpenAPI: son alternativas, no capas. Un action group usa exactamente uno de los dos esquemas, y la unión de ejecutores (ARN de Lambda | RETURN_CONTROL) aplica a ambos.

2.2 Ejemplo 1: construir un agente de viajes (en construcción)

1. Crea el agente y dale instructions: «Eres un agente de viajes. Reserva el vuelo más barato que cumpla la normativa. Nunca inventes precios; llama siempre a FlightsAPI.»
2. Elige un modelo fundacional del catálogo disponible para Agents Classic en tu cuenta.
3. Añade un action group FlightsAPI con un esquema OpenAPI que describa searchFlights y bookFlight.
4. Fija el ejecutor a un ARN de Lambda (la Lambda valida IAM, llama a la API de la aerolínea y devuelve JSON).
5. Opcionalmente adjunta una base de conocimiento de políticas de viaje corporativas, un guardrail que bloquee números de tarjeta y memoria con storageDays = 90.
6. PrepareAgent → anota la versión → crea un alias (por ejemplo T1).
7. Entrega a la aplicación agentId + agentAliasId y llama a InvokeAgent.

Nada de lo anterior es autónomo todavía: la autonomía aparece solo en tiempo de ejecución, en el bucle que el modelo dirige.

---

3. Tiempo de ejecución: el bucle de orquestación

3.1 Las tres fases, en orden

Toda llamada a InvokeAgent pasa por el preprocesamiento, luego un bucle de orquestación que se repite hasta que existe una respuesta o se vuelve a preguntar al usuario, y luego el postprocesamiento (desactivado por defecto). El propio bucle tiene un ritmo interno fijo: el modelo produce una fundamentación (rationale), predice una llamada a un action group o una consulta a la base de conocimiento, los parámetros van a Lambda o de vuelta a tu aplicación a través del retorno de control, el resultado regresa como una observación, la observación se añade al prompt base, y el bucle se repite.

Tres consecuencias se desprenden de ese diagrama y cada una ha sido probada:

• El coste escala con las iteraciones, no con las peticiones. Cada vuelta del bucle es otra invocación del modelo fundacional contra el prompt ampliado: que es la razón por la que un agente es más caro que un único prompt para la misma pregunta.
• El retorno de control es una segunda llamada a InvokeAgent, no un campo que puedes rellenar después en la misma petición. Tu aplicación ejecuta la herramienta y se reinscribe.
• Las observaciones, no el historial de chat, dirigen los resultados de las herramientas. El resultado de una acción se añade al prompt base para que el modelo pueda razonar sobre él en la siguiente iteración.

3.2 Las cuatro plantillas base editables

AWS documenta cuatro plantillas base como sobrescribibles. Los prompts avanzados te permiten reemplazar el texto por completo; promptCreationMode y parserMode en la traza te dicen si un valor vino de DEFAULT o de OVERRIDDEN: que es tu evidencia de auditoría de que una sobreescritura está activa.

3.3 Tipos de traza: siete objetos que responden siete preguntas

Con enableTrace = true el runtime transmite eventos de traza junto a los eventos chunk. Hay 7 tipos de objetos de traza:

3.4 Ejemplo 2: una petición de reserva, traza por traza

1. La aplicación llama a InvokeAgent con agentId, agentAliasId, sessionId = S1, inputText = "Reserva el vuelo más barato a Denver el viernes próximo" (≤ 2.048 caracteres) y enableTrace = true.
2. El preprocesamiento valida la petición → PreProcessingTrace { isValid: true, rationale }.
3. Orquestación, iteración 1: rationale → predecir FlightsAPI.searchFlights → InvocationInput { apiPath, parameters } → Lambda ejecuta → Observation que contiene la lista JSON de vuelos.
4. Iteración 2: falta un parámetro requerido (travelerId) → la Observación devuelta vuelve a preguntar al usuario: «¿Para qué viajero debo reservar?» (AWS documenta este comportamiento explícitamente).
5. El usuario responde en el mismo sessionId → la acción se ejecuta → nueva Observation.
6. Postprocesamiento (si está habilitado) formatea la respuesta → la aplicación recibe chunk.bytes como «Reservado UA 512…», más un objeto attribution si se usó una base de conocimiento. Las trazas se transmiten junto a los trozos.

📚 ¿Sabías que…? El OrchestrationTrace es donde puedes probar qué hizo realmente tu agente: InvocationInput registra el action group, el verbo HTTP, el apiPath o nombre de función, los parámetros resueltos y el executionType, y Observation registra lo que regresó. Cuando un stakeholder pregunta «¿por qué el agente llamó a la API de pago?», la traza, no CloudTrail, es el primer lugar donde mirar, porque CloudTrail ve la invocación de Lambda pero no la fundamentación del modelo para elegirla.

3.5 Leer una traza: síntoma → objeto de traza → arreglo

---

4. Grupos de acción, retorno de control y uso crudo de herramientas

4.1 Dos estilos de esquema, dos ejecutores

Un action group se define con exactamente un estilo de esquema y exactamente un ejecutor:

Dos límites que vale la pena citar: la description de un action group va de 1 a 200 caracteres, y un ejecutor es un tipo unión: un ARN de Lambda o customControl: RETURN_CONTROL, nunca ambos.

4.2 Ejemplo 3: retorno de control, el escenario oficial del clima

Usa el retorno de control cuando tu aplicación deba ejecutar la llamada: un carril de pagos privado, un sistema on-premises, una credencial que Bedrock quizá no deba tener.

1. Crea el action group WeatherAPIs con la función getWeather(location, date) y el ejecutor customControl = RETURN_CONTROL.
2. El usuario dice «Planifica un día en Seattle este fin de semana.» → la orquestación predice getWeather.
3. La respuesta lleva returnControl.invocationInputs con invocationId = abc-123 y los parámetros {location: seattle, date: 2024-09-15}.
4. Tu aplicación llama a la API real del clima → la respuesta es lluvia.
5. Llamas a InvokeAgent otra vez con el mismo sessionId, suministrando sessionState.returnControlInvocationResults = [{ functionResult: { actionGroup, function, responseBody: { TEXT: { body: "{\"cond\":\"rain\"}" } } } }] con el invocationId correspondiente, y inputText se ignora porque returnControlInvocationResults está presente.
6. La orquestación reanuda: «Lleva un paraguas; aquí tienes un plan para interior…». Variantes: responseState = REPROMPT devuelve un resultado de herramienta fallido para un reintento; responseState = FAILURE falla la ejecución con un error de dependencia; confirmationState = CONFIRM | DENY implementa una verificación de confirmación del usuario previa a la acción.

4.3 Ejemplo 4: relleno de slots con function details

1. La función es BookHotel(HotelName/required, CheckinDate/required, NumberOfNights/optional, Email/required, AllowMarketingEmails/required).
2. El usuario dice «Reserva el Hotel X para mañana» → el agente rellena HotelName y CheckinDate.
3. Dos parámetros required son desconocidos → el agente pregunta al usuario: «¿Cuál es tu correo electrónico? ¿Podemos enviarte promociones?»
4. El usuario responde en dos turnos (los valores con ámbito de turno viven en promptSessionAttributes) → todos los parámetros requeridos están presentes → la acción se ejecuta → se devuelve una confirmación.

La solicitud de slots es el discriminador canónico entre agente y prompt. Un prompt simple no puede esperar a un parámetro requerido que falta, llamar a una API y luego reanudar: un agente hace exactamente eso, dirigido por la observación de que falta un parámetro.

4.4 Uso crudo de herramientas sin un agente

El function calling también existe sin ningún agente, en la API Converse: pasas toolConfig.tools[].toolSpec { name, description, inputSchema.json } (más toolChoice), el modelo devuelve JSON con stopReason = toolUse, tu aplicación ejecuta la función, y envías un toolResult de vuelta. El modelo nunca ejecuta la función: esa frontera es todo el punto, y es la forma más fiable de distinguir una pregunta de herramienta de una pregunta de agente.

---

5. InvokeAgent, estado de sesión y memoria

5.1 El contrato de la petición

La respuesta transmite chunk + trace + attributions + returnControl, y las cabeceras de la respuesta incluyen x-amz-bedrock-agent-session-id y, cuando se usa memoria, x-amz-bedrock-agent-memory-id.

5.2 sessionState: cinco ámbitos, una regla de override

5.3 Ejemplo 5: memoria entre sesiones

1. En la sesión S1 el usuario dice «Soy alérgico a los mariscos»; la aplicación llama a InvokeAgent con endSession = true.
2. S1 se pliega en memoryId = M-user-42 y el resumido asíncrono escribe un resumen usando la plantilla de resumido (editable).
3. Después, InvokeAgent(sessionId = S2, memoryId = M-user-42, inputText = "Sugiere un entrante") carga los resúmenes almacenados → la respuesta excluye los mariscos; la cabecera de respuesta x-amz-bedrock-agent-memory-id confirma que se usó memoria.
4. storageDays = 90 significa que los resúmenes más antiguos se purgan tras 90 días; desactivar la memoria devuelve el contexto de sesión única por defecto.

Los hechos sobre la memoria en un solo lugar: el único tipo de memoria es SESSION_SUMMARY, la retención es de 1 to 365 días (storageDays), los desencadenantes del plegado son endSession = true en el mismo sessionId o el vencimiento del idleSessionTimeout, el resumido se ejecuta de forma asíncrona con una plantilla editable, y lees los resúmenes con GetAgentMemory (o la pestaña Memory de la consola).

5.4 Cuotas de gestión de sesiones (separadas de la memoria)

📚 ¿Sabías que…? La CLI de AWS no puede transmitir InvokeAgent. Transmitir los eventos chunk y trace requiere un SDK con manejo de event-stream (por ejemplo boto3/Java/Node con el lector de stream de respuestas). Este es un percance operativo real, y un distractor favorito: «habilita el streaming con aws bedrock-agent-runtime invoke-agent --no-cli-pager» no existe. Usa enableTrace = true más un lector de stream del SDK, y lee la sesión de vuelta desde la cabecera de respuesta x-amz-bedrock-agent-session-id.

---

6. Colaboración multi-agente

6.1 Un supervisor, como máximo diez colaboradores, dos modos

6.2 Ejemplo 6: un supervisor de triaje

1. Despliega los colaboradores ReturnsAgent y BillingAgent y crea un alias para cada uno.
2. Promueve TriageAgent a supervisor, elige el modo Supervisor con enrutamiento y adjunta ambos alias (nunca más de 10).
3. El cliente pregunta «¿Por qué me cobraron dos veces en marzo?» → RoutingClassifierTrace registra la decisión → el supervisor invoca BillingAgent con sessionState.conversationHistory.
4. El action group de BillingAgent llama a Lambda → la respuesta final se sintetiza y se transmite de vuelta.
5. Si el requisito hubiera sido «investigar devoluciones y facturación, y luego resumir», el modo correcto habría sido Supervisor a secas, que descompone la petición y coordina las respuestas de los colaboradores en lugar de elegir uno.

---

7. Amazon Bedrock Flows (antes Prompt Flows)

7.1 Qué es un Flow

Un Flow es un grafo visual y declarativo de nodos que dibujas en el Flow builder e invocas a través de CreateFlow → PrepareFlow → InvokeFlow (con versiones y alias, exactamente como los agentes). El modelo no elige los pasos: el grafo lo hace. Flows llegó a GA el 22 de noviembre de 2024 como «Amazon Bedrock Flows, anteriormente conocido como Prompt Flows», añadiendo visibilidad de ejecución por paso más Guardrails en los nodos de prompt y de base de conocimiento.

7.2 Los 16 tipos de nodo

Las conexiones vienen de dos tipos: conexiones de datos (sólidas) que siempre transportan valores, y condicionales (punteadas) que se disparan solo cuando un nodo Condition se evalúa como verdadera. Los Guardrails pueden adjuntarse a los nodos prompt y knowledge-base: que es como logras aplicación de políticas dentro de un grafo en lugar de a su alrededor.

7.3 Ejemplo 7: un pipeline de invitaciones con una rama

1. CreateFlow con un nombre y un rol IAM; conecta los nodos: Input → Prompt (redactar el cuerpo del correo) → KnowledgeBase (direcciones de asistentes) → Condition (¿asistentes > 50?).
2. Rama Sí → nodo Lambda de envío masivo; rama No → nodo Lambda de envío individual; ambos convergen en Output. Las conexiones de datos son sólidas; las dos ramas condicionales son punteadas.
3. PrepareFlow → prueba dentro del Flow builder, inspeccionando la entrada/salida por nodo.
4. Crea una versión y un alias; la aplicación llama a InvokeFlow (síncrono, techo de 1 hora) o inicia una ejecución de flow asíncrona (vista previa: ≤ 5 minutos por nodo, ≤ 24 horas por flow, instantánea vía GetExecutionFlowSnapshot, errores como ExecutionTimedOut).
5. Lee los FlowTraceEvent para visibilidad por paso; cambia el nodo Prompt por un nodo Agent cuando se requiera razonamiento: la API de conversación multi-turno está en vista previa (INPUT_REQUIRED → tu respuesta → SUCCESS).

7.4 Qué cuesta un Flow, y qué no hace

Los Flows se facturan por transición de nodo, además del consumo del modelo fundacional, de Lambda y de la base de conocimiento dentro de los nodos. El propio recorrido de precios de AWS cuenta una ejecución como 2 + 10×2 + 3 = 25 transiciones; se anunció una tarifa de $0.035 por 1.000 transiciones para el 1 de febrero de 2025, y la tarifa actual debería confirmarse en la página de precios de Bedrock antes de citarla. Dos límites para memorizar: las ejecuciones síncronas de InvokeFlow vencen a 1 hora, y el trabajo de larga duración pertenece a las ejecuciones de flow asíncronas (vista previa: 5 minutos por nodo, 24 horas en total) o a Step Functions.

Ejemplo resuelto: contar transiciones de nodo. El recorrido de precios de AWS cobra una ejecución como 2 + 10×2 + 3 = 25 transiciones: 2 para entrar y ramificar, un cuerpo de bucle de 10 iteraciones × 2 nodos, y 3 más para converger y salir. La lección es que las transiciones, no los nodos, son la unidad facturable:

📚 ¿Sabías que…? La aritmética del ejemplo de precios, 2 + 10×2 + 3 = 25 transiciones de nodo, es un recordatorio de que los bucles no son gratis en un grafo: un nodo revisado diez veces se factura diez veces. Eso es lo contrario de un agente, donde las iteraciones se facturan como tokens del modelo fundacional, y lo contrario de Step Functions, donde las transiciones se facturan como transiciones de máquina de estados más los servicios que llamas. Tres orquestadores, tres unidades de coste distintas.

---

8. Elegir: prompt, agente, Flows o Step Functions

8.1 El árbol de decisión

8.2 La matriz de decisión

8.3 Ejemplo 8: tres requisitos, tres respuestas

1. Extracción determinista → condición → escritura, con rollback A/B → Amazon Bedrock Flows: dibuja el grafo, publica la versión v2, el alias apunta a v1, haz rollback moviendo el alias. Un alias de versión de Flow es exactamente el mecanismo A/B que un agente no tiene.
2. Tarea multi-turno abierta donde el FM decide qué llamar → un agente (AgentCore para una construcción nueva en octubre de 2026). La solicitud de slots, las nuevas preguntas y las observaciones son las pistas.
3. «Esperar 3 días a la aprobación, reintentar 5 veces, y luego notificar» → AWS Step Functions, cuya integración optimizada con Bedrock (anunciada en noviembre de 2023) incluye InvokeModel, CreateModelCustomizationJob .sync y una muestra documentada de «Realiza encadenamiento de prompts con Bedrock». Ni Flows (techo de 1 h síncrono) ni un agente (sin temporizadores nativos largos) encajan.

---

9. Veredicto comparativo

9.1 Revisión humana hoy

Amazon A2I está en mantenimiento: «ya no está abierta a clientes nuevos… no planeamos introducir características nuevas», formó parte del lote de mantenimiento del 30 de junio de 2026, y ha sido eliminado de la lista de alcance actual del AIF-C01 (estaba presente en la guía del examen v1.4, 2024). Para workflows, el patrón documentado de intervención humana es Step Functions con su integración optimizada con Bedrock (2023). AWS no documenta ningún hook de A2I nativo del agente de Bedrock: así que una opción que describa «adjuntar A2I a un agente de Bedrock como paso de revisión humana» está probando si sabes que el servicio salió del alcance del examen.

---

10. Trampas de examen y los números que vale la pena memorizar

Marcas sobre hechos que esta lección deliberadamente no afirmó como verificados: el precio actual por transición de Flow; la fecha exacta de GA de la colaboración multi-agente (los agregadores muestran artículos tanto del 3 dic 2024 como del 10 mar 2025); la lista actual de modelos soportados para multi-agente; el nombre del campo executionId usado para reanudar un flow multi-turno (los estados INPUT_REQUIRED / SUCCESS están documentados, el nombre del campo no se localizó); y el estado de vista previa frente a GA del nodo InlineCode.

10.1 Actualizaciones de 2025 to 2026

Todo lo de este subapartado se leyó en docs.aws.amazon.com, en una publicación What's New de AWS, en una publicación del AWS News Blog o en la propia guía del examen AIF-C01: nada de aquí proviene de un rastreador de terceros. Dos grupos de cambios importan para esta lección: lo que se publicó dentro de Amazon Bedrock AgentCore y Amazon Bedrock Flows, y lo que AWS hizo con la guía del examen y con los servicios que rodean a un agente.

AWS afirma que las actualizaciones de la guía del examen llegan al examen activo aproximadamente un mes después de su publicación, así que los nuevos objetivos de v1.1 han sido materia válida desde aproximadamente finales de mayo de 2026. También dentro de esta ventana: Bedrock Studio independiente se fusionó en SageMaker Unified Studio (espacios de trabajo cerrados el 28 feb 2025, documentación mudada el 25 mar 2025), de modo que el Flow builder y las herramientas de prompts ahora se encuentran ahí en lugar de en un estudio separado.

📚 ¿Sabías que…? El SDK de AgentCore superó 2 millones de descargas en sus primeros cinco meses después del GA, y AgentCore Evaluations se entrega con 13 evaluadores, la cifra de adopción que la propia AWS publicó para mostrar dónde se espera que aterrice el trabajo nuevo de agentes. También explica la forma de las preguntas del examen: los ítems de alcance preguntan por capacidades (Runtime, Gateway, Identity, Memory, Observability, Harness, ahora unidos por Policy y Evaluations) en lugar de por un único objeto «agente», porque AWS descompuso un servicio en componentes en lugar de renombrarlo.

---

11. Casos Reales

AWS publica pocas historias de clientes sobre orquestación como tal, un bucle interno rara vez es fotogénico, así que estos cuatro se eligieron porque cada uno nombra sus servicios, sus cifras y su fuente, y cada uno mapea a una rama distinta del árbol de decisión de la §8. Lee cada porcentaje como una cifra afirmada por el cliente o por AWS, no auditada, y lee «hasta» como un techo.

11.1 Las cuatro historias

Epilot: una cola, no un agente, es dueña de la secuencia (software energético, Colonia, 2026). Las cadenas de correo largas a través de más de 170 clientes de servicios públicos estaban drenando tiempo del personal. El pipeline publicado es una API → Amazon SQS → AWS Lambda → Amazon Bedrock (Claude Sonnet), con el modelo elegido usando Amazon Bedrock Evaluations (valoraciones humanas entre versiones de prompt) antes de producción, y un agente posterior que escribe registros con verificación humana. Resultado informado: −87% en tiempo de manejo de correos, 55.000 resúmenes al mes con una tasa de fallo despreciable, 80% de usuarios diciendo que simplifica su trabajo, un MVP en 2 meses, y los datos procesados mantenidos en una Región de la UE. Esta es la rama de la §8 de «tu código es dueño de cada paso» en producción, más dos hábitos que esta lección repite: evalúa el modelo antes de desplegar, y mantén a un humano al final de una escritura automatizada. Fuente: caso de estudio de AWS, solutions/case-studies/epilot-genai-case-study (2026).

Prime Focus Technologies: agentes donde los pasos varían por activo (medios, 2025). La localización (subtítulos, traducción, transcripciones) a través de 14 millones o más de activos en CLEAR: Disney Star, CBS, Lionsgate: es intensiva en mano de obra, y el etiquetado de críquet en directo necesitaba baja latencia. La arquitectura publicada ejecuta agentes de Amazon Bedrock + AWS Lambda que automatizan y re-revisan esos flujos de trabajo. Resultado informado: coste de localización −20 to 30%, exactitud +20 to 30%, tiempo de respuesta −30 to 40%. La precaución dentro de la fuente es la parte examinable: el primer intento usó APIs externas de LLM, cuya latencia era demasiado alta para el etiquetado en directo, y la latencia «cayó drásticamente» una vez las llamadas se ejecutaron en AWS. Es la rama de la §8 de «el modelo decide qué hacer a continuación», con la ubicación del modelo como requisito duro. Fuente: caso de estudio de AWS, solutions/case-studies/prime-focus-case-study (2025).

Alnylam Pharmaceuticals, las citas como característica de cumplimiento (biotecnología, 2025). El triaje de quejas llevaba 3 to 4 días y la búsqueda interna de información 15+ minutos. Desde junio de 2023 el equipo construyó un prototipo de ingesta/triaje sobre Amazon Bedrock + Amazon S3 con RAG en unos 3 meses bajo restricciones GxP, más AskALNY, un asistente de Slack en Amazon Q Business que devuelve enlaces a las fuentes. Resultado informado: triaje 3 días → horas, búsqueda 15 min → 30 s, 2.000 empleados + 1.000 contratistas servidos, 250+ casos de uso identificados. El mecanismo es una base de conocimiento debajo de lo que sea que sea dueño del bucle, y es la razón por la que la §3.3 trata las atribuciones de KB como de primera clase: en una respuesta regulada, la cita es la pista de auditoría. Fuente: caso de estudio de AWS, solutions/case-studies/alnylam-case-study (2025).

Sun Finance: una máquina de estados, y un prototipo solo-LLM rechazado (préstamos fintech, 9 países, 2026). El 60% de las solicitudes de micropréstamo necesitaba revisión manual, llevando 10 minutos a 20 horas cada una. El pipeline desplegado, construido con el AWS Generative AI Innovation Center, es OCR con Amazon Textract → respaldo y enmascarado facial con Amazon Rekognition → estructuración con Claude Sonnet 4 → reglas de validación → Titan Multimodal Embeddings en S3 Vectors para similitud de fraude, coordinado con AWS Step Functions y AWS Lambda. Resultado informado: exactitud 79,73% → 90,80%, coste por documento −91%, procesamiento 20 horas → menos de 5 segundos, detección de fraude 81%. Es la rama de máquina de estados de la §8 y la lección de la §4 leída al revés: los servicios deterministas extraen, el modelo estructura, y cada paso permanece auditable. Fuente: AWS Machine Learning Blog, blogs/machine-learning/sun-finance-automates-id-extraction-and-fraud-detection-with-generative-ai-on-aws (2026).

11.2 Servicios, cifras y fuentes de un vistazo

11.3 Qué prueba cada caso contra esta lección

📚 ¿Sabías que…? El prototipo rechazado de Sun Finance es la lección más limpia de OCR frente a razonamiento del curso: el intento 1, solo Claude Sonnet 4, alcanzó solo el 61,8% en general y 43% en números de documento de identidad y fue descartado, porque las protecciones de privacidad del modelo bloquean la extracción directa de PII. El intento 2 (Textract + Claude) alcanzó el 85%, y el pipeline desplegado con reglas de validación llegó al 90,80% con un −91% de coste por documento. La conclusión coincide exactamente con la §4: deja que un servicio determinista haga la extracción, deja que el modelo haga la estructura, y deja que una máquina de estados guarde el recibo.

---

Preguntas de Práctica (Practice Questions)

---