Shadow AI no desenvolvimento: educar e monitorar funciona mais do que proibir

Um desenvolvedor trava em um bug e, para resolver, decide colar o trecho de código no Claude Code. A solução é recebida em poucos segundos. O problema é que, junto com o trecho colado, foram algumas informações estratégicas da empresa: uma chave de API, a lógica de um produto ou dados de clientes. Ninguém aprovou, ninguém viu e o time de segurança nem tem como saber que isso aconteceu.

Essa cena é cada dia mais comum. A pressão por produtividade faz com que engenheiros e analistas usem a IA generativa numa velocidade que a governança não acompanha. E a adoção vem de baixo para cima: o dev escolhe a ferramenta que ele mais gosta e não espera processo de compra para começar.

Esse movimento tem nome: Shadow AI.

Shadow AI é o uso de modelos e ferramentas de IA fora do radar das equipes de segurança, e já aparece nos relatórios do setor como o próximo grande vetor de risco em desenvolvimento de software.

Mas sim, é possível incorporar IA generativa sem desmontar os controles de DevSecOps, desde que haja visibilidade, auditoria e guardrails bem desenhados.

O que é Shadow AI no contexto de engenharia de software

No vocabulário tradicional de TI corporativa, a “Shadow IT” sempre representou o uso de hardwares ou softwares sem o conhecimento do departamento de tecnologia. O Shadow AI é a evolução natural (e potencialmente mais perigosa) desse conceito.

O fenômeno vai além de simplesmente alguém digitando uma pergunta no ChatGPT. Ele pode aparecer em camadas mais difíceis de enxergar, como instâncias pessoais do GitHub Copilot vinculadas a contas privadas do dev, extensões obscuras no VS Code, bibliotecas que embarcam chamadas a LLMs de terceiros e até agentes que rodam dentro do ambiente sem qualquer inventário.

O relatório State of AI-Native Application Security 2025, da Harness, ouviu 500 profissionais de segurança nos Estados Unidos, Reino Unido, França e Alemanha. O dado que mais preocupou: 62% afirmam não ter qualquer visibilidade sobre onde os modelos de linguagem estão sendo usados na organização. Três em cada quatro acreditam que o Shadow AI vai superar os riscos que o Shadow IT já causou.

Uma pesquisa da Grip Security vai na mesma direção e estima que 91% das ferramentas de IA dentro das empresas estão fora de qualquer gestão.

Há um desafio técnico que dificulta essa execução. As ferramentas clássicas de SecOps foram desenhadas para código estático. SAST e DAST analisam o código-fonte e a aplicação em execução, mas não enxergam o que sai pela janela de um prompt. Elas não foram programadas para ler um log de chat ou analisar a intenção de um prompt de linguagem natural.

Quando um dev cola um segredo em um chat, nenhum scanner de vulnerabilidade tradicional registra o vazamento. O dado já está fora, e a empresa só descobre quando o estrago aparece.

No Brasil, esse risco ganha um peso extra por causa da LGPD. Se o trecho colado no modelo contém dados pessoais de clientes, a empresa pode estar transferindo informação protegida para um terceiro sem base legal nem contrato que regule o tratamento. Em setores como financeiro e saúde, um vazamento desse tipo deixa de ser falha técnica e vira exposição jurídica e de reputação.

Os novos vetores de risco no CI/CD

A entrada da IA generativa na esteira de produção cria categorias de risco que não existiam no fluxo tradicional.

Exposição de propriedade intelectual

Quando trechos de código-fonte são colados em modelos públicos, parte do que define o produto da empresa pode ser usada para treinar sistemas de terceiros. Isso é como entregar a receita para quem quiser replicá-la.

Vazamento de secrets e credenciais

Para pedir ajuda com um bug, é comum colar o erro inteiro, com tokens, strings de conexão e chaves de acesso no meio. Esses segredos passam por uma API externa e podem ficar registrados em logs sobre os quais a empresa não tem qualquer poder.

Código gerado com falhas e alucinações

A IA (ainda) às vezes inventa bibliotecas que não existem ou sugere padrões inseguros com aparência de boa prática. Se a revisão humana confia demais na sugestão, a vulnerabilidade pode entrar em produção.

Na pesquisa da Harness, 66% dos respondentes já lidaram com algum incidente envolvendo código de LLM vulnerável.

Framework operacional: como auditar e construir guardrails

