Amazon Bedrock Agents, Flows e Orquestração

Tudo neste curso até agora foi sobre uma chamada de modelo: escreva um prompt, obtenha uma completion, avalie-a. IA em produção raramente é uma chamada. É uma sequência, procure algo, verifique uma condição, chame uma API, faça uma pergunta de acompanhamento ao usuário, tente de novo, e o exame tem um vocabulário dedicado para quem é dono dessa sequência: você (o código da sua aplicação), o modelo (um agente que escolhe ações em runtime), um grafo que você desenhou (Amazon Bedrock Flows), ou uma máquina de estados (AWS Step Functions). A Lição 11 é sobre essa decisão de propriedade, e sobre os serviços da AWS que implementam cada resposta.

Ao final desta lição você será capaz de:

• nomear os quatro componentes de build time que todo agente precisa e os opcionais que a AWS lista ao lado deles;
• percorrer o loop de runtime, pré-processamento, orquestração, pós-processamento, e dizer qual dos quatro templates base de prompt é editável em cada fase;
• escolher entre um OpenAPI schema e function details, e entre um executor Lambda e RETURN_CONTROL;
• enunciar o contrato do InvokeAgent: parâmetros obrigatórios, o teto de 2.048 caracteres do inputText, os scopes do sessionState e o que acontece com o inputText em um resubmission de return control;
• descrever a memória do agente (SESSION_SUMMARY, 1 to 365 dias) e as cotas de gerenciamento de sessão;
• configurar colaboração multi-agente (≤ 10 aliases de colaborador, dois modos) e explicar por que orquestração custom é incompatível com ela;
• listar os 16 tipos de nó do Flows, os dois tipos de conexão e os limites de execução (1 h sync, 5 min/nó e 24 h async em preview);
• defender o veredito comparativo: agente vs. prompt simples vs. workflow vs. código.

---

1. Três nomes, três serviços: Agents Classic, AgentCore e Flows

1.1 Os renomeamentos que decidem o exame

Dois renomeamentos carregam mais pontos do que qualquer outro fato desta lição:

1. "Amazon Bedrock Agents" / "Agents for Amazon Bedrock" → Amazon Bedrock Agents Classic. A AWS o colocou sob Serviços indo para Manutenção no seu Service Availability Update de 30 de junho de 2026: fechado para novos clientes a partir de 30 de julho de 2026, sem novos recursos, e um catálogo de modelos de fundação congelado em 30 de julho de 2026. Clientes existentes não são afetados, e modelos, Knowledge Bases e Guardrails do Amazon Bedrock são explicitamente não afetados. Não há exceções para o corte de novos clientes.
2. "Prompt Flows" → Amazon Bedrock Flows, generally available em 22 de novembro de 2024, acrescentando visibilidade de execução por etapa e suporte a Guardrails em nós de prompt e de knowledge base. O nome antigo sobrevive apenas em algumas listas em escopo de certificação.

O alvo de migração documentado para o Agents Classic é o Amazon Bedrock AgentCore: um conjunto de seis componentes (Runtime, Gateway, Identity, Memory, Observability e Harness) que entrou em preview em julho de 2025, chegou ao GA em nove regiões, e continuou entregando ao longo de 2026 (Managed Knowledge Base GA em junho de 2026, Agent Registry GA em agosto de 2026).

📚 Você sabia? AgentCore não é um agente renomeado: é uma decomposição. Seus seis componentes mapeiam para peças que costumavam viver dentro de um único agente: Runtime (o loop de invocação), Gateway (exposição de ferramentas/APIs), Identity, Memory, Observability (traces e telemetria) e Harness (empacotamento). É por isso que a orientação de migração da AWS fala em mover capacidades, não em um upgrade com um clique de um ID de agente existente.

1.2 O que o exame oficialmente pergunta sobre agentes

O guia de exame AIF-C01 é a autoridade para o escopo, e seu conteúdo agentic fica em dois lugares:

