Revisão da arquitetura de IA da empresa: ache a camada mais fraca

A revisão da arquitetura de IA da empresa testa cada camada de que um agente depende (modelo, harness, memória, ferramentas, permissões, canais e observabilidade) contra tarefas reais e, ao final, aponta a única camada que explica a maior parte dos resultados ruins. Corrija essa camada primeiro. Melhorar uma camada que já é forte enquanto a fraca continua intacta raramente muda o que o usuário percebe. A revisão exige uma equipe pequena e uma amostra de trabalho real, não uma plataforma nova.

Principais pontos

• Um agente é um sistema de sete camadas, e a qualidade dele é definida pela mais fraca, não pela mais impressionante.
• Parta de tarefas reais que falharam e que deram certo, e leve cada falha até uma camada, em vez de discutir o modelo em abstrato.
• Mude uma camada por vez e teste de novo nas mesmas tarefas, para saber o que de fato alterou o resultado.
• Memória, ferramentas e permissões costumam ser os limites em ambiente empresarial, e custam menos para corrigir do que uma troca de modelo.
• Mantenha um registro escrito curto com achados, responsáveis e datas de reteste, para que a revisão vire hábito e não um evento isolado.

O que a revisão da arquitetura de IA da empresa realmente examina?

Ela examina o sistema inteiro que transforma um pedido em resultado. O modelo é apenas uma parte. Ao redor dele estão o harness (o código e as instruções que rodam o ciclo de trabalho, chamam o modelo e tratam erros), a memória (o que o agente sabe sobre a empresa e sobre trabalhos anteriores), as ferramentas (o que ele pode ler e fazer nos seus sistemas), as permissões (o que ele pode fazer e quem aprova), os canais (onde as pessoas falam com ele) e a observabilidade (como você enxerga o que aconteceu). Se quiser as definições completas antes, Camadas da infraestrutura de IA empresarial: as sete explicadas trata de cada uma.

O modelo leva a culpa primeiro porque é a parte visível. Quando uma resposta vem errada, as pessoas dizem que a IA não é inteligente o bastante. Muitas vezes, porém, o modelo recebeu contexto desatualizado, uma ferramenta mal descrita, uma permissão que bloqueou a última etapa ou um canal que perdeu o anexo. A revisão separa essas causas para que dinheiro e atenção vão para onde o limite realmente está.

A revisão também não é uma auditoria de conformidade nem uma comparação de fornecedores. Ela responde a uma pergunta operacional: qual camada, se melhorada, mais melhoraria o que este agente entrega ao negócio neste trimestre.

Como preparar a revisão?

A preparação decide se os achados serão úteis. Revisar tudo de uma vez gera uma lista longa e nenhuma prioridade. Siga este plano e limite-se a uma função de agente.

• Escolha um agente em uma função, como um agente de triagem de suporte ou um assistente de operações. Revisar vários ao mesmo tempo esconde padrões.
• Reúna uma amostra representativa de tarefas recentes e reais, incluindo as que deram certo, as que falharam e as que as pessoas abandonaram. Não retire nada por ser constrangedor.
• Escreva como é um bom resultado para cada tipo de tarefa, em termos que um líder de operações aceitaria. Avaliação de desempenho de agente de IA: metas, evidências e ajustes ajuda se você ainda não tem critérios.
• Reúna logs, instruções, lista de ferramentas, configurações de permissão e configuração de canais desse agente. Se não conseguir reunir algo, anote isso, pois já é um achado sobre observabilidade ou responsabilidade.
• Indique uma pessoa do negócio que conheça o trabalho e uma que conheça os sistemas. A revisão precisa dos dois olhares na mesma sala.
• Combine de antemão que o resultado é uma lista ordenada de camadas com uma mudança recomendada, não um redesenho.

Como testar cada uma das sete camadas?

Percorra as camadas em sequência e, para cada uma, faça uma pergunta que você consiga responder com evidências da sua amostra. As perguntas abaixo formam um checklist de trabalho.

