Inteligência
Artificial.

Antes do modelo, o caso de uso. Antes do caso, o dado.

A maior parte dos projetos de IA falha por motivo banal: caso de uso fraco, dado sujo ou ausente, ou expectativa de mágica. A gente começa com discovery curto e brutal — o que dá ROI mensurável, o que tem dado para sustentar, o que pode ir para produção sem virar manchete. Saímos com lista priorizada — não com um POC de chatbot.

• 01

  Inventário de casos de uso

  Workshop de 2 dias com áreas de negócio. Mapa de processos, gargalo operacional, custo de erro humano. Saída: lista priorizada por ROI × viabilidade técnica × risco regulatório.

• 02

  Auditoria de dados disponíveis

  O caso é viável se o dado existe, é acessível, está limpo e tem ACL clara. Diagnóstico honesto: o que precisa ser corrigido na plataforma de dados antes.

• 03

  Build vs. buy vs. API

  SaaS resolve? OpenAI/Anthropic com RAG resolve? Modelo open-source self-hosted faz sentido? Decisão por caso, não por preferência ideológica do arquiteto.

• 04

  Risco regulatório upfront

  LGPD, retenção, residência de dado, contrato com provider de modelo, auditabilidade. Caso de uso que esbarra em compliance volta para a fila — não para piloto.

• 05

  Definição de sucesso operacional

  Métrica de negócio, baseline humano, custo por chamada aceitável, SLO de qualidade. Sem isso, o modelo nunca sai do POC.

• 06

  Roadmap em ondas

  Onda 1: caso de baixo risco, alto valor, dado pronto. Onda 2: o que precisa de plataforma. Onda 3: o ambicioso. Cada onda só começa quando a anterior está em produção de verdade.

Resposta com citação. ACL respeitada. Fonte versionada.

RAG não é "joga PDF no Pinecone e pergunta". É um pipeline com várias camadas falíveis — ingestão, chunking, embedding, retrieval, re-ranking, contexto, geração — e cada uma precisa de teste, métrica e dono. A gente constrói sobre o que o cliente já governa: pgvector no Postgres dele, embeddings em Snowflake/Databricks, ou OpenSearch. Sem migrar dado para vector DB de fornecedor.

• 01

  Ingestão versionada

  Cada documento tem versão, hash, data e fonte rastreável. Ingestão é pipeline (Airflow/Dagster), não script ad-hoc. Quando o documento muda, o embedding regenera — sem ficar respondendo com base obsoleta.

• 02

  Chunking que respeita estrutura

  Markdown e HTML por seção, código por função, PDF por bloco semântico. Chunk de 512 tokens partindo no meio do parágrafo é receita de resposta ruim — a gente não faz.

• 03

  Hybrid retrieval + re-ranking

  BM25 + dense embeddings, fundidos com RRF. Cross-encoder re-ranker (bge-reranker, Cohere Rerank) na 2ª etapa. Recall não é o suficiente — precision@k é o que conta.

• 04

  ACL respeitada no retrieval

  O usuário só vê chunk de documento que ele teria direito de abrir. RLS no Postgres, filtros por tenant no índice. RAG vazando dado entre clientes é incidente regulatório — não bug.

• 05

  Citação obrigatória

  Toda resposta cita fonte, com link clicável e trecho do contexto. Resposta sem citação é hallucination até prova em contrário — a gente bloqueia no prompt template.

• 06

  Eval contínuo do retrieval

  Golden set de perguntas + documentos esperados. NDCG, MRR, hit rate por classe de pergunta. Cada deploy roda contra o golden set — degradou, não promove.

Agente que executa runbook. Humano aprova o que importa.

Agente que conversa bonito não tem valor para operação. Valor é agente que executa: ler alerta, identificar causa, abrir runbook, executar passo determinístico, registrar postmortem. O modelo decide o caminho; a ferramenta executa o passo. Aprovação humana fica em steps de risco, não em todos. Custo por execução é monitorado igual qualquer infra.

• 01

  LangGraph para fluxo determinístico

  Grafo de estado com transições explícitas. O modelo escolhe o próximo nó dentro de um DAG limitado — não inventa caminho. Debugável, testável, versionável.

• 02

  Temporal para durabilidade

  Workflow que sobrevive a restart, retry com backoff, timeout por step. Agente que precisa rodar 4h ou esperar aprovação humana de 2 dias — usa Temporal, não asyncio rezando.

• 03

  Tools com schema rígido

  JSON schema para entrada e saída de cada tool. Validação no servidor — não confia no modelo. Tool que altera estado tem dry-run, audit log e idempotency key.

• 04

  Human-in-the-loop calibrado

  Risco baixo: agente executa direto. Risco médio: pede confirmação. Risco alto: bloqueia até aprovação com SLA. Aprovar tudo é tão ruim quanto aprovar nada.

• 05

  Casos típicos em produção

  Triagem de alerta → runbook. Análise de log com hipótese inicial. Geração de PR de correção (humano revisa). Triagem de ticket de suporte com sugestão de resposta. Reconciliação contábil com explicação.