Duas mudanças de escopo foram publicadas para esta versão do exame: AgentCore, Kiro, Strands Agents, Amazon Q, SageMaker JumpStart e AWS Transform foram adicionados, e Amazon MemoryDB foi removido. Amazon A2I, listado no guia de exame v1.4 (2024), não está mais na lista de escopo atual.

---

2. Anatomia de um agente

2.1 O mínimo de build time

A própria redação da AWS sobre o que um agente é feito é precisa e vale decorar como uma frase: um modelo de fundação, instructions, opcionalmente templates de prompt base ou advanced, e pelo menos um de: action groups ou knowledge bases. Memória, Guardrails, code interpretation e colaboração multi-agente são todos add-ons opcionais.

Duas linhas merecem ênfase própria. Primeiro, alias: InvokeAgent exige agentAliasId, nunca um agent ID puro: um rascunho de agente que você nunca preparou e criou alias não pode ser chamado. Segundo, function details vs. OpenAPI: eles são alternativas, não camadas. Um action group usa exatamente um dos dois schemas, e a união de executor (Lambda ARN | RETURN_CONTROL) se aplica a ambos.

2.2 Exemplo 1: construindo um agente de viagens (build time)

1. Crie o agente e dê a ele instructions: "Você é um agente de viagens. Reserve o voo mais barato em conformidade. Nunca invente preços; sempre chame a FlightsAPI."
2. Escolha um modelo de fundação do catálogo disponível para Agents Classic na sua conta.
3. Adicione um action group FlightsAPI com um OpenAPI schema descrevendo searchFlights e bookFlight.
4. Defina o executor como um ARN de Lambda (o Lambda valida IAM, chama a API da companhia aérea e retorna JSON).
5. Opcionalmente anexe uma knowledge base de políticas de viagem corporativas, um guardrail que bloqueia números de cartão, e memória com storageDays = 90.
6. PrepareAgent → anote a versão → crie um alias (por exemplo T1).
7. Entregue à aplicação agentId + agentAliasId e chame InvokeAgent.

Nada acima é autônomo ainda: a autonomia aparece apenas em runtime, no loop que o modelo dirige.

---

3. Runtime: o loop de orquestração

3.1 As três fases, em ordem

Cada chamada InvokeAgent passa por pré-processamento, depois um loop de orquestração que se repete até que exista uma resposta ou o usuário receba um novo prompt, e então pós-processamento (desativado por padrão). O próprio loop tem um ritmo interno fixo: o modelo produz um rationale, prevê uma chamada de action group ou uma query de knowledge base, os parâmetros vão para o Lambda ou de volta para a sua aplicação via return control, o resultado volta como uma observation, a observation é anexada ao prompt base, e o loop se repete.

Três consequências saem daquele diagrama e cada uma já foi testada:

• O custo escala com as iterações, não com as requisições. Cada volta do loop é outra invocação do modelo de fundação contra o prompt aumentado, e é por isso que um agente é mais caro do que um prompt único para a mesma pergunta.
• Return control é uma segunda chamada InvokeAgent, não um campo que você pode preencher depois na mesma requisição. Sua aplicação executa a ferramenta e resubmete.
• Observations, não o histórico de chat, dirigem os resultados de ferramenta. O resultado de uma ação é anexado ao prompt base para que o modelo raciocine sobre ele na próxima iteração.

3.2 Os quatro templates base editáveis

A AWS documenta quatro templates base como sobrescrevíveis. Prompts advanced deixam você substituir o texto inteiramente; promptCreationMode e parserMode no trace dizem se um valor veio de DEFAULT ou OVERRIDDEN: que é a sua evidência de auditoria de que um override está ativo.

3.3 Tipos de trace: sete objetos que respondem sete perguntas

Com enableTrace = true o runtime transmite eventos de trace ao lado dos eventos chunk. Existem 7 tipos de objeto de trace:

3.4 Exemplo 2: uma requisição de reserva, trace a trace

