Shadow AI: por que a IA paralela é antes de tudo um problema de governance

O essencial

• O Shadow AI é a utilização de qualquer ferramenta, funcionalidade ou agente de IA dentro da organização sem supervisão de governance, e hoje está envolvido em cerca de uma em cada cinco violações de dados em ambiente empresarial.
• A narrativa dominante é de ciberssegurança. A narrativa menos contada, e provavelmente mais consequente, é a de governance de IA: não se pode registar, avaliar ou auditar aquilo que não se vê.
• Shadow AI, proliferação de IA (AI sprawl) e lista de materiais de IA (AI bill of materials) são três conceitos distintos que a indústria costuma confundir. Mantê-los separados é condição para um programa que escala.
• O Regulamento europeu da IA, a norma ISO/IEC 42001 e o NIST AI Risk Management Framework partilham um pressuposto tácito: a organização detém um inventário completo dos sistemas de IA no seu âmbito. O Shadow AI invalida silenciosamente esse pressuposto.
• A resposta não é proibir (as proibições empurram o uso ainda mais para a sombra) mas um programa de descoberta credível que alimente um único registo de sistemas de IA, capaz de servir simultaneamente como fonte do registo Anexo VIII e como registo de riscos ISO 42001.

O que significa Shadow AI, sem reducionismos

Shadow AI designa o uso de qualquer ferramenta, capacidade ou agente de inteligência artificial dentro de uma organização sem conhecimento, aprovação ou supervisão das pessoas responsáveis pela governance da IA: CISO, encarregado da proteção de dados, responsável de governance de IA, compliance, ou qualquer função que sustente esse mandato no organigrama.

A imagem comum é a do colaborador que cola um documento confidencial no ChatGPT. É um caso, não a categoria inteira. O Shadow AI surge em pelo menos três formas, e tratá-las como um problema único produz controlos incompletos.

Ferramentas GenAI de consumo autónomas. Chatbots gratuitos, geradores de imagens, assistentes de código, transcritores de reuniões acedidos através de um navegador ou de uma conta pessoal. É a superfície clássica e a mais fácil de detetar através da telemetria de rede.

Funcionalidades de IA incorporadas em SaaS aprovados. A organização aprovou o SaaS, e o fornecedor ativou uma nova função de IA a meio do contrato. De repente o CRM resume notas de cliente com um modelo de fundação, a suíte de colaboração redige correios eletrónicos automaticamente, a ferramenta de projetos sugere riscos. O registo de compras diz que não foi aprovada nenhuma IA. A realidade diz outra coisa. A IBM observa que a adoção empresarial de GenAI subiu de 74 para 96 por cento entre 2023 e 2024, em grande parte por esta via incorporada (IBM Think).

Modelos, scripts e agentes internos. Um analista afina um modelo de código aberto no seu equipamento. Um engenheiro de plataforma liga um agente a um servidor Model Context Protocol com permissões alargadas. Uma equipa de marketing treina um GPT próprio sobre um corpus sensível. Nenhum destes fluxos passa por um chatbot público de terceiros, escapando à deteção tradicional de shadow IT, mas produzindo a mesma lacuna de governance.

A distinção útil em relação a shadow IT é de âmbito. O shadow IT cobre qualquer ativo tecnológico não autorizado. O Shadow AI é o subconjunto em forma de IA, e traz riscos específicos: saídas probabilísticas, alucinações, dados de treino opacos, deriva do modelo, contaminação da cadeia de valor, e um regime regulamentar próprio (o Regulamento europeu da IA) que atribui explicitamente responsabilidades sobre estas características.

É precisamente este último ponto que move o Shadow AI do registo da ciberssegurança para o registo da governance. A segurança tem duas décadas de prática a perseguir SaaS não autorizado. A disciplina nova das próximas duas décadas é governar a IA cuja existência se ignorava.

Shadow AI, AI sprawl, AI bill of materials: três conceitos distintos

Três noções vizinhas são usadas como sinónimos em blogues e notas de analistas. Não são o mesmo, e confundi-las gera um programa de governance desfocado.

Shadow AI trata da autorização. Um sistema está na sombra quando ninguém com responsabilidade traçou a sua existência. Uma ferramenta perfeitamente aprovada mas usada por uma equipa não habilitada continua a ser Shadow AI, porque falta o rasto de auditoria.

AI sprawl trata da multiplicação, autorizada ou não. Uma organização com 80 ferramentas de IA aprovadas dispersas por 40 equipas sem catálogo central tem proliferação, não Shadow AI no sentido estrito. A proliferação é o que acontece quando a descoberta resulta mas a consolidação não.

