Ciclo de Vida de ML Extremo a Extremo na AWS

Projetos de machine learning raramente falham porque um modelo não pode ser treinado. Eles falham porque ninguém decidiu qual estágio do ciclo de vida é dono de qual serviço, porque um protótipo de notebook foi colocado em produção como um endpoint permanente, ou porque ninguém percebeu que os dados de entrada mudaram seis meses após o lançamento. O exame AIF-C01 é construído exatamente em torno dessa lacuna: a Tarefa 1.3 pede que você posicione coleta de dados, EDA, pré-processamento, engenharia de atributos, treinamento, ajuste de hiperparâmetros, avaliação, implantação e monitoramento contra serviços AWS, e a Tarefa 1.1 pede que você distinga inferência em lote, tempo real, assíncrona e serverless.

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

• posicionar cada um dos nove estágios do ciclo de vida contra a feature do SageMaker e o serviço não-SageMaker que o suporta;
• aplicar o framework de seleção de três perguntas da AWS (construir vs. customizar vs. chamar uma API, modalidade, controle) antes de escrever qualquer código;
• configurar os online store e offline store do Feature Store e explicar por que um modelo de fraude precisa dos dois;
• dimensionar um endpoint serverless, calcular a concorrência do batch transform e conhecer o teto exato de cada uma das quatro opções de inferência;
• construir o loop deriva → CloudWatch → EventBridge → Pipelines retrain e explicar qual monitor detecta qual deriva;
• defender um veredito comparativo: SageMaker vs. construir em EC2, vs. plataformas não-AWS, vs. um processo manual;
• identificar as armadilhas de manutenção e sunset (Ground Truth, Model Monitor, Clarify, Studio Lab, Mechanical Turk) que aparecem em itens de exame de 2026;
• responder dez questões no estilo do exame escritas na voz oficial de questões de prática.

---

1. Os nove estágios do ciclo de vida de ML na AWS

1.1 Mapa de serviços estágio a estágio

Esta tabela é o artefato mais examinável da Tarefa 1.3. A coluna esquerda é o próprio vocabulário do guia de exame; as colunas do meio são os serviços que você deve ser capaz de nomear sob pressão.

1.2 Os conceitos de MLOps que o exame testa

A Tarefa 1.3 não para nos estágios. Ela também nomeia sete fundamentos de MLOps: cada um mapeia para um mecanismo AWS concreto:

1.3 O ciclo de vida é um loop, não uma linha

A seta que retorna de Monitoramento para Treinamento é o ponto todo de MLOps. Uma equipe que implanta e nunca retorna ao estágio 5 tem um projeto, não um sistema, e essa é exatamente a linguagem de "dívida técnica" e "prontidão de produção" que o exame usa.

Ordene o ciclo de vida antes de memorizar os serviços:

---

2. Escolhendo o caminho AWS: o framework de três perguntas

Antes de escolher um serviço, a AWS quer que você responda a três perguntas em ordem. Pular direto para "SageMaker" é o anti-padrão arquitetural mais comum no exame.

2.1 Pergunta 1: chamar uma API, customizar um foundation model ou construir o seu?

2.2 Pergunta 2: qual é a modalidade dos dados?

2.3 Pergunta 3: quanto controle você precisa?

A AWS documenta uma escada de controle que sobe de zero-código para código completo:

A AWS também avisa em sua própria orientação que Studio é o ponto de partida errado para uma equipe sem experiência em ML: comece com o Canvas.

2.4 Arquitetura de referência: uma conta, extremo a extremo

📚 Você sabia? Os SageMaker Pipelines são literalmente um DAG JSON. Os tipos de passo documentados são Processing, Training, Tuning, AutoML, RegisterModel, DeployModel, Transform, Condition, Callback, Lambda, ClarifyCheck, QualityCheck, EMR, Notebook Job e Fail, e as saídas dos passos alimentam as entradas dos passos a jusante, o que é o que torna o loop no diagrama acima automático.