Reduzir o risco não significa reinventar a segurança da empresa toda, mas exige adaptar práticas que os times de DevSecOps já conhecem. Para isso, é preciso construir barreiras de proteção (guardrails), estabelecer um framework de DevSecOps que contemple especificamente o uso de LLMs, abordando visibilidade, controle de acesso e políticas automatizadas.

Isso pode acontecer em quatro passos:

Passo 1: Visibilidade e auditoria de APIs

Antes de bloquear, é preciso enxergar. O primeiro passo é descobrir o que já está em uso. A ISACA recomenda começar pelos logs de rede e de endpoint, que capturam o tráfego para provedores como OpenAI e Anthropic. Times que rodam essa varredura costumam encontrar dezenas de ferramentas ativas que a liderança nem tinha conhecimento.

Passo 2: Gestão de acesso e proxy de IA

Uma vez que o tráfego é identificado, a empresa não deve simplesmente cortar o acesso, mas sim redirecioná-lo de forma segura. Em vez de cada dev falar direto com o modelo externo, as requisições passam por um gateway corporativo. Esse ponto centraliza o tráfego, higieniza os prompts antes do envio (removendo segredos e dados sensíveis) e registra quem chamou o quê.

Passo 3: Auditoria de logs de prompt

Monitorar não significa ler a conversa de cada engenheiro. Isso, além de um problema de privacidade, criaria um gargalo burocrático. Significa, no entanto, rastrear padrões de risco: envio de credenciais, colagem de blocos grandes de código proprietário, picos de uso fora do esperado. O objetivo é flagrar exposição sem virar vigilância sobre o trabalho do time.

Passo 4: Políticas “shift-left” para IA

“Shift-Left” significa trazer as verificações de segurança para o mais cedo possível no ciclo de desenvolvimento. Isso deixa claro, desde a IDE, o que é permitido. Regras embutidas no fluxo avisam o dev no momento da ação, em vez de barrar tudo depois, quando o vazamento já ocorreu.

Adotar essas políticas envolve a distribuição de perfis de configuração via MDM (Mobile Device Management) que bloqueiam a instalação de extensões de IA não homologadas nas IDEs corporativas.

Equilibrando produtividade e segurança

A reação de muitos líderes ao descobrir o tamanho do problema do Shadow AI é a proibição da IA generativa no ambiente de trabalho. Essa costuma ser a pior estratégia de segurança possível.

O bloqueio total não elimina o uso, apenas o empurra para o celular pessoal e para contas que ninguém monitora, onde o risco fica ainda maior. Uma pesquisa recente apontou que 56% dos profissionais de segurança reconheceram o uso de IA por funcionários da organização sem aprovação formal.

A alternativa que funciona é oferecer caminhos seguros e convenientes para que ninguém precise sair deles. Instâncias corporativas privadas, com contrato que impede o uso dos dados para treino, modelos hospedados internamente e integrações homologadas entregam os mesmos benefícios e velocidade sem o risco do vazamento. Quando o caminho oficial é tão bom quanto o atalho, o atalho perde a graça.

Os números ajudam a justificar o investimento. O relatório Cost of a Data Breach 2025, da IBM, calcula que incidentes envolvendo Shadow AI adicionam, em média, 670 mil dólares ao custo de uma violação de dados. Entre as organizações que sofreram brechas relacionadas a IA, 97% não tinham controles de acesso adequados . Construis o caminho seguro custa quase nada comparado ao custo do incidente que ele é capaz de evitar.

A segurança precisa correr na mesma velocidade do código

A IA generativa não vai sair da esteira de desenvolvimento, e tentar fingir que ela não está lá só amplia o ponto cego. Sair desse ponto cego é trabalho de engenharia, não de proibição: inventariar, centralizar o acesso, monitorar e definir regras claras.

O surgimento do Shadow AI é um reflexo claro de que as equipes de engenharia estão ávidas por inovação, mas também é um alerta de que a segurança precisa evoluir na mesma velocidade.

Construir pipelines robustos, dominar IA generativa e proteger dados ao mesmo tempo exige mais do que tutoriais soltos. A Pós Tech e o MBA em Cyber Security e Engenharia de Software da FIAP foram desenhados para esse profissional que precisa entregar rápido sem abrir brechas, com método e visão de infraestrutura moderna.

Olhando para o seu próprio ambiente: você sabe, agora, quantas ferramentas de IA estão conectadas ao seu pipeline e o que cada uma delas envia para fora?

Quer acompanhar as discussões sobre segurança, IA e carreira em tecnologia? Assine a newsletter do Radar Tech: fiap.com.br/radar-tech/newsletter