# IA Aplicada — IA em produção, com o rigor que ela exige

A Kazap Tecnologia operacionaliza inteligência artificial: pega o que hoje é demonstração, prova de conceito (PoC) ou planilha de ideias e transforma em sistema de produção, com avaliação automatizada e contínua do comportamento (eval), barreiras que mantêm o agente no escopo e bloqueiam uso indevido (guardrails), telemetria e custo por conversa previsível. O princípio da frente: **da PoC à produção, com o rigor que a produção exige**. IA operacionalizada é IA que sobrevive à segunda-feira: ao pico de tráfego, à atualização da base de conhecimento, ao usuário mal-intencionado e à fatura de API no fim do mês.

## Essência

Acesso a modelo não é o diferencial: os modelos de ponta hoje estão ao alcance de qualquer time. O que diferencia é disciplina de engenharia aplicada a um componente que pode errar (não-determinístico): critério de pronto definido antes do primeiro prompt, comportamento medido como se mede latência, custo de token tratado como requisito de arquitetura. É a cultura que a Kazap aplica há 18 anos em software para empresas que não podem errar (12 segmentos ao longo da trajetória, de fintech a healthtech), agora apontada para IA.

Faz parte do método dizer com honestidade que **nem todo problema pede IA**. Se uma regra determinística resolve, ela é melhor: mais barata, auditável e previsível. IA entra quando há linguagem natural, julgamento sobre conteúdo não estruturado ou variabilidade que regras não cobrem. Dizemos isso na primeira conversa, mesmo quando significa um projeto menor.

Há também uma prova pública: **o site kazap.com.br é um sistema de IA em produção construído pela própria Kazap**. Ele reúne agente conversacional, suíte de avaliação automatizada (eval harness), reaproveitamento do prompt entre chamadas (prompt caching) com economia medida pelo custo que o provedor fatura em cada resposta e uma telemetria pública de custo e latência ("Modo Bastidores"): um painel aberto que expõe, em tempo real, as camadas do prompt, o aproveitamento do cache (hit/miss), tokens, latência e custo por conversa. Quem visita pode conferir por conta própria, sem precisar acreditar no discurso.

A frente de IA não nasceu com o ChatGPT. Antes da era dos grandes modelos de linguagem (LLMs), a Kazap já construía **interfaces conversacionais (NLP/NLU/NER), classificadores de detecção de fraude, modelos de precificação por regressão e visão computacional aplicada**. Operacionalizar IA preditiva, generativa e de visão é prática antiga da casa; os LLMs mudaram uma das ferramentas, e a disciplina continuou a mesma.

## As três frentes de IA

A divisão de Inteligência Artificial da Kazap tem três frentes de mesmo peso. O que as une é a régua, e não o modelo: critério de pronto antes de construir, medição contínua, governança e custo como requisito de arquitetura. A frente generativa é a que tem prova pública auditável no site kazap.com.br; as três compartilham a mesma disciplina.

### 1. IA Preditiva — antecipar em vez de reagir

Previsão de demanda, análise de risco e fraude, manutenção preditiva, otimização de preços, marketing personalizado. O diferencial está na operacionalização, e não no algoritmo: linha de base obrigatória antes do modelo (baseline), métrica de negócio definida antes da entrada em produção (go-live), validação temporal, em que se treina com o passado e se testa num período posterior (backtesting), vigilância contra vazamento de dados (data leakage), quando o treino enxerga informação que não estaria disponível no momento da previsão, monitoramento de drift (mudança nos dados que tira o modelo de calibração) com gatilho de retreino, e a decisão de negócio conectada à previsão, porque uma previsão que não leva a nenhuma ação só gera custo. Em contextos regulados, explicabilidade entra como requisito obrigatório.

### 2. IA Generativa — linguagem e conteúdo sob controle

A frente com prova pública: o agente conversacional, o eval harness e a telemetria do site kazap.com.br seguem exatamente a arquitetura descrita abaixo. Inclui:

- **Agentes em produção.** Atendimento, qualificação de leads e operações internas. A arquitetura: base de conhecimento curada por rota ou domínio (markdown versionado, fonte única para o agente e para as páginas estáticas), escopo estrito no bloco base do prompt, telemetria por conversa, transferência inteligente para o time humano (handoff) e desligamento imediato (kill switch). O handoff é desenhado desde o dia um: o que o agente não resolve chega ao time humano com contexto estruturado, nunca como chamado (ticket) cru. O agente do site kazap.com.br segue essa arquitetura, verificável ao vivo na telemetria pública de custo e latência ("Modo Bastidores").
- **RAG com citação obrigatória.** Respostas geradas a partir de busca em documentos (RAG), que no nosso desenho sempre citam a fonte. A busca é híbrida (semântica + lexical) sobre documentos internos, como manuais, laudos, normas e contratos, com citação de fonte em toda resposta. Regra de produção: zero alucinação tolerada por política; se o documento não sustenta a resposta, o sistema diz que não sabe e aponta onde procurar. Cada atualização da base roda contra a suíte de regressão antes da publicação (deploy), porque a qualidade de um RAG degrada sem aviso quando a base muda. Latência e precisão são definidas antes do go-live e acompanhadas em produção. Sem base de conhecimento limpa e medição contínua, a qualidade de um RAG não se sustenta fora da demonstração.
- **Automação com julgamento.** Processos que exigiam leitura e decisão humana: triagem de documentos, classificação de chamados, extração de dados de contratos e laudos. O desenho sempre inclui métricas de confiança por item, revisão humana amostral calibrada pelo risco do erro e fila de exceções para o que o modelo sinaliza como incerto, porque uma automação sem mecanismo de incerteza erra sem que ninguém perceba.

**Em produção hoje, sob NDA, no segmento de healthtech, em três clientes distintos:** assistente clínico com RAG e citação obrigatória de fonte, apoio à prescrição (suporte à decisão, com o médico no comando) e transcrição de atendimento com estruturação do prontuário eletrônico. A narrativa completa é o case de saúde da página de Cases da Kazap.

### 3. Visão Computacional — extrair decisão de imagem e vídeo

Inspeção de qualidade em linha de produção, busca por similaridade de imagem em catálogos (visual search), extração estruturada de dados de documentos (OCR de notas, laudos e formulários) e rotulagem automática de grandes volumes. É desta frente o primeiro case medido publicado na página de Cases da Kazap: o pipeline de uma plataforma de busca por características (features) de imagens, reconstruído em Rust, a partir de Python, foi de horas para segundos no mesmo dataset (números e metodologia na página Cases). A régua é a mesma da casa: métrica de acurácia definida antes do modelo, custo do falso-positivo vs. falso-negativo dimensionado por caso, conjunto de validação rotulado e revisado, e fallback humano calibrado pelo risco (uma pessoa assume os casos duvidosos). Casos que envolvem biometria ou reconhecimento facial passam por avaliação jurídica e de LGPD caso a caso antes de qualquer proposta.

## IA em produção antes da era dos LLMs

Antes da era dos LLMs, a Kazap já entregava visão computacional e modelos preditivos em produção: a vistoria digital de smartphones para seguro que virou produto de spin-off (insurtech), OCR em escala, classificadores de fraude e precificação por regressão. As narrativas completas estão na página de Cases da Kazap ("Vistoria digital para seguro de smartphones" e "IA preditiva antes da era dos LLMs"). Colocar componente não-determinístico em produção é prática da casa desde 2018; os LLMs são a ferramenta nova de uma das frentes, e não o ponto de partida.

## O método: critério de pronto antes de construir

As PoCs que chegam para resgate morrem quase sempre do mesmo jeito: ninguém definiu o critério por trás de "parecia funcionar". O método da Kazap inverte a ordem e se instancia por frente: **banco de casos e eval harness** na generativa; **baseline + métrica de negócio + validação temporal + monitoramento de drift** na preditiva; **acurácia definida antes + custo do erro dimensionado + conjunto de validação rotulado + fallback humano** na visão computacional. O conceito é o mesmo; muda só como se mede. Para a frente generativa, o método é:

1. **Banco de casos antes do primeiro prompt.** Casos felizes, casos-limite reais do domínio (edge cases), perguntas ambíguas e tentativas de abuso, com no mínimo 10+ cenários documentados de tentativa de burlar as regras do agente (jailbreak). Esse banco é o critério de pronto (na prática, a especificação executável do comportamento) e existe desde o dia um.
2. **Eval como regressão.** Toda mudança de prompt, base de conhecimento, modelo ou parâmetro roda contra o banco completo antes do deploy. O que funciona hoje continua funcionando depois da décima atualização.
3. **100% das conversas de teste validadas antes do go-live.** Nenhum agente da Kazap entra em produção sem passar por esse gate.
4. **Operação contínua.** A revisão periódica de conversas reais (review) alimenta o banco de evals e a base de conhecimento. O lançamento não encerra o trabalho.