---

3. Ingestão de dados, armazenamento e o Feature Store

3.1 De onde vêm os dados

3.2 Feature Store: online vs. offline

3.3 Camadas do online store e semântica de gravação

A AWS documenta duas camadas online:

• Standard: a configuração padrão do online store;
• InMemory: suportado por Amazon ElastiCache (Redis OSS) para as leituras mais rápidas. É somente online (sem replicação online↔offline) e não suporta chaves KMS gerenciadas pelo cliente.

No caminho de gravação, PutRecord.TargetStores aceita {OnlineStore, OfflineStore} com um máximo de 2 entradas, então uma única chamada pode atualizar ambos os stores, mas somente se um grupo tiver ambos habilitados.

Exemplo 5, frescor de atributos com números reais. Um modelo de fraude chama GetRecord e recebe uma resposta em single-digit milliseconds. O offline store do mesmo feature group mantém cada versão histórica como Parquet no S3, que o Athena pode consultar para um conjunto de treinamento point-in-time correto. Um PutRecord emitido às 14:00 chega ao S3 não mais tarde que 14:15 (bufferização de 15 minutos). O treinamento, portanto, vê um snapshot ligeiramente atrasado enquanto a inferência vê a linha mais nova, o que é exatamente por que o exame pede ambos os stores habilitados em um feature group.

📚 Você sabia? A identidade do Feature Store não é apenas uma chave primária: um registro é unicamente identificado pelo identificador do atributo mais o event time, e o offline store adicionalmente grava write_time, api_invocation_time e um indicador is_deleted. É isso que torna joins point-in-time possíveis: uma consulta de treinamento às 09:00 só pode ver atributos cujo event time é anterior a 09:00, mesmo que tenham sido gravados depois.

---

4. Processamento de dados, EDA e engenharia de atributos

4.1 Qual serviço processa qual carga de trabalho

4.2 O contrato do Processing job

Um SageMaker Processing job tem um contrato de quatro etapas que o exame gosta de testar:

A propriedade "computação é liberada" é por que os Processing jobs superam uma instância de notebook permanentemente anexada para qualquer coisa agendada.

4.3 Onde as ferramentas sem código vivem agora

Duas migrações importam para o exame de 2026:

• O Data Wrangler está integrado ao SageMaker Canvas: não é mais uma experiência separada na barra lateral do Studio;
• A UI do Autopilot mudou para o Canvas em 30 de novembro de 2023: a AutoML API permanece documentada e invocável, mas a experiência visual de AutoML é o Canvas.

📚 Você sabia? O Amazon Athena cobra por consulta e por gigabyte escaneado, então a EDA mais barata é uma tabela Parquet particionada mais um filtro WHERE dt = '…'. Uma varredura de tabela inteira de um CSV de 1 TB custa aproximadamente 100× mais do que a mesma consulta sobre Parquet particionado, o exame não pede o preço, mas pergunta se o Athena é "serverless SQL over S3".

---

5. Treinamento, ajuste de hiperparâmetros e orquestração

5.1 Training jobs e o teto de custo

5.2 Formas de treinar sem escrever o loop você mesmo

5.3 Pipelines: a espinha dorsal da orquestração

Um SageMaker Pipeline é um DAG JSON cujos passos trocam saídas como entradas. Os tipos de passo documentados são: Processing, Training, Tuning, AutoML, Register/Deploy model, Transform, Condition, Callback, Lambda, ClarifyCheck, QualityCheck, EMR, Notebook Job e Fail.

5.4 Model Registry

O Model Registry é a resposta de nível de produção para "qual modelo está no ar?". Ele armazena Model Package Groups versionados, e cada Model Package carrega métricas, linhagem, um estágio de staging, um status de aprovação, e ganchos para implantação CI/CD e compartilhamento entre contas. Qualquer coisa que não esteja no Registry é, em termos de exame, um experimento não rastreado.

