As empresas que mais poderiam ganhar produtividade com IA são, com frequência, as que têm mais dificuldade para colocá-la dentro da operação. O gargalo já não é só a capacidade do modelo. É conseguir dar acesso sem perder controle sobre dados, ferramentas e decisões.
dos respondentes dizem que a IA melhorou sua produtividade pessoal.
McKinsey, State of AI 2026atribuem algum impacto positivo no EBIT de suas organizações.
McKinsey, State of AI 2026das grandes empresas brasileiras usaram algum tipo de IA em 2025. Entre as médias, foram 32%.
Cetic.br, TIC Empresas 2025Todo mundo já tem IA. Pouca gente colocou a IA para trabalhar
Chats e copilotos estão virando parte comum do trabalho de escritório. Uma pessoa abre uma janela, leva um texto, pede uma análise, melhora uma apresentação e volta para o sistema onde o trabalho realmente acontece. A IA ajuda. O processo continua quase igual.
Essa diferença aparece nos números. Na pesquisa global da McKinsey publicada em 2026, 80% dos respondentes disseram que a IA melhorou sua produtividade individual. Só 37% atribuíram algum impacto positivo no EBIT da empresa. Chatbots eram o tipo de ferramenta mais escalado, presente em 47% das organizações pesquisadas. Sistemas agênticos, capazes de agir com mais autonomia ao longo de processos, estavam perto de 20%.1
Não é uma comparação causal, e a pesquisa é baseada em autorrelato. Ainda assim, ela descreve bem o estágio atual. A pessoa ganhou um assistente. A empresa ainda não redesenhou o trabalho.
No Brasil, a TIC Empresas 2025 encontrou uso de algum tipo de IA em 17% das empresas com dez ou mais pessoas ocupadas. A adoção chegou a 32% entre as médias e 50% entre as grandes.2 Quanto maior a organização, mais recursos ela tem para experimentar. Também carrega mais sistemas, contratos, níveis de acesso e obrigações acumuladas. É justamente aí que o avanço começa a emperrar.
Se a IA não pode tocar a operação, existe um teto para a produtividade que ela consegue gerar.
O salto começa quando o modelo ganha acesso
Um chat melhora a produção de um funcionário porque recebe contexto escolhido por ele. Um agente operacional precisa de outra coisa. Precisa consultar o CRM, ler documentos, cruzar registros, chamar APIs, atualizar campos, abrir um chamado, preparar uma cobrança ou encaminhar uma exceção.
É aí que o valor cresce. Também é aí que a conversa muda de natureza.
Considere um BPO financeiro que atende quarenta clientes. Um analista pode trabalhar nas contas A e B, mas não na C. Outro cuida de B e D. Alguns contratos permitem processar dados em determinados provedores; outros exigem condições diferentes. Há documentos pessoais, segredos comerciais, credenciais, dados bancários e rotinas com efeito contábil.
Um agente que apenas resume um procedimento é relativamente simples de conter. Um agente que encontra notas fiscais, reconcilia pagamentos e atualiza o ERP precisa saber qual empresa está atendendo, em nome de quem atua, qual base pode consultar, quais ações pode executar e quando deve parar para pedir aprovação.
Chamamos tudo isso de “acesso”, mas o termo é amplo demais. O problema importante não é apenas abrir uma porta. É definir a autoridade disponível do outro lado.
O acesso é uma das peças desse desenho. O artigo sobre componentes do ambiente operacional de um agente situa permissões ao lado de contexto, memória, ferramentas e avaliação.
Um chatbot precisa de contexto. Um agente precisa de autoridade
Empresas passaram décadas construindo sistemas para responder a uma pergunta conhecida: este funcionário pode acessar este dado?
Com agentes, a pergunta fica mais longa: este agente pode acessar este dado, para executar esta tarefa, em nome deste usuário, usando esta ferramenta, neste momento?
Essa frase parece burocrática até encontrarmos um caso concreto. Imagine um agente de atendimento com permissão para consultar contratos e emitir créditos. “Acesso ao CRM” não diz se ele pode ler todas as contas, modificar qualquer registro ou conceder qualquer valor. A autoridade útil seria bem mais estreita: ler o contrato do cliente que abriu o chamado, consultar as últimas três faturas e emitir um crédito de até R$ 200, durante aquela execução, desde que a política comercial permita.
Neste artigo, chamo de envelope de autoridade o conjunto de limites que define a atuação de um agente de IA: identidade, tarefa, dados acessíveis, ferramentas, valores, duração e condições de aprovação. A identidade pode ser própria ou delegada por um usuário, inclusive de forma temporária. O requisito é conseguir atribuir e limitar cada ação; não é criar uma conta permanente para toda execução.
Menor privilégio, segregação de funções, permissões temporárias e zero trust não são ideias novas. A novidade está em aplicá-las a software que interpreta linguagem, escolhe caminhos e pode encadear ações. Em fevereiro de 2026, o National Cybersecurity Center of Excellence do NIST publicou um documento conceitual específico sobre identidade e autorização para agentes de software e IA. O texto ainda era um rascunho, mas o simples recorte do problema mostra para onde a infraestrutura está indo.3
Produtos empresariais começaram a seguir a mesma direção. A documentação do Microsoft Entra Agent ID trata agentes como identidades próprias, com dono, ciclo de vida, permissões, políticas de acesso condicional e logs.4 Não cito isso como recomendação de fornecedor. Cito porque o mercado de identidade já reconheceu que uma conta de serviço genérica não explica bem quem, ou o quê, tomou uma ação.
Prompt não é permissão
Há uma diferença enorme entre escrever “não acesse dados do cliente C” no prompt e construir uma execução na qual o agente não possui credencial, rota ou ferramenta capaz de acessar esses dados.
Prompts orientam comportamento. Permissões limitam capacidade.
Modelos trabalham com instruções e dados no mesmo espaço semântico. Um e-mail, página ou documento consultado pelo agente pode conter texto que pareça uma instrução. Esse é o problema da prompt injection indireta. O OWASP recomenda reduzir ferramentas, funções, permissões e autonomia, executar ações no contexto do usuário e validar a autorização no sistema de destino, fora do modelo.5
Em 2025, a vulnerabilidade EchoLeak mostrou o tamanho desse problema em um produto real. Uma cadeia de cross-prompt injection no Microsoft 365 Copilot podia, em condições específicas, fazer um e-mail preparado pelo atacante influenciar o sistema e exfiltrar dados limitados aos quais a vítima já tinha acesso. A Microsoft corrigiu a falha, registrada como CVE-2025-32711. Não há base para afirmar que houve exploração contra clientes, mas a vulnerabilidade demonstrou que conteúdo consultado pelo assistente pode tentar governar o próprio assistente.6
O erro seria concluir que prompts não servem. Eles servem para descrever o trabalho, dar contexto e orientar decisões. Só não substituem autorização, isolamento, validação de parâmetros e aprovação humana para ações de alto impacto.
Um prompt pode pedir prudência. A arquitetura precisa impedir que a prudência seja opcional.
A LGPD precisa aparecer no caminho dos dados
“A LGPD impede IA” é uma explicação preguiçosa. A lei não proíbe que uma organização use dados pessoais em sistemas de IA. Ela exige base, finalidade, necessidade, segurança, transparência e responsabilidade compatíveis com o tratamento realizado.
Para um agente, isso produz perguntas práticas. Que dado entrou no contexto? Por qual finalidade? Quem iniciou a execução? Qual fornecedor ou modelo recebeu a informação? Onde ela foi processada? O que ficou registrado? Quanto tempo será mantido? Que ação resultou daquele tratamento?
Essas respostas não podem depender da memória de quem configurou o fluxo. O artigo 37 da LGPD exige que controlador e operador mantenham registro das operações de tratamento. O artigo 49 diz que sistemas usados no tratamento de dados pessoais devem atender a requisitos de segurança, boas práticas, governança e aos princípios da lei. O artigo 50 prevê programas de governança integrados à estrutura da organização, com supervisão, resposta a incidentes, monitoramento contínuo e avaliações periódicas.7
Isso leva a uma consequência simples. Privacidade aplicada a agentes precisa existir na arquitetura.
Em uma empresa com vários clientes, a separação também precisa atravessar a cadeia inteira. Não basta filtrar a interface. O índice de busca, a memória, o cache, o log, a credencial da ferramenta e o conjunto de documentos recuperáveis precisam respeitar o mesmo limite. Uma resposta correta produzida com dados do cliente errado continua sendo um problema.
O desenho começa pela finalidade. Depois reduz dados e permissões ao mínimo necessário. A escolha de modelo e fornecedor vem acompanhada de localização do processamento, retenção, uso dos dados, subprocessadores e compromissos contratuais. Por fim, a operação guarda evidência suficiente para demonstrar o que aconteceu.
Se não dá para reconstruir, não dá para governar
Quando um funcionário altera um registro sensível, sistemas empresariais costumam guardar usuário, horário e mudança. Um agente exige uma trilha mais rica porque a ação final pode resultar de várias decisões intermediárias.
A empresa precisa conseguir reconstruir quem iniciou a execução, qual identidade o agente usou, quais documentos foram recuperados, que versão de política autorizou a ação, quais ferramentas foram chamadas, que modelo processou os dados, quais parâmetros foram enviados, onde houve intervenção humana e qual foi o resultado.
Isso é observabilidade. Quando aplicada ao caminho da informação, também é data lineage, ou rastreabilidade dos dados. Não significa armazenar tudo para sempre. Logs podem conter dados pessoais e segredos, portanto também precisam de minimização, proteção, acesso restrito e prazo de retenção. O objetivo é guardar evidência suficiente, não construir um novo vazamento centralizado.
O NIST organiza a gestão de riscos de IA ao longo do ciclo de vida, e não como uma revisão única antes do lançamento.8 Para agentes, essa continuidade importa ainda mais. Modelos mudam, ferramentas ganham funções, permissões se acumulam e documentos externos trazem novos tipos de entrada. Um fluxo seguro no mês do piloto pode ficar perigoso seis meses depois sem nenhuma grande decisão aparente.
Agentes são uma nova categoria de identidade corporativa
Uma empresa madura consegue listar funcionários, terceiros, aplicações e contas de serviço. Em pouco tempo, também precisará listar agentes.
Quais agentes existem? Quem responde por cada um? Para que foram criados? Quais dados e ferramentas podem usar? Em nome de quem agem? Quando suas permissões expiram? O que fizeram ontem? Como são desligados?
Essa lista parece administrativa. Na prática, ela evita dois problemas previsíveis. O primeiro é o shadow AI: agentes e integrações criados por áreas de negócio sem inventário ou revisão suficiente. O segundo é a conta órfã: o piloto termina, o responsável muda de área e a credencial permanece funcionando.
O Cost of a Data Breach Report 2025 da IBM analisou 600 organizações que já haviam sofrido violações de dados. Nessa amostra específica, 63% não tinham política de governança de IA ou ainda a estavam desenvolvendo. Entre as organizações que relataram incidentes ligados a IA, 97% também relataram controles inadequados de acesso à IA.9 Esses percentuais não representam todas as empresas. Eles mostram o perfil de organizações em que o dano já ocorreu, e por isso são mais úteis como alerta do que como taxa de mercado.
Inventário, dono, finalidade, permissão e expiração são controles pouco glamourosos. Também são o que permite desligar um sistema, investigar um incidente e provar que a autoridade concedida continua fazendo sentido.
Governança é o mecanismo que libera acesso
A visão mais comum coloca produtividade de um lado e governança do outro. Quanto mais uma cresce, mais a outra atrasa. Essa oposição descreve governança ruim: comitês lentos, políticas genéricas e aprovações que não conhecem o sistema.
Sem controles técnicos, a empresa responsável fica com duas opções. Libera acesso demais e assume um risco difícil de explicar. Ou mantém a IA longe dos dados e sistemas importantes. Quase sempre escolhe a segunda. O chatbot fica disponível, as demonstrações ficam bonitas e o trabalho decisivo continua manual.
Governança bem desenhada cria uma terceira opção. A empresa começa com leitura em um conjunto pequeno de dados. Mede qualidade e registra chamadas. Depois libera uma ferramenta reversível. Adiciona aprovação para mudanças sensíveis. Aumenta o escopo quando os resultados, os controles e a capacidade de resposta justificam. Se algo piora, reduz a autoridade sem desmontar o sistema inteiro.
O ganho vem da progressão. Identidade permite atribuir ações. Autorização reduz o raio de dano. Segregação protege clientes e funções. Observabilidade mostra o que acontece. Auditoria permite explicar. E gates humanos reservam decisões de maior impacto para quem carrega a responsabilidade.
Governança não torna um modelo correto. Também não elimina incidentes. Ela transforma uma aposta ampla em uma série de delegações limitadas, observáveis e reversíveis.
Essa progressão também precisa preservar a autonomia das rotinas e o julgamento da equipe, para que a operação ganhe alcance sem perder a capacidade de investigar exceções.
A empresa já sabe delegar. Precisa aprender a delegar para software
Empresas funcionam por delegação de autoridade. Acionistas elegem conselhos. Conselhos orientam e supervisionam executivos. Executivos distribuem decisões entre gestores e equipes. Cada papel recebe poderes, metas e limites. Os princípios de governança corporativa da OCDE tratam orientação estratégica, supervisão da gestão, responsabilidade e controle de riscos como funções centrais desse sistema.10
Agentes introduzem uma delegação diferente. A empresa entrega autoridade a software que interpreta contexto e decide dinamicamente qual ferramenta usar. O agente não é administrador, empregado ou sujeito moral. A responsabilidade continua humana e institucional. Mas sua identidade operacional precisa ser explícita o bastante para que a organização saiba quem o criou, quem o supervisiona e quem responde pelo processo.
Isso também muda a conversa do conselho e da diretoria. “Temos uma política de IA?” é uma pergunta fraca. Perguntas melhores seriam:
- Quais processos já permitem que agentes tomem ações?
- Que classes de dados entram nesses processos?
- Quem pode conceder e revogar autoridade?
- Quais decisões exigem aprovação humana?
- Conseguimos reconstruir uma execução crítica?
- Existe um responsável por cada agente em produção?
O conselho não precisa discutir prompts. Precisa saber se a empresa está delegando autoridade sem perder accountability.
Onde a Fator entra
Quando agentes passam a tocar identidades, permissões, sistemas, dados, privacidade e rotinas operacionais, implementar IA deixa de ser apenas um problema de modelo. Vira engenharia de sistemas seguros.
É nesse recorte que a experiência da Fator em cibersegurança, privacidade, arquitetura e engenharia importa. Não porque segurança deva assumir a agenda de IA, mas porque alguém precisa traduzir finalidade de negócio em identidade, política de acesso, isolamento, observabilidade e limites executáveis.
O trabalho útil não é instalar mais um chat. É construir a menor autoridade capaz de produzir o resultado e a evidência necessária para confiar nele.
A próxima pergunta da IA corporativa
Na primeira fase da IA corporativa, a preocupação era controlar quem podia acessar os modelos. Licenças, contas empresariais e políticas de uso respondiam boa parte do problema.
Na próxima fase, a empresa terá de controlar o que modelos e agentes podem acessar, em nome de quem e para fazer o quê.
Essa mudança decide quanto valor a IA consegue alcançar. Manter agentes longe da operação reduz risco, mas também limita o resultado. Liberá-los sem arquitetura suficiente troca produtividade por exposição.
A saída é governar a autoridade em incrementos: identidade atribuível, acesso mínimo, separação de dados, ferramentas delimitadas, logs úteis, aprovação proporcional e revisão contínua.
Governança não é aquilo que impede a empresa de utilizar agentes. É aquilo que permite dar a eles acesso suficiente para que finalmente sejam úteis.
Fontes e limites da análise
A governança como condição para ampliar a delegação é a tese deste artigo, não um ranking universal dos gargalos da IA. As pesquisas empresariais usam autorrelatos. O levantamento da IBM inclui organizações que sofreram violações e não representa todas as empresas. As perguntas de rastreabilidade propostas são consequências de arquitetura; não reproduzem uma lista literal da LGPD. Residência, retenção e acesso dependem do fluxo, do contrato e da configuração.
Fontes
- McKinsey & Company. The State of AI: Global Survey 2026. Agosto de 2026.
- Cetic.br/NIC.br. Uso de Inteligência Artificial por empresas brasileiras avança e atinge 17%, aponta pesquisa do Cetic.br. TIC Empresas 2025, publicada em junho de 2026.
- NCCoE/NIST. Accelerating the Adoption of Software and AI Agent Identity and Authorization Concept Paper. Draft, fevereiro de 2026.
- Microsoft Learn. Microsoft Entra security for AI overview. Consultado em 9 de setembro de 2026.
- OWASP GenAI Security Project. LLM06:2025 Excessive Agency e LLM01:2025 Prompt Injection. Consultados em 9 de setembro de 2026.
- Microsoft Security. AI Application Security Series 1: AI Tools e Microsoft Security Response Center, CVE-2025-32711. Consultados em 9 de setembro de 2026.
- Brasil. Lei nº 13.709/2018, Lei Geral de Proteção de Dados Pessoais, especialmente arts. 6º, 37, 46, 49 e 50. Texto compilado consultado em 9 de setembro de 2026.
- NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. Julho de 2024.
- IBM e Ponemon Institute. Cost of a Data Breach Report 2025. Julho de 2025.
- OECD. G20/OECD Principles of Corporate Governance 2023. Setembro de 2023.
- Debenedetti, E. et al. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. 2024.
- PwC. Global Compliance Survey 2025. 2025.
Sobre o autor
Ion “Zeugh” Neto trabalha com estratégia, arquitetura e operação de sistemas de inteligência artificial. Seu foco é transformar capacidade de modelos em processos verificáveis, com ferramentas, contexto, avaliações e limites de ação adequados ao trabalho real.
Versão editorial de 9 de setembro de 2026. Métricas e capacidades refletem as fontes consultadas nessa data.
