Agentes de IA Precisam de um Plano de Controle Antes de Escalarem

O Google News destacou um alerta direto para líderes empresariais: agentes de IA precisam de um plano de controle antes que as organizações possam escalá-los com segurança. O conflito já não é mais entre autonomia e trabalho humano. É entre a rápida implantação de agentes e os controles necessários para manter ações autônomas visíveis, delimitadas e reversíveis.

Essa distinção importa porque um agente de IA faz mais do que gerar texto. Ele pode recuperar dados corporativos, acionar ferramentas de software, atualizar registros e disparar fluxos de trabalho com supervisão limitada. Cada capacidade adicional transforma a resposta de um modelo em uma possível ação de negócio.

A cobertura mais recente do Google News captura uma mudança mais ampla na tecnologia empresarial. Microsoft, IBM, Salesforce, Databricks e AWS estão colocando a governança no centro de suas plataformas de agentes. A concorrência agora envolve quem controla os agentes, e não apenas quem fornece o modelo mais inteligente.

A Corrida dos Agentes de IA Passou de Pilotos para Controle

A mudança importante é que a governança de agentes se tornou uma categoria de produto, e não um documento de políticas.

Projetos anteriores de IA empresarial geralmente colocavam uma interface conversacional sobre dados aprovados. As equipes de segurança podiam se concentrar no acesso ao modelo, na retenção de dados e em verificar se funcionários inseriam informações sensíveis em serviços públicos.

Os agentes ampliam esse perímetro de risco. Eles podem conectar vários sistemas durante uma tarefa, selecionar ferramentas, criar planos e executar etapas com base em resultados probabilísticos. Uma ação permitida ainda pode produzir um resultado inaceitável quando surge na sequência errada.

Considere um agente de compras que pode consultar o estoque, contatar fornecedores e criar pedidos. Cada permissão pode ser legítima de forma isolada. Ainda assim, o fluxo de trabalho combinado pode duplicar um pedido, selecionar um fornecedor não aprovado ou expor previsões confidenciais de demanda.

É por isso que um plano de controle se tornou central para a discussão. Um plano de controle de agentes é um sistema compartilhado para registrar agentes, atribuir identidades, aplicar políticas, monitorar ações e gerenciar seu ciclo de vida.

A IBM descreve o conceito como um sistema capaz de implantar, operar, monitorar e governar agentes em toda uma organização. Seu agent control plane também coordena agentes entre sistemas de negócio e fluxos de trabalho com várias etapas.

O plano de controle não substitui a segurança de aplicações nem as salvaguardas dos modelos. Ele fornece uma camada operacional comum acima de diferentes agentes, modelos, ferramentas e aplicações de negócio. Essa camada deve responder a perguntas básicas antes que um agente atue.

Quem é responsável por este agente? Quais dados ele pode recuperar? Quais ferramentas pode invocar? Qual limite de gastos se aplica? Quais ações exigem aprovação? Como um administrador pode interromper ou reverter o fluxo de trabalho?

Muitos projetos-piloto respondem a essas perguntas dentro de código personalizado. Essa abordagem se torna frágil quando equipes separadas implantam agentes por meio de diferentes nuvens, plataformas de software e frameworks de desenvolvimento.

Um departamento financeiro pode adotar um agente dentro de uma aplicação empresarial. Desenvolvedores podem criar outro com um framework aberto. Funcionários também podem criar agentes por meio de ferramentas low-code sem informar as equipes de segurança.

Isso cria uma proliferação de agentes, semelhante ao crescimento anterior de serviços em nuvem e contas de software não gerenciados. A diferença é que um agente pode atuar continuamente e na velocidade de uma máquina.

A manchete do Google News, portanto, representa mais do que outro debate sobre governança. Ela reflete uma mudança arquitetural. As empresas precisam de uma camada de gestão que trate agentes como atores operacionais antes que esses atores se tornem numerosos ou profundamente conectados.

Por Que o Google News Está Apontando para a Governança Agora

A adoção de agentes avança mais rápido do que os sistemas usados para identificar, monitorar e restringir software autônomo.

A pressão vem de duas direções. As equipes de negócio querem automação que atravesse os limites entre aplicações. Os líderes de tecnologia precisam atender a essa demanda sem criar uma população invisível de identidades de software.

Sistemas tradicionais de identidade pressupõem que uma pessoa faça login, receba permissões e permaneça responsável pela sessão. Os agentes complicam esse modelo porque podem operar em nome de uma pessoa, aplicação, departamento ou outro agente.

