Elton José logo
Elton José
Shadow AI

Shadow AI: 96% das Empresas Rodam Agentes em Produção, Só 12% Têm Plataforma para Governá-los

Shadow AI: 96% das Empresas Rodam Agentes em Produção, Só 12% Têm Plataforma para Governá-los
0 visualizações
20 minutos de leitura
#Shadow AI

Shadow AI: 96% das Empresas Rodam Agentes em Produção, Só 12% Têm Plataforma para Governá-los

A reunião de fechamento de orçamento do trimestre costuma ser a hora mais chata do meu mês, e foi ali que este post começou. Finance projetou na tela uma linha de cartão corporativo com cobrança recorrente para um provedor de modelo. Valor pequeno, três dígitos. A pergunta que veio junto foi banal: de quem é essa conta? Ninguém na sala sabia responder.

Levou dois dias para descobrir. Era um time de dados que precisava de um resumidor e não quis esperar o ciclo de compras — legítimo, defensável, e o gasto nem era o ponto. O ponto é que uma credencial de provedor de modelo, com acesso programático e sem dono registrado, existiu por meses e só apareceu porque calhou de virar uma linha numa planilha de custo.

Fui atrás do resto na mesma semana, e aí o buraco cresceu. A lista de aplicativos OAuth conectados ao Workspace tinha mais de uma dúzia de integrações com "AI" no nome que eu nunca vi passar por conversa de arquitetura, de compras ou de segurança: transcritor de reunião, resumidor de e-mail, plugin de pesquisa, e dois ou três agentes que alguém montou num sábado e conectou no Drive com permissão de leitura bem generosa. Nada daquilo foi má-fé. Foi gente tentando fechar a semana. O que me incomodou não foi descobrir que existe uso de IA que eu não aprovei — isso eu já suspeitava. Foi perceber que eu não tinha mecanismo nenhum para saber daquilo antes, e que a política de uso de IA que a gente escreveu no começo do ano não menciona nenhuma daquelas categorias.

É esse fio que quero puxar hoje. Circulou uma pesquisa com número grande e manchete fácil sobre o tema, e quero fazer duas coisas: separar o que o dado realmente mede do que a manchete sugere, e montar um caminho prático que um head de tecnologia consegue executar sem virar o cara que proíbe. Porque proibir não funciona, e entender exatamente por quê é a parte mais útil aqui.


O Número Da Manchete E O Que Ele Realmente Mede

A pesquisa é o State of AI Development 2026 da OutSystems, com quase 1.900 líderes de TI globais, respostas coletadas entre dezembro de 2025 e janeiro de 2026. Os números centrais: 96% das organizações já usam agentes de IA em alguma capacidade, 97% exploram estratégias agênticas em escala de sistema, 49% descrevem a própria capacidade como avançada ou expert, e 94% relatam preocupação com o sprawl de IA aumentando complexidade, dívida técnica e risco de segurança.

O número que virou manchete é o 12%, e vale ler com cuidado o que ele mede. O release da OutSystems diz que 12% implementaram uma plataforma centralizada para gerenciar o sprawl, e que a maioria ainda está experimentando abordagens de governança que variam por time e por região. Não é exatamente "só 12% conseguem governar seus agentes"; é "só 12% têm plataforma central para isso". A diferença importa, porque governar sem plataforma centralizada é possível, só é mais caro e mais frágil.

Dito isso, o resto do levantamento não deixa a leitura pessimista sem base. Trinta e oito por cento das organizações misturam agentes construídos internamente com agentes pré-prontos no mesmo stack, o que cria ambiente difícil de padronizar e de auditar, e 52% já operam num modelo human-on-the-loop, com agentes rodando sob supervisão em vez de aprovação direta. A autonomia subiu, a heterogeneidade subiu, e a camada de controle não acompanhou nenhuma das duas.

Some a isso a projeção da Gartner de que 40% das aplicações corporativas terão agentes específicos por tarefa até o fim de 2026, contra menos de 5% em 2025. Se essa curva se confirmar, a superfície que você precisa governar não é a de hoje: é uma superfície muitas vezes maior, chegando embutida em ferramentas que você já comprou, sem passar por um novo ciclo de procurement.

O que esses números descrevem juntos não é uma empresa negligente. É uma empresa que fez tudo certo pelo manual antigo — aprovou ferramenta, revisou contrato, avaliou fornecedor — e descobriu que o manual pressupõe que a ferramenta entra por um portão controlado. IA generativa não entra por portão: entra por aba de navegador, extensão, conta pessoal, chave de API commitada e agente montado numa tarde.


