Arquitetura empresarial para agentes de IA: onde cada peça fica

A arquitetura empresarial para agentes de IA é a prática de posicionar cada componente do agente (o modelo, o harness que o executa, sua memória, suas ferramentas, suas permissões e sua observabilidade) dentro dos sistemas que a empresa já opera. O agente se conecta às identidades, aos dados e aos sistemas de negócio existentes por meio de interfaces definidas, em vez de virar uma pilha paralela que copia tudo isso. Na maioria das empresas, o trabalho é mapear e definir limites, não reconstruir.

Principais pontos

• Trate o modelo como um componente substituível atrás de uma interface estável, e não como a própria arquitetura.
• Posicione o harness, a memória e as ferramentas nas bordas dos sistemas que você já mantém, e dê a cada um deles um responsável nomeado.
• Busque as permissões no provedor de identidade e nos sistemas de registro, nunca em uma cópia guardada dentro do agente.
• Faça a observabilidade registrar o que o agente viu, o que fez e o que estava autorizado a fazer, em logs que a empresa controla.
• Comece posicionando um único papel no mapa e amplie o escopo somente quando as evidências desse papel se sustentarem.

Comece pelo mapa que você já tem

A maioria das empresas já tem uma arquitetura: um provedor de identidade, um repositório de documentos, um sistema de clientes ou de chamados, um sistema financeiro, um data warehouse, uma camada de integração e pessoas que aprovam mudanças. Antes de nomear qualquer componente do agente, liste esses sistemas e seus responsáveis. Depois, para cada informação de que um agente precisaria, anote qual sistema é a fonte da verdade. Essa lista é mais útil do que qualquer comparação de produtos, porque todas as decisões seguintes (o que o agente pode ler, o que pode gravar, para onde vão os logs) dependem dela.

Uma versão de uma página desse mapa ajuda líderes a enxergar o quadro inteiro de uma vez. O método está descrito em Revisão da arquitetura de IA da empresa: ache a camada mais fraca, e ele funciona bem como primeira sessão de trabalho com as pessoas que são donas desses sistemas.

Onde ficam o modelo, o harness e a memória

O modelo é o serviço de inferência que produz linguagem e decisões. O harness é o software em volta dele: carrega as instruções, chama o modelo, executa o ciclo de passos, aplica limites como número máximo de passos e tempo limite, e trata as falhas. A orientação de engenharia da Anthropic sobre agentes de longa duração descreve essa estrutura como a parte que mantém o trabalho coerente entre sessões. Na empresa, o harness deve rodar no seu próprio ambiente de execução, junto da camada de integração, e não apenas dentro da janela de chat de um fornecedor. Essa posição permite trocar o modelo no futuro sem reescrever a lógica do negócio.

A memória exige mais cuidado do que a maioria das equipes espera. Separe três coisas. A primeira é o contexto fornecido para uma tarefa, que deve ser tão pequeno quanto a tarefa exige. A segunda é a recuperação, em que o agente consulta documentos da empresa no momento da pergunta, em vez de mantê-los permanentemente. A geração aumentada por recuperação (RAG, na sigla em inglês) é o padrão mais comum aqui, e ela deve consultar o repositório de documentos que você já tem, sob as regras de acesso que já existem. A terceira é a memória persistente, como anotações que o agente guarda entre sessões. A memória persistente é um armazenamento de dados, então precisa de um responsável, de uma regra de retenção e de um procedimento de exclusão. Se isso não estiver escrito, a memória vira, sem alarde, um banco de dados sem gestão.

Ferramentas e permissões: ferramentas enxutas com permissões herdadas

Ferramentas são as funções que o harness expõe ao modelo: consultar o status de um pedido, rascunhar uma resposta, criar uma solicitação de compra para aprovação. Cada ferramenta deve ser estreita, com nome claro, poucos campos de entrada e uma única finalidade. Envolva uma API existente em vez de expor um banco de dados inteiro. O Model Context Protocol oferece um jeito padrão de descrever ferramentas e recursos para o modelo, o que reduz código de cola sob medida, mas ele não decide quem pode usá-los. Essa decisão continua com o seu modelo de permissões.

O agente deve aparecer no provedor de identidade como uma identidade própria, não humana, com papéis restritos e, quando possível, concessões que expiram. A orientação de autorização da OWASP aponta para verificar o acesso em cada requisição e negar por padrão. Cada ferramenta deve corresponder a uma permissão na sistema de origem, e toda ação de escrita deve indicar a pessoa que a aprova. O conteúdo que o agente lê em e-mails, documentos ou páginas da web é dado, não instrução, e a orientação da OWASP sobre prevenção de injeção de prompt explica por que essa separação precisa ser garantida na arquitetura, e não apenas pedida no prompt.

• Dê ao agente identidade própria, nunca um login compartilhado de funcionário.
• Relacione cada ferramenta a uma permissão existente no sistema de origem.
• Separe ferramentas de leitura de ferramentas de escrita, e exija aprovação para toda ferramenta de escrita.
• Negue por padrão e registre um responsável e uma data de expiração para cada concessão.
• Trate textos de fontes externas como dados e mantenha-os fora do caminho das instruções.

Cenário ilustrativo: um distribuidor com algumas dezenas de funcionários quer que um agente responda perguntas sobre o status de pedidos. O agente recebe uma ferramenta de leitura no sistema de pedidos existente, que devolve apenas os campos de status, e uma ferramenta de rascunho que prepara uma resposta para um funcionário enviar. Nenhuma ferramenta grava no sistema de pedidos na primeira fase. Quando a equipe quiser, depois, que o agente atualize datas de entrega, essa mudança será uma nova ferramenta, com regra de aprovação própria, revisada antes de entrar em produção.