Um agente também pode delegar trabalho. Um agente principal pode pedir a agentes especializados que pesquisem registros, analisem documentos ou atualizem um sistema. Essa cadeia torna a propriedade e a responsabilização mais difíceis de rastrear.

A Microsoft comparou esse problema à proliferação de identidades. Sua orientação sobre plano de controle alerta que permissões excessivas podem aumentar os danos causados por erros, compartilhamento excessivo ou exposição não intencional de dados.

A identidade, por si só, não é suficiente. Um plano de controle também deve registrar o que um agente tentou fazer, quais recursos acessou e o que ocorreu após cada chamada de ferramenta. Sem esse histórico, as equipes não conseguem reconstruir uma falha.

Observabilidade significa coletar os rastros, eventos, custos e resultados produzidos por um agente. Ela se torna especialmente importante quando a mesma entrada nem sempre gera o mesmo plano.

O software convencional geralmente segue caminhos que os desenvolvedores definiram antecipadamente. Um agente interpreta um objetivo e escolhe etapas em tempo de execução. Portanto, o monitoramento deve capturar decisões e ações, e não apenas a disponibilidade da aplicação.

O custo cria outra fonte de pressão. Um fluxo de trabalho baseado em agentes pode chamar vários modelos, consultar múltiplos armazenamentos de dados e invocar serviços pagos. Um loop ou uma tarefa mal delimitada pode consumir recursos sem entregar um resultado útil.

A CIO Dive informou que Salesforce e Databricks adicionaram recursos de governança à medida que a adoção de agentes se espalhava pelos fluxos de trabalho empresariais. As implementações de governança incluíram controles para acesso a modelos, uso de APIs, sistemas internos, registros e acompanhamento de custos.

A AWS também introduziu um registro centralizado para agentes, segundo essa cobertura. Os registros resolvem um problema básico de descoberta ao criar um inventário de agentes implantados e seus metadados associados.

Um inventário é necessário, mas não suficiente. Uma lista não consegue impedir que um agente chame uma ferramenta não autorizada. Também não consegue decidir se uma transação específica exige aprovação humana.

O modelo mais robusto combina registro com aplicação de regras em tempo de execução. A aplicação em tempo de execução avalia uma ação enquanto o agente está operando, antes que o sistema conectado aceite a solicitação.

É por isso que a mudança atual importa. A governança está passando de uma revisão periódica para o controle contínuo. As políticas precisam acompanhar um agente entre modelos, ferramentas e ambientes.

A conversa encontrada pelo Google News é oportuna porque as empresas estão se aproximando desse limite agora. Projetos-piloto podem sobreviver a controles fragmentados. Portfólios de produção não.

A Principal Disputa É Entre Controle Central e Aprisionamento à Plataforma

As empresas precisam de uma visão única de seus agentes, enquanto os grandes fornecedores querem que sua própria plataforma se torne essa visão.

Um plano de controle unificado promete identidade, políticas, logs, aprovações e relatórios de custos consistentes. Ele pode reduzir a necessidade de cada equipe de desenvolvimento construir essas funções de forma independente.

No entanto, as empresas raramente operam uma única plataforma de agentes. Elas usam várias nuvens, suítes de software, modelos e frameworks internos. Aquisições e compras departamentais acrescentam ainda mais variação.

Isso torna inevitável a questão arquitetural central. A governança deve residir dentro de cada plataforma de agentes ou uma camada independente deve governar agentes entre fornecedores?

Controles nativos de plataforma podem se integrar estreitamente às aplicações onde os agentes trabalham. Um agente Salesforce pode herdar contexto dos registros, permissões e fluxos de trabalho do Salesforce. Um agente nativo de nuvem pode usar os serviços de identidade e monitoramento de seu provedor.

Essas integrações reduzem o trabalho de implementação. Elas também criam ilhas de governança quando outro departamento seleciona uma plataforma diferente. As equipes de segurança podem receber vários painéis com definições incompatíveis e cobertura incompleta.

A Salesforce posicionou seu Agent Fabric expandido como um plano de controle para um ambiente com múltiplos fornecedores. Ele inclui descoberta de agentes, orquestração determinística e governança de modelos.

A orquestração determinística usa regras predefinidas para etapas críticas do fluxo de trabalho, em vez de deixar que um modelo escolha cada ação. Ela pode manter aprovações, limites de transação e verificações obrigatórias fora do raciocínio probabilístico.

A IBM adotou uma posição igualmente ampla. Seu Agentic Control Plane foi projetado para gerenciar agentes entre frameworks e ambientes por meio do watsonx Orchestrate.

