O agente que promete entrar amanhã em qualquer empresa pode ser exatamente o agente que não entende empresa nenhuma.

TL;DR

Agentes genéricos não são necessariamente inúteis. Podem servir como demonstração, protótipo ou base reutilizável. O embuste começa quando essa base é vendida como solução acabada, sem descobrir o processo, as fontes, as exceções, as permissões e as responsabilidades da empresa. A primeira experiência costuma falhar justamente nos detalhes que a demonstração esconde. Depois, a organização conclui que “IA não funciona”, cria rejeição e pode ficar para trás por causa de uma implementação ruim, não por causa do limite real da tecnologia. Fuja de quem chega com a solução antes de entender o problema.

Imagine a proposta.

Um agente de vendas pronto.

Um agente financeiro pronto.

Um agente de atendimento pronto.

Instalação rápida. Algumas integrações. Uma demonstração em que tudo acontece no tempo certo e nenhum cliente resolve fazer a pergunta que não estava no roteiro.

Parece irresistível.

Também pode ser a pior primeira experiência que sua empresa terá com inteligência artificial.

Não porque agentes não funcionem.

Porque “agente genérico para empresas” pode ser uma contradição escondida por uma interface bonita.

Empresa não é um substantivo suficiente para configurar um sistema.

A demonstração vende a parte em que tudo se parece

É fácil demonstrar o caminho comum.

Chega uma mensagem. O agente identifica a intenção. Consulta uma informação. Responde. Talvez atualize um registro. Todo mundo sorri para a tela.

O problema real começa depois:

• qual é a fonte oficial quando dois sistemas discordam?
• o que significa “cliente ativo” naquela empresa?
• quem pode conceder desconto e até qual limite?
• que informação o atendimento pode mostrar para cada perfil?
• qual exceção precisa de aprovação do financeiro?
• o que acontece quando um documento chega incompleto?
• qual ação pode ser desfeita?
• quem recebe o caso quando o sistema não sabe?

A demonstração mostra capacidade.

A operação exige contexto.

É nesse intervalo que muita solução pronta vira embuste — mesmo quando o modelo é bom, a interface funciona e o fornecedor não começou o projeto com intenção de enganar ninguém.

O problema pode nascer de uma promessa maior que a arquitetura.

Um cargo genérico não contém um processo

“Agente de vendas” não descreve um trabalho.

Vendas pode envolver prospecção, qualificação, histórico do relacionamento, política comercial, cálculo, estoque, prazo, contrato, privacidade, passagem para atendimento e dezenas de exceções que mudam de uma empresa para outra.

“Agente financeiro” é ainda mais perigoso como abreviação. Qual parte do financeiro? Conciliação? Cobrança? Leitura de notas? Preparação de pagamento? Projeção? Aprovação? Cada verbo exige dados, autoridade e controles diferentes.

“Agente de recursos humanos” pode significar localizar uma política interna ou participar de uma decisão que afeta direitos e carreira. Usar o mesmo nome para os dois casos esconde uma diferença de risco enorme.

Um agente de IA é um sistema capaz de escolher próximos passos e usar ferramentas dentro de um objetivo. O nome do cargo não informa quais ferramentas ele recebe, quais fontes deve confiar, que decisões pode tomar nem onde precisa parar.

Sem isso, não existe cargo digital.

Existe uma improvisação com crachá.

O agente genérico falha exatamente onde a empresa é específica

Ele não falha necessariamente no resumo de texto, na classificação simples ou na resposta comum.

Falha quando encontra aquilo que transforma um negócio real em algo diferente do slide comercial:

• uma regra que nunca foi documentada;
• dois setores que usam o mesmo termo com sentidos diferentes;
• um cadastro desatualizado que todos aprenderam a contornar;
• uma exceção rara, mas cara;
• uma política que depende do perfil de quem solicita;
• uma integração que funciona nove vezes e falha em silêncio na décima;
• uma decisão cuja responsabilidade ninguém quis assumir no desenho do projeto.

O agente não conhece essas coisas por intuição.