---

6. Avaliação, documentação e governança

6.1 Amazon SageMaker Clarify: três análises diferentes

O Clarify grava métricas de viés JSON, atribuições globais e um relatório visual no S3, e pode executar contra um endpoint ao vivo ou contra um endpoint shadow temporário que o Clarify cria e então apaga.

6.2 Model Cards e Model Dashboard

Se o exame diz "the model owner must record intended uses, risk rating, training details and evaluation results", a resposta é Model Cards: não o Dashboard (que agrega) e não o Model Monitor (que apenas rastreia deriva).

---

7. Implantação: as quatro opções de inferência

Este é o tópico central de seleção de serviço de toda a lição. O SageMaker AI documenta exatamente quatro opções de inferência, e cada uma tem um teto rígido que você deve ser capaz de relembrar.

7.1 Lote vs. tempo real vs. assíncrona vs. serverless

7.2 Os tetos numéricos em um lugar só

Verifique os tetos antes de escolher uma opção, o payload decide, não a preferência de latência:

7.3 Endpoints tempo real em detalhe

• Endpoint HTTPS persistente invocado com InvokeEndpoint; streaming de resposta usa InvokeEndpointWithResponseStream.
• HTTP/2 bidirecional na porta 8443, sessões limitadas a 30 minutos.
• Vários modelos podem compartilhar um endpoint através de inference components: a resposta do exame quando ele pede hospedar múltiplos modelos sem pagar por múltiplos endpoints.

7.4 Serverless Inference em detalhe

Você escolhe a memória; a AWS atribui vCPUs proporcionalmente. O tempo de cold start é impulsionado por tamanho do modelo + download do modelo + início do contêiner, o que é por que a memória deve ser pelo menos do tamanho do seu modelo.

Serverless tem exclusões documentadas: sem GPUs, sem pacotes do AWS Marketplace, sem registries privados, sem multi-model endpoints, sem configuração VPC, sem data capture, sem Model Monitor, e sem inference pipelines. E a conversão é em uma direção: converter um endpoint tempo real existente para serverless falha com um ValidationError, enquanto a conversão reversa é permitida e em uma direção.

7.5 Asynchronous Inference em detalhe

InvokeEndpointAsync pega sua entrada do S3, grava saída no S3, e envia uma notificação de conclusão. Requisições entram na fila enquanto a capacidade é zero, e o autoscaling pode escalar a contagem de instâncias para 0: essa combinação (fila + escala para zero) é o que torna a assíncrona a resposta certa para payloads grandes e lentos.

7.6 Batch transform em detalhe

• SplitType=Line divide o arquivo de entrada em mini-lotes;
• BatchStrategy=MultiRecord|SingleRecord com MaxPayloadInMB;
• CSV com novas linhas embutidas não é suportado;
• MaxPayloadInMB=0 significa streaming em chunk (não para algoritmos built-in);
• o nome de saída padrão é input1.csv.out;
• o MaxConcurrentTransforms ideal iguala o número de workers paralelos que você quer.

7.7 Escolhendo entre as quatro

Exemplo 1: escolha de opção por payload. Uma API de fraude recebe payloads de 3 KB e deve responder em menos de 200 ms → tempo real (tetos 25 MB / 60 s). Mais tarde o mesmo modelo é pedido para pontuar vídeos de 800 MB que levam 10 minutos → isso excede o teto tempo real de 25 MB mas cabe na assíncrona (≤ 1 GB, ≤ 60 min), então você troca de opção e mantém o scale-to-zero.

Exemplo 2: dimensionamento serverless. Um modelo de 3,5 GB precisa de MemorySizeInMB=4096 (memória deve ser ≥ tamanho do modelo; a faixa permitida é 1024…6144). Defina MaxConcurrency=50 (permitido 1 to 200) com ProvisionedConcurrency=10 (deve ser ≤ MaxConcurrency) para pré-aquecer parte do tráfego, e mantenha a imagem do contêiner ≤ 10 GB.

