Camadas da infraestrutura de IA empresarial: as sete explicadas

As camadas da infraestrutura de IA empresarial são as responsabilidades separadas que, juntas, permitem que um agente de IA faça um trabalho confiável dentro de uma empresa: um modelo que raciocina, um harness que executa o trabalho, memória, ferramentas, permissões, canais e observabilidade. Cada camada responde a uma pergunta diferente, e a maioria das falhas acontece quando uma camada é chamada a fazer o trabalho de outra. Trate as sete como partes que você pode inspecionar, ter sob responsabilidade de alguém e substituir, e não como um produto único.

Principais pontos

• As sete camadas são modelos, harness, memória, ferramentas, permissões, canais e observabilidade, e cada uma responde a uma pergunta diferente sobre como o agente funciona.
• O modelo raciocina, mas quem decide como o trabalho é executado é o harness. Por isso, boa parte da confiabilidade de um agente vem das camadas ao redor do modelo.
• Memória, ferramentas e permissões devem ter dono e ser revisadas por pessoas, porque definem o que o agente sabe, no que pode mexer e o que tem autorização para fazer.
• Canais e observabilidade ligam o agente à sua equipe: um é por onde o trabalho chega e sai, o outro é como você mostra o que aconteceu.
• Diagnostique os problemas por camada. Uma resposta errada geralmente aponta para uma camada que deveria ter barrado o erro, e a correção raramente exige trocar de modelo.

Quais são as sete camadas da infraestrutura de IA de uma empresa?

Quando uma empresa diz que usa IA, muitas vezes quer dizer que tem uma janela de chat ligada a um modelo. Isso é uma camada. Um agente que executa tarefas reais precisa também do restante da estrutura, mesmo que algumas camadas comecem pequenas. Cada uma em uma linha:

• Modelos: a capacidade de raciocínio e linguagem que lê a entrada e propõe o próximo passo.
• Harness: o ambiente de execução que monta o contexto, chama o modelo, roda ferramentas, trata novas tentativas e decide quando parar.
• Memória: o conhecimento durável que o agente mantém sobre a empresa, as pessoas, as decisões e o trabalho em andamento.
• Ferramentas: ações e consultas definidas que o agente pode executar em outros sistemas.
• Permissões: as regras sobre o que o agente pode ler, redigir ou enviar, e quando uma pessoa precisa aprovar.
• Canais: os lugares em que as pessoas falam com o agente e recebem o trabalho dele, como e-mail, chat da equipe ou aplicativos de mensagem.
• Observabilidade: o registro que mostra o que o agente viu, decidiu e fez.

Por que separar? Porque a separação torna cada parte testável e substituível. Se um modelo melhora, você o adota sem reescrever suas regras de aprovação. Se um sistema muda a forma de login, só a camada de ferramentas precisa de atenção. E, quando algo dá errado, você pergunta qual camada falhou, em vez de discutir se a IA é boa ou ruim.

Uma definição mais ampla dessa abordagem está no texto Infraestrutura de IA personalizada para empresas: o que é?. O restante deste artigo trata das camadas em si.

Modelos e harness: quem pensa e quem conduz o trabalho?

O modelo é a parte que a maioria das pessoas imagina quando ouve falar de IA. Ele lê texto, imagens ou dados estruturados e produz uma resposta ou um próximo passo sugerido. É capaz, mas sozinho não tem conhecimento persistente da sua empresa, não consegue agir e não sabe o que lhe é permitido fazer. Ele também muda com o tempo: os fornecedores lançam novas versões, e um modelo adequado para uma tarefa pode ser caro demais ou fraco para outra. Trate o modelo como um componente substituível, atrás de uma interface estável, e não como a base de todo o sistema.

O harness é o ambiente de execução em volta do modelo. Ele decide o que entra em cada requisição, quais instruções valem, quais ferramentas são oferecidas, o que acontece quando uma ferramenta falha, quando salvar o progresso e quando parar para perguntar a uma pessoa. É onde ficam as regras de operação do agente. O artigo Modelo, agente e harness de IA: qual é a diferença? separa os três termos em mais detalhe.

Um teste útil: se você trocasse o modelo por outro, o trabalho manteria o mesmo formato? Quando o harness cumpre seu papel, a resposta é quase sempre sim. Instruções, condições de parada, pontos de retomada e limites de aprovação ficam no harness, então sobrevivem à troca, e você reavalia a qualidade em vez de reconstruir o sistema. A orientação de engenharia da Anthropic sobre como construir agentes eficazes aponta na mesma direção: comece com padrões simples e combináveis e só acrescente complexidade quando ela claramente ajudar.