1. A aplicação chama InvokeAgent com agentId, agentAliasId, sessionId = S1, inputText = "Reserve o voo mais barato para Denver na próxima sexta" (≤ 2.048 caracteres) e enableTrace = true.
2. Pré-processamento valida a requisição → PreProcessingTrace { isValid: true, rationale }.
3. Orquestração, iteração 1: rationale → prevê FlightsAPI.searchFlights → InvocationInput { apiPath, parameters } → Lambda executa → Observation contendo a lista JSON de voos.
4. Iteração 2: um parâmetro required (travelerId) está ausente → a Observation retornada faz um novo prompt ao usuário: "Para qual viajante devo reservar?" (a AWS documenta esse comportamento explicitamente).
5. O usuário responde na mesma sessionId → a ação executa → nova Observation.
6. Pós-processamento (se habilitado) formata a resposta → a aplicação recebe chunk.bytes como "Reservado UA 512…", mais um objeto attribution se uma knowledge base foi usada. Traces são transmitidos ao lado dos chunks.

📚 Você sabia? O OrchestrationTrace é onde você pode provar o que seu agente realmente fez: InvocationInput registra o action group, verbo HTTP, apiPath ou nome da função, os parâmetros resolvidos e o executionType, e Observation registra o que voltou. Quando um stakeholder pergunta "por que o agente chamou a API de pagamento?", o trace, não o CloudTrail, é o primeiro lugar para olhar, porque o CloudTrail vê a invocação do Lambda, mas não o rationale do modelo por tê-la escolhido.

3.5 Lendo um trace: sintoma → objeto de trace → correção

---

4. Action groups, return of control e tool use bruto

4.1 Dois estilos de schema, dois executors

Um action group é definido por exatamente um estilo de schema e exatamente um executor:

Dois limites que valem a pena citar: a description de um action group vai de 1 to 200 caracteres, e um executor é um tipo união: um ARN de Lambda ou customControl: RETURN_CONTROL, nunca ambos.

4.2 Exemplo 3: return of control, o cenário oficial de clima

Use return of control quando a sua aplicação deve executar a chamada: um trilho de pagamento privado, um sistema on-premises, uma credencial que o Bedrock pode não reter.

1. Crie o action group WeatherAPIs com a função getWeather(location, date) e executor customControl = RETURN_CONTROL.
2. O usuário diz "Planeje um dia em Seattle neste fim de semana." → a orquestração prevê getWeather.
3. A resposta carrega returnControl.invocationInputs com invocationId = abc-123 e parâmetros {location: seattle, date: 2024-09-15}.
4. A sua aplicação chama a API real de clima → a resposta é chuva.
5. Você chama InvokeAgent de novo com a mesma sessionId, fornecendo sessionState.returnControlInvocationResults = [{ functionResult: { actionGroup, function, responseBody: { TEXT: { body: "{\"cond\":\"rain\"}" } } } }] com o invocationId correspondente, e inputText é ignorado porque returnControlInvocationResults está presente.
6. A orquestração retoma: "Leve um guarda-chuva; aqui está um plano para indoors…". Variantes: responseState = REPROMPT alimenta um resultado de ferramenta com falha de volta para uma nova tentativa; responseState = FAILURE falha a execução com um erro de dependência; confirmationState = CONFIRM | DENY implementa um gate de confirmação do usuário antes da ação.

4.3 Exemplo 4: slot filling com function details

1. A função é BookHotel(HotelName/required, CheckinDate/required, NumberOfNights/optional, Email/required, AllowMarketingEmails/required).
2. O usuário diz "Reserve o Hotel X para amanhã" → o agente preenche HotelName e CheckinDate.
3. Dois parâmetros required são desconhecidos → o agente pergunta ao usuário: "Qual é o seu e-mail? Podemos enviar promoções?"
4. O usuário responde em dois turns (valores com escopo de turn vivem em promptSessionAttributes) → todos os parâmetros required estão presentes → a ação executa → uma confirmação é retornada.

Slot elicitation é o discriminador canônico agente-versus-prompt. Um prompt simples não pode esperar por um parâmetro required ausente, chamar uma API e então retomar: um agente faz exatamente isso, dirigido pela observation de que um parâamento está ausente.

4.4 Tool use bruto sem um agente