Exemplo 3: matemática de concorrência batch. Com MaxPayloadInMB=25, o MaxConcurrentTransforms máximo legal é 4, porque 4 × 25 = 100 ≤ 100 MB. Definir 5 quebraria a regra documentada (5 × 25 = 125 > 100).

---

8. Monitoramento, deriva e o loop de re-treinamento

8.1 Os quatro tipos de monitor

Todos os monitores emitem métricas e violações para o Amazon CloudWatch, que é a resposta do exame sempre que ele menciona "raise an alarm on thresholds". Note também que o contêiner de monitoramento pré-construído suporta somente dados tabulares: modelos NLP e de computer vision precisam de um contêiner traga-o-proprio.

8.2 Do alarme ao modelo retreinado

Exemplo 6, o loop deriva → re-treinar com números reais. Uma baseline Deequ é computada a partir dos dados de treinamento. Um job de monitoramento agendado compara tráfego ao vivo contra ela. O monitoramento de atribuição de atributos levanta um alerta automático quando NDCG cai abaixo de 0,90. Um exemplo de viés usa uma faixa DPPL de (−0,1, 0,1) avaliada ao longo de 2 dias com intervalos de confiança bootstrap. O alarme vai para o CloudWatch, o CloudWatch dispara uma regra EventBridge, e o EventBridge inicia uma execução de re-treinamento do SageMaker Pipelines cuja nova versão chega ao Model Registry como PendingManualApproval.

8.3 O que a AWS agora recomenda em vez disso

Porque Model Monitor e Clarify estão fechados para novos clientes, a própria documentação de mudança de disponibilidade da AWS aponta para uma stack de substituição:

📚 Você sabia? O Experiments Classic está disponível somente no Studio Classic, e a AWS agora recomenda MLflow 3.0 gerenciado com Studio Apps: os artefatos do experimento são armazenados no seu bucket S3, então os dados de tracking sobrevivem ao notebook. O MLflow também é a espinha dorsal da substituição recomendada para o Model Monitor.

---

9. Veredito comparativo: SageMaker vs. as alternativas

9.1 SageMaker vs. serviços individuais

Os critérios de decisão da própria AWS são: gestão de infraestrutura, compromissos de computação, preferência de precificação, suporte à arquitetura do modelo, e controle sobre motor, configuração e infraestrutura.

9.2 Amazon Bedrock vs. Amazon SageMaker: a linha oficial

9.3 Arquitetura de inferência streaming

O padrão que a AWS documenta em seus blogs de arquitetura:

---

10. Disponibilidade, manutenção e armadilhas de sunset

O exame de 2026 testa ativamente disponibilidade. Responder corretamente significa saber o que um aviso de manutenção significa e o que um sunset significa.

10.1 Instantâneo de disponibilidade (SageMaker, 2026)

A redação padrão de manutenção é: "Customers can't on-board… AWS will continue to operate and support these services… but won't enhance or add functionality." Clientes existentes mantêm o acesso; simplesmente não há novas features.

10.2 Mapa de features do SageMaker e status

📚 Você sabia? O Studio Lab, o ambiente JupyterLab 4 gratuito que exigia conta AWS e nenhum cartão de crédito, tinha limites publicados de apenas 12 GB de RAM e 15 GB de armazenamento, e agora está fechado para novos clientes com SageMaker Studio como substituição. É por isso que "use Studio Lab for free" é um distrator em material de 2026.

10.3 Atualizações de 2025 to 2026

Entre dezembro de 2024 e outubro de 2026, o ecossistema SageMaker foi renomeado, aparado e redirecionado várias vezes. Cada linha abaixo vem de um anúncio da AWS, de uma página de mudança de disponibilidade da AWS ou do histórico de mudanças de certificação da AWS: nada aqui é de terceiros, e datas que a própria AWS não publica são deliberadamente omitidas (veja a seção 13).

