IA e sistemas inteligentes

Agentes de IA não são software normal.

Mesma entrada, saída diferente. Eles generalizam além da especificação — essa é a capacidade e o modo de falha. Levá-los à produção exige outra disciplina e outro conjunto de ferramentas.

As duas coisas são o que fazemos.

Ou veja funcionando: rode o AI Opportunity Scan gratuito. Menos de dois minutos. Uma URL.

Um tipo diferente de software

Correção deixa de ser binária.

Quase toda prática de engenharia em que seu time confia pressupõe que correção é um estado: o código está certo ou errado, e um teste diz qual. Sistemas aprendidos por máquina não funcionam assim. Correção é uma distribuição — uma taxa de falsos positivos é uma propriedade do sistema, não um defeito dele. Agentes generativos levam isso ao extremo: são não determinísticos por design, então a mesma entrada não produz de forma confiável a mesma saída duas vezes.

01 · O que você ganha

Comportamento além da especificação.

Software determinístico resolve os casos que alguém enumerou. Um agente resolve os que ninguém escreveu — layouts de documento inéditos, formulações imprevistas, a cauda longa que antes exigia um motor de regras impossível de manter. Problemas antes não especificáveis viraram tratáveis. É por isso que se usa um agente.

02 · O que você aceita

A mesma propriedade, invertida.

Um sistema que generaliza além da especificação às vezes vai agir fora dela — e falha de outro jeito. Software tradicional falha alto: uma exceção, um 500, um build vermelho. Um agente falha de forma plausível — bem formado, confiante, errado, sem nada levantar bandeira. Ele pode falhar em três de cada cem execuções, então não é reproduzível sob demanda, e corrigir não é consertar código: é deslocar uma distribuição. É por isso que uma suíte de regressão é infraestrutura, não higiene.

03 · O que muda sem você

O chão se move.

Com um modelo hospedado, seu fornecedor publica uma atualização e o comportamento muda — sem deploy, sem commit, sem chamado. Com pesos próprios o modelo fica parado, mas o mundo não: as distribuições de entrada derivam e a acurácia do trimestre passado se degrada sem nada mudar no seu stack. É por isso que uma suíte de regressão é infraestrutura, não higiene.

04 · No que a superfície de ataque se transforma

Dados que podem agir.

Em outros lugares, dados são dados e instruções são instruções. Em um agente, qualquer coisa que chegue à janela de contexto — um documento, um e-mail, a resposta de uma ferramenta — pode se comportar como instrução. Injeção de prompt não é uma subclasse de validação de entrada; sua revisão de segurança não tem campo para isso. É específico de agentes — a única propriedade desta lista da qual um sistema de visão ou de ML tabular escapa.

Não dá para testar uma distribuição com teste unitário.

A confiança vem de avaliar contra conjuntos de dados curados, pontuar traces reais de produção e ter portões de regressão que rodam sempre que o modelo muda — não de porcentagens de cobertura. Outro software, outras falhas, outras ferramentas.

Modo de falha 01 · 0 verificações

Sem harness de avaliação.

Cada mudança de prompt, upgrade de modelo ou novo tipo de documento é um chute. Sem evals de regressão, ninguém sabe dizer se o conserto de ontem quebrou os casos do mês passado — então as mudanças congelam e o protótipo fossiliza.

Modo de falha 02 · 1 passo · 5 tarefas

O agente monolítico.

Um prompt fazendo cinco tarefas. Demonstra lindamente e depura terrivelmente: quando a qualidade da saída cai, não há como isolar qual responsabilidade falhou. Sistemas que não se depuram não chegam à produção.

Modo de falha 03 · acurácia ↓ em volume

Colapso de contexto em volume real.

O protótipo rodou em cinquenta documentos escolhidos a dedo. Produção significa centenas de milhares — malformados, duplicados, contraditórios. A recuperação degrada, estratégias de memória que funcionavam na demo desabam e a acurácia escorrega em silêncio.

Modo de falha 04 · gasto ↑ composto

A curva de custo que ninguém modelou.

Custos de tokens que pareciam irrelevantes por requisição se acumulam entre retentativas, laços de agente e escala. Projetos morrem na sala do CFO tão frequentemente quanto no repositório.

Modo de falha 05 · sem caminho de volta

Sem rota de escape.

Sem rollback, sem escalonamento para uma pessoa, sem trilha de auditoria. No momento em que o sistema comete um erro caro sem história de recuperação, a confiança evapora — e confiança não volta a preço de protótipo.

Por que protótipos morrem