• 06

  Custo monitorado por execução

  Tokens por workflow, custo médio por caso resolvido, comparação com baseline humano. Agente que custa mais que o humano que ele substituiu volta para revisão.

ML clássico ainda resolve. Sem GPU, sem hype.

A onda LLM tirou holofote do que continua dando dinheiro: modelo tabular bem feito. Falha de disco predita 14 dias antes. Capacity planning de cluster. Detecção de anomalia transacional. Churn por segmento. XGBoost num laptop ainda bate transformer com prompt mal feito — e custa 1/1000.

• 01

  Feature engineering com dono

  Feature store (Feast, Tecton) com lineage. Cada feature tem definição em código, dono, SLA de freshness. Sem isso, training-serving skew vira incidente em silêncio.

• 02

  Modelo simples primeiro

  Logistic regression de baseline, XGBoost na sequência, deep learning só se justificar. Random forest em produção é melhor que LSTM em notebook.

• 03

  Casos típicos em DBs e cloud

  SMART → falha de disco. Métricas de query → degradação de plano. Crescimento de tabela → ETA para esgotar storage. Anomalia em latência de DB. Predição de capacity para autoscaling.

• 04

  Deploy com canário

  Modelo novo serve 5% por 7 dias com shadow scoring. Métrica de negócio comparada com baseline. Se piorou — mesmo silenciosamente — rollback. A/B sem rigor é placebo.

• 05

  Drift monitorado

  Distribution shift de features (PSI, KS), performance degradation, label drift. Alerta integrado ao plantão de SRE — não fica num dashboard que ninguém abre.

• 06

  Explainability quando o domínio exige

  SHAP, LIME, monotonic constraints. Crédito, fraude, healthcare, qualquer caso com decisão que afeta pessoa — explainability não é opcional.

Sem golden set, é vibe-driven development.

A pergunta certa para qualquer feature de GenAI é: como você sabe que ela ficou melhor? Sem framework de eval, qualquer mudança de prompt, modelo ou retrieval é aposta. A gente entrega feature de IA com bateria de teste — golden set, regression suite, LLM-as-judge calibrado contra anotação humana, métricas de produção monitoradas em tempo real.

• 01

  Golden set construído com domínio

  50–200 casos representativos, anotados por especialista do cliente. Cobre caminho feliz, edge cases, tentativa de jailbreak, ambiguidade. Sem isso, eval não tem pé.

• 02

  Métricas por categoria

  Faithfulness (resposta cabe na fonte), answer relevance, context precision, context recall — Ragas. Para fluxos: success rate, steps to resolution, custo médio.

• 03

  LLM-as-judge calibrado

  Modelo grande avalia saída do modelo de produção. Calibrado contra 50 casos com nota humana — concordância de 0.7+ ou não usa. Sem calibração, é juiz comprado.

• 04

  Regression suite no CI

  Cada PR roda subset rápido (~5 min), nightly roda full. Degradou em qualquer métrica bloqueia merge — igual teste de unidade.

• 05

  Red-team contínuo

  Prompt injection, jailbreak conhecido, PII leakage, geração tóxica. Suite que roda toda semana, com casos novos do mundo (lakera, garak, próprios).

• 06

  Feedback de produção fechado

  Thumbs up/down, comentário do usuário, retry rate. Tudo volta para o golden set como caso novo. Eval que não evolui com o produto morre em 3 meses.

Auditoria pronta. Não é assunto de última hora.

IA em empresa regulada não é problema técnico — é técnico e jurídico e de risco. A gente entrega o lado técnico de forma que o jurídico possa assinar embaixo: contrato com provider revisado, residência de dado, retenção, opt-out, audit trail, PII redaction, modelo on-prem quando o caso pede.

• 01

  Contrato com provider revisado

  Bedrock, Azure OpenAI, Vertex — todos têm cláusula de "não treina no seu dado", retenção configurável, residência por região. OpenAI direto sem zero-retention é não para cliente regulado.

• 02

  PII redaction antes do modelo

  Detecção e mascaramento de CPF, cartão, e-mail, dado de saúde antes do prompt sair para o provider. Reversível só dentro do perímetro do cliente.

• 03

  Audit trail completo

  Cada chamada: usuário, prompt, contexto recuperado, resposta, custo, latência, modelo. Retenção configurada conforme política — não conforme padrão do fornecedor.

• 04

  On-prem quando precisa

  vLLM com Llama 3.1, Qwen, Mistral em GPU do cliente ou em VPC isolada. Para healthcare, financeiro restrito, dado de defesa. Custa mais; é o preço do compliance.

• 05

  Guardrails de saída

  Validação de schema, bloqueio de tópico proibido, detecção de saída tóxica, rate-limit por usuário. Guardrails AI, NeMo Guardrails, próprios.

• 06

  Política e treinamento

  Política interna de uso de IA (o que pode, o que não pode, em qual ferramenta). Treinamento para o time. Shadow IT de IA é o vetor mais comum de vazamento — política clara reduz.