Inteligência
Artificial.
Artificial
Intelligence.
IA na operação. Não no slide. RAG governado sobre dados que você já controla, agentes que executam runbook em vez de sugerir, modelos preditivos com SLO de drift, MLOps com o mesmo rigor do CI/CD da plataforma. Custo por chamada monitorado igual a infra. Eval contínuo. Fallback determinístico quando o modelo erra.
AI in operations. Not on slides. Governed RAG over data you already control, agents that execute runbooks instead of suggesting, predictive models with drift SLOs, MLOps with the same rigor as the platform CI/CD. Cost per call monitored like any infrastructure. Continuous eval. Deterministic fallback when the model misses.
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.
Default. Postgres que o cliente já opera, índice HNSW, hybrid search com tsvector. ACL via row-level security.
Quando o data warehouse já é Snowflake. Embedding e busca dentro do mesmo perímetro de governança — sem mover dado.
Para clientes em Lakehouse. Sync automático com Delta tables, Unity Catalog cuida da ACL.
Dense + sparse retrieval, BM25 + kNN, re-ranking nativo. Boa escolha quando já existe stack ELK.
Quando latência exige store dedicado e pgvector não dá conta. Filtros estruturados ricos, payload por documento.
Chunking semântico, re-rank, citação obrigatória.
- 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
asynciorezando. - 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.
O ciclo é o mesmo do app. Só muda o artefato.
Modelo é artefato. Prompt é código. Embedding é dado. Tudo isso entra num pipeline com versão, teste, deploy, rollback, monitoração — exatamente como qualquer outro componente. Notebook em produção é débito técnico esperando para virar incidente — a gente desfaz isso já no primeiro sprint.
- 01
Model registry & versioning
MLflow ou Weights & Biases. Cada modelo tem versão, métricas de eval, lineage de dado e artefato imutável. Promote de staging para prod é um diff revisável.
- 02
Serving com SLO
BentoML, Triton, vLLM. Latency p95, throughput, GPU utilization, custo por request. SLO declarado, error budget consumido, alerta no plantão.
- 03
Prompt como código
Prompt em arquivo versionado, com template parametrizado. Mudança de prompt passa por PR, eval, canário — não é setting de admin que qualquer um troca.
- 04
Observabilidade end-to-end
Langfuse, LangSmith, Helicone. Trace por chamada, custo, latência, retrieval hit, tokens. Custo de LLM sem observabilidade vira fatura surpresa.
- 05
Self-hosted quando faz sentido
vLLM com Llama/Qwen/Mistral em GPU própria. Quando volume + privacidade + custo justificam. Para 80% dos casos, API gerenciada é mais barata que GPU ociosa.
- 06
Pipeline de retrain
Trigger por drift, por calendário, por novo dado. Treino reproduzível, eval automático contra baseline, gate de promoção. Modelo desatualizado é dívida que cresce sozinha.
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.
Hype não vai pra produção.
- NÃO
Chatbot genérico no site institucional
Caso clássico de IA-tributária: alto risco, baixo ROI, nenhum dado proprietário. Se a pergunta é "qual seu horário", FAQ resolve. Se é técnica, encaminha para humano com contexto.
- NÃO
POC de IA sem dado limpo
"Vamos começar com IA enquanto a gente arruma os dados" é receita de POC eterno. A gente arruma o dado primeiro — ou na mesma onda.
- NÃO
Auto-GPT autônomo em sistema crítico
Agente sem human-in-the-loop tomando ação irreversível em produção é como deploy direto em sexta sem rollback. Não fazemos.
- NÃO
Modelo treinado do zero quando fine-tuning resolve
Fine-tuning sobre base aberta + RAG cobre 95% dos casos. Treino from scratch é meses de GPU para resultado pior. Se a gente não pode justificar com número, não faz.
Before the model, the use case. Before the case, the data.
Most AI projects fail for a banal reason: weak use case, dirty or missing data, or expecting magic. We start with a short, brutal discovery — what delivers measurable ROI, what has the data to sustain it, what can ship to production without becoming a headline. We leave with a prioritized list — not a chatbot POC.
- 01
Use case inventory
2-day workshop with business areas. Process map, operational bottleneck, cost of human error. Output: list prioritized by ROI × technical viability × regulatory risk.
- 02
Available data audit
A case is viable if the data exists, is accessible, is clean, and has clear ACL. Honest diagnosis: what needs to be fixed on the data platform first.
- 03
Build vs. buy vs. API
Does SaaS solve it? Does OpenAI/Anthropic with RAG solve it? Does a self-hosted open-source model make sense? Decision per case, not per the architect's ideological preference.
- 04
Regulatory risk upfront
Data privacy, retention, data residency, model-provider contract, auditability. A use case that bumps into compliance goes back in the queue — not into pilot.
- 05
Operational success definition
Business metric, human baseline, acceptable cost per call, quality SLO. Without this, the model never leaves POC.
- 06
Wave roadmap
Wave 1: low-risk, high-value case with data ready. Wave 2: what needs platform work. Wave 3: the ambitious one. Each wave only starts when the previous is in production for real.
Answer with citation. ACL respected. Source versioned.
RAG isn't "dump PDF in Pinecone and ask". It is a pipeline with several fallible layers — ingestion, chunking, embedding, retrieval, re-ranking, context, generation — and each one needs tests, metrics, and an owner. We build on what the client already governs: pgvector in their Postgres, embeddings in Snowflake/Databricks, or OpenSearch. No moving data to a vendor's vector DB.
Default. Postgres the client already operates, HNSW index, hybrid search with tsvector. ACL via row-level security.
When the warehouse is already Snowflake. Embedding and search inside the same governance perimeter — without moving data.
For Lakehouse clients. Automatic sync with Delta tables, Unity Catalog handles ACL.
Dense + sparse retrieval, BM25 + kNN, native re-ranking. Good choice when an ELK stack already exists.
When latency demands a dedicated store and pgvector doesn't cut it. Rich structured filters, per-document payload.
Semantic chunking, re-rank, mandatory citation.
- 01
Versioned ingestion
Every document has version, hash, date, and traceable source. Ingestion is a pipeline (Airflow/Dagster), not an ad-hoc script. When the document changes, the embedding regenerates — no answering from a stale base.
- 02
Structure-respecting chunking
Markdown and HTML by section, code by function, PDF by semantic block. A 512-token chunk splitting mid-paragraph is a recipe for a bad answer — we don't do it.
- 03
Hybrid retrieval + re-ranking
BM25 + dense embeddings fused with RRF. Cross-encoder re-ranker (bge-reranker, Cohere Rerank) in step 2. Recall isn't enough — precision@k is what counts.
- 04
ACL enforced at retrieval
The user only sees chunks of documents they would have rights to open. RLS in Postgres, tenant filters in the index. RAG leaking data across clients is a regulatory incident — not a bug.
- 05
Mandatory citation
Every answer cites a source, with a clickable link and a context snippet. An answer without citation is hallucination until proven otherwise — we block it at the prompt template.
- 06
Continuous retrieval eval
Golden set of questions + expected documents. NDCG, MRR, hit rate per question class. Each deploy runs against the golden set — if it degraded, it doesn't promote.
An agent that executes a runbook. The human approves what matters.
An agent that chats prettily has no operational value. Value is an agent that executes: read alert, identify cause, open runbook, run deterministic step, log postmortem. The model decides the path; the tool executes the step. Human approval lives in risky steps, not in all of them. Cost per execution is monitored like any infra.
- 01
LangGraph for deterministic flow
State graph with explicit transitions. The model picks the next node within a bounded DAG — it doesn't invent paths. Debuggable, testable, versionable.
- 02
Temporal for durability
Workflows that survive restarts, retry with backoff, timeout per step. An agent that needs to run for 4h or wait 2 days for human approval — uses Temporal, not
asyncioand hoping for the best. - 03
Tools with rigid schema
JSON schema for input and output of every tool. Server-side validation — does not trust the model. State-changing tools have dry-run, audit log, and idempotency key.
- 04
Calibrated human-in-the-loop
Low risk: the agent executes directly. Medium risk: asks for confirmation. High risk: blocks until SLA approval. Approving everything is as bad as approving nothing.
- 05
Typical cases in production
Alert triage → runbook. Log analysis with initial hypothesis. Fix-PR generation (human reviews). Support ticket triage with suggested reply. Accounting reconciliation with explanation.
- 06
Cost monitored per execution
Tokens per workflow, average cost per resolved case, comparison with human baseline. An agent that costs more than the human it replaced goes back for review.
Classic ML still solves it. No GPU, no hype.
The LLM wave took the spotlight off what still makes money: well-done tabular models. Disk failure predicted 14 days in advance. Cluster capacity planning. Transactional anomaly detection. Churn by segment. XGBoost on a laptop still beats a transformer with a bad prompt — and costs 1/1000 of the price.
- 01
Feature engineering with an owner
Feature store (Feast, Tecton) with lineage. Every feature has a code-based definition, owner, freshness SLA. Without that, training-serving skew silently becomes an incident.
- 02
Simple model first
Logistic regression as a baseline, XGBoost next, deep learning only if it pays off. Random forest in production is better than LSTM in a notebook.
- 03
Typical cases in DBs and cloud
SMART → disk failure. Query metrics → plan degradation. Table growth → ETA to exhaust storage. Anomaly in DB latency. Capacity prediction for autoscaling.
- 04
Canary deploy
New model serves 5% for 7 days with shadow scoring. Business metric compared to baseline. If it got worse — even silently — rollback. A/B without rigor is placebo.
- 05
Monitored drift
Feature distribution shift (PSI, KS), performance degradation, label drift. Alert integrated with the SRE on-call — not stuck on a dashboard nobody opens.
- 06
Explainability when the domain requires
SHAP, LIME, monotonic constraints. Credit, fraud, healthcare, anything with a decision affecting a person — explainability is not optional.
Same lifecycle as the app. Only the artifact changes.
A model is an artifact. A prompt is code. An embedding is data. All of it enters a pipeline with version, test, deploy, rollback, monitoring — exactly like any other component. A notebook in production is technical debt waiting to become an incident — we undo that in the first sprint.
- 01
Model registry & versioning
MLflow or Weights & Biases. Every model has a version, eval metrics, data lineage, and immutable artifact. Promotion from staging to prod is a reviewable diff.
- 02
Serving with SLO
BentoML, Triton, vLLM. p95 latency, throughput, GPU utilization, cost per request. Declared SLO, consumed error budget, alert on the on-call.
- 03
Prompt as code
Prompt in a versioned file, with a parameterized template. A prompt change goes through PR, eval, canary — not an admin setting anyone can toggle.
- 04
End-to-end observability
Langfuse, LangSmith, Helicone. Trace per call, cost, latency, retrieval hit, tokens. LLM cost without observability becomes a surprise invoice.
- 05
Self-hosted when it makes sense
vLLM with Llama/Qwen/Mistral on owned GPU. When volume + privacy + cost justify it. For 80% of cases, a managed API is cheaper than idle GPU.
- 06
Retrain pipeline
Trigger by drift, by calendar, by new data. Reproducible training, automatic eval against baseline, promotion gate. An outdated model is debt that grows on its own.
Without a golden set, it's vibe-driven development.
The right question for any GenAI feature is: how do you know it got better? Without an eval framework, any change to prompt, model, or retrieval is a bet. We deliver AI features with a test battery — golden set, regression suite, LLM-as-judge calibrated against human annotation, production metrics monitored in real time.
- 01
Golden set built with the domain
50–200 representative cases, annotated by the client's specialist. Covers happy path, edge cases, jailbreak attempts, ambiguity. Without it, eval has no footing.
- 02
Metrics per category
Faithfulness (answer fits the source), answer relevance, context precision, context recall — Ragas. For flows: success rate, steps to resolution, average cost.
- 03
Calibrated LLM-as-judge
A larger model evaluates the production model's output. Calibrated against 50 cases with human scores — 0.7+ agreement or it isn't used. Without calibration, it is a bought judge.
- 04
Regression suite in CI
Every PR runs a fast subset (~5 min), nightly runs the full suite. Degraded any metric blocks merge — like unit tests.
- 05
Continuous red-team
Prompt injection, known jailbreaks, PII leakage, toxic generation. Suite that runs weekly, with new cases from the wild (lakera, garak, our own).
- 06
Closed-loop production feedback
Thumbs up/down, user comments, retry rate. All of it goes back into the golden set as a new case. An eval that doesn't evolve with the product dies in 3 months.
Audit-ready. Not a last-minute topic.
AI in a regulated company isn't a technical problem — it is technical and legal and risk. We deliver the technical side in a form legal can sign off on: reviewed provider contract, data residency, retention, opt-out, audit trail, PII redaction, on-prem model when the case calls for it.
- 01
Reviewed provider contract
Bedrock, Azure OpenAI, Vertex — all with "won't train on your data" clauses, configurable retention, residency per region. OpenAI direct without zero-retention is a no for a regulated client.
- 02
PII redaction before the model
Detection and masking of national IDs, cards, e-mails, health data before the prompt leaves to the provider. Reversible only inside the client's perimeter.
- 03
Full audit trail
Every call: user, prompt, retrieved context, response, cost, latency, model. Retention configured per policy — not per vendor default.
- 04
On-prem when needed
vLLM with Llama 3.1, Qwen, Mistral on the client's GPU or in an isolated VPC. For healthcare, restricted finance, defense data. Costs more; that is the price of compliance.
- 05
Output guardrails
Schema validation, blocked-topic detection, toxic-output detection, per-user rate limit. Guardrails AI, NeMo Guardrails, our own.
- 06
Policy and training
Internal policy on AI usage (what's allowed, what isn't, in which tool). Training for the team. Shadow AI is the most common leakage vector — clear policy reduces it.
Hype doesn't go to production.
- NO
Generic chatbot on a corporate site
Classic AI-tax case: high risk, low ROI, no proprietary data. If the question is "what are your hours", a FAQ solves it. If it's technical, route to a human with context.
- NO
AI POC without clean data
"Let's start with AI while we tidy the data" is a recipe for an eternal POC. We tidy the data first — or in the same wave.
- NO
Autonomous Auto-GPT in a critical system
An agent without human-in-the-loop taking irreversible action in production is like deploying directly on a Friday without rollback. We don't do it.
- NO
Training a model from scratch when fine-tuning works
Fine-tuning over an open base + RAG covers 95% of cases. From-scratch training is months of GPU for a worse result. If we can't justify it with numbers, we don't do it.
POC parado, modelo no notebook, ou diretoria pedindo "uma estratégia de IA"? Conta o problema.
45 min com engenheiro de IA sênior. Sem pitch.
POC stuck, model in a notebook, or leadership asking for "an AI strategy"? Tell us the problem.
45 min with a senior AI engineer. No pitch.