Antes de perguntar qual inteligência artificial (IA) comprar, vale perguntar por que ainda existe uma etapa que ninguém sabe defender sem começar a frase com “sempre fizemos assim”.
TL;DR
Nem todo gargalo merece inteligência artificial. Às vezes ele pede que uma etapa seja removida; outras vezes, simplificada, padronizada ou automatizada com uma regra comum. IA assistiva entra quando linguagem, ambiguidade ou volume realmente exigem interpretação. Um agente entra quando o caminho varia, há ferramentas para usar e a autonomia está delimitada. Diagnóstico vem antes da ferramenta porque acelerar um processo ruim só produz um processo ruim em alta velocidade — e com uma apresentação bem mais cara.
Tem um ritual corporativo que se repete com uma confiança impressionante.
Alguém encontra uma fila, um retrabalho, uma planilha que ninguém entende ou uma pessoa que passou a vida inteira copiando dado de uma tela para outra. A empresa então olha para a cena, inspira fundo e anuncia a solução contemporânea:
“Precisamos colocar IA nisso.”
Talvez precise.
Mas talvez a operação precise parar de pedir que alguém imprima, confira, assine, escaneie e reenvie um documento que já nasceu digital. Talvez precise de uma regra clara. Talvez precise que dois sistemas conversem. Talvez precise assumir que a etapa existe apenas porque uma decisão provisória de 2017 criou raízes e ninguém teve coragem de perguntar por quê.
Colocar IA sobre isso pode ser usar uma bazuca para matar uma mosca. A mosca até morre. O escritório também deixa de ter janela.
Não escrevo isso para transformar “não usar IA” em pose de sobriedade técnica. Eu trabalho justamente construindo software, automação e sistemas assistidos por IA. O ponto é outro: tecnologia é escolha de como organizar as partes de um sistema, as conexões entre elas e suas responsabilidades — a arquitetura de software. Não é selo de modernidade. E essa arquitetura começa entendendo o problema que existe, não celebrando a ferramenta que acabou de aparecer no vídeo de demonstração.
O problema não é a ferramenta. É a pergunta preguiçosa
No artigo Sua empresa não precisa descobrir onde colocar IA, eu defendi começar pelo lugar onde o trabalho trava. Este texto dá um passo anterior: antes de decidir onde a IA entra, precisamos decidir se ela deveria entrar.
Porque “onde colocamos IA?” muitas vezes é uma forma elegante de evitar perguntas menos fotogênicas:
- qual resultado esta etapa produz de verdade?
- quem usa esse resultado — e o que acontece se ele atrasar ou vier errado?
- que decisão a etapa sustenta?
- o que muda se ela simplesmente deixar de existir?
- a regra já é conhecida ou estamos chamando confusão de inteligência?
Uma ferramenta pode esconder essas perguntas por algum tempo. Não consegue respondê-las no nosso lugar.
Quando a resposta é “ninguém sabe, mas sempre foi assim”, ainda não temos um caso de IA. Temos uma investigação.
A ordem de intervenção que evita teatro tecnológico
Eu costumo pensar em seis saídas possíveis. Elas não são uma escada obrigatória; um processo pode combinar mais de uma. Mas a ordem ajuda a não transformar complexidade em currículo.
1. Eliminar
A pergunta mais subestimada de uma reunião de processo é: isso precisa existir?
Uma aprovação duplicada, um relatório que ninguém lê, uma cópia manual feita “por segurança” e uma conferência criada para compensar outro erro podem parecer pequenos. Juntos, viram um departamento informal de manutenção de passado.
Eliminar uma etapa não é preguiça. É desenho de processo. Se ela não protege um risco, não produz uma decisão, não atende uma obrigação real e não entrega valor a ninguém, a solução mais elegante pode ser aposentá-la.
Não há sistema treinado para processar e produzir texto — um modelo de linguagem — que supere uma tarefa que deixou de existir.
2. Simplificar
Às vezes a etapa tem motivo, mas foi ficando rebuscada porque cada exceção ganhou um remendo. A pessoa preenche cinco campos para alguém descobrir depois que só precisava de dois. O formulário pede uma descrição longa para terminar em “urgente”. O fluxo atravessa três sistemas porque ninguém teve tempo de definir onde a informação deve ser mantida como referência — a chamada fonte de verdade.
Simplificar é reduzir passos, campos, aprovações e transferências entre pessoas ou sistemas até restar o necessário. Não é empobrecer controle. É deixar o controle proporcional ao risco.
Usar uma faca para apertar um parafuso pode funcionar num aperto. Construir o processo inteiro em volta da faca é só uma maneira criativa de garantir que alguém se machuque depois.
3. Padronizar
Há trabalho que parece complexo apenas porque cada pessoa faz de um jeito.
Padronizar significa explicitar entrada, critério, responsável, exceção e saída. É definir o que “pedido pronto” significa antes de criar uma IA para adivinhar se o pedido está pronto. É registrar a política antes de pedir que um agente a aplique. É decidir onde a informação vive antes de criar busca sobre cinco versões conflitantes dela.
Padronização não exige que toda situação fique rígida. Ela separa o caminho comum da exceção que merece análise humana.
4. Automatizar com regra
Quando entrada, regra e saída são conhecidas, a melhor resposta geralmente é um sistema que executa a mesma regra para as mesmas condições — uma automação determinística.
Se o pagamento foi confirmado, atualize o status. Se falta um campo obrigatório, bloqueie o envio. Se o prazo venceu, avise o responsável. Se a cópia de segurança (backup) terminou, registre o resultado.
Não precisamos de IA para somar valores, transferir dados entre sistemas ou validar uma condição objetiva. Usar um sistema que escolhe saídas por probabilidades calculadas a partir de padrões aprendidos, em vez de apenas executar uma regra fixa — um modelo probabilístico — nessa situação pode deixar o resultado menos previsível, mais difícil de testar e mais caro de operar. É impressionante do mesmo jeito que uma torradeira com painel de avião é impressionante: alguém claramente trabalhou muito, mas continua sendo só uma torrada.
5. Usar IA como assistência
IA passa a fazer sentido quando existe linguagem, ambiguidade ou volume que uma regra isolada não resolve bem.
Ela pode resumir um histórico longo, extrair campos de documentos variados, classificar solicitações, comparar versões de texto, localizar informação relevante ou montar uma primeira análise para uma pessoa revisar.
Aqui a IA não recebe autoridade para “resolver tudo”. Ela reduz trabalho cognitivo, organiza material e melhora a próxima decisão. A pessoa continua responsável pelo que importa; a ferramenta ajuda a pessoa a enxergar melhor.
Esse desenho é especialmente útil quando a resposta precisa lidar com contexto, mas o efeito ainda exige revisão humana. É assistência, não abdicação.
6. Usar um agente, mas com contrato
Um agente de IA não é um chatbot com coragem. É um sistema que combina contexto, ferramentas e critérios para escolher próximos passos dentro de um espaço delimitado.
Ele pode consultar dados, reunir evidências, preencher formulários e registros, abrir uma tarefa, pedir uma informação ausente ou executar uma ação permitida. O caminho pode variar conforme o caso; por isso o controle precisa aumentar junto.
Antes de dar esse passo, eu quero saber:
- quais ferramentas o agente pode usar;
- que ações ele jamais pode executar sozinho;
- quando ele deve parar e pedir ajuda;
- como registra o que consultou e fez;
- como corrigimos ou desfazemos uma ação;
- quem responde quando o resultado não vier como esperado.
Sem isso, “agente autônomo” costuma ser só um nome elegante para “ninguém desenhou a responsabilidade ainda”.
Um exemplo menos glamouroso — e muito mais útil
Imagine uma equipe que recebe pedidos por e-mail. Alguém lê, copia dados para uma planilha, pergunta por mensagem se há estoque, espera a resposta, atualiza outro sistema e envia uma confirmação padrão.
A reação apressada seria: “vamos criar um agente de IA para cuidar dos pedidos”.
O diagnóstico pode revelar outra coisa:
- metade dos pedidos poderia passar a usar um formulário que preenchesse os campos corretamente;
- o estoque tem uma interface de programação de aplicações (API), isto é, uma forma documentada de um sistema consultar outro, e não precisa de alguém perguntando no chat interno;
- a confirmação padrão pode ser disparada por regra;
- só os pedidos com descrição ambígua ou exceção comercial precisam de interpretação;
- apenas a exceção realmente relevante precisa chegar a uma pessoa.
O desenho final pode ter formulário melhor, integração de estoque, automação comum, IA assistiva para interpretar texto livre e uma fila humana para exceções. Talvez nem exista agente executor.
Isso não é uma derrota para a IA. É uma vitória para a operação.
O objetivo não é instalar o componente mais vistoso. É remover espera, erro e trabalho inútil sem criar um novo bicho para alimentar.
A ferramenta errada cobra juros
Todo sistema carrega custo de operação: credenciais, integração, dados, monitoramento, falhas, manutenção, treinamento, mudanças de fornecedor e gente que precisa entender o que fazer quando alguma coisa sai do script.
Uma solução excessiva pode resolver o sintoma inicial e criar outro gargalo ao redor dela. O processo que antes tinha uma planilha ruim passa a ter uma planilha ruim, um agente sem contexto, uma integração instável, três assinaturas mensais e uma reunião semanal para descobrir por que ele respondeu “com certeza” a uma hipótese inventada.
Isso não é argumento contra experimentar. Experimentação pequena, reversível e medida é como aprendemos. Mas protótipo não vira operação por osmose. Quando algo passa a interferir em cliente, dinheiro, dado pessoal, acesso ou decisão relevante, ele precisa de dono, critério, observabilidade — sinais que permitem entender o que o sistema fez e diagnosticar falhas — e limite.
O AI Risk Management Framework do Instituto Nacional de Padrões e Tecnologia dos Estados Unidos (NIST) é voluntário e não dita a arquitetura de uma empresa. Ele sustenta algo mais básico: risco de IA precisa ser considerado no desenho, desenvolvimento, uso e avaliação do sistema. Não basta admirar o modelo; é preciso governar o efeito que ele produz.
A pergunta que eu faria antes de qualquer demo
Se eu estiver conversando com uma empresa sobre IA, não começo pedindo acesso à conta de algum fornecedor. Começo tentando localizar o trabalho real.
Pergunto onde as pessoas esperam. Onde repetem. Onde precisam procurar informação. Onde a decisão se apoia em memória. Onde uma exceção se torna incêndio. Onde alguém faz uma etapa que conseguiria explicar — mas não consegue justificar.
Depois vem a pergunta que desmonta muita ansiedade:
Se tirássemos a IA da sala por cinco minutos, o que ainda precisaríamos resolver?
Essa resposta é o material da arquitetura.
Às vezes ela aponta para uma integração simples. Às vezes para uma política melhor. Às vezes para uma automação. Às vezes para IA assistiva. Às vezes para um agente com limites claros. E, sim, às vezes aponta para uma etapa idiota que só precisava de uma despedida educada.
Na i-9.ai, eu começo por esse diagnóstico: entender o que trava, o que precisa ser preservado e qual é a menor arquitetura capaz de produzir um resultado verificável.
Se você tem um processo que parece pedir IA, mas suspeita que ele só esteja pedindo atenção, entre em contato. Pode trazer a planilha feia. Ela costuma contar mais verdade que a demonstração bonita.
Continue lendo
- Sua empresa não precisa descobrir onde colocar IA: o mapa maior para escolher processo, automação, IA assistiva, agente ou decisão humana.
- Agentes genéricos podem ser seu pior primeiro contato com IA: por que solução pronta sem contexto costuma decepcionar antes de ajudar.
- IA não é só um gerador de conteúdo para redes sociais: uma visão mais ampla do que a IA pode fazer depois que existe um problema real para resolver.
Referências e limites de uso
- OpenTelemetry — o que é o OpenTelemetry? (What is OpenTelemetry?): documentação oficial sobre sinais de telemetria, como rastros, métricas e registros de eventos (
logs), usados para entender sistemas em execução. Apoia a explicação de observabilidade; não impõe uma ferramenta ou implementação específica. - NIST — estrutura de gestão de riscos de IA (AI Risk Management Framework): referência oficial para gestão voluntária de riscos associados a sistemas de IA. Sustenta a necessidade de considerar risco no ciclo de vida; não prescreve a ordem de intervenção proposta neste artigo nem certifica uma implementação.
Os exemplos são hipóteses de arquitetura para tornar os critérios visíveis. Não são estudos de caso, promessa de resultado ou substituição de diagnóstico técnico, jurídico, financeiro, trabalhista ou de segurança no contexto real.

Conversa aberta
Continue a conversa
Discordou, encontrou uma lacuna ou tem uma experiência que amplia o assunto? Comente usando sua conta do GitHub. Não publique dados pessoais, credenciais ou informações sensíveis.