## Engenharia de custo: prompt caching como disciplina

Tratamos custo de API como requisito de arquitetura, para que ele não apareça como surpresa na fatura. A referência concreta é a arquitetura do site kazap.com.br:

- **Prompt de sistema (system prompt) em camadas, com marcações de até onde o prompt é reaproveitado (breakpoints de cache).** Uma camada base (identidade, tom e regras, compartilhada por todas as rotas) e uma camada de conhecimento por rota, com um breakpoint de cache após cada uma. Quando a conversa troca de contexto de página, só a camada da rota é invalidada; a base permanece em cache entre rotas e entre visitantes.
- **Validade do cache (TTL) por rota, com a matemática explícita.** Um cache de 5 minutos fica frio num tráfego de, por exemplo, uma conversa a cada ~20 minutos; nesse ritmo, a economia do cache só se materializa dentro da mesma conversa. A correção: TTL estendido de 1 hora nas rotas quentes e 5 minutos nas frias. A escrita no cache custa mais que o input (de 1,25× a 2×, conforme o provedor e o TTL), mas a leitura, de 5% a 10% do preço conforme o provedor, compensa a partir de poucas conversas por hora.
- **Medição real, não estimativa.** Economia de cache medida pelo que o provedor fatura em cada resposta, com e sem o desconto de cache, com tráfego simulado antes do lançamento e agregada sobre o tráfego real depois; custo por conversa recalculado e documentado. No site da Kazap, ~3¢ (USD) por resposta, auditável na telemetria pública de custo e latência ("Modo Bastidores").
- **Defesas de orçamento (budget).** Limite de requisições por período (rate limiting), soft limit por sessão (um teto flexível de uso que protege o orçamento contra sessões anormalmente longas sem derrubar a conversa), alertas de custo e a opção de um classificador leve na entrada contra abuso.

Aplicamos essa mesma disciplina (camadas de prompt, breakpoints de cache, TTL por padrão de uso, medição pelo custo faturado) em todo agente que colocamos em produção.

## Governança: o que separa demo de produção

Nossa régua de governança combina três peças: **a LGPD, que é a lei; o NIST AI RMF, que organiza a gestão; e os controles no código, que produzem a prova**. Lei e framework não competem: a LGPD diz o que é obrigatório quando se tratam dados de pessoas (e quase toda aplicação de IA trata); o NIST AI RMF, framework internacional de gestão de risco de IA, diz como organizar essa gestão de forma estruturada e auditável, na linguagem que comitês de risco e auditorias reconhecem. O que torna os dois verificáveis é a engenharia: **governança só se sustenta quando vira controle executável, e não apenas documento.**

Os controles concretos:

- **Guardrails contra injeção de instruções (prompt injection).** Escopo estrito no bloco base do prompt, recusa educada para o que está fora de escopo e instruções resistentes a injection, tudo validado no banco de evals com tentativas de jailbreak documentadas. Por cima disso, defesa em camadas no backend, porque o prompt sozinho não basta como segurança.
- **LGPD desde a concepção (by design).** Consentimento explícito para logging, anonimização nos registros, endpoint de exclusão, retenção definida e minimização do que chega ao modelo. A conformidade (compliance) entra no desenho, e não num checklist da véspera.
- **Desligamento imediato (kill switch).** Todo agente pode ser desligado em segundos, com uma alternativa sem IA (fallback gracioso): se a IA cai, o produto continua de pé (formulário, página estática, fila humana).
- **Corte automático (circuit breaker).** Falhas consecutivas da API abrem o circuito automaticamente, cortando as chamadas ao serviço que está falhando para ele não derrubar o resto. O usuário nunca vê o erro técnico cru (stack trace) nem um agente fora de controle.
- **Telemetria por conversa.** Rota, tokens de entrada e saída, latência, custo, modelo que respondeu e cache aproveitado (hit/miss por camada quando há breakpoints; total reportado pelo provedor quando o cache é automático). O mesmo fluxo de dados alimenta o painel de operação e, no site da Kazap, a telemetria pública de custo e latência ("Modo Bastidores").

