Quando qualquer pessoa da empresa consegue criar um chatbot, conectar um modelo de IA a dados internos ou automatizar uma decisão, o problema deixa de ser apenas técnico. O termo shadow AI descreve o uso ou desenvolvimento de inteligência artificial sem conhecimento, avaliação ou controle formal da organização. Esse cenário exige governança compartilhada, mas com responsáveis claramente definidos.

A resposta curta é: não deve ficar somente com desenvolvedores, DevOps ou Segurança da Informação. A responsabilidade final precisa estar no nível executivo; a gestão deve ser multidisciplinar; e cada aplicação deve ter um dono de negócio identificável.

O que é shadow AI e por que ela cresce tão rápido?

Shadow AI é uma evolução do antigo “shadow IT”. Ela aparece quando colaboradores adotam ferramentas de IA por conta própria, quando equipes criam agentes e automações sem passar por avaliação formal ou quando aplicações inicialmente experimentais começam a processar dados reais sem controles adequados.

Isso acontece porque as barreiras de entrada caíram. Hoje, uma pessoa sem formação em software consegue montar uma aplicação com plataformas low-code, APIs e assistentes generativos. O ganho de produtividade é real, mas também surgem riscos de vazamento de dados, decisões incorretas, violações de propriedade intelectual, dependência de fornecedores, falta de rastreabilidade e descumprimento da LGPD.

Proibir toda experimentação costuma empurrar o uso ainda mais para as sombras. Governar bem significa criar um caminho seguro e rápido para inovar.

Então, de quem é a responsabilidade?

A melhor resposta é um modelo de responsabilidade distribuída, porém não difusa. “Todos são responsáveis” não pode significar que ninguém responde pelo resultado.

1. Diretoria executiva: accountable pela governança

A alta liderança deve definir o apetite a risco, aprovar a política corporativa de IA e designar um executivo responsável, normalmente CIO, CTO, CDO ou, em algumas empresas, um Chief AI Officer. Esse patrocinador não precisa aprovar cada protótipo, mas deve garantir que existam regras, recursos e autoridade para a governança funcionar.

2. Comitê de IA: decide padrões e exceções

Um comitê enxuto deve reunir Tecnologia, Segurança, Privacidade/DPO, Jurídico, Riscos/Compliance, Dados e representantes das áreas de negócio. Sua função é classificar riscos, aprovar ferramentas corporativas, definir controles mínimos e decidir sobre casos sensíveis. O comitê não deve virar uma fila burocrática para todo experimento.

3. Área de negócio: dona do caso de uso

Cada aplicação precisa de um AI Product Owner ou responsável de negócio. É essa pessoa que responde pela finalidade, pelos usuários, pelos dados utilizados, pelo impacto de uma decisão errada e pela continuidade ou desligamento da solução. Se o RH usa IA para apoiar recrutamento, por exemplo, RH não pode transferir toda a responsabilidade para TI.

4. Plataforma, DevOps e MLOps: tornam o uso governável

DevOps, Plataforma e MLOps cuidam dos mecanismos operacionais: ambientes aprovados, identidade e acesso, gestão de segredos, logs, versionamento, observabilidade, limites de custo, avaliação de modelos, implantação e rollback. Eles são responsáveis pelo “como operar com segurança”, não pela legitimidade do objetivo de negócio.

5. Desenvolvimento e dados: implementam os controles

Desenvolvedores, analistas e cientistas de dados devem documentar fontes, prompts, modelos, integrações, testes e limitações. Também precisam implementar revisão humana, validação de entradas e saídas, proteção contra abuso e rastreabilidade compatíveis com o risco.

6. Segurança, Jurídico e DPO: estabelecem guardrails

Segurança avalia ameaças e exposição; Jurídico trata contratos, propriedade intelectual e obrigações; e o DPO avalia finalidade, base legal, minimização, retenção e direitos dos titulares. Essas áreas orientam e fiscalizam, mas não devem se tornar proprietárias de todos os sistemas de IA.

Um modelo simples de gestão

1. Descobrir: manter um inventário único de ferramentas, modelos, agentes, automações e integrações de IA.
2. Classificar: separar casos de baixo, médio, alto e inaceitável risco, considerando dados, autonomia, impacto e público afetado.
3. Oferecer um caminho aprovado: disponibilizar ferramentas corporativas, ambientes de sandbox e modelos pré-aprovados.
4. Aplicar aprovação proporcional: experimentos sem dados sensíveis seguem uma via rápida; decisões sobre pessoas, saúde, finanças ou direitos passam por avaliação reforçada.
5. Monitorar: registrar acessos, custos, versões, incidentes e qualidade das saídas.
6. Reavaliar: toda aplicação deve ter proprietário, data de revisão e procedimento de desligamento.

O inventário mínimo de cada aplicação

• nome, finalidade e área responsável;
• proprietário de negócio e responsável técnico;
• modelo, fornecedor e integrações utilizadas;
• tipos de dados enviados, armazenados ou gerados;
• usuários e pessoas potencialmente afetadas;
• nível de autonomia e pontos de revisão humana;
• classificação de risco e controles aplicados;
• métricas, logs, incidentes e data da próxima revisão.

A matriz de responsabilidade na prática

Em uma matriz RACI simplificada, a diretoria é accountable pela política; o dono de negócio é accountable pelo caso de uso; Tecnologia/Plataforma é responsável pela infraestrutura e operação; Desenvolvimento é responsável pela implementação; Segurança, Jurídico e DPO são consultados e fiscalizadores; e os usuários são responsáveis por seguir as regras e reportar usos ou incidentes.

Essa separação evita dois erros comuns: transformar DevOps em “dono de toda IA” ou criar um comitê que assume decisões que pertencem ao negócio.

Por onde começar nos próximos 90 dias

• Primeiros 30 dias: nomear o patrocinador executivo, publicar uma política curta de uso aceitável e abrir uma declaração sem punição dos usos atuais.
• De 30 a 60 dias: criar o inventário, definir a classificação de risco e homologar um conjunto inicial de ferramentas.
• De 60 a 90 dias: implantar a via rápida de aprovação, logs mínimos, treinamento por função e revisão dos casos mais críticos.

Conclusão

Shadow AI não é um problema que se resolve escolhendo entre Dev, DevOps ou Segurança. É um tema de governança empresarial. A direção define o risco aceitável; o negócio responde pela finalidade e pelo impacto; Tecnologia cria a plataforma; DevOps/MLOps opera; Desenvolvimento implementa; e Segurança, Jurídico e DPO estabelecem e verificam os controles.

O objetivo não deve ser impedir que as pessoas criem. Deve ser tornar visível o que está sendo criado, acelerar o que é seguro e interromper rapidamente o que expõe a organização.

Referências

• NIST, AI Risk Management Framework (AI RMF)
• NIST AI 600-1, Generative AI Profile
• ISO/IEC 42001:2023, AI management systems
• OWASP GenAI Security Project, riscos e mitigações para aplicações com LLMs
• Comissão Europeia, AI Act e abordagem baseada em risco