• Modelo: nas tarefas que falharam, o agente raciocina mal mesmo quando tem os fatos certos, as ferramentas certas e instruções claras? Se a mesma tarefa dá certo quando você entrega o contexto que faltava, o modelo não é o limite.
• Harness: o agente perde o fio em tarefas longas, repete etapas, para cedo ou falha sem tentar de novo um erro recuperável? Verifique como ele trata tempos esgotados, resultados parciais e tarefas que se estendem por várias sessões.
• Memória: o agente conhece as políticas atuais, os detalhes do produto, o histórico do cliente e os nomes que a empresa usa, e sabe quando seu conhecimento está desatualizado? Procure respostas fluentes porém erradas sobre a sua empresa e contexto empilhado em excesso, que enterra a parte útil. A orientação da Anthropic sobre engenharia de contexto para agentes é uma boa referência para essa camada.
• Ferramentas: nomes, descrições e entradas das ferramentas são claros o bastante para que um colega novo as use corretamente? Procure ferramenta errada escolhida, entradas malformadas, mensagens de erro vagas e ferramentas que devolvem muito mais dados do que a tarefa pede. A orientação da Anthropic sobre como escrever ferramentas para agentes descreve esses padrões de falha.
• Permissões: o agente tem o menor acesso que ainda lhe permite concluir o trabalho, e toda ação sensível passa por uma aprovação que você sabe nomear? Verifique acessos amplos demais e também estreitos demais, que obrigam as pessoas a colar dados à mão. A orientação de autorização da OWASP apoia o princípio do menor privilégio e da negação por padrão.
• Canais: as pessoas chegam ao agente onde já trabalham, e o contexto chega intacto (anexos, histórico da conversa, quem está pedindo)? Pouco uso costuma ser problema de canal, não de inteligência.
• Observabilidade: você consegue reconstruir, para qualquer tarefa, o que o agente recebeu como pedido, o que buscou, quais ferramentas chamou e o que devolveu? O material introdutório do OpenTelemetry sobre observabilidade explica os rastros, as métricas e os logs que tornam isso possível.

No caso das permissões, uma checagem recorrente é mais fácil de sustentar do que uma análise profunda única. Revisão trimestral de IA na empresa: manter, corrigir ou encerrar mostra como manter esse ritmo leve.

Como saber qual camada é o limite real?

Os sintomas se sobrepõem, então use um guia de decisão e depois confirme com uma mudança controlada. Leia cada linha como um padrão na sua amostra.

• O agente é fluente, mas erra sobre a sua empresa: suspeite primeiro da memória e, depois, da busca de informações dentro do harness.
• O agente sabe a resposta certa, mas não consegue concluir o trabalho: suspeite das ferramentas ou das permissões.
• O agente começa bem e piora em tarefas longas ou de várias etapas: suspeite do harness e de como o contexto é levado de uma etapa à outra.
• O agente acerta, mas ninguém usa: suspeite dos canais, depois da confiança e, por fim, do treinamento.
• O agente comete o mesmo tipo de erro repetidamente e ninguém percebeu por semanas: suspeite da observabilidade e da avaliação, não do modelo.
• O agente vai bem nos casos fáceis e falha nos que exigem julgamento, mesmo com contexto completo e ferramentas claras: aí o modelo é um limite plausível.

Em seguida, faça uma mudança controlada. Escolha a camada suspeita, altere somente ela e rode de novo a mesma amostra de tarefas. Se os resultados melhorarem, você achou o limite. Se nada mudar, o diagnóstico estava errado, e isso também é útil. Trocar o modelo, as instruções e o conjunto de ferramentas ao mesmo tempo não diz nada sobre qual deles importou.

Como é uma revisão na prática? Um cenário ilustrativo

Este cenário é ilustrativo, não um caso real de cliente. Uma distribuidora de médio porte tem um agente que redige respostas a dúvidas de fornecedores. A equipe diz que ele não é confiável, e a diretoria considera trocar de modelo.

A revisão toma uma amostra de tarefas recentes e rastreia cada falha. A maioria dos rascunhos ruins cita uma política de entrega desatualizada, porque o agente lê um documento que foi substituído meses antes e ninguém é responsável por atualizá-lo. Isso aponta para a memória. Um segundo grupo de falhas acontece quando o agente tenta consultar o status de um pedido, mas a ferramenta devolve um erro ilegível, e ele acaba chutando. Isso aponta para as ferramentas. Um terceiro grupo, pequeno, reúne erros reais de julgamento em disputas incomuns, que podem ser do modelo.