A lacuna tem uma anatomia.

O não determinismo é a causa. Estes são os sintomas. Todo projeto de IA travado para o qual fomos chamados falhou de uma entre poucas formas previsíveis — falhas de engenharia, não de estratégia.

Assinatura da falha0 verificações

ingerir

classificar

extrair

decidir

efetivar

sem verificação

todo passo roda, nenhum é verificado — mude um e você não saberá o que se moveu

Um pipeline · cinco formas de falhar

Como um projeto começa

Duas perguntas, respondidas em artefatos.

Seu problema

01 · Avaliar

02 · Arquitetar

A construção começa →

Oito entregáveis · continue rolando ou escolha um

Antes de qualquer uma das quatro práticas começar, as duas são resolvidas em código que funciona e contratos escritos — não em slides. Tudo isso fica com você, construindo o sistema ou não.

01 · Avaliarvale a pena construir?

Prova de viabilidadeCódigo funcionando sobre seus dados reais, não um slide afirmando que é viável.

O que isso te dizQual a acurácia hoje, medida nos seus documentos e não em um benchmark.Quais casos ele resolve limpo e quais ainda precisam de uma pessoa.O que precisa ser verdade para o sistema completo se sustentar em produção.

Software funcionandoA decisão que isso resolveSe vale a pena construir isso.

Mapa de oportunidades de IAOnde a IA cria alavancagem nos seus fluxos de trabalho reais.

O que isso te dizOs dois ou três pontos que vale automatizar primeiro, e por quê.Os que parecem atraentes mas não pagam o esforço.Quanto cada um vale por mês em horas ou em gasto.

Entregável escritoA decisão que isso resolvePor onde começar e o que deixar de lado por ora.

Diagnóstico dos dadosO que seus dados sustentam hoje e o que precisa de enriquecimento antes.

O que isso te dizQuais fontes já são utilizáveis como estão.Onde estão as lacunas, as duplicidades e o histórico que falta.Quanta preparação é necessária antes de confiar nos resultados.

Entregável escritoA decisão que isso resolveSe os dados sustentam o plano, ou o plano muda.

Modelo de custosProjeção da economia de inferência e infraestrutura nos seus volumes.

O que isso te dizCusto por documento, requisição ou transação no volume de hoje.Como isso escala, incluindo as retentativas que a maioria das estimativas ignora.Alternativas mais baratas e do que cada uma abre mão.

Modelo financeiroA decisão que isso resolveSe a economia fecha em escala, não só num piloto.

02 · Arquitetaro que é o sistema, exatamente?

Topologia de agentesQuais responsabilidades são agentes, quais são código determinístico e como se compõem.

O que isso te dizQuais passos realmente precisam de um modelo — normalmente menos do que se espera.Quais passos seguem como software convencional, para continuarem previsíveis e baratos.Onde o trabalho é dividido para que uma falha seja rastreável a um só lugar.

ArquiteturaA decisão que isso resolveO que vamos construir, preciso o bastante para estimar.

Contrato de fluxo de dados e integraçãoComo o sistema se conecta ao seu ERP, CRM, mensageria e repositórios de dados.

O que isso te dizExatamente quais dados cruzam cada fronteira, e em que direção.O que acontece quando um sistema está lento, fora do ar ou manda a mesma coisa duas vezes.O que é responsabilidade do seu time e o que é nossa.

Plano de integraçãoA decisão que isso resolveComo isso encaixa no seu stack sem que um lado trave o outro.

Plano de avaliaçãoA suíte de testes que vai barrar toda mudança futura, projetada antes de a construção começar.

O que isso te dizO que significa “bom o bastante para lançar”, como um número com que todos concordam.Como uma atualização de modelo ou de fornecedor é pega antes de seus usuários sentirem.Como problemas de produção viram testes permanentes em vez de recorrentes.

Plano de qualidadeA decisão que isso resolveComo você vai saber, daqui a seis meses, que ainda funciona.

Projeto de guardrails e checkpoints humanosOnde o sistema precisa ceder, escalonar ou parar.

O que isso te dizQuais decisões vão para uma pessoa, e a partir de qual confiança.O que nunca pode ser gravado em um sistema de negócio sem verificação.O que acontece quando algo dá errado: escalonar, reverter ou parar.

Risco e controlesA decisão que isso resolveQuanta autonomia o sistema tem no primeiro dia.

A maioria dos projetos começa com uma versão de dois minutos do primeiro portão. Rode seu AI Opportunity Scan gratuito →