Elas precisam ser descobertas, transformadas em contexto e conectadas à operação.

Às vezes, nem a própria empresa consegue explicá-las de primeira. É por isso que levantamento de requisitos não é uma reunião burocrática antes da instalação. É o trabalho de tornar o processo legível o bastante para que qualquer sistema — humano, convencional ou assistido por IA — consiga operá-lo.

Uma primeira impressão ruim cobra juros

Depois de uma implantação ruim, a conclusão raramente fica restrita ao fornecedor.

As pessoas dizem:

• “a IA inventa demais”;
• “ninguém confia nisso”;
• “tentamos e não funcionou”;
• “nossa empresa é diferente”;
• “melhor continuar fazendo manualmente”.

E talvez estejam descrevendo corretamente o sistema que receberam.

O problema é transportar essa experiência para qualquer uso futuro.

Existe uma linha de pesquisa chamada aversão a algoritmos, que investiga a tendência de rejeitar um sistema automatizado depois de observar seus erros. Em experimentos publicados por Dietvorst, Simmons e Massey, participantes passaram a evitar previsões algorítmicas depois de vê-las falhar, mesmo quando elas superavam as previsões humanas em média.

O estudo de 2015 tratou tarefas experimentais de previsão, não implantação de agentes de IA em empresas. Ele não prova que uma experiência ruim com um chatbot condenará toda adoção futura. Serve aqui como uma lente limitada para algo que vale considerar: as pessoas não avaliam apenas a taxa de acerto; elas atualizam sua confiança quando veem como o sistema erra.

Uma implantação irresponsável não desperdiça apenas orçamento.

Pode ensinar a organização a rejeitar uma capacidade que ainda nem chegou a conhecer direito.

A empresa também aprende um comportamento ruim

Quando o agente pronto é apresentado como mágico, a equipe aprende duas opções igualmente ruins.

Ou deve confiar porque “a IA sabe”.

Ou deve rejeitar tudo porque a primeira experiência errou.

Nenhuma das duas ensina uso responsável.

Uma adoção madura deveria ensinar as pessoas a:

• reconhecer para que o sistema foi desenhado;
• verificar a fonte de uma resposta importante;
• distinguir sugestão, validação e decisão;
• perceber quando a situação saiu do contexto previsto;
• corrigir o sistema sem esconder o erro;
• encaminhar exceções para o responsável certo;
• medir se o processo melhorou de verdade.

A ferramenta não entra apenas numa arquitetura técnica.

Entra numa cultura de trabalho.

Se a primeira lição é “clique e torça”, a tecnologia pode até parecer moderna. O aprendizado organizacional não é.

Base reutilizável é diferente de resposta pronta

Eu mesmo trabalho com uma base reutilizável.

Seria desperdício reconstruir do zero controle de versões, memória, gestão de permissões, registro de ações, padrões de validação e componentes de automação sempre que um novo sistema começa.

Também existem automações que podem ser praticamente replicadas quando o processo e as ferramentas são equivalentes, exigindo apenas ajustes de configuração e integração.

O problema não é reutilizar engenharia.

O problema é reutilizar conclusões.

Uma base responsável acelera o que é estrutural e mantém explícito o que precisa ser descoberto:

Pode ser reutilizado	Precisa nascer do contexto
Estrutura de memória e rastreabilidade	Que informação merece ser lembrada e por quanto tempo
Padrões de ferramentas e permissões	Que sistemas o agente pode acessar e com qual autoridade
Mecanismos de validação	O que significa uma entrega correta naquele processo
Registro, monitoramento e alertas	Que falha importa, quem precisa saber e quando agir
Fluxos de aprovação	Quem responde por cada decisão e qual limite exige escalonamento
Componentes de integração	Quais dados são canônicos e como resolver divergências reais

Produto pronto pode significar componentes maduros.

Não deveria significar contexto imaginado.

O que costuma faltar dentro da caixa

Um agente útil para produção precisa de mais que um modelo e um conjunto de instruções.