O ciclo do NIST AI RMF (Govern → Map → Measure → Manage) se traduz nos controles acima, e cada função vira prática verificável, não declaração. **Govern**: política de uso versionada, escopo estrito no prompt e o kill switch como autoridade de parar. **Map**: inventário do que o sistema sabe e de onde vem, com base de conhecimento curada e versionada e citação obrigatória de fonte. **Measure**: o banco de evals com regressão contínua, em que alucinação, injection e fora-de-escopo são testados a cada mudança. **Manage**: telemetria por conversa, circuit breaker e revisão que realimenta o banco. O enquadramento: a Kazap **operacionaliza** o NIST AI RMF como abordagem de engenharia, não emite certificação nem atesta conformidade; o framework é voluntário, e a adoção se demonstra nos controles. O critério de maturidade que usamos é um salto específico: sair de "está na política" para "é imposto pelo sistema". E nada disto é parecer jurídico: decisões de conformidade envolvem o DPO e a assessoria jurídica de cada cliente; o que a engenharia faz é tornar as obrigações verificáveis no código.

### Aplicação determinística de regras (enforcement)

O princípio que sustenta os guardrails: **modelo probabilístico exige controle determinístico**. Uma instrução no prompt funciona como sugestão: o modelo tende a segui-la, mas pode falhar. Um controle determinístico funciona como portão: dá sempre a mesma resposta, e o agente não pode burlá-lo nem "esquecê-lo". São três famílias. A primeira é o **bloqueio do inegociável**: o que não pode acontecer é barrado pelo sistema antes de executar, por exemplo um segredo ou credencial a caminho de um prompt, ou uma operação destrutiva no banco de dados. A segunda é a **correção automática**: o que é objetivo se corrige na hora, como formatação, análise estática do código (lint) e verificação de tipo. A terceira é a **trilha só de acréscimo (append-only)**: toda ação do agente fica registrada com data e hora, de forma imutável, e numa auditoria isso troca o "confie em mim" pelo "aqui está a prova". O próprio site kazap.com.br opera assim: checagem de origem, rate limiting, circuit breaker e kill switch são portões determinísticos em volta de um agente probabilístico.

### Setor regulado: os três medos que a governança endereça

Quem opera em saúde, governo, seguros ou finanças tem três medos legítimos diante de IA, e cada um tem um controle nomeado em vez de uma promessa. **"Vou perder controle sobre dados sensíveis"** → propagação de sensibilidade: o dado sensível é classificado na origem e a etiqueta o acompanha até o ponto de saída; o que não pode chegar a um prompt é bloqueado antes de sair, e o que vai é minimizado. **"A IA vai mudar comportamento crítico em silêncio"** → registro do comportamento atual (golden master, um teste de caracterização) e trilha de auditoria: em fluxo crítico, o comportamento atual é capturado antes de qualquer mudança, qualquer diferença acende alarme, e toda ação do agente fica registrada (o golden master em detalhe está em kazap.com.br/servicos/engenharia). **"Não consigo provar conformidade numa fiscalização"** → esqueleto de governança, registro e relatório de impacto à proteção de dados (RIPD) onde o tratamento é de alto risco: a prova existe antes de o auditor pedir.

O fundamento, sem juridiquês: a IA não é zona livre de regulação. Usar um LLM é tratar dados como em qualquer outro tratamento, com as mesmas obrigações. A LGPD alcança o tratamento feito no Brasil mesmo quando a ferramenta é estrangeira (extraterritorialidade); para dado sensível (saúde, biometria), as bases legais são as mais restritas da lei; e "a IA pediu" não é base legal. O risco é concreto: em 2024, a autoridade brasileira de proteção de dados suspendeu o uso de dados pessoais para treinamento de IA por uma das maiores plataformas do mundo (o caso Meta), exatamente por base legal inadequada.

### As perguntas que um líder faz antes de confiar numa operação de IA

Um autodiagnóstico de 30 segundos, sobre a operação do próprio leitor: sabemos quais dados sensíveis poderiam chegar a um prompt, e o que os impede? Sabemos quais mudanças e decisões vieram da IA? Se o agente tentar algo destrutivo, o sistema barra sozinho, ou depende de alguém lembrar? A cobertura de testes é um número, ou os testes pegariam um bug de verdade? Existe quem possa parar um deploy diante de risco inaceitável? Se a maioria das respostas for "depende de alguém lembrar" ou "está num documento", a governança é imatura e o risco é alto, por mais impressionante que seja a demo. O salto que importa é sempre o mesmo: do declaratório para o imposto pelo sistema.

