O incentivo ao uso de IA nas empresas deixou de ser iniciativa isolada de um time de engenharia. Hoje atravessa comercial, financeiro, infraestrutura, suporte, operações, jurídico, praticamente toda a organização. O discurso é sempre parecido: “use a ferramenta que te ajudar a entregar mais rápido.”

E isso funciona. Só que atuando em infraestrutura e segurança (quase um papel de vilão em alguns casos), tenho acompanhado de perto o outro lado dessa moeda. O lado que raramente aparece no LinkedIn sobre “produtividade turbinada por IA”.

Este artigo não é sobre se a IA vale a pena. É sobre o que acontece quando uma empresa incentiva o uso de IA sem, ao mesmo tempo, construir a maturidade para sustentar esse uso com segurança, um padrão que venho observando de forma recorrente na prática.

E não, esse artigo não foi escrito por IA, eu (Marcelo) estou digitando palavra por palavra. Tudo bem, usei a IA para revisar, admito. 😉

O ganho é real e precisa ser dito

Antes de ir para os potenciais problemas, é importante ser honesto sobre os ganhos, porque eles existem e são muitos:

  • Entregas mais rápidas em times de engenharia, suporte e outros
  • Análise de dados e arquivos em uma fração do tempo que levaria manualmente
  • Organização e estruturação de informação em escala
  • Redução de trabalho repetitivo ou manual em tarefas operacionais
  • Suporte a decisões com dados que antes ficavam represados por falta de tempo de análise

Nenhum desses pontos está em discussão. O problema não é a ferramenta e sim a forma como ela está sendo absorvida pela empresa sem controles equivalentes e necessários.

Quando todo mundo vira arquiteto de solução

Existe um efeito colateral pouco discutido: quando alguém usa IA, é fácil se sentir capaz de resolver qualquer problema, mesmo sem ter o conhecimento técnico necessário para sustentar aquela solução depois.

É comum ver esse padrão se repetir em times técnicos: o entusiasmo em torno da IA gera dispersão. Automações, plugins e soluções paralelas que talvez nem sejam a melhor escolha técnica, consumindo tempo que deveria estar no que realmente importa. Em algumas situações, o responsável por trazer esse “freio” é quem lidera o time, redirecionando o esforço para o que de fato agrega.

E esse é só o efeito visível de um lado. É bastante provável que o mesmo padrão se repita em outras áreas de qualquer empresa que tenha esse mesmo nível de incentivo, sem alguém filtrando.

Quando a IA sugere a permissão errada

Este é o ponto mais sério do artigo, do ponto de vista de segurança.

Cada vez mais, usuários criam agentes e projetos de IA que precisam acessar dados da organização, sejam transcrições de reuniões, arquivos no SharePoint, e-mails ou mensagens no Teams. E aqui mora um problema estrutural, que passa por um detalhe técnico simples de entender, mas que faz toda a diferença.

No Microsoft Entra, existem dois tipos de permissão para uma aplicação acessar dados:

  • Permissão delegada: a aplicação age em nome do usuário logado, com o mesmo nível de acesso que aquele usuário já tem. Se eu só tenho acesso às minhas próprias reuniões, uma aplicação com permissão delegada só vai conseguir ler as minhas reuniões.
  • Permissão de aplicativo: a aplicação passa a ter acesso próprio, independente de qualquer usuário. Não existe “em nome de quem” aqui: é a aplicação inteira que passa a enxergar o dado, em geral, para o tenant inteiro.

Quando alguém pede pra IA ajudar a resolver o problema “meu agente precisa ler as transcrições das reuniões”, a sugestão mais direta e menos trabalhosa, do ponto de vista de implementação, tende a ser: conceda permissão de aplicativo. Funciona, resolve rápido, mas o resultado, muitas vezes sem que o solicitante perceba, é uma aplicação com acesso de leitura a qualquer transcrição de qualquer reunião do tenant inteiro, não só às reuniões de quem está usando o agente.

Se essa credencial vazar, o impacto deixa de ser pontual, restrito a um usuário, e vira organizacional. Não é incomum times de infraestrutura e segurança receberem esse tipo de pedido já pronto: uma solução desenhada, aguardando só a “liberação da permissão”, sem que o solicitante tenha dimensionado o alcance real daquele escopo.

Quando a equipe de infraestrutura e segurança não analisa com cuidado cada uma dessas concessões, o que ela permite, e qual o impacto em caso de vazamento, o risco cresce de forma silenciosa, escondido atrás da narrativa de “estamos inovando”.