Fornecedores independentes de segurança e observabilidade oferecem outra alternativa. Eles podem se posicionar entre agentes e sistemas empresariais, inspecionar chamadas de ferramentas, aplicar políticas e registrar atividades em várias pilhas de desenvolvimento.

Cada abordagem envolve uma contrapartida. O controle nativo oferece integração mais profunda, mas pode aumentar a dependência de um fornecedor. O controle independente oferece cobertura mais ampla, mas adiciona outra camada que as equipes precisam integrar e manter.

A resposta também dependerá de onde a autoridade realmente reside. Um painel pode observar um agente sem controlá-lo. Um registro pode identificar um agente sem restringir suas ações.

Um plano de controle confiável precisa de um ponto de aplicação. Ele deve ser capaz de negar uma chamada de ferramenta, solicitar aprovação, reduzir permissões, suspender uma identidade ou interromper um fluxo de trabalho.

Ele também deve abranger componentes de terceiros. Agentes empresariais frequentemente dependem de modelos externos, conectores, plugins e serviços de dados. Um plano de controle que enxerga apenas os componentes de seu fornecedor oferece uma visão incompleta dos riscos.

O relatório de custos enfrenta o mesmo problema. Um fluxo de trabalho pode usar o agente de um fornecedor, o modelo de outro provedor e um serviço de busca separado. A cobrança fragmentada obscurece o custo do resultado completo de negócio.

Essa concorrência pressiona CIOs e líderes de segurança. Selecionar uma plataforma de agentes significa cada vez mais selecionar um modelo operacional para identidade, políticas, telemetria e governança financeira.

Essa decisão não deve começar com uma lista de funcionalidades. Ela deve começar pelos fluxos de trabalho de maior risco da organização e pelos sistemas que os agentes precisam acessar.

Um resumo de atendimento ao cliente traz consequências diferentes de um agente que emite reembolsos. Um assistente de pesquisa tem um perfil de risco diferente de um agente que altera infraestrutura de produção.

A pergunta útil não é se um fornecedor oferece governança. Quase todos os fornecedores farão essa afirmação. Os compradores devem perguntar quais ações o produto consegue observar, interromper, aprovar e reconstruir ao longo de todo o fluxo de trabalho.

Proteções Uniformes Podem Criar um Tipo Diferente de Falha

O controle central se torna contraproducente quando todos os agentes recebem as mesmas restrições, independentemente de sua autonomia ou impacto.

A demanda por um único plano de controle pode incentivar uma ideia enganosa: uma política deve governar todos os agentes. Essa abordagem simplifica a administração, mas ignora diferenças importantes entre as funções dos agentes.

A Gartner alertou em maio de 2026 que aplicar governança uniforme a todos os agentes pode levar ao fracasso das implantações empresariais. Seu framework de governança pede controles que variem conforme a autonomia, a sensibilidade e o escopo de um agente.

Um agente de sumarização com acesso somente de leitura não precisa do mesmo fluxo de aprovação que um agente que transfere fundos. Tratá-los da mesma forma pode sobrecarregar o fluxo de baixo risco ou deixar o de alto risco insuficientemente protegido.

Isso revela a principal tensão. As empresas precisam de controles comuns sem presumir riscos iguais.

Uma arquitetura útil pode padronizar identidade, inventário, registros e responsabilidade em todos os agentes. Em seguida, deve aplicar controles mais rigorosos à medida que a autonomia e o impacto potencial aumentam.

Um agente de baixo risco pode operar com registros rotineiros e avaliações periódicas. Um agente de risco moderado pode exigir permissões delimitadas, limites de gastos e alertas para comportamentos incomuns.

Um agente de alto risco pode precisar de verificações determinísticas, aprovação dupla, ambientes de execução restritos e controles de desligamento imediato. Algumas ações devem permanecer indisponíveis para softwares autônomos.

É nesse ponto que muitas alegações de fornecedores exigem escrutínio. Visibilidade não garante segurança. A configuração de políticas não garante sua aplicação. Uma trilha de auditoria não impede uma ação irreversível.

Os resultados de avaliações também têm limites. Testar um agente com um conjunto fixo de prompts pode revelar fragilidades conhecidas. Ambientes de produção introduzem dados, ferramentas, objetivos de usuários e interações com outros agentes em constante mudança.

Atacantes podem explorar essas conexões. A injeção de prompt insere instruções maliciosas em conteúdos recuperados por um agente, como um documento, e-mail ou página da web. O agente pode tratar a instrução oculta como parte de sua tarefa.