O function calling também existe sem nenhum agente, na API Converse: você passa toolConfig.tools[].toolSpec { name, description, inputSchema.json } (mais toolChoice), o modelo retorna JSON com stopReason = toolUse, a sua aplicação executa a função, e você envia um toolResult de volta. O modelo nunca executa a função: essa fronteira é o ponto inteiro, e é a maneira mais confiável de distinguir uma questão de ferramenta de uma questão de agente.

---

5. InvokeAgent, session state e memória

5.1 O contrato da requisição

A resposta transmite chunk + trace + attributions + returnControl, e os headers da resposta incluem x-amz-bedrock-agent-session-id e, quando memória é usada, x-amz-bedrock-agent-memory-id.

5.2 sessionState: cinco scopes, uma regra de override

5.3 Exemplo 5: memória entre sessões

1. Na sessão S1 o usuário diz "Sou alérgico a frutos do mar"; a aplicação chama InvokeAgent com endSession = true.
2. S1 se dobra em memoryId = M-user-42 e a sumarização assíncrona escreve um resumo usando o template de sumarização (editável).
3. Depois, InvokeAgent(sessionId = S2, memoryId = M-user-42, inputText = "Sugira um starter") carrega os resumos armazenados → a resposta exclui frutos do mar; o header x-amz-bedrock-agent-memory-id confirma que memória foi usada.
4. storageDays = 90 significa que resumos mais antigos são expurgados após 90 dias; desligar a memória retorna o contexto de sessão única padrão.

Fatos sobre memória em um lugar: o único tipo de memória é SESSION_SUMMARY, a retenção é de 1 to 365 dias (storageDays), os gatilhos de dobra são endSession = true na mesma sessionId ou o vencimento do idleSessionTimeout, a sumarização roda de forma assíncrona com um template editável, e você lê resumos com GetAgentMemory (ou a aba Memory do console).

5.4 Cotas de gerenciamento de sessão (separadas da memória)

📚 Você sabia? A AWS CLI não consegue transmitir InvokeAgent. Transmitir eventos chunk e trace requer um SDK com tratamento de event-stream (por exemplo boto3/Java/Node com o response stream reader). Este é um problema operacional real, e um distrator favorito: "habilite o streaming com aws bedrock-agent-runtime invoke-agent --no-cli-pager" não existe. Use enableTrace = true mais um SDK stream reader, e leia a sessão de volta do header de resposta x-amz-bedrock-agent-session-id.

---

6. Colaboração multi-agente

6.1 Um supervisor, no dez colaboradores, dois modos

6.2 Exemplo 6: um supervisor de triagem

1. Implante os colaboradores ReturnsAgent e BillingAgent e crie um alias para cada.
2. Promova TriageAgent a supervisor, escolha o modo Supervisor com roteamento e anexe ambos os aliases (nunca mais de 10).
3. O cliente pergunta "Por que fui cobrado duas vezes em março?" → RoutingClassifierTrace registra a decisão → o supervisor invoca BillingAgent com sessionState.conversationHistory.
4. O action group de BillingAgent chama o Lambda → a resposta final é sintetizada e transmitida de volta.
5. Se o requisito fosse "investigar devoluções e faturamento, depois resumir", o modo correto seria Supervisor puro, que decompõe a requisição e coordena as respostas dos colaboradores em vez de escolher um.

---

7. Amazon Bedrock Flows (ex-Prompt Flows)

7.1 O que um Flow é

Um Flow é um grafo visual e declarativo de nós que você desenha no Flow builder e invoca através de CreateFlow → PrepareFlow → InvokeFlow (com versões e aliases, exatamente como agentes). O modelo não escolhe as etapas, o grafo escolhe. Flows tornou-se GA em 22 de novembro de 2024 como "Amazon Bedrock Flows, anteriormente conhecido como Prompt Flows", acrescentando visibilidade de execução por etapa e Guardrails em nós de prompt e de knowledge base.

7.2 Os 16 tipos de nó