A equipe corrige a fonte da política e designa um responsável, reescreve a ferramenta de pedidos para que seus erros sejam claros e acionáveis, e roda de novo a mesma amostra. A maior parte das falhas desaparece sem nenhuma troca de modelo. Os poucos casos de julgamento que sobram são encaminhados a uma pessoa por uma regra de aprovação. A diretoria passa a ter evidências de onde aplicar o próximo esforço, e a discussão sobre o modelo é adiada com um motivo claro.

Como a Be Human trata isso em um serviço gerenciado?

A Be Human trata a revisão por camadas como parte da operação de um agente, não como um projeto separado. O primeiro trabalho define uma função útil, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável, o que dá à revisão algo concreto para medir. A operação gerenciada inclui monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões e melhorias controladas, de modo que os achados por camada alimentem um ciclo regular de mudanças em vez de uma lista que envelhece. As mudanças passam por uma etapa de aprovação com responsável, e a empresa mantém o controle da identidade, da memória, dos canais, das ferramentas e das permissões do agente. Como melhorar a IA que a empresa já usa: auditoria passo a passo trata de uma auditoria parecida, caso você prefira conduzi-la por conta própria.

O que fazer depois da revisão?

Transforme os achados em um conjunto pequeno de decisões. Escolha a camada com maior efeito sobre os resultados que importam, nomeie um responsável e descreva a mudança em uma frase. Anote ao lado a data do reteste, usando a mesma amostra de tarefas para que a comparação seja justa.

Mantenha um registro curto com quatro campos para cada achado: a camada, a evidência da amostra, a mudança feita e o resultado após o reteste. Esse registro evita que a mesma discussão volte em três meses e dá a um novo responsável um histórico confiável caso quem conduziu a revisão mude de função.

Repita a revisão quando algo relevante mudar: um novo modelo, uma nova integração, um novo canal, um novo grupo de usuários ou um novo tipo de tarefa. Entre uma revisão e outra, observe sinais precoces, como aumento de correções manuais, tarefas abandonadas no meio e aprovações que as pessoas clicam sem ler. Esses sinais costumam aparecer antes de a falha ficar visível para os clientes.

Por fim, resista à vontade de corrigir tudo de uma vez. Uma revisão que produz uma melhoria clara e testada vale mais do que uma que produz um roteiro longo que ninguém consegue sequenciar.

Perguntas frequentes

Com que frequência devemos fazer a revisão da arquitetura de IA da empresa? Faça uma passagem completa quando um agente entrar em operação, depois de qualquer mudança importante em modelos, ferramentas ou canais, e em um calendário regular que acompanhe a velocidade com que o seu trabalho muda. Entre as revisões completas, mantenha checagens leves de permissões e de tarefas que falharam, para que os problemas apareçam cedo.

Podemos fazer a revisão internamente ou precisamos de ajuda externa? Uma equipe interna capaz consegue conduzi-la se tiver alguém que conheça o trabalho do negócio e alguém que conheça os sistemas, e se estiver disposta a olhar as falhas com honestidade. A ajuda externa é mais útil quando falta visibilidade sobre os logs, quando a responsabilidade pelas camadas não está clara ou quando você quer uma segunda opinião sobre as escolhas e suas trocas.

O modelo costuma ser a camada mais fraca? Em ambiente empresarial, ele é o limite com menos frequência do que as pessoas imaginam. Conhecimento da empresa ausente ou desatualizado, ferramentas pouco claras, permissões amplas ou estreitas demais e pouca visibilidade sobre o comportamento causam muitas falhas que parecem fraqueza do modelo. Teste as outras camadas com tarefas reais antes de pagar por uma troca de modelo.

E se não conseguimos ver o que o agente fez e, por isso, não conseguimos rastrear as falhas? Trate isso como o primeiro achado. Sem registros dos pedidos, do contexto recuperado, das chamadas de ferramentas e das respostas, todas as outras camadas viram suposição. Comece incluindo essa visibilidade e depois rode a revisão na próxima amostra de tarefas.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.