AI bill of materials (AI BOM) é o artefacto documental, modelado de forma frouxa sobre a lista de materiais de software. Para um sistema dado, a lista enumera componentes: modelo de fundação e versão, fontes de dados de treino e ajuste fino, bases de recuperação, APIs de terceiros invocadas na inferência, pontos de controlo humano. O AI BOM não é um problema, é um entregável, e é o que torna auditável a remediação do Shadow AI.

Um programa maduro aborda os três: trazer o Shadow AI à superfície através da descoberta, reduzir a proliferação através da consolidação, e produzir um AI BOM por sistema para que o registo tenha substância e não apenas nome e dono.

Porque o fenómeno explode agora

Num preprint de 2026, Silic e colegas propõem ler o Shadow AI como falha sociotécnica de governance em vez de incidente de segurança, argumentando que o caráter generativo, opaco e autónomo da IA cria desafios que a governance de TI existente não absorve (Silic et al., Preprints.org). O seu enquadramento bate certo com o que se vê no terreno. Quatro forças reforçam-se mutuamente.

A consumerização da GenAI. Uma conta gratuita da OpenAI ou uma subscrição de quinze euros mensais entrega capacidade que há dois anos exigia um ciclo de compras e uma factura cloud. A fricção que travava o utensílio não aprovado desapareceu.

A IA incorporada em SaaS aprovados. Quando um fornecedor sob contrato ativa uma função de IA por defeito, o contrato não muda, mas o fluxo de dados muda. Poucos CISOs dispõem da instrumentação contratual necessária para saber quando o seu quinto maior fornecedor SaaS ativou em silenço a geração aumentada por recuperação sobre dados do cliente.

Os agentes e a camada MCP. Servidores Model Context Protocol e agentes autónomos constituem uma superfície nova que os secure web gateways tradicionais não foram concebidos para inspecionar. Um agente que invoca um servidor MCP herda as permissões desse servidor, que podem exceder as do utilizador chamador. Sem visibilidade dedicada, o raio de impacto de uma implantação de agente é desconhecido.

O desfasamento de velocidade entre TI e negócio. Os colaboradores recorrem ao Shadow AI pela mesma razão por que recorriam ao shadow SaaS: porque é mais rápido do que a via oficial. Como nota um explicador da Splunk, proibir ferramentas GenAI de consumo sem oferecer alternativa interna empurra o uso ainda mais fundo para a sombra (Splunk).

Os números são inequívocos. A Gartner prevê que mais de 40 por cento das empresas vão sofrer um incidente de segurança ou compliance ligado ao Shadow AI até 2030 (comunicado Gartner, novembro de 2025). O relatório IBM Cost of a Data Breach 2025 cifra o prémio de custo das violações ligadas a Shadow AI em cerca de 4,63 milhões de dólares contra 3,96 milhões para violações padrão, e observa que apenas 37 por cento das organizações têm uma política para gerir ou detetar o Shadow AI (IBM Cost of a Data Breach 2025). Uma violação em cada cinco envolve hoje o Shadow AI como fator contributivo.

A direção é clara. A pergunta estratégica é se a organização trata a lacuna como um problema de segurança a remendar, ou como uma disciplina de governance a construir.

O risco de governance: o que o Shadow AI realmente parte

A narrativa de segurança é intuitiva: dados sensíveis saem do perímetro, o regulador sanciona, os clientes vão-se. É real, e outros artigos contam-na bem. A narrativa de governance é menos contada e mais consequente. Três regimes regulamentares e normativos convergem, e todos os três assentam num único pressuposto que o Shadow AI invalida.

O mandato de registo do Regulamento da IA

O Artigo 49.º do Regulamento europeu da IA exige que os fornecedores de sistemas de IA de alto risco listados no Anexo III se registem e registem o sistema na base de dados pública da UE antes da colocação no mercado ou da entrada em serviço. Os utilizadores que sejam autoridades públicas devem registar também o uso. O conteúdo exigido, definido no Anexo VIII, inclui identidade do fornecedor, denominação e finalidade do sistema, instruções de utilização, certificado de avaliação da conformidade, estado (no mercado, retirado, recolhido) e resúmenes das avaliações de impacto (Artigo 49.º, Anexo VIII).

