SOC 2 e ISO 27001 não fazem exceção para código gerado por IA: um sistema vibe coded que processa dado de cliente ou sustenta relatório financeiro entra no escopo de auditoria pelo que ele faz, não por como foi escrito. Na prática, vibe coding não reduz a obrigação de controle — aumenta o ônus de evidência, porque os artefatos tradicionais de gestão de mudança (ticket, revisão de código, aprovação registrada) costumam ser mais rasos em um fluxo de prompt conversacional do que em um pipeline de desenvolvimento tradicional.
Este artigo é para quem lidera engenharia, segurança da informação ou compliance em empresas que já vibe codam aplicações internas ou comerciais — ver o panorama completo em vibe coding nas empresas: velocidade com governança — e precisam responder a um cliente, auditor ou questionário de due diligence que pergunta: "como vocês garantem controle sobre código escrito por IA?".
O que muda quando um app vibe coded entra no escopo de auditoria
SOC 2 (framework da AICPA, focado em cinco critérios de confiança: segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade) e ISO 27001 (norma internacional de sistema de gestão de segurança da informação) não têm cláusula específica sobre "como o código foi produzido". O que eles exigem é evidência de controle sobre mudança, acesso e risco — e é aí que o vibe coding tropeça, não na tecnologia em si.
O ponto de atrito mais comum é o controle CC8.1 (Change Management) do SOC 2: ele espera um processo formal de revisão e aprovação antes de qualquer mudança ir para produção. Um fluxo de prompting rápido, sem etapa de revisão ou aprovação documentada antes do deploy, é quase o oposto do que esse controle foi desenhado para evidenciar (Accel Comply, "Does SOC 2 Require Code Review for AI-Generated Code?").
Aplicativos vibe coded costumam ter log de aplicação para depuração — mas não o log de auditoria estruturado e à prova de adulteração que um auditor de SOC 2 espera encontrar (vahu.org, "Compliance Controls for Vibe-Coded Systems").
O tamanho do problema: vulnerabilidade em código gerado por IA
O risco de segurança do código em si já é conhecido — cobrimos em detalhe no checklist de segurança do vibe coding — mas vale reafirmar o número que sustenta a exigência de compliance mais rígida: em março de 2026, a Veracode analisou cerca de 4 milhões de scans e encontrou 45% das amostras de código gerado por IA introduzindo pelo menos uma vulnerabilidade do OWASP Top 10. Código gerado por IA carrega, em média, de 1,5 a 2 vezes a taxa de vulnerabilidade do código escrito por humano.
Esse número é exatamente o motivo pelo qual auditores de SOC 2 e ISO 27001 não tratam vibe coding como "só mais uma forma de escrever código" — o volume de vulnerabilidade introduzida exige controle compensatório proporcional.
Os controles que um auditor vai cobrar
Cinco frentes concentram a maior parte das lacunas encontradas em sistemas vibe coded:
- Trilha de auditoria de sessão. Registro de cada sessão de prompting que gerou código em produção — não só o commit final, mas o histórico de prompts e revisões que levaram até ele.
- Revisão humana documentada antes do deploy. Um humano nomeado precisa ter revisado e aprovado a mudança, com registro de quando e por quem — mesmo em fluxo assistido por agente.
- Princípio de menor privilégio para o agente de codificação. O agente de IA não deveria ter acesso irrestrito a produção, segredos ou dados sensíveis durante a geração de código — o Replit Enterprise, por exemplo, endereça isso com RBAC granular e SSO/SCIM nativos.
- Classificação de risco por tipo de aplicação. Nem todo app vibe coded merece o mesmo nível de controle — um protótipo interno de baixo risco não precisa do mesmo rigor que um sistema que processa dado de cartão de crédito. Ver matriz de risco do vibe coding.
- Inventário atualizado do portfólio. Um auditor não avalia o que a empresa não sabe que existe — sem inventário de portfólio de vibe coding, não há como demonstrar escopo completo de controle.
SOC 2 vs. ISO 27001: o que cada um exige na prática
| Dimensão | SOC 2 | ISO 27001 |
|---|---|---|
| Natureza | Relatório de atestação (AICPA, EUA) | Certificação de sistema de gestão (ISO, internacional) |
| Foco | Controles de confiança sobre um serviço específico | Sistema de gestão de segurança da informação da organização inteira |
| Validade | Relatório por período (Type II cobre 6–12 meses de operação) | Certificado válido por 3 anos, com auditorias de manutenção anuais |
| Uso típico no Brasil | Exigido por clientes enterprise americanos/SaaS B2B | Exigido por clientes que compram de fornecedores globais ou setores regulados |
| Relevância para vibe coding | Controle de mudança (CC8.1) é o ponto mais testado | Anexo A cobre desenvolvimento seguro (A.8.25–A.8.29) diretamente |
Empresas brasileiras que vendem para clientes enterprise — no Brasil ou no exterior — cada vez mais recebem os dois pedidos na mesma due diligence, principalmente quando o fornecedor usa IA generativa em qualquer parte do ciclo de desenvolvimento.
Roteiro prático: preparar um sistema vibe coded para auditoria
Para times que já vibe codam e precisam se preparar para uma auditoria SOC 2 Type II ou uma certificação ISO 27001 sem refazer o sistema do zero, a sequência que reduz mais esforço de retrabalho é:
- Inventariar antes de controlar. Levantar todo sistema vibe coded em produção, com dono nomeado e dado que ele processa — sem isso, nenhum controle seguinte tem escopo definido.
- Classificar por risco. Aplicações que tocam dado de cliente, dado financeiro ou infra crítica entram no perímetro de auditoria primeiro; protótipo interno de baixo risco pode esperar.
- Retroagir a trilha de auditoria. Para sistemas já em produção, reconstituir o histórico de mudança relevante (commits, deploys, quem aprovou) na medida do possível, e passar a registrar tudo daqui para frente.
- Formalizar o ponto de revisão humana. Definir, por escrito, quem tem autoridade para aprovar deploy de código gerado por IA — e garantir que essa aprovação fique registrada, não apenas implícita em um "ok" de chat.
- Selecionar o framework pela demanda do cliente, não por preferência interna. Se a base de clientes é majoritariamente SaaS B2B americano, SOC 2 tende a vir primeiro; se a empresa vende para setores regulados ou clientes internacionais fora dos EUA, ISO 27001 costuma aparecer antes.
Esse roteiro reduz o tempo de preparação, mas não substitui um assessment formal com um auditor credenciado — o objetivo aqui é chegar a esse assessment com a maior parte da evidência já organizada, em vez de reconstruí-la sob pressão de prazo.
Quando isso vira exigência contratual
O gatilho mais comum não é uma auditoria espontânea — é um questionário de segurança de um cliente enterprise perguntando explicitamente "vocês usam IA para gerar código? Como isso é controlado?". Projeções de mercado (Forrester) estimam que, até 2026, 70% das empresas vão precisar de controles de compliance especializados para desenvolvimento assistido por IA, ante apenas 15% em 2024 — e que, até 2027, 85% do compliance de vibe coding será garantido por motores de política automatizados, não revisão manual.
Isso não é exigência isolada de mercado americano: qualquer empresa brasileira que venda software para outra empresa — SaaS B2B, sistema white-label, integração via API — deve esperar essa pergunta entrar no processo comercial em algum momento, independentemente de onde o cliente final esteja.
FAQ
SOC 2 e ISO 27001 têm cláusula específica sobre IA generativa?
Não diretamente — nenhum dos dois frameworks cita "vibe coding" ou "IA generativa" como categoria à parte. O que eles exigem é evidência de controle de mudança, acesso e risco; o vibe coding entra no escopo pela forma como afeta esses controles, não por uma cláusula dedicada.
Um app vibe coded pode passar em auditoria SOC 2 Type II?
Pode, desde que os controles de revisão humana documentada, trilha de auditoria e classificação de risco estejam implementados antes do período de avaliação — Type II avalia a operação efetiva do controle ao longo de 6 a 12 meses, não só a existência da política no papel.
Qual a diferença entre segurança do código e compliance do sistema?
Segurança do código (coberta em segurança do vibe coding) é sobre vulnerabilidade técnica — injeção, exposição de segredo, falha de autenticação. Compliance é sobre evidência de processo — se existe registro de quem revisou, aprovou e monitorou aquela mudança. Os dois são necessários e independentes.
Ferramentas como o Replit Agent ajudam nesse compliance?
Plataformas com controle nativo — RBAC granular, SSO/SCIM, log de auditoria — reduzem o esforço de implementar esses controles manualmente, mas não substituem a política de revisão humana e classificação de risco que a empresa precisa definir. Ver Replit Enterprise: governança nativa para vibe coding.
Por onde uma empresa deve começar?
Pelo inventário: sem saber quantos sistemas vibe coded existem e qual o nível de risco de cada um, não há como priorizar onde aplicar controle de compliance primeiro. Ver governança de portfólio de vibe coding.
Conclusão
Vibe coding não isenta uma empresa de SOC 2 ou ISO 27001 — só desloca onde o esforço de compliance precisa entrar: menos no código em si, mais na evidência de processo em torno dele. Trilha de auditoria de sessão, revisão humana documentada e classificação de risco por aplicação são os três controles que decidem se um sistema vibe coded passa ou não em auditoria — e são os três que mais faltam hoje.
Se sua empresa está estruturando o programa de governança de vibe coding com o cliente enterprise já batendo na porta perguntando sobre compliance, fale com a Jetpacks sobre o business case da governança.
Descubra onde a IA gera mais resultado na sua empresa.
Comece com um diagnóstico gratuito: mapa de impacto por área e o desenho de um primeiro piloto medível, sem compromisso.