Shadow AI Ultrapassou Shadow IT, E A Diferença É Estrutural

O relatório da CloudFuze, montado a partir de conversas com mais de 100 líderes de TI ao longo de 2026, coloca isso de forma direta: shadow AI passou shadow IT como a preocupação número um de TI. O padrão que aparece em quase toda conversa é o mesmo — funcionário se cadastrando em ChatGPT, Claude, Gemini e afins com o e-mail corporativo, sem que TI saiba até que um log de login ou uma extensão de navegador denuncie.

A diferença estrutural entre shadow IT e shadow AI é o que torna o problema mais difícil, não mais barulhento. Shadow IT era um SaaS que alguém assinou com cartão corporativo: existe fatura, existe domínio, existe um lugar para olhar. Shadow AI muitas vezes não gera fatura nenhuma, porque a camada gratuita já resolve o problema do funcionário. Segundo o Netskope Cloud and Threat Report 2026, citado na análise da MarkTechPost sobre governança corporativa de IA, 47% dos usuários de IA generativa em ambiente corporativo acessam essas ferramentas por contas pessoais e não gerenciadas — ou seja, nenhuma política de DLP corporativa está no caminho do dado.

E o custo disso já tem número. O Cost of a Data Breach 2025 da IBM incluiu shadow AI como fator de brecha pela primeira vez: brechas com shadow AI envolvido custaram em média 4,63 milhões de dólares contra 3,96 milhões das brechas padrão, uma diferença de cerca de 670 mil dólares por incidente, e shadow AI apareceu em uma a cada cinco brechas estudadas. Entre as organizações que sofreram incidente relacionado a IA, 97% relataram não ter controles de acesso adequados para IA, e 63% não tinham nenhuma política de governança de IA no lugar.

Esses 63% me incomodam mais do que os 12% da manchete. Implementar plataforma centralizada é caro e leva trimestres; escrever uma política que descreva o que é dado sensível no contexto de IA e quais ferramentas estão liberadas para qual tipo de dado custa uma semana de trabalho de alguém sênior. A distância entre não ter nada e ter o básico é curta, e a maioria não percorreu.

Shadow AI, no fim, não é sintoma de indisciplina. É descompasso entre a velocidade com que indivíduos adotam capacidade nova e a velocidade com que a organização adapta o controle. Enquanto o time de governança discute o framework, o desenvolvedor já colou o stack trace no chat e fechou o ticket — fazendo exatamente o que a empresa pede dele.


Por Que Proibir Não Funciona

A reação intuitiva é banir. E é aqui que os dados são mais claros e mais desconfortáveis.

O caso Samsung de 2023 continua sendo o exemplo mais citado porque comprime todo o problema em vinte dias. A empresa liberou o uso de ChatGPT com uma política em formato de memorando — um aviso de limite de 1.024 bytes por prompt — e sem nenhuma aplicação técnica. Em menos de três semanas houve três incidentes: código-fonte proprietário colado para depuração, código de detecção de defeito em equipamento de semicondutor enviado para otimização, e transcrição de reunião interna processada por ferramenta externa. Em nenhum deles o funcionário estava sendo imprudente pelo próprio padrão dele.

A lição estrutural não é sobre o ChatGPT, é sobre enquadramento: quando o funcionário percebe a IA como "ferramenta de produtividade" e não como "serviço externo de processamento de dado", ele aplica o modelo mental errado sobre o que é seguro compartilhar. Política sem enforcement técnico é aspiração, não é segurança.

Depois dos incidentes, a Samsung baniu o ChatGPT. E é aí que a segunda parte do problema aparece: banir uma ferramenta específica sem resolver a tarefa subjacente produz substituição, não eliminação. O Netskope aponta que aproximadamente 90% das organizações bloqueiam pelo menos uma aplicação de IA por motivo de segurança, e bloqueio no nível de rede não impede acesso por dados móveis pessoais nem por conta pessoal no navegador. O que o bloqueio faz, com eficiência notável, é destruir a sua visibilidade. O risco não fica menor, fica invisível.

Tem ainda o motivo mais prosaico: 27% dos que usam ferramentas não aprovadas dizem que fazem isso porque a não aprovada é melhor do que a liberada. Não é rebeldia, é resposta racional a uma lacuna de ferramental. Se o stack corporativo não cobre revisão de código, resumo de documento e análise de dado, o funcionário vai cobrir sozinho, independentemente da política.