A implicação para o Shadow AI é direta. Se uma ferramenta usada na organização, autorizada ou não, se enquadrar nas categorias de alto risco do Anexo III (seleção de pessoal, scoring de crédito, identificação biométrica, infraestruturas críticas, educação, aplicação da lei, migração, administração da justiça), o registo é uma obrigação legal e não uma boa prática. Um sistema na sombra que se revela de alto risco é um registo em falta, precisamente o tipo de não conformidade factual que as autoridades nacionais de fiscalização do mercado vão perseguir.

As obrigações do utilizador nos Artigos 26.º e 27.º agravam a exposição. O utilizador deve seguir as instruções de utilização do fornecedor, manter registos, assegurar a supervisão humana e, para utilizadores públicos ou sectoriais no âmbito, realizar uma avaliação de impacto sobre direitos fundamentais (FRIA). A implantação na sombra parte silenciosamente as quatro, porque o sistema nunca esteve no inventário que as teria acionado.

Esta secção é puramente descritiva do texto jurídico. O ponto não é o que os leitores devem fazer a respeito. O ponto é que o Shadow AI converte uma obrigação documental numa falha documental sem que ninguém perceba até chegar uma auditoria.

A declaração de aplicabilidade ISO/IEC 42001

A cláusula 6 da ISO/IEC 42001 exige que a organização identifique riscos e oportunidades ligados à IA, os trate e documente o tratamento num registo de riscos de IA. O Anexo A oferece um catálogo de controlos recomendados, e a declaração de aplicabilidade (Statement of Applicability) declara que controlos estão incluídos ou excluídos, com justificação.

O Shadow AI parte esta estrutura duas vezes. Primeiro, o registo de riscos é incompleto por construção: um sistema desconhecido não pode ter tratamento documentado. Segundo, a declaração de aplicabilidade afirma que certos controlos se aplicam a certos sistemas. Assim que um sistema sombra entra no âmbito, essas afirmações ficam inexatas, e as organizações certificadas expõem-se a uma não conformidade na reauditoria.

A implicação prática é que uma certificação 42001 vale o que vale o programa de descoberta que a sustenta. As organizações que se preparam para a certificação descobrem, muitas vezes dolorosamente, que a distância entre a lista oficial de IA e a pegada real excede o que o calendário de auditoria pode absorber.

A função MAP do NIST AI RMF

O NIST AI Risk Management Framework 1.0 organiza as atividades de IA de confiança em quatro funções: GOVERN, MAP, MEASURE, MANAGE. GOVERN fixa política e responsabilidade. MAP, a segunda função, exige aquilo a que o NIST chama análise contextual: para cada sistema de IA, conhecer finalidade, proprietários, dados de treino, estado de implantação, pontos de integração (NIST AI RMF).

O Shadow AI inviabiliza a função MAP à raiz. Não se pode caracterizar o contexto de um sistema não identificado. O NIST AI 600-1 (perfil GenAI) acrescenta camada ao enumerar doze riscos específicos da GenAI (privacidade dos dados, segurança da informação, cadeia de valor, configuração humano-IA, confabulação, viés prejudicial, etc.) que exigem todos visibilidade ao nível do sistema para serem geridos (NIST AI 600-1).

A OWASP AI Exchange, projeto bandeira da OWASP desde março de 2025, formula o mesmo ponto pelo ângulo do catálogo de controlos: toda a ameaça e todo o controlo pressupõem um ativo conhecido. Onde o ativo está na sombra, o modelo de ameaças cala-se por defeito (OWASP AI Exchange). Os projetos de normas harmonizadas do CEN-CENELEC em elaboração (prEN 18228 e prEN 18282) seguem a mesma lógica ao nível europeu.

Três referências, uma dependência não enunciada: é preciso saber que IA se tem.

Descobrir o Shadow AI: cinco camadas indispensáveis

A descoberta deve ser em camadas, pois nenhum sinal isolado capta todas as formas. As cinco camadas seguintes, executadas em combinação, produzem uma cobertura defensável.

Camada 1: telemetria de rede e SaaS. Logs DNS, dados de secure web gateway, telemetria CASB e extensões de browser revelam tráfego para endpoints de IA de consumo conhecidos. Apanha o caso clássico do ChatGPT no browser. Não vê o que corre dentro de um SaaS aprovado ou atrás de um IP empresarial.

Camada 2: auditoria de identidade. Histórico de concessões OAuth, logs SSO e ecrãs de consentimento mostram que serviços de IA terceiros receberam acesso à identidade corporativa. Apanha os serviços que se apoiam na identidade do Google Workspace ou do Microsoft 365. Não vê os usos totalmente isolados.