Ele precisa de um harness: o sistema ao redor do modelo que fornece contexto, memória, ferramentas, permissões, fontes, validações, limites e ciclos de feedback.

Na prática, isso inclui pelo menos:

1. Fonte de verdade

O agente precisa saber qual documento, banco de dados ou sistema possui a informação oficial. Quando fontes divergem, a regra de precedência não pode ser inventada durante a resposta.

2. Vocabulário do negócio

Termos aparentemente simples — cliente, proposta, pendência, aprovado, concluído — precisam ter o significado usado naquela operação.

3. Ferramentas e permissões

Consultar é diferente de alterar. Preparar é diferente de enviar. Recomendar é diferente de aprovar. Cada ação precisa do menor acesso necessário e, quando houver consequência material, de um ponto de aprovação.

4. Casos de avaliação

Antes de produção, o sistema precisa enfrentar um conjunto representativo de situações reais: caminho comum, dados ausentes, informação contraditória, exceção, tentativa indevida e falha de ferramenta. Avaliação não é perguntar ao fornecedor se a demonstração funcionou. É comparar o resultado com critérios de aceite definidos antes.

5. Observabilidade

Observabilidade é a capacidade de compreender o estado interno de um sistema a partir de evidências como registros de eventos, métricas e rastros de execução. Sem ela, o agente pode falhar em silêncio ou produzir uma resposta sem que ninguém consiga reconstruir o caminho.

6. Forma segura de falhar

O sistema precisa conseguir se abster, pedir informação, transferir o caso, interromper uma ação e reverter o que for reversível. “Não sei” pode ser uma função de segurança.

7. Dono da decisão

Se ninguém consegue responder quem autoriza, quem monitora e quem corrige, o agente não recebeu autonomia.

Recebeu abandono.

A pergunta não é “quanto ele faz na demo?”

É fácil impressionar medindo quantidade de ações.

Eu prefiro perguntar:

• Em quais situações ele não deve agir?
• Que contexto foi usado para configurar a demonstração?
• Quais casos reais foram testados?
• Como o sistema mostra a fonte de uma afirmação?
• Quem define e altera as políticas?
• Que permissões entram ligadas por padrão?
• O que acontece quando uma integração fica indisponível?
• Existe ambiente de teste separado da operação real?
• Como uma ação errada é detectada e revertida?
• Os dados e registros ficam sob qual controle?
• A empresa consegue trocar de modelo, ferramenta ou fornecedor?
• Quem mantém o sistema quando o processo mudar?

Um bom fornecedor deveria gostar dessas perguntas.

Elas ajudam a vender menos fantasia e entregar mais sistema.

Fuja dos entregadores de solução pronta

Não fuja de quem traz componentes prontos, experiência acumulada ou uma arquitetura de referência.

Fuja de quem:

• apresenta a solução antes de ouvir o processo;
• chama uma demonstração de implantação;
• trata acesso amplo como facilidade de integração;
• promete autonomia sem explicar autoridade;
• mede sucesso pela qualidade da conversa, não pelo resultado do trabalho;
• não consegue mostrar como o agente é avaliado;
• vende personalização como troca de nome, logotipo e mensagem inicial;
• não fala de exceção, segurança, registro, custo, manutenção ou reversão;
• culpa o usuário quando o sistema encontra uma situação que nunca foi mapeada;
• cria dependência sem oferecer controle sobre contexto, dados e operação.

Uma solução realmente madura não tem medo de revelar o que ainda precisa ser descoberto.

O contexto vem antes do agente

O NIST AI Risk Management Framework inclui, na função de mapear, a necessidade de entender o propósito, o contexto de uso, os usuários, os impactos, a supervisão humana e o escopo pretendido do sistema. É uma estrutura voluntária e ampla; não certifica fornecedores nem determina a arquitetura de um agente. Ainda assim, sustenta um princípio importante: risco e capacidade não podem ser avaliados fora do contexto em que a IA será usada.