Dois fatos de vocabulário completam o quadro:

• Manutenção = sem novos clientes, sem novas features, ainda suportado · sunset = fim planejado de operações, tipicamente anunciado com cerca de um ano de antecedência · encerramento total = removido do portfólio da AWS. A referência de Ciclo de Vida de Serviços da AWS define todos os três, e cada linha acima está nos dois primeiros estados.
• Atualizações do guia de exame chegam ao teste cerca de um mês após a publicação, então qualquer coisa que a AWS publicou na v1.1 (30 abr 2026) já está em jogo: incluindo SageMaker JumpStart, Bedrock AgentCore, Kiro e Strands Agents na lista no escopo.

📚 Você sabia? A página de disponibilidade do Kendra não diz "deprecated": ela redireciona novas aplicações de busca para o Amazon Bedrock Managed Knowledge Base, cujo Smart Parsing e Agentic Retrieval API são documentados como a substituição do Kendra. "Kendra was shut down" é, portanto, um distrator: Kendra está em manutenção, o que sob o próprio vocabulário da AWS significa que continua rodando para clientes existentes.

---

11. Custo, free tier e os números que você pode memorizar com segurança

11.1 Free tier do SageMaker (a cada mês, nos primeiros 2 meses)

11.2 Padrão de custo trabalhado

O exemplo trabalhado da própria AWS totaliza $2,38: 2 horas de ml.m4.4xlarge a $0,96 cada mais 2 horas de ml.m5.xlarge a $0,23 cada, com regras built-in de Debugger cobradas a $0. Aprenda o padrão (horas-de-instância × tarifa + taxas de job), nunca a tarifa: preços ml.* são dependentes de região e data.

11.3 Cotas

Contagens de endpoints, cotas de pipeline, limites de jobs concorrentes e concorrência serverless vivem em Service Quotas. Nunca adivinhe uma cota numérica em uma resposta de exame ou revisão de design: procure-a.

---

12. Exemplos AWS trabalhados com números

Exemplo 1: escolha de opção por payload (seção 7.7). API de fraude: payloads de 3 KB, < 200 ms → tempo real (tetos 25 MB / 60 s). Mesmo modelo pontuando vídeos de 800 MB que levam 10 minutos → excede 25 MB mas cabe na assíncrona (≤ 1 GB, ≤ 60 min). Troque de opção; mantenha o scale-to-zero.

Exemplo 2: dimensionamento serverless (seção 7.4). Modelo de 3,5 GB → MemorySizeInMB=4096; MaxConcurrency=50 (faixa 1 to 200); ProvisionedConcurrency=10 (≤ 50) para pré-aquecer; imagem do contêiner ≤ 10 GB.

Exemplo 3: matemática de concorrência batch (seção 7.6). MaxPayloadInMB=25 → máximo MaxConcurrentTransforms=4 porque 4 × 25 = 100 ≤ 100 MB. Cinco workers violariam a regra documentada.

Exemplo 4: orçamento free tier. 250 horas de notebook ≈ 8,3 dias-de-instância; 50 horas de treinamento ≈ seis execuções de 8 horas; 125 horas tempo real ≈ 4,2 dias de hosting; 150.000 segundos serverless ≈ 41,7 horas cobráveis. Exceder 250 horas de notebook no mês 1 inicia cobrança medida.

Exemplo 5: frescor de atributos (seção 3.2). GetRecord online responde em single-digit milliseconds; o offline store mantém cada versão como Parquet no S3 (consultável com Athena) para joins point-in-time; um PutRecord de 14:00 chega ao S3 até 14:15 no máximo.

Exemplo 6: loop deriva → re-treinar (seção 8.2). Baseline Deequ dos dados de treinamento; monitoramento agendado de tráfego ao vivo; alerta automático de deriva de atribuição abaixo de NDCG 0,90; exemplo de viés usa DPPL ∈ (−0,1, 0,1) ao longo de 2 dias com intervalos de confiança bootstrap → CloudWatch → EventBridge → re-treinamento Pipelines.