As conexões vêm em dois tipos: conexões de dados (sólidas) que sempre carregam valores, e conexões condicionais (pontilhadas) que disparam apenas quando um nó Condition avalia como true. Guardrails podem ser anexados a nós de prompt e de knowledge base: é assim que você aplica uma política dentro de um grafo em vez de ao redor dele.

7.3 Exemplo 7: um pipeline de convites com um branch

1. CreateFlow com um nome e uma role do IAM; ligue os nós: Input → Prompt (redigir o corpo do e-mail) → KnowledgeBase (endereços dos participantes) → Condition (participantes > 50?).
2. Branch Sim → nó Lambda de envio em massa; branch Não → nó Lambda de envio único; ambos convergem em Output. As conexões de dados são sólidas; os dois branches condicionais são pontilhados.
3. PrepareFlow → teste dentro do Flow builder, inspecionando o input/output de cada nó.
4. Crie uma versão e um alias; a aplicação chama InvokeFlow (síncrono, teto de 1 hora) ou inicia uma execução de flow assíncrona (preview: ≤ 5 minutos por nó, ≤ 24 horas por flow, snapshot via GetExecutionFlowSnapshot, erros como ExecutionTimedOut).
5. Leia FlowTraceEvents para visibilidade por etapa; troque o nó Prompt por um nó Agent quando raciocínio for necessário: a API de conversa multi-turn está em preview (INPUT_REQUIRED → sua resposta → SUCCESS).

7.4 O que um Flow custa, e o que ele não faz

Flows são cobrados por transição de nó, além do uso de modelo de fundação, Lambda e knowledge base dentro dos nós. O próprio walkthrough de preços da AWS conta uma execução como 2 + 10×2 + 3 = 25 transições; uma taxa de $0.035 por 1.000 transições foi anunciada para 1 de fevereiro de 2025, e a taxa atual deve ser confirmada na página de preços do Bedrock antes de você citá-la. Dois limites para decorar: execuções síncronas do InvokeFlow estouram em 1 hora, e trabalho de longa duração pertence a execuções de flow assíncronas (preview: 5 minutos por nó, 24 horas no total) ou a Step Functions.

Exemplo resolvido: contando transições de nó. O walkthrough de preços da AWS cobra uma execução como 2 + 10×2 + 3 = 25 transições: 2 para entrar e ramificar, um corpo de loop de 10 iterações × 2 nós, e mais 3 para convergir e sair. A lição é que transições, não nós, são a unidade faturável:

📚 Você sabia? A aritmética do exemplo de preços, 2 + 10×2 + 3 = 25 transições de nó, é um lembrete de que loops não são grátis em um grafo: um nó revisitado dez vezes é cobrado dez vezes. Isso é o oposto de um agente, onde as iterações são cobradas como tokens de modelo de fundação, e o oposto de Step Functions, onde as transições são cobradas como transições de máquina de estados mais os serviços que você chama. Três orquestradores, três unidades de custo diferentes.

---

8. Escolhendo: prompt, agente, Flows ou Step Functions

8.1 A árvore de decisão

8.2 A matriz de decisão

8.3 Exemplo 8: três requisitos, três respostas

1. Extrair determinístico → condition → gravar, com rollback A/B → Amazon Bedrock Flows: desenhe o grafo, publique a versão v2, o alias aponta para v1, faça rollback movendo o alias. Um alias de versão de Flow é exatamente o mecanismo A/B que um agente não tem.
2. Tarefa aberta multi-turn onde o FM decide o que chamar → um agente (AgentCore para uma construção nova em outubro de 2026). Slot elicitation, re-prompts e observations são os indicadores.
3. "Esperar 3 dias por aprovação, tentar 5 vezes, depois notificar" → AWS Step Functions, cuja integração otimizada com Bedrock (anunciada em novembro de 2023) inclui InvokeModel, CreateModelCustomizationJob .sync e um sample documentado "Perform prompt-chaining with Bedrock". Nem Flows (teto síncrono de 1 hora) nem um agente (sem timers nativos de longa duração) servem.

---

9. Veredito comparativo

9.1 Revisão humana hoje