Observabilidade: registre o que o agente viu e fez

A observabilidade responde à pergunta que todo líder de operações acaba fazendo: por que o agente fez aquilo? Os conceitos gerais do OpenTelemetry (traces que acompanham os passos, métricas ao longo do tempo e logs com contexto) se aplicam diretamente a agentes. Cada execução deve ter um identificador. O registro deve mostrar a versão do modelo, as ferramentas chamadas com argumentos resumidos, as aprovações solicitadas e concedidas, os erros e as tentativas, e o resultado final. Guarde esses logs na pilha de observabilidade da própria empresa, para que uma auditoria não dependa de um painel do fornecedor que você não consegue exportar.

Os logs, sozinhos, não provam qualidade. Combine-os com um conjunto fixo de casos de teste que representem pedidos reais, e rode esses testes após cada mudança. O guia de avaliações (evals) da OpenAI e as notas da Anthropic sobre avaliação de agentes descrevem esse padrão: definir o comportamento esperado, pontuar os resultados e repetir as mesmas verificações quando o modelo, o prompt ou as ferramentas mudarem. Reduza o conteúdo sensível nos logs. Você precisa de detalhe suficiente para explicar uma decisão, não de uma cópia de todos os registros de clientes que o agente tocou.

Um plano de posicionamento que você pode executar neste trimestre

A arquitetura se torna concreta quando é escrita como uma sequência. Os passos abaixo são uma ordem prática para o primeiro posicionamento.

• Faça o inventário dos sistemas existentes, de seus responsáveis e da fonte da verdade de cada informação que o agente precisa.
• Defina o único papel que o agente vai ocupar e liste as decisões que ele pode tomar sem perguntar a ninguém.
• Posicione cada componente: o modelo atrás de uma interface, o harness no seu ambiente de execução, a recuperação sobre os repositórios existentes, as ferramentas como invólucros enxutos e a identidade vinda do provedor.
• Escreva o limite de aprovação de cada ação de escrita e nomeie a pessoa que a concede.
• Defina o critério de sucesso observável, junto com os logs e casos de teste que vão mostrar se ele foi atingido.
• Rode o agente com um grupo pequeno de usuários, revise os logs em uma agenda fixa e amplie o escopo somente por meio de uma mudança registrada.

Cada passo produz um documento que um futuro auditor, engenheiro ou gestor novo consegue ler. Esse é o resultado real do trabalho de arquitetura empresarial nesta etapa.

Como a Be Human trabalha isso na prática

A Be Human projeta, implanta e opera infraestrutura de IA personalizada para empresas, com agentes que mantêm sob controle humano sua identidade, memória, canais, ferramentas, permissões e contexto operacional. Um primeiro projeto define um papel útil, a memória e as ferramentas de que ele precisa, seus limites de aprovação e um critério de sucesso observável, e depois posiciona esses componentes dentro dos sistemas que a empresa já usa. A operação gerenciada pode incluir monitoramento, avaliações recorrentes, manutenção das integrações, revisão de permissões, resposta a incidentes e melhorias controladas. Mudanças de escopo passam por um pedido documentado, para que o posicionamento continue visível para as pessoas que são donas dele. O serviço é remoto e disponível em inglês e português.

Escolhendo a primeira tarefa a posicionar

A melhor primeira tarefa costuma ser repetitiva e bem documentada, com um responsável claro, um conjunto limitado de sistemas e um resultado que alguém consiga verificar em uma semana. Procure trabalhos em que a fonte da verdade seja clara e os erros sejam fáceis de pegar antes de chegarem a um cliente. Se você quer ajuda para identificar essa primeira tarefa, o diagnóstico gratuito de IA da Be Human é um bom ponto de partida.

Perguntas frequentes

Um agente de IA precisa de uma arquitetura separada do resto da empresa? Geralmente não. Um agente bem posicionado usa o provedor de identidade, os repositórios de documentos, os sistemas de negócio e os registros que já existem, e acrescenta um número pequeno de componentes novos, como o harness, a recuperação e os invólucros de ferramentas. Montar uma pilha paralela tende a duplicar permissões e criar cópias de dados difíceis de governar.

O modelo deve rodar na nossa própria nuvem ou com o fornecedor? A resposta depende da sensibilidade dos dados, dos termos do contrato e da capacidade interna da empresa, e deve ser decidida carga de trabalho por carga de trabalho, não uma vez para a empresa inteira. Mantenha o modelo atrás de uma interface para que a escolha possa mudar sem reescrever a lógica de negócio. Documente onde cada carga de trabalho roda e quais dados ela recebe.

Quem é o dono das permissões de um agente depois do lançamento? Um responsável de negócio nomeado deve ser dono do papel e dos seus limites de aprovação, enquanto a equipe técnica mantém os invólucros de ferramentas e a configuração de identidade. As permissões devem ser revisadas em uma agenda fixa, e toda concessão deve ter um responsável e uma data de expiração. Sem essa revisão, o acesso tende a acumular além do que o papel precisa.

O que devemos registrar para provar que um agente se comportou corretamente? Registre um identificador de execução, a versão do modelo, as ferramentas chamadas com argumentos resumidos, as aprovações solicitadas e concedidas, os erros e o resultado final. Combine esses logs com um conjunto fixo de casos de teste que reflitam pedidos reais, e rode-os novamente após cada mudança. Mantenha conteúdo sensível fora dos logs, a menos que ele seja necessário para explicar uma decisão.

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