A conclusão prática é curta. Proibição sem alternativa não reduz uso, reduz visibilidade. Uma política que os funcionários entendem mas ignoram rotineiramente não é framework de governança, é documento de isenção de responsabilidade.


Governed Enablement: Trocar A Pergunta Antes De Trocar A Ferramenta

As organizações que estão lidando melhor com isso em 2026 não são as do bloqueio mais agressivo. São as que reformularam a pergunta: saíram de "como impedimos o uso de IA não autorizada" para "como canalizamos esse uso para caminhos governados e monitorados, preservando o ganho de produtividade e controlando o risco".

Essa troca não é retórica. Se o objetivo é impedir, você investe em bloqueio, auditoria punitiva e treinamento sobre o que não fazer. Se é canalizar, você investe em descoberta contínua, em alternativa sancionada genuinamente boa, em classificação de dado que ajude a pessoa a decidir sozinha, e em telemetria que te diga onde o caminho sancionado ainda não é o mais fácil. O critério de sucesso muda junto: num programa proibicionista, sucesso é uso zero de ferramenta não aprovada, o que é inatingível e por isso vira teatro; na habilitação governada, sucesso é a proporção do uso que passa por canal governado subindo trimestre a trimestre. É métrica que você consegue mover.

Já falei em governança de IA e controle de agentes sobre a diferença entre controle que atrapalha e controle que habilita, e a lógica é a mesma aqui, aplicada ao funcionário em vez do agente. Vale também revisitar o argumento de governança enterprise e compliance como vantagem competitiva: quem consegue provar o que seus sistemas de IA fazem escala mais rápido, porque não precisa parar a cada incidente para reconstruir confiança interna.

O jeito mais honesto de resumir o princípio é esse: o caminho governado precisa ser mais fácil que o caminho não governado. Se a ferramenta aprovada exige três aprovações e a não aprovada exige um clique, a política perdeu antes de ser publicada.


O Playbook Em Cinco Camadas

Aqui é onde eu tento traduzir isso em coisas que dá para começar na segunda-feira. São cinco camadas, e a ordem importa, porque cada uma depende do que a anterior produziu.

Inventário Honesto

Você não governa o que não enxerga, e essa é a etapa que quase todo mundo pula porque parece burocrática demais para render história. Ela rende. Meia dúzia de fontes de descoberta dá resultado rápido e nenhuma delas exige comprar ferramenta: a lista de aplicativos OAuth conectados ao Workspace ou ao M365, que foi onde eu me assustei; logs de proxy ou de DNS filtrados por domínios de provedores de IA; faturas de cartão corporativo procurando assinatura individual, que foi por onde a minha história começou; extensões de navegador nos dispositivos gerenciados; e uma varredura de chaves de API de provedores de modelo nos repositórios. Duas semanas de trabalho focado de uma pessoa dão um mapa razoável do que existe.

O erro mais comum nessa etapa não é falta de rigor na coleta, é o destino do resultado: o inventário vira planilha produzida sob a pressão de uma auditoria, apresentada num comitê e arquivada até a próxima. Ele precisa ser artefato vivo, com dono nomeado e revisão trimestral, porque a superfície que você está mapeando muda mais rápido do que qualquer ciclo anual de compliance. Um mapa de janeiro descreve uma empresa que não existe mais em julho.

Classificação De Dado Antes De Classificação De Ferramenta

Esta é a inversão que mais gente erra, e erra de boa-fé. O instinto é começar pela lista de ferramentas, porque é a parte que parece acionável. Mas sem uma definição operacional do que conta como sensível no contexto de processamento externo, o funcionário não consegue decidir bem por mais clara que a lista seja. "Não cole dado confidencial" não significa absolutamente nada para quem não sabe se um log de produção com ID de usuário conta como confidencial.

O que funciona é escrever três ou quatro categorias com exemplos tirados do seu próprio domínio: código de repositório privado, dado de cliente identificável, projeção financeira não publicada, transcrição de reunião interna. Exemplo vale mais que definição, porque a decisão que o funcionário toma é sempre sobre um caso concreto na frente dele, não sobre uma taxonomia — e quando a categoria é reconhecível, ele consegue estender o julgamento a situações que você não previu, que é o que qualquer política precisa habilitar.

Três Níveis De Ferramenta

