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 sistemas. A autonomia muda completamente a discussão sobre governança; os controles e procedimentos inicialmente projetados para usuários humanos e aplicativos tradicionais não foram criados para governar software que pode executar ações em múltiplos passos 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, governar agentes de IA não pode ser feito apenas adicionando mais documentos de política. Isso requer governança por design: uma abordagem arquitetônica na qual os controles são incorporados no plano de controle e aplicados continuamente em tempo de execução. Se os agentes forem agir como colegas digitais, eles devem herdar as mesmas barreiras de segurança da empresa 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 múltiplos clouds, centros de dados privados e ambientes de borda.

Existem organizações que executam suas plataformas em sistemas paralelos porque elas têm múltiplos 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 cloud. 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 os 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 cloud, telemetria operacional em outra cloud e documentos em um conjunto de colaboração. Se a organização aplicar política de forma diferente em cada lugar, o agente falhará ou, pior, terá sucesso de maneiras que você não pode explicar ou controlar.

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

A governança, por esse motivo, 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 para a 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 todo o cloud e centros de dados.

O objetivo é escrever políticas uma vez e aplicá-las onde quer que os dados e os modelos sejam executados, em vez de reconstruir sistemas de controle sistema por sistema. Isso evita o drift de comportamento do agente, onde o mesmo agente se comporta de forma segura em um ambiente, mas de forma 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 diferentes estruturas de propriedade de diferentes equipes, 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 Apache Iceberg, suportam 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 “ter” agradável, mas é a base para controles em tempo de execução e resposta a incidentes.

Especificamente, é necessário ter 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 solucionem 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 concedem entrada a alguns prédios e salas, mas não a 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 do 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 mudam de experimentos para 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.

Sem uma governança arquitetônica definida, essas duas velocidades entrarão em conflito.

Se as equipes implantarem esses agentes antes que eles sejam governados, haverá um patchwork de controles e falhas operacionais. 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ê estiver construindo ou escalando 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 tomar 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 de agentes, 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 está alinhado com suas obrigações regulatórias e apetite de 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 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 de missão crítica, as consequências serão reais. Veremos essas repercussões em vazamentos de dados, falhas de conformidade, paradas 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 das 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.