Camada 3: auditoria das funções de IA incorporadas nos SaaS aprovados. Diálogo direto com cada um dos vinte principais fornecedores SaaS: que funções estão ativas por defeito, quais são opt-in, para onde vão os dados. Trabalho de gestão de compras pouco glamoroso, mas é o que faz emergir a forma incorporada que a telemetria não vê.

Camada 4: programas de amnistia e inquérito. Uma janela de amnistia claramente comunicada em que os colaboradores declaram o seu uso de IA sem sanção. Combinada com um inquérito curto e honesto, produz uma descoberta qualitativa que nenhuma telemetria iguala. A condição de sucesso é a segurança psicológica, não a ferramenta.

Camada 5: DLP consciente de IA. Inspeção ao nível do prompt nos canais aprovados, à procura de padrões de exfiltração de dados sensíveis. É o foco atual de investimento da indústria de ciberssegurança e a camada mais destacada nos blogues dos fornecedores. Necessária, mas não suficiente isolada.

Nenhuma organização atinge cem por cento de cobertura. O objetivo realista é uma varredura suficientemente fina para que o resto desconhecido seja pequeno, documentado e em declínio. O erro é sobreinvestir numa só camada e chamar isso descoberta.

Da descoberta ao registo de sistemas de IA

A descoberta sem destino é uma folha de cálculo de uma só utilização que envelhece num trimestre. O destino é um registo de sistemas de IA central que alberga cada sistema conhecido, numa estrutura que satisfaz em simultâneo o regulador, os organismos de normalização e a função de risco interna.

O que o registo tem de capturar por sistema:

• Identidade: nome, proprietário, sponsor de negócio, sponsor técnico
• Finalidade: uso previsto, usos proibidos, populações de utilizadores no âmbito
• Dados: classificações de entradas e saídas, fontes de treino e ajuste, bases de recuperação
• Cadeia de fornecedores: modelo de fundação e versão, fornecedor de ajuste fino, ambiente de hosting, APIs de terceiros na inferência
• Estado do ciclo de vida: piloto, produção, retirado; data de entrada em serviço
• Nível regulamentar: classificação de risco do Regulamento UE, aplicabilidade do Anexo A da ISO 42001, perfil NIST AI RMF
• Risco residual: após controlos, com o aceitador identificado
• Evidências: ligadas a FRIA, avaliações de conformidade, model cards, datasheets

A secção AI BOM de cada entrada é o que torna o sistema auditável. Linhagem do modelo, composição dos dados de treino, índices de recuperação e dependências de APIs a jusante formam um grafo que um auditor externo pode verificar contra as implantações reais.

Bem feito, o registo é a fonte única que alimenta três artefactos a jusante: o dossier de registo do Anexo VIII quando um sistema cai sob o Regulamento UE, o registo de riscos da ISO 42001 e os anexos da declaração de aplicabilidade, e os outputs MAP do NIST AI RMF. Construídos em três folhas separadas, derivam uns em relação aos outros em semanas. Construídos uma vez, com o esquema correto, geram alavancagem de governance.

Trazer o Shadow AI à luz: um plano de 60 dias

A sequência importa, pois descobrir sem habilitar gera ressentimento e empurra o Shadow AI mais fundo.

Semanas 1-2. Anúncio da janela de amnistia. Comunicação centrada no objetivo: habilitar a IA, não proibir. Montagem do esqueleto do registo com esquema mínimo. Captura de telemetria de base nas cinco camadas.

Semanas 3-4. Varrimento de descoberta. Combinação de telemetria, auditoria de identidade, diálogo com fornecedores SaaS e inquérito de amnistia. Surpresas previsíveis na categoria de IA incorporada.

Semanas 5-6. Triagem. Exposição regulamentar primeiro, criticidade de negócio depois. Identificar os sistemas que correspondem ao Anexo III do Regulamento UE, pois trazem obrigações de registo independentemente da maturidade do resto do programa.

Semanas 7-8. Migração da triagem para o registo. Para cada sistema Tier 1, anexar o AI BOM, a FRIA quando aplicável, a model card, a classificação de dados. Para os Tiers inferiores, capturar identidade e finalidade, e adiar a documentação profunda para o sprint seguinte.

Para lá do dia 60, o programa torna-se operacional: a entrada de novos sistemas substitui a descoberta, o registo alimenta os pipelines regulamentares e de auditoria, e o sprint seguinte ataca a proliferação (consolidação, descomissionamento, reforma).