Com as categorias de dado no lugar, a lista binária de aprovado e proibido pode dar lugar a três faixas. A primeira é a ferramenta plenamente aprovada, que opera sob as regras normais de tratamento de dado e não exige raciocínio adicional de ninguém. A segunda é a de uso limitado: aprovada com uma regra amarrada a uma categoria de dado — liberada para código open source mas não para código de produto ainda não lançado, por exemplo. A terceira é a proibida de fato, com perfil de risco inaceitável por tratamento de dado não conforme ou ausência de acordo de processamento.

Esse modelo faz duas coisas ao mesmo tempo, e a segunda é a que mais importa. A primeira é dar ao funcionário um critério acionável, em vez de um sim ou não que ele sabe que é grosseiro. A segunda é criar um canal para o shadow AI migrar para dentro: com uma faixa intermediária, a ferramenta hoje usada às escondidas tem para onde ir sem que alguém precise admitir uma infração. Lista binária empurra para a clandestinidade tudo que não é claramente aprovado, porque não sobra opção honesta.

Identidade E Governança De Acesso, Inclusive Para O Que Não É Humano

Aqui a conversa deixa de ser sobre o funcionário e passa a ser sobre o agente que ele criou. Todo agente precisa ser tratado como principal distinto, com credencial própria, permissão explícita e ciclo de vida documentado — não como extensão da identidade de quem o construiu. Na prática isso é um registro central com um punhado de campos por entrada:

  • quem é o responsável humano
  • que dados e sistemas o agente acessa
  • quando foi criado e com qual propósito declarado
  • qual é a data de revisão seguinte

Depois do registro vem a separação: conta de serviço distinta por especialização, para que um agente de suporte e um de relatório financeiro nunca compartilhem credencial — credencial compartilhada destrói qualquer possibilidade de atribuir uma ação a um agente específico depois. E vem o processo explícito de aposentadoria, conduzido com o mesmo rigor de um desligamento de funcionário: revogar acesso, encerrar credencial, registrar a data. Detalhei essa parte em IAM e identidades não-humanas para agentes, e o ponto que mais se aplica aqui é o acúmulo silencioso — um agente provisionado com leitura ampla em janeiro continua exercendo aquela permissão em agosto, muito depois do propósito original ter mudado ou desaparecido.

Rastreabilidade Que Serve Para Investigar, Não Só Para Arquivar

A última camada é a que separa quem consegue responder a um incidente de quem só consegue confirmar que ele aconteceu. Log tradicional registra qual dado foi acessado; governança de agente exige registrar por que ele foi acessado e o que resultou disso. O mínimo que vale capturar em cada ação é o identificador e a versão do agente, as permissões delegadas naquela execução específica, a ferramenta ou API invocada, a decisão da política — permitir ou negar — e o passo de raciocínio que o agente gerou antes de agir.

Esse último campo é o que mais se paga e o que mais gente corta por parecer verboso. Ele separa saber que um agente apagou um arquivo de entender por que ele achou que apagar era correto, e as duas coisas levam a correções diferentes: uma leva a revogar permissão, a outra a corrigir uma instrução ambígua.

O destino do log importa tanto quanto o conteúdo: ele precisa ir para o SIEM em tempo real, porque auditoria periódica é controle detectivo desenhado para violação em velocidade humana, e agente não opera nessa velocidade. E essa camada tem um consumidor externo além de você — documentação de política sem log de enforcement não sustenta conversa com auditor sob o EU AI Act, onde a pergunta nunca é se a política existe, é se ela foi aplicada.


Quando Shadow AI Vira Shadow Agent

Tudo o que descrevi até aqui trata de uma superfície que ainda era, em boa medida, uma aba de navegador. O risco que cresce mais rápido é outro: agentes construídos por gente que não é do time de plataforma. Alguém com acesso ao Copilot Studio, às capacidades de IA do Zapier, ou simplesmente a uma chave de API de um provedor de modelo, monta em uma tarde um workflow que processa dado de negócio, envia comunicação externa e toma decisão operacional. Um agente não autorizado com acesso OAuth persistente ao CRM, ao e-mail e ao calendário não é só exposição de dado: é um sistema autônomo operando dentro de infraestrutura crítica, sem controle de governança, continuamente e em velocidade de máquina.

Os vetores dessa camada são conhecidos e ainda pouco cobertos pelos programas que eu vejo: servidores MCP expondo APIs internas sem revisão, extensões de navegador com capacidade agêntica rodando em toda página que o funcionário visita, tokens de API criando cadeias de acesso não monitoradas, e — o que mais me preocupa no dia a dia de engenharia — a instalação casual de extensões de comportamento vindas de repositórios públicos, assunto que discuti ontem ao falar sobre marketplaces de skills como superfície de risco.

