Saber como identificar Shadow AI nas empresas exige ir muito além de monitorar o uso de chatbots no navegador. Essa é, normalmente, a camada mais visível e, por isso mesmo, a mais fácil de confundir com o problema inteiro.
Na prática, o uso não governado de IA se espalha por pelo menos quatro camadas distintas da organização, e cada uma delas exige um tipo diferente de observação. Esse é o erro mais comum que encontramos em organizações que já investiram em descoberta de IA: tratar a visibilidade sobre uma camada como se fosse visibilidade sobre o ambiente inteiro.
Um sensor que monitora atividade no navegador não enxerga uma integração feita via API. Uma ferramenta de CASB que cobre aplicações SaaS aprovadas não vê um agente com acesso a sistemas internos, criado por um time de produto sem passar pelo processo de aprovação.
A sensação de segurança gerada por essa cobertura parcial costuma ser mais perigosa do que a ausência de qualquer sensor, porque ela desestimula a pergunta seguinte.
Este artigo detalha as quatro camadas onde o uso de IA generativa e de agentes autônomos hoje se manifesta dentro de uma empresa, o que cada uma delas consegue (e não consegue) responder sozinha, porque a correlação entre esses sinais é o que efetivamente transforma descoberta em uma visão priorizada de exposição.
Por que Shadow AI é maior do que o navegador
Quando o tema Shadow AI entra em pauta, a primeira imagem que normalmente vem à mente é a de um colaborador colando um trecho de contrato em um chatbot de uso pessoal. Esse cenário existe e é relevante, mas representa apenas uma fração do problema.
O uso não governado de IA hoje acontece em pelo menos quatro frentes diferentes, muitas vezes simultâneas: no comportamento individual de quem usa uma ferramenta de IA generativa no dia a dia; em aplicações de SaaS que já embutem algum recurso de IA, contratadas pela empresa sem que essa característica tenha sido avaliada como parte de um processo de segurança; em integrações e agentes que se conectam a sistemas e dados por meio de APIs, muitas vezes fora do radar de qualquer inventário; e em workloads e aplicações internas construídas com IA, onde o modelo passa a ser parte da própria arquitetura do produto.
Tratar qualquer uma dessas camadas isoladamente como sinônimo de “cobertura de Shadow AI” cria um ponto cego estrutural, não porque a camada observada seja irrelevante, mas porque ela nunca foi desenhada para enxergar as demais.
Camada 1: atividade do usuário
Essa é a camada mais discutida publicamente, e a mais intuitiva de entender: colaboradores acessando ferramentas de IA generativa por conta própria, via navegador ou aplicativo, fora de qualquer processo de aprovação corporativa.
A pergunta que essa camada ajuda a responder é relativamente direta: quem está usando o quê, com que frequência, e (quando há visibilidade de conteúdo) que tipo de dado está sendo inserido nesses prompts. É uma camada essencial porque captura o comportamento humano mais espontâneo diante da IA, geralmente o primeiro ponto de contato de uma organização com o problema.
A limitação dessa camada é igualmente direta: ela não enxerga nada que aconteça fora da interação direta de um usuário com uma interface de IA. Uma integração automatizada entre dois sistemas, feita por um desenvolvedor, não passa por esse tipo de sensor, porque não existe, ali, um usuário digitando um prompt.
Camada 2: aplicações SaaS
A segunda camada cobre um fenômeno menos discutido, mas igualmente relevante: ferramentas de SaaS que a empresa já contratou, muitas vezes por um motivo totalmente alheio à IA, e que passaram a incorporar algum recurso de inteligência artificial em uma atualização de produto, sem que isso tenha sido reavaliado pela área de segurança.
Essa camada responde a uma pergunta específica: quais das aplicações já autorizadas dentro da empresa processam dados usando IA hoje, mesmo que essa capacidade não tenha existido no momento da contratação original? É uma pergunta que raramente aparece em um processo tradicional de gestão de fornecedores, porque pressupõe reavaliação contínua, não apenas aprovação pontual no início do contrato.
A lacuna aqui é sutil: uma aplicação SaaS pode estar corretamente listada no inventário de fornecedores aprovados e, ainda assim, representar uma superfície de risco de IA completamente não avaliada.
Camada 3: APIs, integrações e agentes
Essa camada observa um tipo de uso estruturalmente diferente das duas anteriores: não é mais um humano interagindo com uma interface, e sim sistemas conversando entre si, ou agentes de IA operando com algum grau de autonomia sobre ferramentas, arquivos e dados.
A pergunta central aqui é: quais integrações e agentes têm permissão para acessar sistemas ou dados da empresa, e quem autorizou cada uma dessas conexões?
Diferente do uso individual, esse tipo de acesso costuma ser configurado por times técnicos, muitas vezes com boa intenção operacional e sem qualquer intenção de burlar controle, mas fora do fluxo normal de revisão de segurança, porque a integração nasceu como solução pontual para um problema de produtividade.
O risco documentado por frameworks como o OWASP GenAI Security Project (no Top 10 for LLM and GenAI Applications) reforça porque essa camada exige atenção própria: riscos como excesso de permissão concedida a um agente, ou manipulação de uma cadeia de integrações, dependem diretamente de como essas conexões foram desenhadas e a que elas têm acesso, algo que nenhuma das duas camadas anteriores consegue capturar.
Camada 4: workloads e aplicações construídas com IA
A quarta camada é a mais próxima do desenvolvimento de produto: workloads e aplicações internas onde a IA não é uma ferramenta usada por alguém, mas parte constituinte da própria arquitetura, modelos embutidos em produção, pipelines que processam dado através de um LLM, aplicações que expõem alguma capacidade generativa a usuários finais.
Aqui, a pergunta muda de “quem usa” para “o que foi construído, com que controles e com que exposição”. O NIST AI Risk Management Framework trata esse tipo de risco como parte de um ciclo de vida contínuo, não como um evento único de aprovação. A gestão de risco acompanha a aplicação da concepção à operação, considerando como dados, acesso, integração e uso mudam ao longo do tempo.
A limitação de tratar apenas essa camada é a mais perigosa das quatro: uma aplicação construída com todos os controles de segurança de código convencionais pode ainda assim carregar riscos específicos de IA, como injeção de instruções ou vazamento de dado via resposta do modelo, que só aparecem quando a aplicação é avaliada especificamente sob essa ótica.
Como correlacionar os sinais e priorizar a exposição
Nenhuma dessas quatro camadas, isoladamente, entrega uma visão completa. E nenhuma tecnologia única promete cobrir as quatro com o mesmo nível de profundidade. Qualquer fornecedor que afirme o contrário está simplificando o problema, não resolvendo.
O valor real aparece na correlação. Um mesmo uso de IA pode aparecer, de formas diferentes, em mais de uma camada: um agente descoberto na camada de integrações pode ter sido criado a partir de uma ferramenta identificada na camada de atividade do usuário; uma aplicação SaaS com recurso de IA pode estar alimentando um workload interno através de uma API não documentada.
Sem correlacionar esses sinais, cada camada gera um alerta isolado e nenhum time consegue, sozinho, montar o quadro inteiro a tempo de agir.
Correlacionar significa, na prática, cruzar o que cada camada observa contra um único critério: sensibilidade do dado envolvido, exposição ao público e posição no ciclo de desenvolvimento.
É essa combinação que transforma uma lista de achados dispersos em uma exposição priorizada, separando o que exige ação imediata do que pode ser mapeado e acompanhado dentro de um ciclo normal de revisão.
Vale reforçar: correlacionar sinais não é sinônimo de bloquear tudo o que aparece como não aprovado. Bloqueio indiscriminado não é governança. É, na melhor das hipóteses, uma medida temporária que não resolve a causa, e na pior, um incentivo para que o uso migre para uma camada ainda menos visível.
O que um ponto cego entre camadas custa ao negócio
Até aqui, o problema foi descrito em termos técnicos: sensores, camadas, correlação de sinais. Mas cada lacuna entre camadas se traduz em um tipo concreto de risco para o negócio, não apenas em uma falha de monitoramento.
Um ponto cego na camada de uso individual costuma se traduzir em exposição de dado: informação sensível, contratual ou regulada saindo da empresa dentro de um prompt, sem que exista qualquer registro de que isso aconteceu. Um ponto cego na camada de aplicações SaaS tende a aparecer como risco de conformidade: um fornecedor já aprovado processando dado de forma diferente da que foi avaliada no momento da contratação, sem que o contrato ou a política tenham acompanhado essa mudança.
Um ponto cego comum na camada de APIs, integrações e agentes é aquele que se manifesta como risco operacional: um agente com acesso mais amplo do que o necessário, capaz de tomar ações sobre sistemas de produção sem supervisão direta. E um ponto cego na camada de workloads e aplicações construídas com IA tende a aparecer como risco de continuidade e reputação: uma aplicação exposta ao público que pode ser manipulada para vazar dado ou se comportar de forma inesperada diante de usuários reais.
Nenhum desses quatro cenários depende de um ataque sofisticado para se concretizar. Na maioria dos casos, basta a ausência de correlação entre o que já está acontecendo em cada camada.
Como saber se a minha organização tem esse ponto cego?
Antes de qualquer investimento em nova tecnologia, um pequeno teste ajuda a identificar em qual camada a lacuna é mais provável:
Sua empresa consegue responder, com dado atualizado, quais ferramentas de IA generativa estão sendo usadas por colaboradores agora, incluindo o que não foi formalmente aprovado? Se a resposta depende de suposição, a lacuna provavelmente está na camada de uso individual.
Existe um processo que reavalia fornecedores de SaaS já contratados quando eles passam a incorporar recursos de IA depois da assinatura do contrato? Se essa reavaliação só acontece na renovação, ou não acontece, a lacuna provavelmente está na camada de aplicações SaaS.
Alguém consegue listar, agora, todos os agentes e integrações de IA com acesso a sistemas ou dados da empresa, e quem autorizou cada um? Se essa lista não existe de forma centralizada, a lacuna provavelmente está na camada de APIs, integrações e agentes.
As aplicações internas que usam Inteligência Artificial em produção já passaram por uma avaliação específica de riscos como injeção de instruções ou vazamento de dado via resposta do modelo, além da revisão de segurança convencional? Se essa avaliação nunca aconteceu, a lacuna provavelmente está na camada de workloads e aplicações construídas com IA.
Poucas organizações respondem sim às quatro perguntas ao mesmo tempo. O objetivo desse exercício não é chegar a uma nota, mas identificar qual camada merece atenção primeiro, e é exatamente esse ponto de partida que orienta o trabalho de correlação e priorização descrito neste artigo.
Próximos passos de governança
Descobrir onde a IA está sendo usada, nas quatro camadas, é a base, não o destino final. A partir da correlação entre sinais, o passo seguinte é de governança: quem é o responsável por decidir sobre cada tipo de achado, que critério de exceção existe para um uso de baixo risco, e que processo garante que uma descoberta vire ação, não apenas mais um item registrado em um painel.
A IBLISS estrutura esse caminho através de suas três jornadas de Segurança de IA: Exposição Cibernética, que cobre justamente a identificação e correlação das camadas descritas neste artigo; AppSec e DevSecOps, voltada à análise de aplicações e workloads construídos com IA; e Governança e Cultura, responsável por transformar essa visibilidade em política, papéis e processo de decisão.
Se sua organização já tem algum grau de visibilidade sobre o uso de IA, mas ainda não sabe dizer com confiança onde estão os pontos cegos entre essas quatro camadas, fale com um especialista da IBLISS para estruturar uma abordagem proporcional ao risco do seu ambiente.
Leia mais conteúdos sobre segurança da informação no blog da IBLISS.