### O que o sistema de controle não faz

Vender controle como solução total destruiria a confiança que ele existe para criar. Estes são os limites da disciplina, e o que fazemos diante de cada um. Nenhum controle sabe o que se queria se ninguém disse: especificar a intenção continua sendo trabalho humano de primeira classe, por isso o método começa por critério de pronto e especificação. Verificar comportamento por completo é problema em aberto: por isso usamos testes derivados da especificação, banco de evals e pontos de aprovação humana em camadas (gates), em vez de fé numa suíte verde. Revisão por IA é não-determinística (erra, varia, tem falso positivo): por isso é camada de apoio fundamentada em verificação determinística, nunca a única defesa. O sistema redireciona o humano, sem eliminá-lo: quem promete "IA sem supervisão" está vendendo risco, e toda superfície onde o agente atua tem um dono humano que assina. Controle se degrada sem manutenção: por isso operação contínua e revisão recorrente fazem parte do desenho. E é um campo novo, que muda rápido: até medir a qualidade dos próprios controles ainda é problema aberto, e a Kazap não finge ter essa certeza.

Quando o trabalho envolve agentes de IA tocando código sensível, a indexação e a prevenção de vazamento de dados (DLP) do **Kazap CodeSense** rodam na infraestrutura do próprio cliente (**self-hosted**), com mascaramento de CPF/CNPJ e quarentena de segredos, e o índice do código fica na infraestrutura que o cliente controla. Como em qualquer ferramenta de codificação assistida por IA, trechos de código são processados nas APIs do provedor de modelo (inferência e representações vetoriais, os embeddings), sob os termos que o cliente mantém com o provedor; a Kazap não retém nem armazena o código do cliente. O CodeSense é tecnologia que equipa o método, e não produto à venda.

## Engajamento típico: resgate de PoC

É o engajamento de entrada da frente de IA. O cenário: uma PoC interna que impressionou na demonstração e morreu antes de chegar a produção, sem evals, sem guardrails, sem noção de custo em escala. O fluxo:

1. **Auditoria da PoC:** o que aproveitar, o que reescrever, quais riscos (segurança, custo, compliance) estão abertos.
2. **Eval harness primeiro:** o banco de casos que a PoC nunca teve vira o contrato de qualidade.
3. **Reengenharia para produção:** guardrails, telemetria, engenharia de custo, fallback e LGPD.
4. **Go-live com gate:** 100% das conversas de teste validadas; operação assistida no início, transferência ou operação contínua depois.

## Stack típica

- **Modelo: escolhido por projeto, por medição.** A escolha pesa seguimento de instrução, segurança e custo, validados na suíte de comportamento do caso, e a arquitetura isola o provedor: trocar de modelo é configuração, não reescrita. O modelo que respondeu cada turno deste site aparece na telemetria pública de custo e latência ("Modo Bastidores").
- **Backend: Python, Rust e Node.js**, escolhidos por caso de uso e pelos requisitos funcionais e não-funcionais de cada projeto (o agente do site kazap.com.br, por exemplo, roda em Node/Next). Em qualquer stack, o desenho é o mesmo: rate limiting, circuit breaker e telemetria na frente do modelo, e nenhum framework de agente quando ele não compensa o próprio peso, porque orquestração explícita é mais auditável.
- **Frontend: Next.js** com a resposta exibida token a token (streaming).
- **Base de conhecimento: markdown estático versionado** como padrão. **Qdrant (busca vetorial) entra quando a base cresce para a ordem de dezenas de milhares de tokens por contexto**, ou antes, se a decisão pede (muitos documentos, base com alta taxa de atualização, citação por trecho, custo × volume). Abaixo disso, o prompt direto com caching é mais simples, mais barato e sem o risco de a busca (retrieval) trazer o trecho errado. Não é um limiar fixo, e sim julgamento de arquitetura: a complexidade entra quando o dado pede, não antes.

## Números e fatos verificáveis