Esse problema geralmente é agravado por três fatores:

  1. Cultura: parte das pessoas que criam essas soluções enxerga a revisão de segurança como burocracia, como algo que atrapalha a entrega e não como parte do processo.
  2. Capacidade técnica: nem toda equipe de infraestrutura e segurança tem a maturidade necessária para avaliar, com profundidade, o real impacto de uma permissão solicitada, o que pode levar à aprovação de escopos mais amplos do que o necessário só para não travar a entrega.
  3. Ferramental: o próprio Microsoft 365 tem permissões granulares que só são configuráveis via PowerShell, o que dificulta a configuração correta em times de infraestrutura com pouca maturidade ou pouco preparo técnico.

A combinação desses fatores, incentivo geral ao uso de IA + dificuldade de configurar permissões granulares + cultura que trata segurança como obstáculo, é a receita para um incidente que só vai aparecer como manchete depois que já tiver acontecido.

Não é uma percepção isolada

Vale reforçar que esse é um padrão identificado no mercado como um todo, não uma situação pontual de uma empresa específica ou percepção individual. Os dados sustentam a preocupação:

  • Empresas em que a IA expandiu significativamente o número de identidades com acesso a dados registraram uma taxa de violação de segurança quatro vezes maior no último ano, comparado a organizações onde esse padrão de acesso não mudou (Netwrix, 2026).
  • O acesso de funcionários a ferramentas de IA cresceu 50% em um ano, mas apenas uma em cada cinco empresas possui um modelo de governança maduro para agentes autônomos (Deloitte, State of AI in the Enterprise, 2026).
  • Boa parte da adoção de IA em empresas acontece “de baixo para cima”, por iniciativa de times individuais, sem gestão central, o que é exatamente o padrão descrito neste artigo (Wiz, State of AI in the Cloud, 2026).

Ou seja, o que se observa na prática, no dia a dia de infraestrutura e segurança, é o retrato de um problema estrutural do momento atual do mercado e não uma exceção isolada.

Da liberdade ao controle

Diante desse cenário, minha posição não é “trave o uso de IA”. É a de que incentivo sem estrutura mínima é irresponsabilidade de gestão, e isso precisa ser dito com todas as letras, inclusive para diretoria e liderança.

Algumas boas práticas que considero essenciais para equilibrar incentivo e segurança:

  1. Política de uso de IA: regras claras sobre quais ferramentas podem ser usadas e em que contexto.
  2. Documentação de permissões: todo agente, aplicação ou integração de IA que acessa dados corporativos precisa ter suas permissões documentadas e revisadas, com clareza sobre o impacto em caso de vazamento.
  3. DLP e classificação de dados: políticas de prevenção contra perda de dados (DLP) bem configuradas ajudam a impedir que um agente ou aplicação de IA extraia ou compartilhe informação sensível, mesmo quando a permissão concedida é mais ampla do que deveria. É uma camada de proteção que atua onde a governança de permissão, sozinha, não alcança.
  4. Monitoramento ativo em cenários críticos: nem todo acesso tem o mesmo peso. Soluções de IA que tocam dados sensíveis, folha de pagamento, jurídico, propriedade intelectual, merecem monitoramento mais próximo, com alertas e revisão periódica, não apenas uma aprovação pontual no momento da criação.
  5. Limite definido e comunicado: a empresa precisa estar confortável em dizer “essa ideia é boa, mas não é aderente às práticas de segurança da empresa.” Isso exige comprometimento real da gestão e da diretoria. Entender que acelerar entregas não pode ser feito a qualquer custo, porque o problema criado agora aparece lá na frente e pode custar caro.

Vale mencionar que esse movimento já está começando a aparecer também do lado dos fornecedores. A Microsoft lançou recentemente o Agent 365 e o conceito de Entra Agent ID, tratando agentes de IA como identidades isoladas com dono, ciclo de vida, revisão periódica de permissões e políticas de acesso condicional próprias, reconhecendo na prática, o mesmo problema que descrevo aqui: agente de IA com acesso a dado sensível precisa ser governado com o mesmo rigor que qualquer identidade humana ou de serviço.

A IA generativa não é o problema. O problema é tratá-la como incentivo sem contrapartida de controle. Empresas que incentivam o uso massivo de IA sem investir, na mesma proporção, em política, documentação e limites, estão apenas adiando um incidente e não evitando ele.

Fontes utilizadas

  • Netwrix, 2026 Data and Identity Security Report — dados sobre expansão de identidades com acesso a dados via IA e taxa de violação: netwrix.com
  • Deloitte, State of AI in the Enterprise (2026) — crescimento de acesso a IA e maturidade de governança de agentes autônomos, citado via Wiz: wiz.io
  • Wiz, State of AI in the Cloud Report (2026) — adoção “bottom-up” de ferramentas de IA nas empresas: wiz.io
  • Microsoft, Microsoft Agent 365 entra em disponibilidade geral (maio 2026): news.microsoft.com
  • Microsoft Learn, Governança e segurança para agentes de IA em toda a organização — Cloud Adoption Framework: learn.microsoft.com
  • Microsoft Learn, Visão geral do SDK de Agentes do Microsoft 365: learn.microsoft.com