Por quase cinco décadas, a governança de segurança corporativa operou sobre uma premissa raramente questionada: existe uma separação clara entre quem usa tecnologia e quem a constrói.
Programas de segurança, modelos de auditoria e controles regulatórios foram todos desenhados com essa divisão como ponto de partida. Essa separação está desaparecendo, e a velocidade com que isso acontece não dá margem para respostas improvisadas.
A mudança estrutural que já está em curso
Ferramentas de geração de código permitem hoje que profissionais sem formação em engenharia de software criem aplicações funcionais, integrem sistemas e automatizem processos corporativos a partir de instruções em linguagem natural.
O fenômeno popularizado como vibe coding não é uma tendência passageira; é uma mudança estrutural na forma como o software passa a ser produzido dentro das organizações, e ela já está em curso na sua empresa, com ou sem a sua ciência.
Para a segurança, o efeito é direto: a superfície de risco cresce de forma descentralizada, fora dos processos formais de arquitetura, desenvolvimento seguro e gestão de riscos. Surge uma nova categoria de exposição, que proponho denominar Shadow Engineering. O problema não é tecnológico, é de governança. A capacidade de desenvolver software foi distribuída por toda a organização, mas a responsabilidade por incidentes, vazamentos e violações regulatórias permaneceu concentrada na empresa.
O que é Shadow Engineering
Shadow IT, Shadow Cloud e Shadow SaaS descrevem o consumo não governado de tecnologia. O vibe coding exige uma categoria nova, porque o que está em jogo deixou de ser consumo e passou a ser produção.
Shadow Engineering é o desenvolvimento, a implantação ou a operação de componentes tecnológicos corporativos fora dos processos formais de arquitetura, engenharia, segurança, conformidade e gestão de riscos. Não se trata de usuários acessando ferramentas não homologadas; trata-se de usuários criando ativos digitais que processam dados sensíveis, automatizam decisões e sustentam processos de negócio, sem qualquer rastro nos inventários ou nos registros de risco da organização.
Por que não é possível conter isso por proibição
O motor dessa transformação é econômico. Historicamente, desenvolver software era caro e exigia equipes especializadas, o que funcionava como uma barreira natural: a engenharia permanecia concentrada em áreas controláveis.
As ferramentas de geração de código derrubaram esse custo de forma estrutural, e atividades que antes demandavam departamentos inteiros passam a ser executadas por um único profissional munido de um assistente.
Quando uma tecnologia reduz o custo de uma atividade dessa forma, sua adoção se torna inevitável. Estratégias baseadas exclusivamente em bloqueio serão contornadas, gerando ironicamente ainda mais Shadow Engineering. O caminho viável é tornar a produção descentralizada de software visível, mensurável e governável.
O risco já se materializou
Em 2023, colaboradores da Samsung inseriram código-fonte proprietário em ferramentas de geração de texto durante atividades de desenvolvimento. A exposição nasceu de boa intenção, operando na ausência de controles, mas houve lacuna de governança. É exatamente esse o perfil do risco de Shadow Engineering.
No mesmo ano, no caso Mata v. Avianca, advogados submeteram ao tribunal referências jurídicas inexistentes, produzidas por uma ferramenta de geração de texto e não verificadas. O resultado foi sanção por falha profissional grave. A falha não esteve na ferramenta, mas na ausência de validação humana sobre o que foi produzido.
Já em 2024, no caso Moffatt v. Air Canada, a companhia foi responsabilizada judicialmente após um assistente virtual fornecer informação incorreta sobre sua política de tarifas. O tribunal rejeitou o argumento de que a empresa não responderia pelas respostas de um sistema automatizado.
Aplicada ao Shadow Engineering, a conclusão é que a organização responde por aplicações que talvez nem saiba que existem. O traço comum aos três casos é que o ponto de falha não foi a tecnologia, foi a lacuna de governança ao redor dela.
Os cinco vetores de risco
Aplicações construídas fora dos controles formais tendem a manipular dados sem classificação ou minimização, expondo informações sensíveis que trafegam por serviços externos sem acordo de tratamento.
Código gerado por assistência automatizada continua sujeito às vulnerabilidades catalogadas no OWASP Top 10 e no CWE Top 25, e sem revisão de segurança essas vulnerabilidades chegam à produção em ativos que ninguém auditou.
Do ponto de vista regulatório, LGPD, GDPR, PCI DSS, DORA e NIS2 impõem controles que usuários de negócio, em regra, desconhecem, e uma aplicação construída sem essa consciência pode violar exigências legais desde o primeiro dia de operação.
Operacionalmente, sistemas críticos surgem sem inventário, sem plano de continuidade e sem gestão de configuração e, quando falham, não há processo formal para restaurá-los porque formalmente nunca existiram. Além disso, à medida que o desenvolvimento se descentraliza sem registro, a organização perde a noção de quantos sistemas possui, e com isso perde também a capacidade de governar.
Roadmap para líderes de segurança
A resposta ao Shadow Engineering precisa partir da visibilidade e avançar até a resiliência.
Nos primeiros seis meses, o foco deve ser mapear o que já existe: inventariar ferramentas de geração de código em uso, identificar agentes e automações em operação e atualizar a política de uso aceitável para contemplar o desenvolvimento descentralizado.
De seis a doze meses, o trabalho passa a instituir governança dedicada com participação de segurança, jurídico, conformidade e negócio, e definir requisitos mínimos que toda aplicação deva cumprir antes de processar dados corporativos.
No segundo ano, o objetivo é escalar esse modelo com um ciclo de desenvolvimento seguro, adaptado à produção descentralizada e monitoramento automatizado dos ativos criados fora dos canais formais.
A partir do terceiro ano, a meta é resiliência, integrando o tema ao programa corporativo de Enterprise Risk Management, quantificando a exposição financeira com metodologia FAIR e conduzindo simulações de crise envolvendo falhas de aplicações que nasceram fora da governança formal.
A pergunta que os conselhos ainda não estão fazendo
Ao longo de mais de vinte anos em segurança da informação, acompanhei o perímetro de proteção ser redefinido repetidas vezes.
O Shadow Engineering representa uma transformação de escopo comparável às anteriores, com uma diferença relevante: nenhuma das ondas anteriores colocou a capacidade de criar tecnologia nas mãos de toda a organização ao mesmo tempo.
A pergunta que os conselhos de administração deveriam fazer não é qual é a política da empresa para essas ferramentas. E sim, como a organização está governando os milhares de desenvolvedores em potencial que já existem dentro dela.
As empresas que responderem a isso de forma estruturada construirão uma vantagem real.
As demais descobrirão que a maior superfície de ataque da próxima década não terá sido aberta por adversários externos, mas criada pelos próprios colaboradores, movidos pelas melhores intenções e pelas ferramentas mais poderosas já colocadas em suas mãos.
Se este tema já chegou à sua organização ou você ainda está mapeando o tamanho da exposição, os especialistas do Ivy Group S/A estão disponíveis para conversar. Entre em contato.
