A Mudança Arquitetônica Necessária para Governar Agentes de IA

A IA não é mais apenas um chatbot que gera texto. Em ambientes empresariais, os agentes de IA estão realizando ações como recuperar dados sensíveis, acionar fluxos de trabalho, chamar ferramentas e registrar atividades em vários sistemas. A autonomia muda completamente a discussão sobre governança; os controles e procedimentos inicialmente projetados para usuários humanos e aplicações tradicionais não foram criados para governar software que pode executar ações multi-etapas em tempo de execução.

O risco não é teórico. Pequenas lacunas na visibilidade, controle de acesso e auditoria podem se somar rapidamente, transformando-se em falhas em tempo de execução que são difíceis de detectar e ainda mais difíceis de reverter.

Para acompanhar essa nova era, a governança de agentes de IA não pode ser feita apenas adicionando mais documentos de política. Isso requer governança por design: uma abordagem arquitetônica na qual os controles são incorporados ao plano de controle e aplicados continuamente em tempo de execução. Se os agentes forem agir como colegas digitais, eles devem herdar as mesmas salvaguardas empresariais que os humanos, além de uma supervisão mais forte em tempo de execução.

Por que a governança quebra na era de convergência

A arquitetura empresarial entrou em uma era de convergência. Dados e cargas de trabalho agora abrangem vários ambientes de nuvem, centros de dados privados e ambientes de borda.

Há organizações que executam suas plataformas em sistemas paralelos porque têm vários processos para gerenciar simultaneamente. Isso inclui sistemas de identidade separados, pipelines de registro, catálogos e processos aprovados. O resultado é o que alguns chamam de “plataforma Frankenstein”, onde a sobrecarga de integração aumenta com cada nova ferramenta ou ambiente de nuvem. Na verdade, essa fragmentação está aparecendo na realidade cotidiana.

De acordo com uma pesquisa recente, 47% dos respondentes citam requisitos de acesso complicados e processos, e 44% citam visibilidade limitada sobre onde os dados residem como barreiras para usar dados de forma eficaz.

É exatamente aqui que os agentes expõem as costuras entre os sistemas.

Para responder a uma pergunta de negócios, um agente pode precisar recuperar dados de um sistema ERP local, um CRM na nuvem, telemetria operacional em outra nuvem e documentos em um conjunto de colaboração. Se a organização aplicar políticas de forma diferente em cada local, o agente falhará ou, pior, terá sucesso de maneiras que não podem ser explicadas ou controladas.

Este é o momento em que os líderes empresariais devem prestar atenção. Os agentes estão forçando uma barra mais alta que exige consistência em todos os ambientes e responsabilidade em tempo de execução.

A governança, por essa razão, está sendo trazida para o centro das atenções por reguladores e agências de segurança. Um exemplo disso é o NIST AI Risk Management Framework, que enfatiza a gestão de riscos em todo o ciclo de vida da IA, não apenas no momento da construção. É um lembrete de que a conformidade e a confiança são responsabilidades operacionais, não apenas listas de verificação de uma vez.

Da política à plataforma

A governança por design significa que a governança viaja com a carga de trabalho, em vez de ser reimplantada em cada silo. Na prática, isso depende de três blocos de construção:

• Um plano de controle unificado

Um lugar para definir e aplicar identidade, acesso, política, catálogos e direitos em toda a nuvem e centros de dados.

O objetivo é escrever políticas uma vez e aplicá-las em todos os lugares onde os dados e os modelos são executados, em vez de reconstruir sistemas de controle em cada sistema. Isso evita a deriva do comportamento do agente, onde o mesmo agente se comporta de forma segura em um ambiente, mas perigosa em outro.

Um teste prático é simples: se um usuário não pode acessar uma coluna, verifique se um agente agindo em seu nome não pode acessá-la também. Isso deve indicar se as políticas escritas estão sendo aplicadas em todo o plano.

• Um tecido de dados baseado em padrões abertos

Os agentes precisam de contexto para operar. Quando esse contexto está espalhado por estruturas diferentes pertencentes a equipes diferentes, um tecido de dados ajuda a padronizar a semântica e os padrões de acesso, para que os agentes não precisem aprender um novo conjunto de regras para cada conjunto de dados.

Formatos de tabela abertos, como o Apache Iceberg, apoiam isso permitindo que vários motores compartilhem os mesmos dados governados sem copiá-los em um novo silo. Isso é importante porque a duplicação de dados é onde a governança geralmente falha. Uma vez que as equipes começam a copiar “apenas o que o agente precisa”, você criou um novo ambiente menos governado.