- **Agente do site kazap.com.br**: suíte de regressão de comportamento (injection, conversão, alucinação, casos difíceis e fora-de-escopo) rodando a cada mudança de prompt ou base de conhecimento, versionada no repositório do site; a suíte cresce junto com o agente. Prompt montado em 2 camadas de cache. Custo, latência e cache são auditáveis na telemetria pública de custo e latência do site ("Modo Bastidores").
- **~3¢ (USD) por resposta** do agente do site kazap.com.br. Metodologia: telemetria por conversa (o custo que o provedor fatura naquele turno, já com o efeito do cache). A referência é 3,17¢, a média de uma conversa de 6 turnos (o primeiro escreve o cache, os cinco seguintes leem; o turno cacheado sozinho sai a ~1,7¢), medida na configuração atual do agente; com amostra suficiente (50 respostas), o número exibido no site passa a ser a média real das respostas. Auditável na telemetria pública de custo e latência ("Modo Bastidores").
- **~70% de economia com prompt caching** numa mesma conversa, contando o turno que grava o cache, medida pelo custo faturado em cada resposta, com e sem o desconto de cache, não estimada por fórmula; com amostra suficiente, o site exibe a economia real agregada sobre as respostas. Entre visitantes, a economia depende de TTL e volume, por isso o TTL de 1 hora nas rotas quentes.
- **Gate de go-live: nenhum agente entra em produção sem 100% das conversas de teste validadas por eval harness**, política do processo; a regressão contínua roda a cada mudança de prompt ou base.
- **Zero alucinação tolerada em produção** nos sistemas RAG, política operacional verificada por citação obrigatória de fonte e suíte de regressão a cada atualização da base; não é garantia matemática de que o modelo nunca errará.
- **18 anos de engenharia de software e 12 segmentos atendidos** ao longo da trajetória da Kazap, de fintech a healthtech; **três clientes de healthtech** com sistemas generativos em produção hoje, sob NDA.

## Perguntas frequentes

**Já existe uma PoC interna que funciona. A Kazap assume a partir daí?**
Sim, é o engajamento de entrada da frente (resgate de PoC). Mas "funciona na demo" é diferente de pronto para produção, e algumas perguntas separam os dois: a PoC tem banco de evals com regressão? Guardrails testados contra injection? Custo projetado em escala com caching? Fallback quando a API cai? LGPD no logging? Se a resposta for sim para todas, não há necessidade da Kazap. Se não, o resgate audita o que existe, constrói o eval harness que a PoC nunca teve e reescreve o que precisa para ir a produção: guardrails, telemetria, custo e fallback. Aproveitamos o que funciona e não refazemos nada por vaidade.

**Como funciona o eval harness na prática?**
É um banco de casos de teste de comportamento (casos felizes, edge cases do domínio, perguntas ambíguas e tentativas de abuso) que roda como regressão automática a cada mudança de prompt, base ou modelo. Definido antes do primeiro prompt, ele é o critério de pronto do projeto e faz a regressão aparecer antes do deploy, e não em produção.

**IA alucina. Como confiar em um sistema desses?**
Modelo solto alucina, e a Kazap não promete o contrário. Por isso o nosso desenho não confia no modelo: RAG com citação obrigatória de fonte, instrução explícita de dizer "não sei", suíte de regressão a cada mudança e revisão amostral nas automações. A confiança vem da arquitetura e da medição contínua, e não da fé no modelo. Quando o caso de uso não tolera nenhuma taxa de erro nem com essas camadas, a Kazap diz que IA não é a ferramenta certa.

**Como a LGPD é tratada nos projetos?**
LGPD entra no design: consentimento explícito para logging, anonimização dos registros, endpoint de exclusão, política de retenção e minimização dos dados enviados ao modelo (as requisições pedem que o provedor não retenha nem treine com o conteúdo, e os termos vigentes do fornecedor em uso são verificados no desenho de cada projeto). O que a Kazap não faz: afirmar que um cenário específico está em compliance sem auditar o contexto, porque bases legais e fluxos de dados variam por empresa.

**Quanto custa manter um agente no ar?**
Duas parcelas. API: o custo mensal é o custo por resposta multiplicado pelo volume de respostas, e a engenharia de custo (caching com breakpoints, TTL por uso, rate limiting) atua no primeiro fator. Como referência medida, o agente do site kazap.com.br custa ~3¢ de dólar (USD) por resposta, pelo custo que o provedor fatura. Operação: revisão de conversas, atualização de base e regressão, com o time do cliente (treinado pela Kazap) ou com a própria Kazap. O número exato depende de volume e escopo, por isso a qualificação vem antes do orçamento, e o custo por conversa é métrica de projeto desde o dia um.