O que quebra aqui é o pressuposto temporal do controle. Frameworks de governança foram desenhados para interação iniciada por humano, em sessões discretas. Um agente comprometido exfiltra volume grande de registro antes de um ciclo de auditoria de 24 horas sequer começar.

A resposta, na prática, é mover a decisão de política para o momento da execução: em vez de conceder escopo no início da sessão e confiar, avaliar cada ação contra a política antes de executar. Controle de acesso baseado em atributo faz o trabalho pesado aqui — filtro por linha e máscara por coluna, de forma que um agente de detecção de fraude enxergue valor e horário da transação sem enxergar número de cartão nem nome do cliente, não por falta de acesso ao banco, mas porque a governança filtra o retorno na consulta. E some detecção de anomalia: se um agente que normalmente lê dez registros por execução de repente lê dez mil, isso precisa escalar antes de a execução continuar, não depois do relatório mensal.


Fazendo Isso Caber Numa Organização Real

Nada disso funciona se ficar dentro de um único time. Governança de IA que vive só em TI e segurança produz política que endereça a superfície de risco que TI enxerga, e essa não é a superfície que existe. O desenho que tenho visto funcionar distribui a propriedade: jurídico assume exposição contratual, compliance assume o mapeamento regulatório, líderes de unidade de negócio assumem o inventário de casos de uso — são a única camada com visibilidade real dos fluxos que os times deles rodam sobre IA —, segurança assume detecção e resposta, TI assume controle técnico e o stack sancionado. Um comitê com poder real de aprovar, pausar ou rejeitar um deploy de agente costura tudo isso.

Sobre a política escrita, o formato importa mais do que a gente admite. Uma página que a pessoa lê em três minutos e consegue aplicar vence um documento de vinte páginas juridicamente perfeito que ninguém abre. E o mecanismo de reforço mais eficaz não é o bloqueio duro, é o aviso contextual no momento da decisão: quem cola dado e recebe um alerta de que aquele documento parece conter dado pessoal de cliente recebeu orientação acionável exatamente onde a decisão está sendo tomada.

Por último, meça a governança em si, não só a contagem de incidente. Três indicadores: taxa de falso positivo, ou seja, ações legítimas bloqueadas por política rígida demais — se esse número sobe, seus usuários vão contornar o controle e você volta à estaca zero; tempo médio até detecção de uma violação; e incidentes por cada cem agentes em produção, que é o que te diz se você está escalando com segurança ou só escalando.


Conclusão

Voltando àquela linha de cartão corporativo: o que me incomodou não foi a conta de API, e nem a lista de OAuth que veio atrás dela. Foi a constatação de que as duas existiam havia meses e o único motivo de eu ter visto foi uma reunião de orçamento onde alguém do financeiro perguntou de quem era um gasto de três dígitos. Se a descoberta de uso de IA na sua empresa depende de o controle de custo tropeçar nela primeiro, você não tem programa de governança, tem sorte intermitente.

O caminho maduro, pelo que os dados e a prática apontam, não é o do controle mais rígido. É o da habilitação governada: dar ao funcionário um caminho sancionado que seja genuinamente melhor do que o alternativo, e ao mesmo tempo reduzir risco com visibilidade contínua, classificação de dado utilizável, governança de acesso que trate agente como identidade de primeira classe, e rastreabilidade que sirva para investigar de verdade. Nenhuma dessas cinco camadas depende de comprar a plataforma dos 12%. Todas dependem de decidir que o problema é seu.

Não tenho isso resolvido no meu time, e seria desonesto escrever como se tivesse. Estou na camada um, montando o inventário, e já sei que ele vai me mostrar coisa que eu preferia não ver. Mas prefiro descobrir agora, no meu ritmo, do que descobrir depois no ritmo de um incidente — a distância entre esses dois momentos costuma ser a distância entre uma tarde de trabalho chato e uma conversa muito ruim com o jurídico.

Fontes:

Newsletter

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

Um resumo semanal com os melhores posts sobre IA, engenharia de software e tecnologia, enviado no melhor momento para continuar a conversa depois da leitura.

Foto de Elton José

Escrito por

eltonjose

Engenheiro de software e estrategista de produtos digitais, focado em IA pragmática e em transformar experiências de trabalho remoto em aprendizados aplicáveis. Compartilho frameworks e decisões reais que uso em consultorias e projetos.

  • Principais temasShadow AI, Governança de IA
  • Formato do conteúdoGuia prático + insights de carreira