A Anthropic também recomenda começar pela solução mais simples e customizar as capacidades para o caso de uso. É uma referência de engenharia da própria empresa, não uma regra universal. O valor está no contraste com a venda do agente universal: mais complexidade só merece existir quando melhora um resultado que pode ser avaliado.

O agente não deveria chegar primeiro e procurar uma função depois.

Primeiro vem o trabalho.

Depois, a arquitetura.

É assim que eu prefiro entregar

Na i-9.ai, eu posso partir de componentes, padrões e automações já maduros.

Mas a entrega começa entendendo a operação: conversar com quem executa, localizar o gargalo, levantar requisitos, mapear dados, decisões, exceções e responsabilidade. Só então faz sentido escolher entre processo, integração, automação determinística, IA assistiva, agente ou decisão operacional delimitada.

Esse é o mesmo princípio que apresentei em “Sua empresa não precisa descobrir onde colocar IA”: a tecnologia entra depois que o trabalho travado se torna visível.

Se você recebeu uma proposta de “agente pronto” e quer entender o que existe dentro dela, entre em contato. A conversa pode começar pelo processo, pelos riscos e pelo que precisaria ser provado antes de colocar qualquer sistema em produção.

Não deixe uma implantação ruim definir o futuro

Talvez sua primeira experiência com IA realmente tenha sido ruim.

Talvez o agente tenha inventado, atrapalhado, exigido mais conferência que o processo manual e desaparecido quando encontrou a primeira exceção.

Isso é evidência sobre aquele desenho.

Não é uma prova sobre tudo o que pode ser construído.

Ao mesmo tempo, não aceite que a promessa de “agora vai” seja suficiente para tentar de novo. A segunda experiência precisa começar com um método melhor, critérios mais claros e uma autoridade muito mais delimitada.

Agentes genéricos podem fazer a empresa rejeitar a IA antes de conhecê-la.

O antídoto não é acreditar mais.

É exigir que a solução deixe de ser genérica antes de receber acesso ao que é específico, valioso e real.

Continue lendo

• Sua empresa não precisa descobrir onde colocar IA: como começar pelo gargalo e escolher a menor intervenção suficiente.
• IA não é uma coisa só: modelo, agente, automação e harness: as camadas que uma demonstração costuma esconder.
• A melhor resposta não é a que mais me agrada: por que fontes, pontos cegos, permissões e validações fazem parte da capacidade.

Para se aprofundar

• Agente inteligente: contexto enciclopédico sobre sistemas que percebem um ambiente e agem para alcançar objetivos.
• Levantamento de requisitos: disciplina usada para descobrir, analisar e registrar necessidades, restrições e critérios de um sistema.
• Princípio do menor privilégio: prática de conceder apenas os acessos necessários para uma função.
• Observabilidade: introdução a registros, métricas e rastros usados para compreender sistemas em operação.
• Aversão a algoritmos: panorama do conceito e das pesquisas sobre rejeição a sistemas algorítmicos após erros observados.

Referências e limites de uso

• Dietvorst, Simmons e Massey, “Algorithm Aversion: People Erroneously Avoid Algorithms after Seeing Them Err” (2015): artigo dos autores com experimentos sobre previsões algorítmicas e reação a erros observados. Não estudou agentes generativos, implantação empresarial nem prova que toda primeira experiência ruim produzirá rejeição duradoura.
• NIST, “Artificial Intelligence Risk Management Framework 1.0” (2023): estrutura voluntária para governar, mapear, medir e gerenciar riscos. Apoia a necessidade de documentar contexto e escopo; não avalia ofertas comerciais específicas.
• Anthropic, “Building Effective Agents” (2024): orientação da própria empresa para customizar capacidades, manter simplicidade e adicionar complexidade quando houver ganho demonstrável. Não é comparação independente de fornecedores.

Os exemplos de falha e os sinais de alerta são síntese autoral de riscos de arquitetura. Não acusam um fornecedor específico, não demonstram fraude e não substituem avaliação técnica, jurídica ou de segurança da solução concreta.

A imagem de capa é uma ilustração editorial sintética criada para contrastar um módulo genérico com uma integração adaptada e governada.