O vibe coding chegou às empresas brasileiras pela porta dos fundos, e quase sempre com a melhor das intenções. Alguém do financeiro, do comercial ou da operação descreve um problema para uma ferramenta de IA, recebe uma aplicação funcionando em algumas horas e coloca aquilo em uso na mesma semana. Ninguém violou política, porque em geral não existia política sobre vibe coding. Portanto, a discussão útil aqui não é sobre proibir. É sobre o que acontece com essas aplicações no terceiro mês, quando elas já processam dado de cliente e ninguém sabe quem responde por elas.
O antes e o depois: quando construir software virou tarde de trabalho
Até pouco tempo atrás, resolver uma necessidade interna com software significava abrir um chamado, disputar prioridade e esperar orçamento. Boa parte das áreas desistia no meio do caminho e voltava para a planilha. Esse era o equilíbrio, imperfeito, porém previsível.
Com o vibe coding, no entanto, o custo de criar caiu de forma abrupta. Hoje, uma pessoa sem formação técnica descreve o que quer em linguagem natural e recebe uma aplicação com interface, banco de dados e endereço na internet. A produtividade é real e explica a adoção rápida. O ponto cego também é real, já que ninguém no caminho perguntou onde esse dado ia parar.
O que separa o vibe coding que dá certo do que vira incidente
Nem toda aplicação criada com vibe coding representa risco. Uma calculadora interna que não guarda nada, roda no computador de uma pessoa e não se conecta a sistema algum é inofensiva. O problema aparece quando três características caminham juntas.
A primeira envolve dado sensível, ou seja, informação de cliente, de colaborador, financeira ou de saúde. A segunda é exposição para fora, quando a aplicação ganha um endereço público que qualquer pessoa alcança. A terceira é conexão com sistema interno, porque a partir daí a aplicação deixa de ser um brinquedo isolado e vira porta de entrada.
Quando as três aparecem juntas, você não tem mais um experimento. Você tem um sistema de produção sem dono, sem inventário e sem manutenção prevista.
Vibe coding e os riscos que já aparecem em número
Os dados de segurança sobre o código gerado por IA são consistentes o bastante para orientar decisão. O relatório GenAI Code Security 2025, da Veracode, avaliou mais de cem modelos em 80 tarefas de programação e encontrou 45% das amostras falhando em testes baseados no OWASP Top 10, a referência global de riscos em aplicações web. O índice não melhorou no último ano, apesar das promessas dos fornecedores de ferramentas de vibe coding.
A exposição já é mensurável em campo. Levantamentos citados pelo setor apontam cerca de 380 mil aplicações web criadas com ferramentas de IA acessíveis publicamente, sem controle de acesso. Desse total, aproximadamente cinco mil vazavam dado corporativo e pessoal sensível, incluindo escala de trabalho de hospital com identificação de médicos e conversas entre pacientes e profissionais de saúde. A empresa de segurança Red Access encontrou cinco mil aplicações de uso corporativo expostas na internet, nenhuma delas listada em qualquer inventário de ativos.
Além disso, as falhas se repetem em padrão. Consultas ao banco que juntam texto em vez de usar parâmetros abrem caminho para injeção de comando. Esse padrão apareceu em cerca de 34% das aplicações testadas no primeiro trimestre de 2026. A chave de acesso digitada direto no código é o outro clássico, porque basta alguém encontrar o arquivo para usar o serviço no lugar da empresa.
A AI Infinity estrutura governança, segurança e critérios claros para que as áreas ganhem velocidade sem criar aplicações órfãs e riscos invisíveis. Fale com nosso time.
Os pré-requisitos que quase ninguém cumpre
Antes de discutir ferramenta de vibe coding, vale checar quatro itens simples. Nenhum deles exige time de engenharia grande e todos evitam a maior parte dos incidentes conhecidos.
O primeiro chama-se inventário, porque ninguém protege o que não aparece em lista. O segundo é autenticação de verdade, já que muita aplicação nasce aberta e continua assim. O terceiro é gestão de segredos, ou seja, chaves e senhas fora do código, guardadas em cofre. O quarto pede dono, ou seja, uma pessoa que atualiza e desliga aquilo quando o uso acabar.
Repare que nenhum desses pontos discute a qualidade do código em si. Todos tratam do entorno, que é justamente onde o vibe coding costuma falhar.
Quem responde quando o código foi escrito por IA
Do ponto de vista jurídico, aliás, a origem do código é irrelevante. Se a aplicação tratava dado pessoal e vazou, a Lei Geral de Proteção de Dados coloca a responsabilidade na empresa que a publicou. A ANPD, aliás, incluiu inteligência artificial entre os eixos prioritários de fiscalização para o biênio 2026 e 2027.
Existe ainda um risco menos comentado, que é o de continuidade. A pessoa que criou a aplicação sai da empresa e leva consigo o contexto inteiro, uma vez que ninguém escreveu documentação, organizou repositório ou registrou decisão. O sistema continua rodando até quebrar. Quando quebrar, ninguém saberá por onde começar.
Como liberar o vibe coding com trilho em vez de proibir
Bloquear o vibe coding não funciona, e a experiência com shadow IT já mostrou isso. Quem precisa resolver um problema urgente encontra outro caminho, muitas vezes no dispositivo pessoal, fora de qualquer visibilidade. O caminho que funciona passa por dar trilho, isto é, ambiente próprio, padrão mínimo de revisão e critério claro sobre o que pode ir para produção.
Na prática, esse trilho separa três categorias. O que não guarda dado sensível nem fica exposto roda livre. Já a aplicação com dado interno passa por revisão antes de publicar. Por fim, o que toca cliente, dinheiro ou dado pessoal vira projeto de engenharia, com as exigências que qualquer sistema crítico tem.
É esse desenho que a AI Infinity monta dentro do cliente. Em vez de entregar uma ferramenta e desejar sorte, a empresa instala um departamento de inteligência artificial com squad, método e governança na mesma estrutura, definindo o que cada área pode construir sozinha e o que precisa de engenharia. Além disso, a governança de dados entra como princípio de arquitetura, com isolamento por cliente e propriedade intelectual do código, dos agentes e da documentação nas mãos de quem contratou. O oposto, portanto, da aplicação órfã que ninguém assume.
A decisão que cabe à diretoria
A pergunta sobre vibe coding para levar à próxima reunião é curta. Quantas aplicações existem hoje na sua empresa que ninguém da tecnologia sabe que existem, e quantas delas tocam dado de cliente? Enquanto ninguém souber a resposta, o risco segue fora de controle, mesmo que nada tenha acontecido até agora.
Vale dizer o outro lado com a mesma clareza, sem dúvida. Empresa que proíbe perde velocidade real e empurra o problema para a sombra. O objetivo aqui não é frear quem resolve problema, e sim garantir que a solução de hoje não vire o incidente do próximo trimestre.
FAQ: Vibe Coding
1. Como distinguir a aplicação que pode continuar rodando da que precisa ser reescrita?
Avalie três eixos antes de decidir, a saber: sensibilidade do dado tratado, exposição na rede e integração com sistemas internos. Aplicação isolada, sem dado pessoal e sem endereço público, segue em uso com ajustes de autenticação e um dono nomeado. Já a que combina dado de cliente com acesso externo costuma exigir reescrita, porque corrigir falha estrutural em código sem testes sai mais caro que refazer com escopo enxuto.
2. Pedir para a própria IA revisar o código resolve o problema de segurança?
Ajuda pouco e, em certos casos, piora. Um experimento publicado nos anais do IEEE-ISTAS 2025 mediu o efeito de rodadas sucessivas de refinamento assistido e encontrou aumento de 37,6% nas vulnerabilidades críticas depois de cinco iterações. Ou seja, pedir para o modelo melhorar o próprio trabalho não substitui análise estática, revisão humana e teste de intrusão nas aplicações que importam.
3. Quem responde perante a ANPD se o vazamento veio de código gerado por IA?
A empresa responde, na condição de controladora dos dados. O fornecedor da ferramenta de geração de código não assume essa posição, e o argumento de que a falha foi do modelo não afasta a responsabilidade. Por isso, o registro de qual aplicação existe, quem a criou e qual dado ela toca deixa de ser burocracia e vira peça de defesa.
4. Como fazer o inventário sem transformar isso em caça às bruxas?
Anuncie o levantamento como anistia, isto é, com prazo e sem punição para quem se apresentar. Ofereça algo em troca, como suporte para deixar a aplicação em conformidade ou para migrar o que virou essencial. Depois do prazo, sim, vale monitorar tráfego e domínios para achar o que ficou de fora. A ordem importa, porque começar pelo bloqueio garante que metade das aplicações nunca apareça.
5. Em que momento um projeto de vibe coding deveria virar projeto de engenharia?
Quando a aplicação cruza uma destas quatro linhas: ganha usuários fora da área que a criou, começa a tratar dado pessoal, integra com sistema que gera efeito financeiro ou vira dependência de um processo que não pode parar. Nesse ponto, o custo de um incidente supera o custo de fazer direito, e o assunto deixa de ser produtividade individual para virar risco de operação.