Amazon A2I está em manutenção: "não está mais aberto a novos clientes… não planejamos introduzir novos recursos", fazia parte do lote de manutenção de 30 de junho de 2026, e foi removido da lista em escopo atual do AIF-C01 (estava presente no guia de exame v1.4, 2024). Para workflows, o padrão documentado de intervenção humana é Step Functions com sua integração otimizada com Bedrock (2023). A AWS não documenta nenhum hook de A2I nativo do agente Bedrock, então uma opção descrevendo "anexar A2I a um agente Bedrock como etapa de revisão humana" está testando se você sabe que o serviço saiu do escopo do exame.

---

10. Armadilhas do exame e os números que valem a pena decorar

Sinalizadores sobre fatos que esta lição deliberadamente não afirmou como verificados: o preço atual por transição do Flow; a data exata de GA da colaboração multi-agente (agregadores mostram itens de 3 dez 2024 e 10 mar 2025); a lista atual de modelos suportados para multi-agente; o nome do campo executionId usado para retomar um flow multi-turn (os estados INPUT_REQUIRED / SUCCESS são documentados, o nome do campo não foi localizado); e o status preview-vs-GA do nó InlineCode.

10.1 Atualizações de 2026 (em outubro de 2026)

Tudo nesta subseção foi lido em docs.aws.amazon.com, um post do AWS What's New, um post do AWS News Blog ou no próprio guia de exame AIF-C01: nada aqui vem de um rastreador de terceiros. Dois grupos de mudança importam para esta lição: o que foi entregue dentro do Amazon Bedrock AgentCore e do Amazon Bedrock Flows, e o que a AWS fez com o guia de exame e com os serviços ao redor de um agente.

A AWS afirma que atualizações do guia de exame chegam ao exame vivo cerca de um mês após a publicação, então os novos objetivos da v1.1 foram válidos desde aproximadamente finais de maio de 2026. Também dentro desta janela: o Bedrock Studio isolado foi incorporado ao SageMaker Unified Studio (workspaces fechados em 28 fev 2025, documentação movida em 25 mar 2025), então o Flow builder e as ferramentas de prompt agora se encontram lá em vez de em um studio separado.

📚 Você sabia? O SDK do AgentCore passou de 2 milhões de downloads em seus primeiros cinco meses após o GA, e o AgentCore Evaluations vem com 13 avaliadores, o número de adoção que a própria AWS publicou para mostrar onde o trabalho novo de agentes se espera que aterrice. Isso também explica o formato das questões do exame: itens de escopo perguntam sobre capacidades (Runtime, Gateway, Identity, Memory, Observability, Harness, agora unidos por Policy e Evaluations) em vez de sobre um objeto "agente" único, porque a AWS decompôs um serviço em componentes em vez de renomeá-lo.

---

11. Casos Reais

A AWS publica poucas histórias de clientes sobre orquestração como tal, um loop interno raramente é fotogênico, então estas quatro foram escolhidas porque cada uma nomeia seus serviços, seus números e sua fonte, e cada uma se mapeia em um ramo diferente da árvore de decisão da §8. Leia cada percentual como uma figura reivindicada pelo cliente ou pela AWS, não auditada, e leia "até" como um teto.

11.1 As quatro histórias

Epilot: uma fila, não um agente, é dona da sequência (software de energia, Colônia, 2026). Longas cadeias de e-mails entre mais de 170 clientes de utilities estavam drenando o tempo da equipe. O pipeline publicado é uma API → Amazon SQS → AWS Lambda → Amazon Bedrock (Claude Sonnet), com o modelo escolhido usando Amazon Bedrock Evaluations (avaliações humanas entre versões de prompt) antes da produção, e um agente posterior que grava registros com humanos verificando. Resultado relatado: −87% no tempo de tratamento de e-mails, 55.000 resumos por mês com taxa de falha negligenciável, 80% dos usuários dizendo que simplifica seu trabalho, um MVP em 2 meses, e dados processados mantidos em uma região da UE. Este é o ramo "seu código é dono de cada etapa" da §8 em produção, mais dois hábitos que esta lição repete: avalie o modelo antes de publicar, e mantenha um humano no fim de uma gravação automatizada. Fonte: estudo de caso da AWS, solutions/case-studies/epilot-genai-case-study (2026).