Quatro práticas, não quatro passos. A quarta é a razão pela qual as três primeiras continuam verdadeiras.

Sistemas de IA multiagente

Construa

Sistemas de agentes orquestrados com os guardrails, o monitoramento e a disciplina de custo que permitem rodar sem supervisão.

Você chega com

Um notebook que funciona, um piloto de um único time ou uma demo de fornecedor que empacou em “impressionante”.

Nós construímos

A topologia de agentes — orquestradores, agentes especialistas, passos determinísticos onde o determinismo vence — com uso de ferramentas, memória, checkpoints humanos e tracing projetados desde o primeiro commit.

Você sai com

Um sistema implantado, sua suíte de evals, seus traces e a documentação que seu time precisa para estendê-lo.

Um julgamento que fazemos

Quando dividir um agente monolítico em um orquestrador com especialistas — e quando não. Se o fluxo é fixo, código determinístico ganha de um agente sempre; agentes só merecem seu lugar onde roteamento e raciocínio são de fato dinâmicos. A maioria dos projetos travados errou essa fronteira, para um lado ou para o outro.

LangChainAWS BedrockFireworks AITavily

Enriquecimento de dados e ML

Alimente

Sistemas de IA só valem o que valem os pipelines de dados por baixo deles — e o pipeline costuma ser o projeto de verdade.

Você chega com

Dados espalhados por um ERP, planilhas, PDFs e um fluxo de sensores que ninguém olha; ou um protótipo de RAG que responde com confiança e erra.

Nós construímos

Pipelines automatizados de enriquecimento e ML — limpar, conectar e ativar seus dados para que os modelos operem sobre fatos confiáveis, com fluxos agendados que mantêm isso assim. Isso inclui os dados de eval do sistema: exemplos curados, traces de falha rotulados e golden datasets também são engenharia de dados — e são justamente os datasets que a maioria dos times esquece de construir.

Você sai com

Pipelines em produção, contratos de dados documentados e fluxos de retreino e atualização que seu time consegue operar.

Um julgamento que fazemos

Quando enriquecer a jusante e quando corrigir os dados na origem. Pipelines de enriquecimento conseguem mascarar um processo quebrado por um tempo — mas se o sistema de origem continuar produzindo lixo, vamos dizer para corrigir a origem, mesmo quando o pipeline seria a fatura maior.

LangGraphKestraAWS SageMakerAWS Glue

Cloud, edge e posicionamento do modelo

Implante

Implantar onde os dados estão, no modelo que serve — cloud AWS quando dá, chão de fábrica quando é preciso, pesos próprios quando a economia ou a privacidade exigem.

Você chega com

Um sistema que funciona em um ambiente e requisitos que ele não atende ali — latência, conectividade, residência de dados ou custo unitário. Ou uma conta de API de fronteira que parou de fazer sentido em volume de produção.

Nós construímos

Implantação em produção na AWS, ou inferência em edge onde os dados nascem — chão de fábrica, veículos, locais remotos — com resiliência offline quando a rede é um talvez. E a decisão de modelo por baixo: API de fronteira, modelo de pesos abertos, ajustado ou quantizado para o hardware alvo.

Você sai com

Infraestrutura como código, pipelines de implantação, uma decisão documentada sobre a origem do modelo com seus trade-offs de custo e qualidade, e uma frota edge que seu time atualiza remotamente.

Um julgamento que fazemos

Cloud, edge ou modelo próprio é uma decisão de economia e física, não de preferência. Modelamos orçamentos de latência, a conectividade real, a gravidade dos dados e o custo por inferência nos seus volumes. Às vezes um modelo pequeno ajustado no seu próprio hardware ganha da API de fronteira em todos os eixos que importam para você, menos naquele do gráfico do benchmark.

AWS GreengrassAWS SageMaker EdgeLambdasAWS Kinesis

Evals, observabilidade e performanceO caminho de volta

Monitore

O sistema que entra no ar é uma hipótese. Monitorar é como ela vira fato — e continua sendo.

Você chega com

Um sistema em produção que ninguém consegue provar que funciona. Qualidade é medida em volume de reclamação, “parece pior desde a atualização do modelo” é infalsificável, e ninguém sabe dizer quanto custa uma requisição nem quanto ela ficou mais lenta no mês passado.

Nós construímos

O harness de eval e a camada de observabilidade. Suítes de regressão offline que barram cada release; evals online pontuando traces reais de produção onde não existe resposta de referência; tracing distribuído em cada passo de agente e chamada de ferramenta; orçamentos de latência e de custo em tokens medidos por passo do fluxo em vez de estimados. E o laço que conecta tudo — uma falha em produção vira um modo de falha nomeado, depois um exemplo no dataset, depois cobertura de regressão permanente.