Um filtro no nível do modelo pode ajudar, mas a fronteira mais segura está em torno da ação. Mesmo que um agente seja manipulado, ele não deve obter permissão para expor segredos ou executar uma transação não autorizada.

A aprovação humana apresenta outra complicação. Exigir que uma pessoa aprove cada ação elimina grande parte do valor da automação. Pedir que pessoas revisem solicitações longas e frequentes também gera fadiga de aprovação.

O plano de controle deve reservar a intervenção humana para decisões relevantes. Ações de menor risco podem seguir políticas aplicáveis, enquanto ações incertas ou sensíveis passam para revisão.

As organizações também precisam de responsabilização clara quando um agente falha. Designar um responsável para cada agente implantado é essencial, mas a responsabilidade não pode terminar na equipe de desenvolvimento.

Líderes de negócio definem resultados aceitáveis. Equipes de segurança estabelecem controles de acesso. Equipes jurídicas e de compliance interpretam obrigações. Equipes de tecnologia operam a infraestrutura compartilhada.

Essa distribuição de responsabilidades torna a governança um modelo operacional, e não apenas uma compra de software. Um plano de controle pode aplicar decisões, mas as pessoas primeiro precisam defini-las com precisão.

Por isso, é necessária uma leitura cética da narrativa do Google News. Comprar um painel centralizado não torna as operações de agentes seguras. O sistema precisa oferecer controles diferenciados, aplicação real e responsabilidade definida.

Um Plano de Controle Funcional Precisa de Cinco Camadas Aplicáveis

A arquitetura só funciona quando conecta a identidade do agente a cada ação, resultado e responsável.

A primeira camada é o inventário. Todo agente em produção precisa de um registro único contendo seu responsável, finalidade, framework, dependências de modelo, acesso a dados, ferramentas e status de implantação.

A descoberta deve incluir agentes criados fora da TI central. Caso contrário, o inventário se torna uma lista de projetos aprovados, enquanto agentes paralelos continuam operando sem supervisão.

A segunda camada é identidade e acesso. Os agentes precisam de identidades não humanas que possam receber permissões limitadas, temporárias e específicas para cada tarefa.

Compartilhar as credenciais de um funcionário destrói a responsabilização. Também concede ao agente todas as permissões do funcionário, mesmo quando a tarefa exige apenas uma ação restrita.

As permissões devem seguir o princípio do menor privilégio, ou seja, conceder apenas o acesso necessário para o trabalho atribuído. Credenciais de curta duração podem reduzir ainda mais a exposição causada por tokens roubados ou agentes abandonados.

A terceira camada é a aplicação de políticas. As políticas devem avaliar chamadas de ferramentas, acesso a dados, transações e delegações antes da execução.

Uma política pode bloquear exportações que contenham registros sensíveis. Outra pode exigir aprovação quando uma compra ultrapassa um limite definido. Uma terceira pode proibir que um agente combine dados de clientes com um modelo externo.

A quarta camada é a observabilidade. As equipes precisam de rastros que conectem a solicitação original, o plano do agente, chamadas ao modelo, contexto recuperado, atividade de ferramentas, custos, aprovações e resultado final.

Esses registros apoiam a resposta a incidentes e a análise de desempenho. Eles também revelam agentes que concluem tarefas, mas geram custo excessivo, erros recorrentes ou limpeza manual oculta.

A quinta camada é a gestão do ciclo de vida. As organizações devem conseguir testar, implantar, atualizar, suspender e desativar agentes por meio de processos controlados.

Modelos e ferramentas mudam após a implantação. Um agente que passou por avaliação em uma configuração pode se comportar de forma diferente depois que um conector, prompt, modelo ou permissão é alterado.

Os controles do ciclo de vida devem acionar novas avaliações quando dependências importantes mudarem. Também devem remover credenciais e integrações quando um agente for desativado.

Essas camadas se tornam mais valiosas quando os agentes interagem com conhecimento interno. Uma base de conhecimento de IA confiável pode melhorar a recuperação de informações, mas o acesso ainda exige limites baseados em função e tarefa.

Um contexto melhor não elimina a necessidade de controle. Ele aumenta a importância de saber quais documentos um agente recuperou e por que esses documentos influenciaram uma ação.

O mesmo princípio se aplica à memória do agente. A memória persistente pode ajudar um agente a manter o contexto entre tarefas. Ela também pode preservar detalhes sensíveis, instruções desatualizadas ou suposições incorretas.