Prime Focus Technologies: agentes onde as etapas diferem por asset (mídia, 2025). Localização (legendas, tradução, transcrições) em mais de 14 milhões de assets no CLEAR: Disney Star, CBS, Lionsgate: é intensiva em mão de obra, e a marcação ao vivo de cricket precisava de baixa latência. A arquitetura publicada roda agentes Amazon Bedrock + AWS Lambda que automatizam e re-revisam esses workflows. Resultado relatado: custo de localização −20 to 30%, precisão +20 to 30%, turnaround −30 to 40%. A precaução dentro da fonte é a parte examinável: a primeira tentativa usou APIs externas de LLM, cuja latência era alta demais para marcação ao vivo, e a latência "caiu dramaticamente" quando as chamadas rodaram na AWS. Este é o ramo "o modelo escolhe o que fazer a seguir" da §8, com o posicionamento do modelo como um requisito rígido. Fonte: estudo de caso da AWS, solutions/case-studies/prime-focus-case-study (2025).

Alnylam Pharmaceuticals, citações como o recurso de conformidade (biotecnologia, 2025). O triagem de reclamações levava 3 to 4 dias e a busca de informação interna 15+ minutos. Desde junho de 2023 a equipe construiu um protótipo de intake/triagem em Amazon Bedrock + Amazon S3 com RAG em cerca de 3 meses sob restrições GxP, mais o AskALNY, um assistente Slack no Amazon Q Business que retorna links de fontes. Resultado relatado: triagem 3 dias → horas, busca 15 min → 30 s, 2.000 funcionários + 1.000 contratados atendidos, 250+ casos de uso identificados. O mecanismo é uma knowledge base sob o que quer que seja dono do loop, e é por isso que a §3.3 trata as atribuições de KB como de primeira classe: em uma resposta regulada, a citação é o rastro de auditoria. Fonte: estudo de caso da AWS, solutions/case-studies/alnylam-case-study (2025).

Sun Finance: uma máquina de estados, e um protótipo somente-LLM rejeitado (fintech de empréstimos, 9 países, 2026). 60% das aplicações de microemprestimo precisavam de revisão manual, levando 10 minutos a 20 horas cada. O pipeline entregue, construído com o AWS Generative AI Innovation Center, é OCR Amazon Textract → fallback Amazon Rekognition e mascaramento de rosto → estruturação Claude Sonnet 4 → regras de validação → Titan Multimodal Embeddings em S3 Vectors para similaridade de fraude, coordenado com AWS Step Functions e AWS Lambda. Resultado relatado: precisão 79,73% → 90,80%, custo por documento −91%, processamento 20 horas → menos de 5 segundos, detecção de fraude 81%. Este é o ramo de máquina de estados da §8 e a lição da §4 lida de trás para frente: serviços determinísticos extraem, o modelo estrutura, e cada etapa permanece auditável. Fonte: AWS Machine Learning Blog, blogs/machine-learning/sun-finance-automates-id-extraction-and-fraud-detection-with-generative-ai-on-aws (2026).

11.2 Serviços, números e fontes em uma olhada

11.3 O que cada caso prova contra esta lição

📚 Você sabia? O protótipo rejeitado da Sun Finance é a lição mais limpa de OCR-versus-raciocínio do curso: tentativa 1, Claude Sonnet 4 sozinho, alcançou apenas 61,8% no geral e 43% em números de documento de identidade e foi descartado, porque as proteções de privacidade do modelo bloqueiam a extração direta de PII. A tentativa 2 (Textract + Claude) atingiu 85%, e o pipeline entregue com regras de validação atingiu 90,80% com −91% de custo por documento. A lição combina exatamente com a §4: deixe um serviço determinístico fazer a extração, deixe o modelo fazer a estruturação, e deixe uma máquina de estados guardar o recibo.

---

Perguntas de Prática (Practice Questions)

---