Você sai com

Uma suíte de regressão que cresce a cada incidente, painéis de latência p50/p95 e custo por fluxo que seu time lê sem a gente, alertas ajustados a modos de falha nomeados em vez de a notas genéricas de qualidade, e um procedimento escrito para transformar a próxima falha de produção em teste.

Um julgamento que fazemos

Quais falhas merecem um juiz LLM e quais precisam de uma verificação determinística. Juízes são sedutores porque escalam para qualidade subjetiva, mas precisam ser calibrados contra traces rotulados antes de suas notas poderem barrar um release — senão só enfeitam um painel. Tudo que se expressa como verificação de schema, correspondência exata ou status de saída nunca deveria ser entregue a um modelo. Preferimos entregar cinquenta asserções determinísticas baratas a um juiz impressionante em que ninguém confia.

Numa frota edge isso é outra disciplina de novo — saúde dos dispositivos, versões de firmware e deriva de sensores em hardware onde você não consegue entrar por SSH.

LangSmithAWS Bedrock AgentCore

Quatro práticas, um laço. O que Monitore aprende em produção vira o que Construa muda, o que Alimente cura e o que Implante lança em seguida. Um sistema sem esse caminho de volta não está em produção — está solto por aí.

“Nosso time não conseguiria construir isso?” Quase certamente sim. A construção é a metade visível — o harness, os traces e o laço são a metade que decide se daqui a um ano ainda está rodando.

Por dentro de um sistema em produção

O que “pronto para produção” significa de fato, desenhado.

O mesmo pipeline de documentos e sensores da nossa página inicial — desta vez com as partes que o tornam produtivo: o laço de avaliação, os traces, os checkpoints, os medidores.

Arquitetura de referência · pipeline de documentos e sensoresRole para o lado para acompanhar o pipeline →

o caminho de volta — falha → exemplo no dataset → cobertura de regressão

portão de evals offline— nada é mergeado até a suíte passar, então o que a produção aprendeu decide o que sai em seguida

documentos

sensores

▶

ingerir

▶

orquestrador

▶

classificador

extrator

validador

▶

revisão humana

erp

tracingmedição de custoevals online

Portão de evals offline — cada classe de saída tem uma suíte de regressão com exemplos curados; mudanças em prompts ou modelos não são mergeadas até a suíte passar.

Evals online — traces de produção são pontuados continuamente contra sinais de qualidade e de política, sem uma resposta de referência para apoiar; o equivalente ao vivo do portão offline.

Tracing — cada decisão do agente emite um trace; quando algo dá errado, a resposta está no trace, não numa sala de crise.

O caminho de volta — um trace que expõe uma falha vira um modo de falha nomeado, depois um exemplo no dataset, depois cobertura de regressão permanente; essa seta é o que faz do diagrama um laço em vez de um pipeline.

Checkpoint humano — saídas de baixa confiança e alto risco vão para revisão; o limiar é um parâmetro ajustado, não uma esperança.

Medição de custo — o gasto é medido por passo do fluxo; retentativas e laços de agente são orçados, não descobertos.

Guardrails nas fronteiras — validação de entrada na entrada, contratos de saída na saída; o ERP nunca recebe uma gravação sem validação.

Contrato de integração — a fronteira com o ERP é um schema versionado, para que o sistema de IA e o sistema de negócio evoluam de forma independente.

Onde o outro pilar se conecta

IA precisa de dados. Dados precisam de sensores. Sensores precisam de hardware.

Quando os dados de que seus modelos precisam ainda não existem — porque estão no chão de fábrica, dentro de uma máquina ou na ponta de uma rede instável — o projeto deixa de ser um problema de software. Nossa divisão de hardware e IoT projeta o hardware que produz esses dados: PCBs sob medida, rádios avaliados em RF, orçamentos de energia medidos em microampères. Um time só, as duas pontas do pipeline.

Conheça as capacidades do nosso laboratório →

Quando você quiser

Veja a disciplina antes de contratá-la.

O AI Opportunity Scan é ele próprio um sistema agêntico em produção — construído com a mesma disciplina de eval, tracing e guardrails descrita nesta página. Rode na URL da sua empresa e receba seu mapa de oportunidades de IA e sua distância competitiva. Menos de dois minutos. Uma URL.

Rode seu AI Opportunity Scan gratuitoFale com um engenheiro