O modo de falha a vigiar é a sobreengenharia. Um registo perfeito que ninguém atualiza vale menos do que um registo aproximado que cobre oitenta por cento dos sistemas e é refrescado trimestralmente. Começar leve, fazer correr as entradas, e deixar a pressão regulamentar moldar a precisão com o tempo.

Perguntas frequentes

O que é o Shadow AI, em palavras simples? O Shadow AI é a utilização de qualquer ferramenta, função ou agente de IA na organização de que os responsáveis pela governance de IA não têm conhecimento. Pode ser um colaborador que usa um chatbot gratuito, uma função de IA ativada num SaaS aprovado, ou um modelo interno que corre num computador portátil. O denominador comum é a ausência do inventário, logo a ausência de gestão.

Shadow AI e shadow IT são a mesma coisa? Não. O shadow IT é a categoria mais ampla de ativos tecnológicos não autorizados. O Shadow AI é o subconjunto em forma de IA, e traz riscos próprios: saídas probabilísticas, alucinações, dados de treino opacos, deriva do modelo, e um regime regulamentar próprio na UE. Os controlos de shadow IT apanham parte do Shadow AI, mas falham completamente as formas incorporadas e internas.

Qual a dimensão do fenómeno em 2026? A Gartner estima que mais de 40 por cento das empresas vão sofrer um incidente de segurança ou compliance ligado ao Shadow AI até 2030. O relatório IBM 2025 indica que cerca de uma violação em cada cinco envolve hoje o Shadow AI como fator, e que essas violações custam em média 0,67 milhões de dólares acima das violações padrão. Apenas 37 por cento das organizações declaram dispor de uma política de gestão ou deteção.

O Regulamento da IA obriga-me a inventariar o Shadow AI? O Regulamento da IA não usa a palavra “inventário” mas o efeito é o mesmo. O Artigo 49.º exige o registo dos sistemas de alto risco do Anexo III antes da colocação no mercado. Os Artigos 26.º e 27.º impõem ao utilizador obrigações (registos, supervisão, instruções de uso, FRIA para utilizadores no âmbito) que não podem ser satisfeitas sem saber que sistemas estão em âmbito. Um sistema sombra que se revele de alto risco é, na prática, uma lacuna de compliance à espera de enforcement.

Como trata a ISO 42001 o Shadow AI? A cláusula 6 da ISO/IEC 42001 exige um registo de riscos de IA. O Anexo A oferece um catálogo de controlos, e a declaração de aplicabilidade estabelece quais se aplicam a cada sistema. O Shadow AI parte ambos: o registo de riscos é incompleto por construção, e a declaração de aplicabilidade torna-se inexata assim que um sistema sombra entra no âmbito. É por isso que as auditorias de certificação começam muitas vezes por um exercício de descoberta em vez de uma revisão de controlos.

Qual a diferença entre Shadow AI e AI sprawl? O Shadow AI trata da autorização: um sistema está na sombra quando a governance não o vê. O AI sprawl trata da multiplicação: muitos sistemas de IA, autorizados ou não, que se espalham sem catálogo central. Pode haver proliferação sem sombra (está tudo registado, mas são oitenta) e sombra sem proliferação (duas ferramentas não autorizadas, em uso alargado). Um programa maduro aborda os dois, e o AI BOM por sistema é o entregável que faz a ponte.

O que deve conter um registo de IA, no mínimo? No mínimo: identidade do sistema e proprietário, finalidade e utilizadores em âmbito, classificações de dados, modelo de fundação e versão, APIs de terceiros na inferência, estado do ciclo de vida, nível regulamentar, risco residual após controlos, e ligações a evidências (model card, datasheet, avaliação de conformidade, FRIA). Cada entrada serve simultaneamente de fonte para o registo Anexo VIII UE, o registo de riscos ISO 42001 e o output MAP do NIST AI RMF.

Conclusão

O Shadow AI não cede a proibições nem à sola ferramenta de ciberssegurança. É um problema de descoberta de governance disfarçado de problema de segurança, e as organizações que o tratam como tal vão passar os próximos dois anos a construir registos, AI BOM e tratamentos de risco que sobrevivem a uma auditoria. As que o tratam como problema de perímetro vão passar esses dois anos atrás de incidentes. O entregável é idêntico nos dois casos: um inventário único, atual e credível, de cada sistema de IA que a organização opera. A pergunta é se se constrói ao próprio ritmo ou sob pressão do regulador.