📊 Os dados de risco
Os benefícios de vibe coding são reais — e os riscos também. Dados de pesquisas independentes e relatos de líderes técnicos revelam um quadro que exige atenção antes de qualquer implementação em produção.
📈 Números que o executivo precisa conhecer
⚠️ O que esses números significam para executivos
Se 16 de 18 CTOs relataram desastres, o problema não é estatístico — é sistêmico. Não é que alguns CTOs foram imprudentes. É que a ausência de governança transforma a velocidade do vibe coding em vetor de risco. A mesma propriedade que faz o código surgir rapidamente faz os bugs também surgirem rapidamente — e em produção, sem revisão, antes que alguém os detecte.
💡 O contexto correto
Esses dados não invalidam o vibe coding — eles definem as condições nas quais ele deve ser aplicado. Sistemas de aviação têm altas taxas de acidente quando operados sem treinamento. A ferramenta não é o problema; a ausência de processo é. Com governança, os mesmos dados mostram que o risco cai para níveis gerenciáveis.
💥 Os incidentes reais
Casos documentados publicamente mostram o que acontece quando vibe coding é aplicado sem governança. Esses não são hipotéticos — são relatos de empresas reais com usuários reais afetados.
Lovable — 18.000 usuários expostos
DadosPlataforma de vibe coding no-code · Incidente de autenticação · 2025
Um bug no código gerado por IA da plataforma Lovable expôs dados de 18.000 usuários. O problema estava na lógica de autenticação gerada automaticamente, que tinha uma falha de controle de acesso (IDOR — Insecure Direct Object Reference). A empresa levou horas para identificar a causa raiz porque nenhum desenvolvedor tinha lido e compreendido o código gerado antes do deploy. O código "funcionava" nos testes superficiais mas tinha uma brecha estrutural.
Base44 — Falha de controle de acesso em produção
SegurançaPlataforma de no-code vibe coding · Falha de autenticação · 72 horas em produção
Plataforma de no-code vibe coding lançou feature com falha de controle de acesso que permitia usuários acessar dados de outras contas. O código tinha sido gerado por IA e publicado sem revisão de segurança. A vulnerabilidade ficou em produção por 72 horas antes de ser detectada por um usuário externo — não pela equipe interna. O tempo de exposição multiplicou o número de contas potencialmente comprometidas.
Replit Agent — Banco de dados deletado em desenvolvimento
AgenticUsuário individual · Agente com permissões amplas · 8h de trabalho perdidas
Desenvolvedor usando Replit Agent para automação instruiu o agente a "limpar dados de teste". O agente interpretou o comando de forma mais ampla do que o esperado e deletou o banco de dados de desenvolvimento inteiro, incluindo dados que não eram de teste. Backup existia, mas 8 horas de trabalho foram perdidas no processo de restauração. O caso foi documentado pelo próprio usuário no X e tornou-se referência sobre o risco de agentes com permissões irrestritas.
⚠️ O padrão comum nos incidentes
Nos três casos: código em produção sem revisão humana, ausência de SAST, e velocidade de entrega priorizando sobre verificação. A lição executiva: o risco não vem da ferramenta — vem da ausência de processo entre a geração e o deploy.
⚖️ Propriedade intelectual
A questão de propriedade intelectual em código gerado por IA é uma das mais complexas e menos resolvidas do direito de tecnologia em 2025-2026. Há três dimensões que seu time jurídico precisa conhecer.
Perspectiva legal
Quem é dono do código gerado?
A maioria dos ToS (OpenAI, Anthropic, Cursor) concede ao usuário os direitos sobre o output. Porém, nos EUA, código sem autoria humana suficientemente original pode não ser protegível por direito autoral. O USCO já recusou pedidos de registro de obras 100% geradas por IA — a questão ainda está sendo definida nos tribunais.
O que as jurisdições dizem
Posição de diferentes países
EUA: sem proteção para obras sem autoria humana substancial. Reino Unido: permite direito autoral para obras geradas por computador (CDPA 1988). UE: em discussão. Brasil: sem regulamentação específica ainda — LGPD e direito autoral tradicional se aplicam por default. Seu jurídico precisa acompanhar a evolução.
Recomendações práticas
O que fazer agora
Documente a contribuição humana no desenvolvimento (arquitetura, revisão, testes). Use ferramentas enterprise com cláusulas de indemnização de IP (GitHub Copilot Enterprise, Cursor Business). Verifique se a ferramenta usa filtros de reprodução de código licenciado. Revise ToS periodicamente — estão evoluindo.
⚠️ Risco de código de terceiros no output
LLMs foram treinados em código público — incluindo código com licenças restritivas (GPL, AGPL). Há risco de que o modelo gere código que reproduza trechos com licença incompatível com seu uso comercial. Ao enviar código-fonte proprietário para LLMs externos, você pode estar comprometendo a confidencialidade do seu segredo comercial. Verifique a política de retenção de dados de cada ferramenta — algumas usam os dados para treinar modelos futuros.
💡 Insight executivo sobre IP
A questão de IP em IA não tem resposta definitiva em 2026. A decisão pragmática: use ferramentas enterprise com cobertura de indenização de IP (GitHub Copilot Enterprise e Cursor Business têm isso explicitamente), documente o processo de desenvolvimento com revisão humana, e envolva o time jurídico agora — não depois do primeiro contencioso.
📋 LGPD e código de IA
A Lei Geral de Proteção de Dados cria responsabilidades específicas quando LLMs são usados no contexto de desenvolvimento de software que processa dados pessoais de usuários brasileiros.
🗓️ Obrigações LGPD no contexto de desenvolvimento com IA
Dados que NUNCA devem ir para LLMs externos
- ✗CPFs, RGs, passaportes — qualquer identificador único de pessoa
- ✗Dados financeiros de clientes reais (saldos, transações, histórico)
- ✗Dados de saúde (especialmente sensíveis sob LGPD)
- ✗Emails, telefones ou endereços de clientes reais
- ✗Logs de produção que contenham dados pessoais identificáveis
O que fazer na prática
- ✓Usar dados sintéticos ou anonimizados em todos os contextos de desenvolvimento com IA
- ✓Escolher ferramentas com política de não retenção de dados (planos enterprise)
- ✓Documentar no ROPA o uso de IA generativa no desenvolvimento
- ✓Treinar time sobre o que é dado pessoal e o que é dado sintético válido
⚠️ Riscos e penalidades — alerta para executivos
A ANPD pode aplicar multas de até 2% do faturamento bruto (limitado a R$50M por infração) em casos de violação de dados pessoais. Um incidente de segurança causado por código gerado por IA sem revisão adequada pode configurar negligência — o que agrava a penalidade. A responsabilidade é da empresa controladora dos dados, não da ferramenta de IA.
Consulte seu DPO (Data Protection Officer) antes de expandir o uso de LLMs externos no ciclo de desenvolvimento.
🔒 Política de uso seguro
Uma política de uso seguro não precisa ser um documento de 50 páginas. Um checklist de duas categorias — "pode enviar" e "nunca enviar" — já previne a maioria dos incidentes. A clareza é mais importante do que a extensão.
PODE enviar para LLMs externos
- ✓Código novo sem dados de produção ou variáveis de ambiente
- ✓Código de projetos open source ou públicos da empresa
- ✓Dados sintéticos criados especificamente para testes
- ✓Descrições abstratas de problema sem identificadores de usuários
- ✓Código de ferramentas internas sem dados sensíveis embutidos
- ✓Documentação técnica e especificações de produto (sem PI sensível)
NUNCA enviar para LLMs externos
- ✗Chaves de API, tokens de autenticação, senhas de qualquer tipo
- ✗CPFs, emails, dados pessoais de clientes reais
- ✗Dados financeiros de clientes (saldos, transações, histórico de crédito)
- ✗Código-fonte de sistemas classificados como segredo comercial
- ✗Arquivos de configuração com credenciais de produção (.env, config.yml)
- ✗Logs de produção que contenham dados pessoais identificáveis
Exemplo de texto de política (modelo para adaptação)
POLÍTICA DE USO DE IA GENERATIVA NO DESENVOLVIMENTO — [EMPRESA] v1.0
1. FERRAMENTAS AUTORIZADAS: Cursor Business, Claude API (plano Team), GitHub Copilot Enterprise.
2. DADOS PROIBIDOS: É vedado o envio de dados pessoais, credenciais ou código de segredo comercial a LLMs externos. Violação é passível de advertência formal.
3. REVISÃO OBRIGATÓRIA: Todo código gerado por IA deve ter PR com checklist de IA preenchido e aprovado por 1 revisor humano antes do merge.
4. SAST: Análise estática obrigatória em todo código antes do deploy. Vulnerabilidades críticas bloqueiam o pipeline.
5. RESPONSÁVEL: [Nome do DPO/Engenheiro de Segurança]. Dúvidas: [contato]. Vigência: [data] — revisão trimestral.
* Este texto é um modelo inicial. Adapte com seu time jurídico antes de distribuir.
🏗️ Arquitetura de governança
A governança eficaz é construída em camadas — cada camada é uma linha de defesa que impede que problemas cheguem ao usuário final. Não é burocracia; é engenharia de processo.
🔄 Fluxo de governança: Geração → Revisão → Aprovação
O que acontece: Dev gera código com LLM. Responsabilidade do dev: revisar linha por linha antes de qualquer PR.
Papéis: Dev individual · Ferramenta: Cursor, Windsurf, Claude Code ou similar aprovado
O que acontece: PR criado com checklist de IA preenchido. SAST automatizado roda no pipeline. Revisor humano inspeciona o código e a saída do SAST.
Papéis: Engenheiro revisor (obrigatório) · Para sistemas críticos: senior designado · Ferramenta: SonarQube/Snyk no CI/CD
O que acontece: Merge aprovado após SAST sem vulnerabilidades críticas e revisão humana concluída. Deploy com monitoramento ativo nas primeiras 24h.
Papéis: Tech Lead ou Engineering Manager · Ferramenta: alertas de produção configurados (Datadog, Grafana ou similar)
Camada 1: Política de uso
Documento de uma página com "pode enviar / não pode enviar". Distribuído e assinado por todos os devs antes de usar ferramentas de IA. Revisão trimestral obrigatória.
Camada 2: Pull Request obrigatório
Todo código — gerado por IA ou não — deve passar por PR antes do merge. Checklist específico para código de IA: "Você revisou todo o código? SAST passou? Dados sensíveis verificados?"
Camada 3: SAST no pipeline de CI/CD
Análise estática automatizada em todo código antes do deploy. Vulnerabilidades críticas bloqueiam o pipeline automaticamente. Resultado documentado no PR para rastreabilidade.
Camada 4: Revisão de senior obrigatória
Para código em sistemas de produção críticos, revisão de pelo menos um engenheiro sênior é obrigatória antes do merge. Não pode ser bypassada — a velocidade não justifica o risco.
Camada 5: Monitoramento e rollback
Alertas de produção configurados para detectar anomalias rapidamente após deploys. Processo de rollback documentado e testado regularmente. SLA de detecção e resposta definido.
🚫 Quando NÃO usar vibe coding
Existem contextos onde o risco de vibe coding é estruturalmente muito alto — não por falta de governança, mas pela natureza do sistema. Nesses contextos, o código deve ser escrito, revisado e validado por humanos com expertise específica no domínio.
Sistemas financeiros críticos
Lógica de processamento de pagamentos, cálculo de juros, transferências, reconciliação contábil, sistemas de liquidação.
Por que: Um bug de 1 centavo em lógica de cálculo pode resultar em perda financeira de escala e passivo regulatório (BACEN, CVM). A verificação exaustiva necessária elimina o ganho de velocidade.
Sistemas de saúde e medicina
Dosagem de medicamentos, histórico médico, diagnósticos por IA, sistemas de suporte à decisão clínica, monitoramento de pacientes.
Por que: Falhas têm impacto direto na saúde e vida de pacientes. Regulação específica (ANVISA, FDA) exige validação clínica que incompatível com a velocidade do vibe coding.
Infraestrutura crítica nacional
Sistemas de energia elétrica, abastecimento de água, telecomunicações, controle industrial (SCADA/ICS), redes ferroviárias e de aviação.
Por que: Falhas podem ter impacto em escala de população e são frequentemente irreversíveis no curto prazo. Ataques a esses sistemas via código vulnerável têm consequências de segurança nacional.
Sistemas de autenticação e identidade
Lógica de autenticação, autorização, gestão de sessões, controle de acesso de sistemas com dados de alto valor.
Por que: Os incidentes Lovable e Base44 mostraram que falhas de autenticação geradas por IA são um vetor de ataque real. Em sistemas com dados sensíveis, código de auth deve ser escrito e validado por especialistas em segurança.
Sistemas com decisões automatizadas sobre pessoas
Sistemas de crédito automatizado, triagem de currículos, decisões de benefícios sociais, sistemas judiciais auxiliados por IA.
Por que: LGPDs e regulações de IA (EU AI Act) exigem explicabilidade e auditabilidade que o vibe coding não produz nativamente. Riscos de bias sistêmico e responsabilidade legal são elevados.
💡 O critério decisivo — e o equilíbrio correto
Se uma falha no sistema pode resultar em perda irreversível — de vida, de dados críticos, de dinheiro em escala, de infraestrutura — o custo de verificação exaustiva cancela o benefício de velocidade do vibe coding. Nesses casos, a velocidade correta é a velocidade segura.
Mas isso não significa que vibe coding não cabe nesses setores. Significa que ele cabe nas partes certas — ferramentas internas, dashboards, automações de processos, sistemas de suporte que não tocam na lógica crítica. A decisão é sobre granularidade, não sobre exclusão total do setor.
✅ Resumo do Módulo 3.4
Próximo Módulo:
3.5 — 🔭 O Futuro: Do Vibe Coding ao Agentic Engineering: Karpathy em 2026, agentes em paralelo e o novo perfil de engenheiro