Capítulo 0.9 — Estudo de caso fio condutor: Hermes Logística¶

🎯 Objetivo do capítulo¶

Apresentar um estudo de caso narrativo recorrente que vai aparecer em várias partes do livro como pequenas vinhetas. O caso serve para dar peso concreto às decisões - quando uma técnica é discutida em abstrato, é fácil concordar; quando aparece num contexto com restrições reais (multi-tenant, idioma, regulação, orçamento apertado), os trade-offs ficam visíveis.

⚠️ Não é exemplo executável. Nada aqui é código real; nenhuma empresa "Hermes Logística" precisa existir para o livro funcionar. O caso é didático e propositadamente verossímil. Quando os exemplos práticos em examples/ forem implementados, eles serão ligados a partes deste caso por afinidade conceitual - não por promessa de reprodução fiel. Hoje, a Hermes aparece exclusivamente como narrativa.

🏢 Cenário¶

A Hermes Logística é uma empresa B2B fictícia que opera plataforma de fretes e armazéns para varejistas e indústrias de médio porte. O time de operação recebe centenas de tickets por dia: rastreio, divergência de pedido, reembolso, cancelamento, integração com ERP do cliente, escalada para jurídico, etc. Há vários tenants (clientes finais), três idiomas operacionais e exigências regulatórias por região.

O time de IA da Hermes começa pequeno e cresce em ondas que vão aparecer ao longo do livro:

Onda	O que entra	Por quê
Onda 1 - Triagem clássica	Classificador ML tradicional de intent + roteamento	Cortar volume com algo barato e auditável
Onda 2 - Conhecimento via RAG	RAG por tenant para FAQ, contratos e SLA	Reduzir respostas inventadas, manter freshness
Onda 3 - Ações via agente	Agente com tools (CRM, billing, WMS) e HITL	Automatizar passos repetitivos com aprovação humana
Onda 4 - Endurecer	Policy-as-code, tenant isolation, threat modeling, audit	Passar em auditoria, suportar incidente real
Onda 5 - Operar	Observabilidade, evals contínuos, FinOps por tenant	Sustentar em produção, não só go-live
Onda 6 - Ciclo de vida	Versionamento, canary, depreciação de tool, breaking changes	Mudar sem virar incidente

A Hermes é deliberadamente "comum": não é big tech, não tem orçamento infinito, não roda em cluster próprio dedicado de GPUs. É o tipo de ambiente em que a maior parte das equipes vai operar.

🧭 Restrições principais do caso¶

Latência. Respostas em chat: p95 ≤ 8 s. Classificação inicial: p95 ≤ 200 ms. Operações no CRM via agente podem chegar a dezenas de segundos quando há aprovação humana.
Custo. Custo médio por ticket automatizado deve ficar abaixo do custo médio do atendente humano para a tarefa equivalente, com margem definida em ADR.
Privacidade. PII de clientes finais (CPF/CNPJ, e-mail, endereço, histórico de pedidos) não pode atravessar tenants nem sair do perímetro regional sem contrato.
Auditoria. Cada ação executada por agente precisa de trilha: quem propôs (modelo), quem autorizou (policy + humano quando aplicável), em qual versão de tool, contra qual recurso.
Operação. O time de operação é pequeno; runbooks, alertas e rollback precisam ser simples o suficiente para serem usados às 3h da manhã.

🧪 Como este caso é usado no livro¶

A Hermes reaparece em momentos como:

Parte 1 (ML tradicional). Classificador de intent, drift quando a Hermes entra em uma nova vertical, fairness por tenant.
Parte 2 (LLMs). RAG por tenant; quando o time tenta resolver "conhecimento" com fine-tuning e por que volta para RAG; embeddings e Matryoshka para controlar custo de retrieval.
Parte 3 (Agentic AI). Agente que cria/atualiza ticket; tool registry; uso de MCP para integrar com o ERP de um cliente grande; por que multi-agent é evitado.
Parte 4 (Segurança). Threat modeling com STRIDE adaptado; indirect prompt injection vindo de mensagens do cliente final; vector poisoning durante ingestão de manuais; tenant isolation no retriever.
Parte 5 (Observabilidade). Como um incidente ("agente abriu ticket no tenant errado") foi diagnosticado a partir de spans semânticos; eval regression antes de promover prompt.
Parte 6 (Custos). Por que a fatura dobrou em uma semana; uso de gateway, cache e roteamento por modelo; orçamento por tenant.
Parte 7 (Lifecycle). Depreciação da tool crm.update_contact@1.x com janela, dual-read em índice RAG, breaking change comunicada a consumidores internos.

🚧 O que o caso não é¶

Não é estudo de caso real. Qualquer semelhança com empresa específica é coincidência. Os números usados são ordens de grandeza plausíveis, não medições.
Não é implementação. Não há código associado neste estágio do livro. Quando exemplos em examples/ forem entregues, eles serão ligados a partes deste caso por afinidade.
Não é receita única. A Hermes mostra um caminho razoável; outros caminhos seriam igualmente defensáveis. O caso serve para tornar trade-offs concretos.

📌 Como acompanhar o caso¶

Trechos referentes à Hermes aparecem ao longo do livro como blocos explicitamente marcados:

🏢 Hermes Logística - onda X. (narrativa curta de decisão ou erro, ligada ao capítulo em curso).

Esses blocos são opcionais para a leitura por consulta. Em modo linear, eles funcionam como aterramento do que acabou de ser discutido.