Exemplo 7: teto de custo de treinamento (seção 5.1). Um training job com o padrão MaxRuntimeInSeconds para após 1 dia; o máximo rígido é 28 dias, e um job não pode exceder 30 dias no total. Ao parar, o SageMaker envia SIGTERM e espera 120 segundos para o seu código de checkpoint terminar.

---

13. Fatos conflitantes, não verificados e não examináveis

Bons candidatos a exame separam o que a AWS documenta do que a AWS anuncia. Mantenha esta lista fora do seu conjunto de memorização, exceto onde sinalizado.

Fontes primárias para esta lição: o Guia de Exame AIF-C01; páginas do guia de desenvolvedor do SageMaker deploy-model-options, hosting-faqs, serverless-endpoints, batch-transform, processing-job, pipelines-overview, define-pipeline, model-registry, clarify-configure-processing-jobs, model-monitor, feature-store*, model-cards, model-dashboard, data-wrangler, autopilot-automate-model-development, mlflow; a referência de API do SageMaker (API_StoppingCondition, API_feature_store_PutRecord); os decision guides bedrock-or-sagemaker.html e genai-guide.html; a página geral de serviços em manutenção; e a página de preços do SageMaker.

---

Casos Reais

A AWS publica estes casos em aws.amazon.com/solutions/case-studies/ e aws.amazon.com/blogs/machine-learning/. Eles pertencem a esta lição porque cada um mapeia um estágio do ciclo de vida para uma escolha de serviço com um número anexado: que é exatamente como as questões da Tarefa 1.3 são formuladas.

Caso 1, HAYAT HOLDING: o loop inteiro treinar → implantar → monitorar no chão de fábrica

Ambientes de ML construídos internamente eram "time-consuming and cumbersome" neste fabricante de painéis de MDF. O pipeline publicado: 194 sensores via OPC-UA → SiteWise Edge Gateway em AWS IoT Greengrass → SageMaker Model Training + Automatic Model Tuning + Model Deployment, com SageMaker Edge Manager executando o modelo no dispositivo. Resultado: $300.000 por ano economizados mais qualidade de painel superior. Lição do ciclo de vida: estágios 5 to 8 executam totalmente gerenciados, e o Automatic Model Tuning substitui um sweep manual de hiperparâmetros em 194 entradas. Fonte: aws.amazon.com/blogs/machine-learning/hayat-holding-uses-amazon-sagemaker-to-increase-product-quality-and-optimize-manufacturing-output-saving-300000-annually (2023).

Caso 2, Forethought: inferência DIY é um imposto oculto

Uma equipe de 3 pessoas suportando 30 milhões de interações por ano estava executando modelos e Kubernetes no seu próprio Amazon EKS, incluindo exceções de memória e interrupções. Eles migraram para multi-model endpoints do SageMaker e Serverless Inference: −66% de custo em multi-model endpoints (com latência melhor), ≈ −80% em serverless, e mais de 80% da inferência GPU agora roda no SageMaker. Lição do ciclo de vida: estágio 7, endpoints compartilhados e scale-to-zero superam um cluster auto-gerenciado que você tem de babar. Fonte: aws.amazon.com/solutions/case-studies/forethought-technologies-case-study.

Caso 3, RareJob: o gargalo era orquestração, não qualidade do modelo

Treinar em um PC local permitia um modelo por desenvolvedor; a tentativa EC2/ECS que se seguiu ainda custava caro demais. AWS Glue e Amazon Athena alimentam jobs paralelos de SageMaker Managed Spot Training. Resultado: −25% de tempo de treinamento, > 10× de eficiência de desenvolvedor, 100 horas por mês economizadas, e escores de teste de fala retornados em 2 to 3 minutos. Lição do ciclo de vida: estágios 1 to 3 (coletar → EDA → pré-processar) pertencem ao Glue e Athena; a fila, não o algoritmo, era a restrição. Fonte: aws.amazon.com/solutions/case-studies/rare-job-case-study (2020).