O que a camada de memória deve guardar?

Memória é o que permite ao agente continuar o trabalho em vez de recomeçar do zero toda manhã. É também a camada mais confundida com histórico de chat. Uma transcrição registra o que foi dito. A memória registra o que ainda deve ser verdade amanhã: um cliente prefere respostas formais, uma exceção foi aprovada por uma pessoa identificada, um projeto está esperando um documento assinado. A diferença é tratada em Memória de IA ou histórico de chat: o que guardar?.

Uma boa memória tem quatro propriedades:

• Fonte: cada registro aponta de volta para sua origem, seja um documento, uma mensagem ou uma decisão.
• Dono: uma pessoa ou função é responsável por corrigi-lo.
• Escopo: ele só é visível para o trabalho e para os clientes a que pertence.
• Atualidade: ele pode expirar ou ser marcado como substituído.

Sem isso, a memória vira uma fonte silenciosa de erros. Um agente que repete com segurança uma política que mudou não está inventando nada. Está lembrando fielmente de algo que ninguém atualizou.

A memória inclui ainda a identidade e o contexto de operação do próprio agente: seu papel, tom, limites e o trabalho pelo qual responde. Escrever isso uma vez, em um lugar que as pessoas possam ler e corrigir, custa menos do que redescobrir tudo por meio de erros.

Como ferramentas e permissões trabalham juntas?

Ferramentas são o modo como o agente alcança qualquer coisa fora da conversa: buscar em um CRM, ler uma agenda, redigir um e-mail, criar uma tarefa. Cada ferramenta deve ter um propósito estreito, entradas claras, saídas previsíveis e uma mensagem de erro sobre a qual o agente consiga agir. Padrões como o Model Context Protocol ajudam os sistemas a expor ferramentas de forma consistente, mas um padrão não decide quais ferramentas o seu agente deve ter. Essa é uma decisão de negócio.

Permissões são separadas das ferramentas, e essa separação importa. A ferramenta descreve o que é possível. A permissão descreve o que é permitido, para este agente, sobre estes dados, neste momento. As permissões devem ser aplicadas pelos sistemas aos quais a ferramenta se conecta, e não por uma frase nas instruções pedindo que o modelo se comporte. A orientação de autorização da OWASP descreve o mesmo princípio para software em geral: negar por padrão e verificar a cada requisição.

Uma forma prática de definir permissões é dividir cada capacidade em três níveis:

• Ler: consultar informações. Em geral, o ponto de partida mais seguro.
• Preparar: redigir uma mensagem, uma alteração de registro ou um documento para uma pessoa revisar.
• Enviar ou gravar: alterar algo fora do espaço de trabalho do próprio agente, o que muitas vezes é difícil de desfazer.

Comece por ler, avance para preparar e conceda enviar apenas para ações específicas, com uma regra de aprovação clara. O artigo Menor privilégio para agentes de IA: limite o acesso inicial percorre essa sequência. Permissões estreitas também limitam o dano caso um documento lido pelo agente contenha instruções ocultas, um risco que cresce a cada tipo de arquivo e canal que você conecta.

Canais e observabilidade: como o trabalho chega e como você sabe que foi feito?

Canais são os lugares em que o agente encontra as pessoas. Podem ser e-mail, chat da equipe, aplicativo de mensagens ou um painel interno. Essa camada faz mais do que entregar mensagens. Ela responde quem pode dar instruções ao agente, como o remetente é identificado, que formato serve a cada público e como um pedido informal vira uma tarefa com responsável. Um canal que trata toda mensagem como comando é um problema de segurança. Um canal que perde o contexto entre mensagens é um problema de usabilidade.

Observabilidade é o registro do que aconteceu. No mínimo, deve permitir que alguém responda, depois do fato: que pedido chegou, que contexto o agente usou, quais ferramentas chamou, o que propôs, quem aprovou e qual foi o resultado. O material introdutório do OpenTelemetry descreve observabilidade como a capacidade de entender o estado interno de um sistema a partir dos sinais que ele produz, como logs, métricas e rastros. A mesma ideia vale para o trabalho de agentes, adaptada a tarefas e decisões. O artigo Observabilidade de agentes de IA: o que registrar? traz uma lista prática.

A observabilidade também é o que transforma as outras seis camadas em algo que você consegue melhorar. Sem ela, um resultado ruim é uma discussão. Com ela, o resultado vira um diagnóstico.