Se os agentes puderem operar em conjuntos de dados sem introduzir novas lacunas de permissão, a governança está funcionando como pretendido.

• Observabilidade e linhagem em tempo real

Os agentes são governáveis apenas se você puder ver o que eles estão fazendo em tempo de execução.

A observabilidade aqui não é apenas um “nice-to-have”, mas é a base para controles em tempo de execução e resposta a incidentes.

Especificamente, é necessário ter uma prova de ponta a ponta das ações do agente. Os agentes devem ser capazes de provar ações, como quais dados foram acessados e quais ferramentas foram chamadas, e a partir daí, a linhagem pode conectar os resultados de volta às entradas. Isso permite que as equipes auditem essas decisões e resolvam falhas, se necessário, provando assim a conformidade geral.

Trate os agentes como “colegas digitais”

Um dos modelos mentais mais úteis é tratar os agentes como colegas digitais.

Aqui está uma comparação que quebra isso: assim como os funcionários têm crachás de acesso que permitem a entrada em alguns prédios e salas, mas não em outros, a governança permite que os agentes tenham acesso com restrições. Uma adição importante é que os agentes devem estar cientes da situação sobre o que eles são permitidos revelar.

Considere um agente de suporte. Ele pode precisar acessar casos de suporte anteriores para resolver um problema, mas não pode vazar detalhes privados de outro cliente enquanto o faz. Em outras palavras, o agente pode usar conhecimento restrito para raciocinar, mas ainda precisa aplicar limites de divulgação. Isso não é um problema de “escrita de prompts” que historicamente sabemos como navegar; em vez disso, é um problema de identidade e aplicação em tempo de execução.

O que muda em 2026: os agentes saem dos experimentos e vão para a produção

2026 é o ano em que os experimentos terminam e os agentes assumem o assento de produção.

Essa mudança força as empresas a operar em duas velocidades. Uma é a velocidade de inovação, onde as equipes testam novos modelos, ferramentas e fluxos de trabalho de agentes para ganhar uma vantagem competitiva. E a outra é a velocidade segura, onde os sistemas devem atender aos requisitos de conformidade e operacionais, que podem incluir controles de acesso estritos e pontos cegos.

Se as equipes implantarem esses agentes antes que eles sejam governados, haverá um patchwork de controles e falhas operacionais de uma vez. E se o contrário ocorrer, você obtém um modo de falha no qual a segurança bloqueia tudo, e a inovação se move para a TI sombra, minando a governança.

O objetivo não é escolher uma velocidade. É construir uma arquitetura que suporte ambas.

Uma lista de verificação prática para governar agentes em tempo de execução

• Se você está construindo ou dimensionando agentes, é imperativo perguntar a si mesmo as seguintes perguntas para revelar se a governança é realmente arquitetônica: Você pode explicar, de ponta a ponta, quais dados um agente acessou para produzir uma resposta ou realizar uma ação?
• As decisões de acesso são consistentes em ambientes híbridos, ou diferem por plataforma?
• Você tem telemetria para ações do agente, incluindo chamadas de ferramentas, verificações de política e escalonamentos humanos?
• Você pode reduzir a velocidade, pausar ou colocar em quarentena um agente em tempo de execução se ele se comportar de forma inesperada?
• Você tem um plano de monitoramento pós-implantação que se alinha com suas obrigações regulamentares e apetite para risco?

Se você não puder responder a essas perguntas, trate a implantação do agente como um incidente de produção esperando para acontecer.

A mudança de governança precisa ser arquitetônica, ou então não existe

Os agentes se tornarão uma adição padrão às operações empresariais. A pergunta é se eles se tornarão uma parte confiável das operações empresariais.

Se os agentes não forem governados com a mesma confiança que os humanos e o software crítico da missão, as consequências serão reais. Veremos essas repercussões em vazamento de dados, falhas de conformidade, falhas operacionais e perda de confiança nos programas de IA.

Os líderes precisam parar de tratar a governança de agentes como um exercício de documentação. À medida que as capacidades da plataforma se expandem, a governança de agentes deve ser uma delas que assume a supervisão de outros papéis. Isso significa incorporar controles no plano de controle, tornar as ações observáveis e as decisões auditáveis. E então escalar.

É assim que você obtém agentes que se movem rapidamente sem quebrar a empresa.