**Faz sentido construir com o time interno em vez de contratar?**
Talvez sim. A longo prazo, a recomendação da Kazap é inclusive internalizar, e há treinamento exatamente para isso. O problema é o custo da curva de aprendizado: eval harness, engenharia de caching, guardrails e governança de custo são disciplinas que um time aprenderia errando em produção, com a marca da empresa em jogo. O formato que mais funciona: a Kazap entrega a primeira versão em produção com o método completo e transfere a operação com treinamento. O cliente fica com o sistema e com a capacidade.

**Os modelos mudam rápido. O que impede tudo de ficar obsoleto em dois anos?**
Os modelos vão mudar, por isso a arquitetura isola o provedor e trata modelo como configuração. A disciplina permanece: evals, governança e custo. Quem constrói isso agora trata troca de modelo como configuração, sem reescrita; quem acopla a PoC ao modelo da moda reescreve tudo. E se um caso não tem retorno claro sobre o investimento (ROI) hoje, a Kazap diz isso na qualificação.

**Qual modelo a Kazap usa?**
A arquitetura isola o provedor: o modelo é decisão de configuração, não reescrita, e o modelo que respondeu cada turno é visível na telemetria pública de custo e latência do site ("Modo Bastidores"). A escolha pesa seguimento de instrução, segurança e custo, e qualquer troca passa pelo eval antes de valer.

**Quando entra busca vetorial (Qdrant) e quando não?**
Não há um número mágico: é julgamento de arquitetura, por alguns fatores (volume da base, taxa de atualização, necessidade de citar por trecho e custo × volume). Como regra prática, bases na ordem de poucos a algumas dezenas de milhares de tokens por contexto vão direto no prompt com caching, o que é mais simples, mais barato e sem risco de a busca trazer o trecho errado; conforme crescem ou esses fatores pesam, entra RAG com Qdrant e busca híbrida. A complexidade entra quando o dado pede.

**Modelo preditivo não degrada com o tempo?**
Degrada: todo modelo preditivo sofre drift quando o mundo muda. Por isso o desenho inclui monitoramento de drift, gatilho de retreino e validação temporal desde o início, e o modelo é medido em produção contra a realidade, não só contra o conjunto de treino. Um preditor entregue sem plano de drift perde a calibração sem que ninguém perceba.

**Como se mede a qualidade de um modelo preditivo ou de visão? Não é "eval de prompt".**
Não é, e por isso o critério muda por frente. Para a generativa, banco de casos de comportamento como regressão. Para preditiva e visão, conjunto de validação rotulado, métrica definida antes do go-live (precision/recall por classe ou MAE, conforme o caso), conjunto de teste separado por período (holdout temporal) e monitoramento de drift em produção. O conceito é o mesmo, critério de pronto antes de construir, instanciado por tipo de modelo.

**Projetos com biometria ou reconhecimento facial são viáveis?**
Depende do contexto, e o tema é tratado com cautela: casos de biometria passam por avaliação jurídica e de LGPD caso a caso antes de qualquer proposta. A Kazap não afirma que um cenário está em compliance sem auditar base legal e fluxo de dados, e diz não quando o uso não se sustenta.

**O agente pode ser desligado se algo der errado?**
Sim. O kill switch faz parte do desenho das entregas, com fallback gracioso: o produto continua funcionando (página estática, formulário, fila humana) mesmo com a IA fora do ar. E o circuit breaker corta automaticamente as chamadas em caso de erros consecutivos ou anomalia de custo.

**A Kazap faz visão computacional e OCR, ou só agentes?**
As três frentes (preditiva, generativa e visão computacional), com a mesma régua de produção. Visão computacional e modelos preditivos são prática da casa desde antes dos LLMs (inspeção de qualidade, OCR estruturado, previsão de demanda, detecção de fraude). A frente generativa é a que tem prova pública auditável no site kazap.com.br.

**Em que estágio faz sentido procurar a Kazap?**
Qualquer um: ideia (ajudamos a decidir se IA é a ferramenta certa, inclusive quando a resposta é não), PoC parada (resgate) ou sistema em produção com problema de custo ou qualidade. A primeira conversa é de qualificação, e não de venda.