Cenário ilustrativo: qual camada falhou?

Este cenário é ilustrativo. Uma empresa de serviços tem um agente que redige e-mails de acompanhamento para clientes depois de reuniões. Um dos rascunhos cita um prazo de entrega que mudou no mês anterior, e o cliente percebe.

Uma equipe que culpa o modelo pode trocá-lo por outro e torcer. Uma equipe que lê a estrutura por camada faz uma pergunta diferente a cada passo:

• Modelo: seguiu o contexto que recebeu? Sim, citou o que viu.
• Harness: algo verificou se o contexto estava atual? Não, nenhum passo comparou o prazo com a fonte.
• Memória: o prazo antigo estava numa nota do cliente, sem dono e sem data de validade.
• Ferramentas: o agente tinha uma consulta ao contrato vigente, mas nada exigia usá-la antes de citar um prazo.
• Permissões: o rascunho podia ser enviado sem revisão.
• Canais: o pedido chegou numa conversa que não mencionava a mudança de prazo.
• Observabilidade: o registro mostrou qual nota forneceu o prazo, então o diagnóstico levou minutos em vez de dias.

O reparo se distribui por várias camadas. Marcar a nota como substituída, exigir a consulta ao contrato antes de qualquer prazo citado e reter rascunhos destinados a clientes para aprovação até que a verificação se prove confiável. Nenhuma dessas mudanças precisou de um novo modelo.

Como revisar a sua própria estrutura, camada por camada?

Use estas perguntas em uma sessão de trabalho com as pessoas responsáveis pelo processo. Toda camada para a qual você não consegue responder é uma camada que hoje não tem dono.

• Modelos: qual modelo cuida de cada tarefa, e que evidência mostra que ele é bom o bastante para ela?
• Harness: onde estão escritas as instruções, as condições de parada, as regras de nova tentativa e os pontos de retomada?
• Memória: para qualquer fato guardado, você enxerga a fonte, o dono e a data da última confirmação?
• Ferramentas: cada ferramenta tem propósito estreito, entradas e saídas documentadas e um comportamento definido para quando falha?
• Permissões: cada capacidade está definida como ler, preparar ou enviar, e isso é aplicado fora das instruções?
• Canais: quem pode dar instruções ao agente, e como cada pessoa é identificada?
• Observabilidade: você conseguiria reconstruir a tarefa mais importante de ontem só a partir do registro?

Com as respostas em mãos, escolha a camada mais fraca e fortaleça-a antes de acrescentar qualquer coisa nova. Um agente modesto com as sete camadas compreendidas é mais fácil de confiar do que um ambicioso com três delas faltando.

A Be Human projeta, implementa e opera essas camadas como um único sistema para a empresa. O trabalho começa definindo 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. A operação gerenciada pode então incluir monitoramento, avaliações recorrentes, manutenção das integrações, revisão de permissões, resposta a incidentes e melhorias controladas, enquanto as pessoas da empresa mantêm o controle sobre o que o agente pode fazer.

Perguntas frequentes

As sete camadas precisam existir desde o início? Sim, em tamanho pequeno. Até um agente simples tem um modelo, instruções, algum contexto, uma ou duas ferramentas, um limite do que pode fazer, uma forma de receber pedidos e algum registro de suas ações. O que dá para adiar é a sofisticação, como uma memória mais ampla ou mais canais, e não a camada em si.

Qual camada importa mais? Nenhuma camada sustenta o sistema sozinha, mas permissões e observabilidade merecem atenção cedo, porque limitam e revelam os erros. Um modelo mais fraco, com limites claros e bom registro, é mais fácil de gerenciar do que um mais forte que ninguém consegue inspecionar.

Podemos montar essas camadas com fornecedores diferentes? Pode, e muitas empresas fazem isso. O risco está nas junções: alguém precisa ser responsável por como a memória alimenta o harness, como as ferramentas respeitam as permissões e como os logs de cada parte se conectam em um único registro. Se você está avaliando esse trabalho, Harness de IA: construir ou contratar? Compare responsabilidades é uma boa próxima leitura.

Como isso é diferente de um chatbot? Um chatbot é, em grande parte, um modelo mais um canal. Ele responde perguntas, mas em geral não mantém memória governada, não usa ferramentas sob permissões nem deixa um registro auditável. As sete camadas descrevem o que se acrescenta quando o objetivo é trabalho concluído, e não apenas respostas.

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