Caso 4, Chronomics: quando a construção interna falha, vá para AutoML

Quatro meses de modelagem customizada de computer vision interna nunca atingiram o alvo. Amazon Rekognition Custom Labels entrou em produção em 3 to 4 semanas com 96,5% de acurácia / 97,9% F1. Elevar o limiar de decisão para 0,99 produziu 99,6% de precisão mas descartou 5% das previsões; 0,999 deu 99,87% enquanto descartava 27%. Lição do ciclo de vida: estágio 6: avaliação é o que diz para parar de construir, e a cauda descartada precisa de um caminho de revisão humana. Fonte: aws.amazon.com/blogs/machine-learning/chronomics-detects-covid-19-test-results-with-amazon-rekognition-custom-labels (2022).

Caso 5, Sun Finance: separe OCR de raciocínio

A primeira tentativa enviou fotos de documento de identidade direto ao Claude Sonnet 4 e pontuou 61,8% no geral (43% nos números do documento): a AWS o rejeitou. O pipeline reconstruído: OCR Amazon Textract → fallback e mascaramento de rosto Amazon Rekognition → estruturação Claude Sonnet 4 → regras de validação, com Amazon Titan Multimodal Embeddings em S3 Vectors para similaridade de fraude, avaliado em 585 imagens. Resultado: acurácia 79,73% → 90,80%, custo por documento −91%, tempo de processamento 20 horas → menos de 5 segundos, detecção de fraude 81%. Lição do ciclo de vida: avaliação (estágio 6) matou o protótipo elegante, e o serviço pronto: não o modelo: é dono da extração. Fonte: aws.amazon.com/blogs/machine-learning/sun-finance-automates-id-extraction-and-fraud-detection-with-generative-ai-on-aws (2026).

Caso 6, Anthem: pronto primeiro, humanos na cauda

Extração manual de formulários de sinistro levava 20 minutos por sinistro. Um pipeline Amazon Textract (OCR mais indexação/classificação de ML atrás do portal de sinistros) automatizou 80% do fluxo de trabalho com meta de 90%+, em milhares de sinistros por dia. Lição do ciclo de vida: estágios 1 to 2: chame uma API gerenciada antes de treinar qualquer coisa custom, e projete o caminho de exceção humana para os 10 to 20% restantes. Fonte: aws.amazon.com/solutions/case-studies/anthem (2021).

Todos os seis casos em uma tabela

Cinco regras que recorrem em todos os seis casos:

1. Escolha a camada deliberadamente: serviço pronto (Anthem, Chronomics) → ML custom gerenciado (HAYAT, RareJob, Forethought) → IA generativa (Sun Finance). O exame recompensa a camada mais barata que funciona.
2. Baseline antes de construir: uma porcentagem sem um "antes" é marketing, não métrica.
3. Separe responsabilidades: OCR não é raciocínio (Sun Finance), e recuperação não é geração.
4. Avaliação é uma fase, não um checkbox: as primeiras tentativas do Sun Finance e do Chronomics falharam no estágio 6.
5. Mantenha um humano na cauda: os 5% descartados e os 10 to 20% não automatizados ainda precisam de alguém.

📚 Você sabia? A única taxa de produção que a AWS publica para o seu próprio Generative AI Innovation Center é 65% dos projetos chegando à produção em 2025, alguns em apenas 45 dias, de mais de 1.000 implementações, usando o framework Five V's da AWS: Value → Visualize → Validate → Verify → Venture. A AWS nunca afirmou que todos os pilotos dão certo, então qualquer opção dizendo "100%" está errada de cara.

---

14. Perguntas de Prática (Practice Questions)