Portanto, a memória precisa de regras de retenção, controles de acesso e caminhos de exclusão. Os usuários devem saber quando um agente armazena informações além da sessão atual.

As equipes devem testar essas camadas em fluxos de trabalho completos, não em respostas isoladas do modelo. Uma resposta bem-sucedida é irrelevante se o agente usou dados proibidos ou deixou uma alteração não autorizada.

Os testes de cenário devem incluir erros comuns, entradas maliciosas, ferramentas indisponíveis, picos de custo, falhas de permissão e solicitações que exigem escalonamento. Também devem testar se os administradores conseguem interromper atividades rapidamente.

Esse foco operacional separa um plano de controle real de uma encenação de governança. O sistema deve restringir comportamentos e, ao mesmo tempo, preservar flexibilidade suficiente para uma automação útil.

Três Sinais Mostrarão se o Controle Conseguirá Acompanhar

A próxima fase será definida pela aplicação entre plataformas, resultados mensuráveis em produção e evidências de que a governança diferenciada funciona.

O primeiro sinal é se os planos de controle dos fornecedores gerenciam agentes além de seus próprios ecossistemas. Anúncios de produtos já prometem visibilidade multiforncedor, mas as empresas precisam de comprovação em implantações reais.

Observe conectores que preservem identidade, políticas e telemetria entre nuvens, modelos e plataformas de software. Um plano de controle se torna mais crível quando consegue interromper ações de terceiros, e não apenas exibi-las.

Um suporte robusto entre plataformas reforçaria o argumento de que a governança pode se tornar uma camada empresarial compartilhada. Um suporte fraco deixaria os clientes gerenciando vários sistemas de controle e conciliando manualmente suas lacunas.

O segundo sinal é se as organizações relatam resultados de negócio juntamente com a quantidade de agentes. Os números de implantação revelam atividade, mas não mostram se os agentes concluem trabalhos úteis com segurança.

Medições úteis incluem conclusão bem-sucedida de tarefas, taxas de escalonamento para humanos, frequência de reversões, violações de políticas, custo total do fluxo de trabalho e tempo gasto corrigindo a saída dos agentes.

A pesquisa de liderança tecnológica da IBM de 2026 argumenta que a gestão de portfólio pode melhorar a implantação de agentes sem aumentar o orçamento de IA. Seu estudo sobre líderes de tecnologia também destaca lacunas na visibilidade de gastos em tempo real.

Evidências de custos menores com falhas e menos intervenções manuais fortaleceriam o argumento a favor do plano de controle. Um número crescente de agentes sem dados de resultados sugeriria que a experimentação ainda supera a maturidade operacional.

O terceiro sinal é se as organizações adotam controles baseados em risco em vez de uma política universal. Isso exige produtos capazes de classificar agentes por autonomia, sensibilidade dos dados e impacto potencial.

Procure arquiteturas de referência que conectem essas classificações à aplicação técnica. Ações de alto risco devem receber requisitos mais rigorosos de aprovação, isolamento, registro e recuperação.

Uma governança diferenciada bem-sucedida responderia ao alerta da Gartner sobre controles uniformes. Ela mostraria que a administração centralizada não exige restrições idênticas.

Uma falha nesse ponto enfraqueceria todo o modelo. As organizações desacelerariam agentes inofensivos com revisões pesadas ou exporiam fluxos de trabalho relevantes a controles concebidos para assistentes simples.

O enquadramento do Google News oferece aos compradores empresariais um ponto de partida útil, mas os planos de controle devem enfrentar o mesmo escrutínio dos agentes que governam. Os compradores precisam de evidências de aplicação, portabilidade e redução mensurável de riscos.

Líderes de tecnologia podem começar antes de selecionar uma plataforma. Inventariem os agentes já em uso, identifiquem seus responsáveis, mapeiem seu acesso a ferramentas e classifiquem as consequências de falhas.

Em seguida, escolham um fluxo de trabalho relevante e testem toda a cadeia de controle. Verifiquem se a organização consegue identificar o agente, limitar suas permissões, inspecionar suas ações, interromper a execução e reconstruir o resultado.

Não meçam a preparação pelo número de agentes que uma plataforma consegue registrar. Meçam-na pela capacidade de impedir, aprovar, rastrear e reverter a ação de maior risco.

A próxima manchete do Google News provavelmente destacará mais um grande lançamento de agentes. Antes de entrar nessa corrida, faça uma pergunta mais difícil: sua organização consegue ver e interromper o que o agente faz depois que a demonstração termina?