Shadow AI é a utilização não autorizada de ferramentas, modelos e agentes de IA por parte dos colaboradores, sem o conhecimento ou a aprovação da TI. A prática está muito disseminada e é, em grande medida, invisível para as equipas de segurança, o que explica precisamente o seu custo elevado.
Segundo o relatório de 2025 da IBM, as organizações com níveis elevados de shadow AI pagam mais 670 000 dólares por violação de dados do que as que têm níveis baixos ou nulos, o que eleva o total esperado para 4,63 milhões de dólares. Esta diferença reflete fluxos de dados não monitorizados, acessos a modelos sem governação e credenciais transmitidas a serviços de IA de terceiros fora de qualquer perímetro de segurança.
A dimensão do fenómeno é mais difícil de ignorar do que a maioria das equipas de segurança prevê. Programadores, equipas financeiras, de RH e de operações estão todos a adotar ferramentas de IA por iniciativa própria. Este artigo explica o que é, na prática, a shadow AI em ambientes empresariais, porque cria exposição em matéria de segurança e conformidade e o que as equipas de TI podem fazer para se antecipar.
O que é a Shadow AI?
A shadow AI é qualquer ferramenta, modelo, plug-in ou agente de IA utilizado numa organização sem aprovação explícita da TI ou da segurança. Situa-se na interseção entre a shadow IT (TI paralela) e a IA generativa, herdando os pontos cegos de governação da primeira e acrescentando os riscos de tratamento de dados da segunda. De acordo com dados da Varonis, 98 % das organizações têm colaboradores a utilizar aplicações não autorizadas, incluindo shadow AI.
O âmbito é mais vasto do que a maioria das equipas de segurança supõe.
| Categoria | Exemplos | Risco principal |
|---|---|---|
| Ferramentas de IA generativa | Contas pessoais de ChatGPT, Claude e Gemini utilizadas em tarefas profissionais | Dados sensíveis enviados para servidores de terceiros sem acordos empresariais de tratamento de dados |
| Extensões de navegador com IA | Verificadores gramaticais, ferramentas de resumo e assistentes de reuniões | Processamento silencioso do conteúdo das páginas, incluindo documentos internos e credenciais |
| SaaS de IA não aprovado | IA jurídica, ferramentas de texto para marketing e assistentes de código adotados por equipas individuais | Sem análise de aquisição, sem DPA (acordo de tratamento de dados) e sem visibilidade sobre as políticas de retenção de dados |
| Agentes de IA | Sistemas autónomos com permissões OAuth para ler ficheiros, chamar APIs e executar ações | Sem registo de eventos ao nível da organização; o acesso delegado persiste após a saída do colaborador |
| Plug-ins de IDE com IA | Cursor, Tabnine e instâncias de Copilot não aprovadas em ambientes de programação | Bases de código proprietárias e esquemas de API internos expostos a fornecedores externos de modelos |
| Ferramentas de IA para reuniões | Otter.ai, Fireflies e Notion AI ligados a plataformas de videoconferência | Conversas gravadas e armazenadas em servidores de terceiros sem aprovação da TI |
| Ferramentas de IA para análise de dados | Plataformas de análise com IA que recebem conjuntos de dados internos e relatórios financeiros | Registos de clientes e dados financeiros tratados fora do ecossistema de dados aprovado |
| Ferramentas de e-mail e calendário com IA | Plug-ins com acesso total à caixa de correio concedido via OAuth | Acesso às comunicações invisível para a TI; tokens OAuth raramente auditados ou revogados |
Os agentes de IA representam uma mudança qualitativa no risco. Uma folha de cálculo guardada numa unidade de nuvem não aprovada é um problema de exposição de dados. Um agente de IA com acesso delegado ao correio eletrónico, ao calendário e ao sistema de ficheiros é um problema de governação de acessos.
Shadow IT vs. Shadow AI: Compreender o multiplicador de risco
A shadow IT e a shadow AI envolvem colaboradores que utilizam ferramentas fora do alcance de visibilidade da TI. O perfil de risco é, no entanto, fundamentalmente diferente.
A shadow IT (SaaS não autorizado, armazenamento pessoal na nuvem, dispositivos não geridos) cria sobretudo problemas de residência de dados e de conformidade. Os dados ficam num local que a TI não controla. A exposição é, em grande medida, estática.
A shadow AI processa dados. Raciocina sobre eles, resume-os, gera resultados a partir deles e, no caso dos sistemas com agentes, atua sobre eles. A exposição é dinâmica e muitas vezes irreversível.
| Dimensão | Shadow IT | Shadow AI |
|---|---|---|
| Risco principal | Residência de dados | Tratamento de dados + treino de modelos |
| Tipo de exposição | Estática (dados em repouso) | Dinâmica (dados em movimento, nos prompts) |
| Reversibilidade | Moderada (revogar o acesso) | Baixa (os dados podem ser usados para treinar modelos públicos) |
| Ação autónoma | Nenhuma | Sim: os agentes de IA atuam sem revisão humana |
| Registo de auditoria | Parcial | Muitas vezes inexistente em contas pessoais ou de nível gratuito |
| Âmbito de conformidade | RGPD, soberania dos dados | RGPD + Regulamento da IA (AI Act), PI, segredos comerciais |
O problema da proliferação de SaaS agrava esta situação. Os colaboradores utilizam mais de 665 ferramentas de IA num ambiente empresarial típico, segundo a análise da Harmonic Security a 22 milhões de prompts de IA empresariais (2025). Seis aplicações são responsáveis por 92,6 % da exposição de dados sensíveis, mas bloquear as restantes 659 é operacionalmente inútil e destrói a produtividade. O desafio de governação é a visibilidade, a classificação e o acesso controlado.
O impacto financeiro: porque a Shadow AI custa 670 mil dólares por violação
Segundo o Cost of a Data Breach Report de 2025 da IBM, as violações de dados que envolvem níveis elevados de shadow AI acrescentam 670 000 dólares ao custo médio de uma violação, em comparação com as que têm níveis baixos ou nulos, o que representa um aumento de 16 % e eleva o total esperado para 4,63 milhões de dólares por incidente.
Duas estatísticas subjacentes explicam o mecanismo:
- 97 % das organizações que sofreram um incidente de segurança relacionado com IA não dispunham de controlos de acesso adequados para a IA
- 63 % das organizações afetadas por violações de dados não tinham políticas de governação para gerir a IA ou detetar utilizações não autorizadas
A cadeia de causalidade é direta. Os colaboradores adotam ferramentas de IA mais depressa do que as equipas de segurança conseguem avaliá-las. Sem controlos de acesso, os dados sensíveis fluem para modelos que a TI nunca aprovou e não consegue auditar. Quando ocorre uma violação, a ausência de registo de eventos e de governação prolonga o tempo de deteção e de contenção, e, na economia das violações de dados, o tempo é o principal fator de custo.
A cadeia da Shadow AI
de dados
de acessos
de auditoria
dos resultados
de credenciais
Para os diretores financeiros, o cálculo é simples: o custo esperado de uma violação de dados associada à shadow AI é de 4,63 milhões de dólares. O custo de um programa empresarial de governação da IA (controlos de acesso, implementação de CASB, licenciamento de ferramentas aprovadas, gestão de credenciais) é uma fração desse valor. O argumento ajustado ao risco a favor do investimento em governação é inequívoco.
As equipas de segurança enfrentam também um ponto cego de DLP (prevenção de perda de dados): a maioria das ferramentas de DLP inspeciona transferências de dados estruturados. Os prompts de IA conversacional são texto não estruturado. Um colaborador que escreve uma cadeia de ligação a uma base de dados numa conta gratuita de um LLM não gera qualquer alerta de DLP. Os dados saem da organização em silêncio.
A ameaça oculta: Exposição de credenciais e agentes de IA
O risco de shadow AI mais direto e menos divulgado é a exposição de credenciais. Os colaboradores colam segredos em LLMs públicos de forma constante, porque é o caminho mais rápido para obter ajuda.
Um programador que depura um problema em produção cola uma cadeia de ligação à base de dados no ChatGPT, juntamente com o log de erros. Um engenheiro de DevOps partilha com um assistente de IA um ficheiro de configuração do Kubernetes, incluindo chaves de API incorporadas, para pedir ajuda sobre uma falha de implementação. Um analista financeiro carrega uma folha de cálculo com as projeções do Q3 para uma ferramenta de resumo com IA não aprovada, a fim de preparar uma reunião do conselho de administração.
Segundo a análise da Harmonic Security a 22,4 milhões de prompts de IA empresariais (2025), o código, os documentos jurídicos e os dados financeiros representam 74,5 % dos dados sensíveis expostos a ferramentas de IA. Só o código-fonte contém segredos incorporados (chaves de API, tokens de acesso e credenciais de contas de serviço escritas diretamente no código) que a maioria dos programadores trata como detalhes de configuração e não como material crítico para a segurança.
A camada de risco dos agentes acrescenta uma segunda superfície de ataque. Os agentes de IA (sistemas que utilizam permissões OAuth delegadas para ler ficheiros, enviar e-mails, consultar bases de dados e chamar APIs externas) operam com concessões de acesso amplas, que nunca foram concebidas para uma utilização autónoma. Quando um colaborador autoriza um agente de IA de produtividade a aceder ao correio eletrónico e ao armazenamento de ficheiros da empresa, esse agente pode ter permissões efetivas mais amplas do que as que a função do próprio colaborador justifica.
A maioria das organizações não tem um inventário dos agentes que detêm cada concessão OAuth, nem um processo para as revogar quando um colaborador sai.
16,9 % de todas as exposições de dados sensíveis no conjunto de dados da Harmonic passaram por contas pessoais de nível gratuito, onde a TI não tem qualquer visibilidade nem registo de auditoria e os dados podem ser utilizados para treinar modelos públicos (Harmonic Security, 2025).
A combinação de exposição de credenciais e de acesso por agentes cria um risco agravado: um agente de IA comprometido, com acesso a um cofre de segredos não geridos, pode exfiltrar muito mais do que uma única chave de API divulgada.
Violações reais associadas à Shadow AI
Estes três incidentes têm um fio condutor comum: em cada caso, um componente de IA que operava num ambiente de confiança acedeu a muito mais dados do que alguém tinha autorizado explicitamente.
Microsoft AI Research: 38 TB de dados internos expostos
O que aconteceu. Uma equipa de investigação em IA da Microsoft publicou no GitHub um conjunto de dados aberto para treinar modelos de reconhecimento de imagem. Para partilhar os ficheiros, utilizou um token SAS do Azure, mas configurou-o com acesso total a toda a conta de armazenamento (Storage Account) em vez de apenas à pasta de destino. Quem seguisse a ligação do repositório obtinha acesso irrestrito a 38 TB de dados privados da empresa.
O que foi divulgado. Cópias de segurança de postos de trabalho de dois colaboradores, mais de 30 000 mensagens internas do Microsoft Teams de 359 funcionários, chaves privadas, palavras-passe de serviços e tokens secretos. O token tinha permissões de «controlo total» e estava configurado para expirar em 2051.
Porque é um incidente de Shadow AI. A violação ocorreu diretamente no decurso do trabalho com conjuntos de dados de IA. Os investigadores, ao avançarem depressa para disponibilizar modelos de IA, contornaram os procedimentos habituais de revisão de acessos. A Wiz Research, que descobriu a exposição, descreveu-a como «uma nova classe de risco com que as organizações se deparam à medida que aceleram a adoção da IA». Como o token concedia acesso de escrita, um atacante poderia ter injetado código malicioso nos modelos de IA que outros programadores estavam a descarregar ativamente.
Resposta. A Wiz divulgou publicamente o incidente em setembro de 2023. A Microsoft revogou o token e encerrou o acesso. O caso tornou-se um exemplo de referência no Cost of a Data Breach Report de 2025 da IBM.
Slack AI: Exfiltração de dados de canais privados por injeção de prompts
O que aconteceu. Investigadores da PromptArmor encontraram uma vulnerabilidade crítica no Slack AI, o assistente integrado que permite aos colaboradores consultar todo o histórico do Slack em linguagem natural. A classe de ataque era a injeção indireta de prompts (indirect prompt injection): um agente de ameaça publica num canal público uma mensagem com instruções ocultas dirigidas ao LLM. Quando o alvo usa o Slack AI para procurar informação, o modelo trata as instruções maliciosas como legítimas e executa-as.
O que estava em risco. Chaves de API e outros segredos guardados em canais privados aos quais o atacante não tinha acesso direto. O Slack AI agregava dados de canais públicos e privados ao responder às consultas dos utilizadores, e esse acesso entre canais foi o vetor do ataque. Um segundo cenário permitia que o Slack AI apresentasse uma ligação de phishing para capturar credenciais.
Porque é um incidente de Shadow AI. O Slack AI é um caso exemplar de shadow AI incorporada: uma funcionalidade de IA ativada numa ferramenta empresarial já aprovada, sem revisão de segurança autónoma do seu componente de IA. As equipas de TI não sabiam que o assistente podia aceder a canais privados e servir de vetor de exfiltração. A 14 de agosto de 2024 (o mesmo dia em que a vulnerabilidade foi divulgada), o Slack alargou as capacidades do assistente para indexar documentos carregados e ficheiros do Google Drive, ampliando ainda mais a superfície de ataque.
Resposta. O Slack classificou inicialmente o comportamento como «intencional» e, depois, publicou uma correção. A empresa afirmou que não havia «provas de acesso não autorizado a dados de clientes». O incidente foi amplamente noticiado como o primeiro caso documentado de exfiltração de dados por injeção de prompts num produto SaaS empresarial em produção.
Microsoft 365 Copilot: EchoLeak, exfiltração de dados zero-click
O que aconteceu. Investigadores da Aim Security divulgaram a vulnerabilidade CVE-2025-32711 (CVSS 9,3: crítica) no Microsoft 365 Copilot, designada EchoLeak. É a primeira injeção de prompts zero-click documentada com exfiltração de dados confirmada num sistema de IA em produção. O ataque não exigiu qualquer ação por parte da vítima.
Como funcionava. Um atacante enviou à vítima um e-mail com instruções ocultas, disfarçadas de ligações Markdown de estilo referência. Quando o Copilot processou o e-mail, contornou o classificador XPIA integrado (proteção contra injeção de prompts) e o mecanismo de ocultação de ligações. Em seguida, o Copilot acedeu automaticamente aos ficheiros da vítima no OneDrive, no SharePoint e no Teams, construiu um URL através da Microsoft Teams Proxy API (que consta da lista de permissões do Copilot) e enviou os dados para o servidor do atacante. Não foi necessário qualquer clique.
O que estava em risco. Qualquer ficheiro ou conversa acessível ao utilizador no Microsoft 365: documentos do OneDrive, ficheiros do SharePoint, mensagens do Teams. Em meados de 2024, mais de 10 000 empresas já utilizavam o Microsoft 365 Copilot, segundo a Netrix Global.
Porque é um incidente de Shadow AI. O EchoLeak representa a próxima geração do risco de shadow AI: um agente de IA com acesso amplo a dados empresariais, a operar numa ferramenta autorizada, sem uma revisão de segurança adequada do seu componente de IA. O ataque não deixou rastos nos sistemas de monitorização habituais, porque todo o tráfego circulou por domínios fidedignos da Microsoft.
Resposta. A Microsoft publicou uma correção de emergência em junho de 2025. O caso mudou de forma fundamental a maneira como o setor avalia o risco dos agentes de IA com permissões de acesso alargadas.
Como detetar e prevenir a Shadow AI na empresa
A deteção e a prevenção exigem uma abordagem estruturada. Proibir totalmente a IA não funciona: os dados da Harmonic mostram que os colaboradores utilizam ferramentas de IA independentemente da política, muitas vezes através de dispositivos e contas pessoais que contornam por completo os controlos da empresa. O objetivo é a governação, não a proibição.
Modelo de governação da Shadow AI em 5 passos
- Descobrir a exposição à IA. Implemente monitorização de rede para identificar o tráfego de saída para domínios de IA conhecidos. Utilize um Cloud Access Security Broker (CASB) para obter visibilidade sobre a utilização de SaaS nos dispositivos geridos. Audite as extensões de navegador nos endpoints da empresa, pois muitas ferramentas de IA funcionam como extensões com acesso amplo ao conteúdo das páginas. Crie um inventário do que está realmente em uso antes de redigir a política.
- Definir políticas de utilização aceitável. Classifique as ferramentas de IA em três níveis: aprovadas (com licença empresarial e acordos de tratamento de dados em vigor), condicionais (permitidas apenas para tarefas não sensíveis) e proibidas (sem controlos de soberania dos dados e com treino de modelos públicos). Publique a política.
- Implementar o controlo de acesso baseado em funções (RBAC) para as ferramentas de IA. O RBAC aplica-se ao acesso às ferramentas de IA da mesma forma que a qualquer outro sistema. Os programadores não devem ter acesso a ferramentas de IA financeiras. As equipas financeiras não devem ter acesso a repositórios de código que alimentam pipelines de IA. Limite as concessões de acesso ao mínimo necessário para cada função. Reveja-as trimestralmente.
- Disponibilizar alternativas autorizadas. Os colaboradores adotam a shadow AI porque as ferramentas aprovadas demoram a ser adquiridas ou não servem para a tarefa. Para cada categoria de ferramentas proibida, disponibilize uma alternativa autorizada com capacidade equivalente. Se os programadores precisam de um assistente de programação com IA, forneça-lhes um com controlos de dados empresariais. A governação sem capacitação gera ressentimento e soluções de contorno.
- Proteger as credenciais subjacentes. Este é o passo que a maioria dos modelos de governação ignora. Mesmo com políticas e CASB implementados, os colaboradores com acesso direto a chaves de API em bruto, palavras-passe de bases de dados e credenciais de contas de serviço podem colá-las em qualquer ferramenta. Centralizar a gestão de segredos, de modo que as credenciais sejam armazenadas, injetadas e rodadas de forma programática em vez de copiadas manualmente, elimina o caminho mais direto da shadow AI para o comprometimento de credenciais.
Como o Passwork protege a base contra os riscos da Shadow AI
Não é possível impedir fisicamente um colaborador de abrir um separador do navegador e escrever num LLM público. O que se pode controlar é aquilo a que tem acesso para colar.
O princípio central: Retirar o texto em claro da equação
Se as chaves de API, as credenciais de bases de dados, os segredos de produção e as palavras-passe de contas de serviço estiverem num cofre cifrado centralizado, com acesso programático em vez de cópia manual, o risco de exposição de credenciais pela shadow AI diminui substancialmente. O programador que quer depurar um problema em produção com um assistente de IA não consegue colar a cadeia de ligação à base de dados porque nunca a teve em texto em claro.
O que o Passwork oferece
O Passwork está disponível tanto como implementação autoalojada como numa solução alojada na nuvem. Ambas partilham a mesma arquitetura de base: cifragem AES-256 num modelo zero-knowledge, em que as credenciais são cifradas do lado do cliente antes de saírem do dispositivo.
Quatro controlos são os mais relevantes no contexto da shadow AI:
- Controlo de acesso baseado em funções. Os administradores atribuem o acesso aos cofres a equipas e funções específicas. Um programador tem acesso aos segredos do ambiente de desenvolvimento, não aos de produção. O acesso é concedido por função, e não por antiguidade ou conveniência.
- Registos de auditoria. Cada evento de acesso é registado: quem obteve que credencial, quando e a partir de que sistema. Se uma credencial surgir onde não devia, existe um rasto.
- Gestão de contas de serviço. O risco da shadow AI não se limita a pessoas que colam segredos em janelas de chat. Os agentes de IA e os pipelines automatizados funcionam com contas de serviço, e essas contas acumulam permissões ao longo do tempo sem que ninguém as reveja ativamente. O Passwork permite armazenar, rodar e delimitar as credenciais das contas de serviço da mesma forma que se gere o acesso humano: com funções explícitas, políticas de expiração e um histórico de acessos completo.
- Entrega de credenciais com abordagem API-first. A API REST do Passwork permite que pipelines e aplicações obtenham segredos de forma programática em tempo de execução, em vez de os lerem de ficheiros de ambiente ou de repositórios de configuração. A credencial nunca passa pela área de transferência do programador. Vai diretamente do cofre para o processo que precisa dela, e a obtenção fica registada.
Autoalojado vs. na nuvem
A opção autoalojada mantém todos os dados na infraestrutura própria da organização, e é a escolha adequada para equipas com requisitos rigorosos de residência de dados ou para ambientes regulados. A opção na nuvem elimina a carga operacional de gerir uma instância própria, preservando as mesmas garantias de cifragem e os mesmos controlos de acesso. Nenhuma das opções envia credenciais em texto em claro para os servidores do Passwork.
Como o Passwork responde aos riscos da Shadow AI
| Risco de Shadow AI | Como ocorre | Como o Passwork responde |
|---|---|---|
| Exposição de credenciais em prompts | O programador cola uma chave de API ou uma cadeia de ligação a uma base de dados num LLM público para depurar um problema em produção | Os segredos são armazenados cifrados e entregues de forma programática através da API REST: os programadores nunca possuem credenciais em texto em claro para colar |
| Segredos fixos no código-fonte (hardcoded) | Chaves de API e tokens incorporados no código são partilhados com assistentes de programação com IA ou submetidos a repositórios | A entrega de credenciais com abordagem API-first mantém os segredos totalmente fora dos ficheiros de configuração e das variáveis de ambiente |
| Acesso excessivo | Os colaboradores têm acesso a mais segredos do que a sua função exige, e qualquer um deles pode acabar num prompt de IA | O controlo de acesso baseado em funções delimita o acesso aos cofres por equipa e função: um programador vê os segredos de desenvolvimento, não os de produção |
| Credenciais de contas de serviço não geridas | Os agentes de IA e os pipelines funcionam com contas de serviço com permissões acumuladas e sem ciclo de revisão | As credenciais das contas de serviço são armazenadas, delimitadas e rodadas no Passwork, com funções explícitas e histórico de acessos completo |
| Sem registo de auditoria após a exposição | Uma credencial surge num local inesperado, sem forma de determinar quem lhe acedeu, quando ou a partir de onde | Cada obtenção fica registada (credencial, utilizador, data e hora, sistema de origem), com um rasto forense completo disponível de imediato |
| Acesso residual após a saída de colaboradores | O colaborador que sai mantém acesso a credenciais partilhadas, a concessões OAuth de agentes de IA e a palavras-passe de contas de serviço | O acesso é revogado uma só vez ao nível do cofre; o painel de segurança sinaliza como potencialmente comprometidas todas as credenciais a que o colaborador podia aceder |
| Proliferação de segredos entre ambientes | Credenciais guardadas em folhas de cálculo, mensagens do Slack, ficheiros .env e gestores de palavras-passe pessoais, sem inventário central | Um único cofre cifrado para todas as credenciais de todas as equipas; a sincronização AD/LDAP mantém o acesso alinhado com os grupos do diretório de forma automática |
Conclusão
O sobrecusto de 670 mil dólares por violação de dados associado à shadow AI é o custo de utilizar IA sem governação. As organizações que pagam esse sobrecusto não são casos isolados. São os 63 % que não tinham políticas de governação da IA e os 97 % que não dispunham de controlos de acesso adequados quando ocorreu um incidente.
A governação começa na camada das credenciais. Um colaborador que não consegue aceder a segredos de produção em bruto não os pode expor por acidente, independentemente da ferramenta de IA que abra. Este é o ponto de controlo que a maioria dos modelos de governação da shadow AI ignora e aquele que proporciona a redução de risco mais imediata.
Audite as credenciais a que as equipas podem aceder hoje em texto em claro. Essa lista é a superfície de exposição à shadow AI da organização.
Perguntas frequentes: Shadow AI nas empresas
Como se deteta a Shadow AI?
As organizações podem detetar a shadow AI através da monitorização dos logs de rede para identificar tráfego de saída invulgar para domínios de IA, da implementação de um Cloud Access Security Broker (CASB) para auditar a utilização de SaaS nos dispositivos geridos e da revisão das extensões de navegador nos endpoints da empresa. As ferramentas de DLP em endpoints podem sinalizar transferências de grandes volumes de texto para serviços de IA conhecidos, embora as contas pessoais de nível gratuito continuem a ser um ponto cego persistente.
Qual é um exemplo de Shadow AI?
Um exemplo comum é o de um programador que cola código-fonte proprietário numa conta pessoal do ChatGPT para depurar um problema em produção, expondo no processo chaves de API incorporadas no código e a arquitetura interna. Outro é o de uma equipa de marketing que carrega dados confidenciais de clientes para uma ferramenta de resumo com IA não aprovada, ou o de um analista financeiro que partilha projeções do Q3 com um assistente de IA de nível gratuito para preparar materiais para o conselho de administração.
Porque é que a Shadow AI é mais perigosa do que a Shadow IT?
A shadow IT cria problemas de residência de dados: os dados ficam num local que a TI não controla. A shadow AI processa dados: raciocina sobre eles, gera resultados a partir deles e, em implementações com agentes, atua sobre eles de forma autónoma. A exposição através da shadow AI é muitas vezes irreversível, sobretudo quando os dados circulam por contas de nível gratuito, nas quais podem ser utilizados para treinar modelos públicos.
Que credenciais estão mais em risco devido à Shadow AI?
As chaves de API, as cadeias de ligação a bases de dados, os tokens OAuth e as palavras-passe de contas de serviço são as credenciais de maior risco. São os segredos que os programadores e os engenheiros de DevOps têm maior probabilidade de incluir em prompts de IA ao depurar ou ao pedir ajuda com a configuração. Os segredos incorporados no código-fonte estão particularmente expostos, uma vez que o código é a maior categoria isolada de dados sensíveis partilhados com ferramentas de IA (Harmonic Security, 2025).
Proibir as ferramentas de IA impede a Shadow AI?
Não. A análise da Harmonic Security a 22,4 milhões de prompts empresariais concluiu que os colaboradores de mais de 90 % das organizações utilizam ativamente ferramentas de IA, sobretudo através de contas pessoais que a TI nunca aprovou. As proibições generalizadas empurram a utilização para dispositivos e contas pessoais com ainda menos visibilidade. A governação eficaz combina alternativas aprovadas, políticas de utilização aceitável claras e controlos técnicos na camada de acesso.
Alex Muntyan
Alex Muntyan
Alex Muntyan