Riscos do vibe coding nas empresas: matriz de risco

Os riscos do vibe coding nas empresas não são um bloco único — variam drasticamente conforme o dado que a aplicação toca, o quanto ela é crítica, quem vai usá-la e o quanto o agente de IA agiu sem supervisão para criá-la. Tratar "um protótipo de fim de semana" e "um formulário que grava CPF de cliente numa planilha" com a mesma régua é o erro mais comum de quem tenta governar vibe coding — e é exatamente por isso que política genérica de "revisar tudo" trava a adoção, e política de "não revisar nada" cria passivo. Este guia apresenta um framework de classificação de risco: quatro critérios que colocam qualquer aplicação vibe-coded num de quatro níveis — baixo, médio, alto ou crítico — e o nível de revisão que cada um exige antes de ir para produção.

Por que "revisar tudo" ou "não revisar nada" são as duas respostas erradas

O guia de vibe coding nas empresas já mapeou os riscos gerais da prática — segurança, dados sensíveis, shadow IT, ausência de padrões (se você ainda não conhece a definição completa do termo, comece por o que é vibe coding). O que falta na maioria das empresas não é saber que o risco existe; é saber decidir, caso a caso, o quanto de governança um app específico exige. Sem esse critério, duas coisas acontecem, e nenhuma é boa:

• Governança de tamanho único trava a velocidade. Exigir revisão técnica completa para todo protótipo — incluindo o painel interno que um analista monta para ver as próprias vendas da semana — mata exatamente o ganho que trouxe as áreas de negócio para o vibe coding em primeiro lugar.
• Ausência de critério deixa passar o que importa. Sem uma régua, o aplicativo que processa dado de cliente passa pelo mesmo caminho livre do protótipo descartável — e é aí que nasce o incidente que vira manchete.

A saída não é escolher entre os dois extremos. É classificar. Uma análise recente da Distrito sobre os riscos do vibe coding nas empresas já aponta essa direção, propondo separar protótipos internos sem dados reais de integrações com produção em setores regulados. O framework abaixo leva essa lógica adiante, com quatro critérios explícitos e uma regra clara de como combiná-los.

O framework: quatro critérios que definem o risco de cada aplicação

Toda aplicação vibe-coded pode ser avaliada em quatro dimensões independentes. Cada uma delas, sozinha, já é suficiente para elevar o risco — é por isso que a classificação final não é uma média, é o pior caso entre as quatro (mais sobre isso na seção seguinte).

1. Exposição de dados

O que a aplicação lê, processa ou armazena. É o critério de maior peso prático, porque conecta diretamente com a LGPD (Lei 13.709/2018) e com a exposição de segredos que já preocupa quem lida com governança de IA.

• Baixo — sem dados reais: dados fictícios, sintéticos ou de exemplo.
• Médio — dados internos não sensíveis: métricas operacionais, informação já pública dentro da empresa.
• Alto — dados pessoais de colaboradores ou clientes (nome, e-mail, CPF) em volume limitado, ou dado interno confidencial (financeiro não público, estratégico).
• Crítico — dado pessoal sensível conforme a LGPD (saúde, biometria, dado de criança e adolescente), dado financeiro que movimenta valor, ou segredo industrial.

2. Criticidade do sistema

O que acontece se a aplicação falhar, sair do ar ou entregar um resultado errado.

• Baixo — protótipo descartável, uso pontual, ninguém depende dele para trabalhar amanhã.
• Médio — ferramenta de apoio recorrente de uma pessoa ou grupo pequeno; a falha gera retrabalho, não parada.
• Alto — processo do dia a dia de uma área inteira depende dela; a falha impacta a operação daquela área.
• Crítico — integra com sistemas de produção ou oficiais da empresa, movimenta dinheiro, ou a falha chega ao cliente externo ou a um requisito de compliance.

3. Público-alvo da aplicação

Quem usa o que foi construído — e, portanto, quantas pessoas um erro atinge.

• Baixo — uso pessoal de quem criou a aplicação.
• Médio — um time ou área interna restrita.
• Alto — múltiplas áreas da empresa, uso corporativo amplo.
• Crítico — usuários externos: clientes, parceiros, público em geral.

4. Nível de autonomia do agente gerador de código

Este é o critério que a maioria dos frameworks de risco de shadow IT e low-code ainda não tinha, porque não existia antes do vibe coding: o quanto a IA agiu sozinha para chegar ao resultado, sem que uma pessoa revisasse cada decisão no caminho. O mesmo espectro de autonomia que detalhamos em governança de agentes de IA autônomos se aplica aqui, adaptado ao código:

• Baixo — geração assistida com revisão linha a linha por alguém com conhecimento técnico antes de cada mudança.
• Médio — geração supervisionada: a pessoa acompanha os checkpoints e testa manualmente antes de aceitar cada etapa relevante (o fluxo que descrevemos em como funciona o Replit Agent).
• Alto — geração majoritariamente autônoma (modo agente completo, como o Replit Agent em autopilot): a pessoa revisa o resultado final, não o código gerado no caminho.
• Crítico — autonomia total, incluindo deploy automático em produção sem um humano no caminho antes de qualquer ação sensível ir ao ar.

A matriz de classificação: como combinar os quatro critérios

A regra é simples e deliberadamente conservadora: o nível de risco final da aplicação é o maior nível entre os quatro critérios, nunca a média entre eles. Um app com dado de saúde de paciente é crítico mesmo que o público seja "só o time de dez pessoas do ambulatório" e o sistema seja "só um protótipo" — o pior critério governa, porque um único ponto fraco já é suficiente para o incidente acontecer. Essa lógica de "o elo mais fraco decide o nível de risco" segue o mesmo princípio usado em frameworks corporativos de avaliação de risco, como o NIST SP 800-30, aplicado aqui ao caso específico do código gerado por IA.

Critério	Baixo	Médio	Alto	Crítico
Exposição de dados	Fictícios/sintéticos	Interno não sensível	Dado pessoal (LGPD) em volume limitado	Dado sensível (saúde, biometria) ou financeiro
Criticidade do sistema	Protótipo descartável	Apoio recorrente de um grupo pequeno	Processo diário de uma área inteira	Integrado a produção / movimenta dinheiro
Público-alvo	Só quem criou	Time/área interna restrita	Múltiplas áreas da empresa	Clientes ou público externo
Autonomia do agente	Revisão linha a linha	Supervisionada com checkpoints	Majoritariamente autônoma	Autônoma com deploy automático

O nível final de risco de uma aplicação é o pior valor encontrado em qualquer uma das quatro linhas para aquele app específico — não a soma, não a média.

O que muda na governança em cada nível de risco

Classificar só compensa se o resultado muda o que a empresa exige antes do app ir ao ar. É aqui que o framework vira operação, não teoria:

Nível de risco	Quem pode publicar	Revisão exigida	Controles adicionais
Baixo	Qualquer colaborador capacitado, sem aprovação prévia	Nenhuma revisão formal — scan automático básico de segredos, se a plataforma oferecer	Registro simples no inventário de aplicações internas
Médio	Colaborador capacitado, com aviso ao responsável da área	Revisão por par ou pela liderança da área antes de virar ferramenta padrão	Inventário obrigatório, dono designado
Alto	Só com plano de revisão técnica definido antes de começar	Revisão técnica obrigatória por TI/segurança antes de ir para produção	SSO/RBAC, log de auditoria, teste de segurança básico (varredura de dependências e segredos)
Crítico	Não é decisão da área sozinha — é projeto conjunto com TI/segurança/jurídico	Aprovação formal de TI e compliance, revisão de segurança completa, sign-off documentado	Ambiente com controles enterprise (SSO, VPC, DLP), auditoria contínua, plano de resposta a incidente

Na prática, a maioria dos apps vibe-coded numa empresa vive nos níveis baixo e médio — e é aí que o framework libera velocidade, tirando a exigência de revisão pesada de onde ela não é necessária. Ele só freia onde o risco de fato justifica frear.

Exemplos: classificando casos reais

Nenhum framework convence sem exemplo. Veja como os mesmos quatro critérios classificam aplicações típicas de vibe coding dentro de uma empresa:

Caso de uso	Dados	Criticidade	Público	Autonomia	Risco final
Painel que mostra vendas por região, dados já agregados internamente	Médio	Médio	Médio	Médio	Médio
Protótipo de chatbot de FAQ interno para testar uma ideia, com perguntas fictícias	Baixo	Baixo	Baixo	Alto	Alto (a autonomia do agente puxa o risco para cima)
Formulário que registra nova oportunidade comercial com nome e e-mail do lead	Alto	Médio	Médio	Baixo	Alto
Automação que aprova reembolso e libera pagamento sem revisão intermediária	Crítico	Crítico	Alto	Crítico	Crítico
App de agendamento usado por pacientes de uma clínica parceira	Crítico	Alto	Crítico	Médio	Crítico

O segundo caso é o mais instrutivo: um protótipo inofensivo pelos três primeiros critérios ainda vira alto risco só por ter sido construído em modo totalmente autônomo, sem ninguém revisando o que a IA decidiu no caminho — o tipo de situação que uma política de "dado sensível, sim ou não" deixaria passar, e o motivo pelo qual o quarto critério existe.

Os dados por trás de cada critério

Nenhum dos quatro critérios é hipotético — cada um responde a um risco já documentado:

• Exposição de dados. O relatório GenAI Code Security 2026 da Veracode, que testou dezenas de modelos de IA em tarefas reais de codificação, encontrou que 44% do código gerado falha em testes de segurança contra o OWASP Top 10 — e a aprovação cai para apenas 30% em Java, linguagem comum em sistemas corporativos, segundo cobertura da TheNextWeb. Código que toca dado sensível sem revisão carrega esse risco embutido.
• Criticidade do sistema. O Gartner projeta, no relatório Predicts 2026, que geração de código por IA sem processo de validação adequado pode aumentar os defeitos de software em até 2.500% até 2028, segundo o Portal Information Management. Quanto mais crítico o sistema, maior o custo de cada defeito não revisado.
• Público-alvo e shadow IT. Uma varredura de uma empresa israelense de cibersegurança, em maio de 2026, identificou cerca de 380 mil aplicações vibe-coded publicamente acessíveis sem os controles de segurança padrão de quem as criou, das quais ~5 mil vazavam dados sensíveis ativamente, segundo o Portal Information Management. O Gartner já via esse padrão antes da onda de vibe coding: 41% das organizações relataram uso de tecnologia fora do controle formal de TI, segundo pesquisa de 2024 citada pela Distrito — o vibe coding amplia um problema que já existia, não cria um novo.
• Autonomia do agente. Quanto menos supervisão humana no caminho, menor a chance de captar o erro antes da publicação — o mesmo raciocínio por trás dos controles de checkpoint que a própria Replit reforçou após o incidente descrito em como funciona o Replit Agent, quando um agente apagou um banco de produção mesmo após instrução explícita de não alterar nada.

Como aplicar o framework na sua empresa

Critérios no papel só valem quando viram processo. Quatro passos operacionalizam o framework:

1. Publique a matriz como parte da política de uso de IA. O framework de classificação entra como anexo prático da política de uso de IA na empresa — não como documento à parte que ninguém consulta.
2. Exija a autoclassificação antes de publicar. Quem constrói responde às quatro perguntas (dado, criticidade, público, autonomia) antes de colocar qualquer app no ar — dois minutos de formulário, não um processo de aprovação.
3. Automatize a rota, não a decisão. Baixo e médio seguem direto; alto e crítico disparam automaticamente um chamado para TI/segurança. A régua decide o caminho, uma pessoa decide o mérito.
4. Mantenha o inventário vivo. Toda aplicação classificada entra num registro único — o mesmo princípio de visibilidade central que sustenta qualquer governança de agentes de IA autônomos ou agente de IA para não-desenvolvedor: saber a qualquer momento quantas aplicações existem, quem é dono e qual o nível de risco de cada uma.

É esse desenho — critério objetivo, rota automática, dono designado — que a Jetpacks instala dentro do método Flight Plan: o Launchpad mapeia os casos de uso existentes e o risco de cada um, o Booster capacita o time dentro do programa Builders já usando essa régua, e o Mission Control acompanha se as aplicações de alto e crítico risco de fato passaram pela revisão devida. Como parceira oficial da Replit no Brasil, é assim que a Jetpacks conduz essa adoção — sem travar o protótipo de baixo risco e sem deixar passar o que não pode passar.

FAQ

Quais são os principais riscos do vibe coding nas empresas?

Vulnerabilidades de segurança no código gerado (o próprio setor mede falha em quase metade das amostras testadas contra o OWASP Top 10), exposição de dados sensíveis sem os controles da LGPD, shadow IT — aplicações que a TI não sabe que existem — e ausência de padrões entre equipes. Mas o risco real de cada aplicação específica depende do caso: um protótipo interno sem dado real carrega uma fração do risco de um app que processa dado de cliente.

Como saber se uma aplicação vibe-coded é de alto risco?

Avalie quatro critérios: que dado ela toca, quão crítico é o sistema se ela falhar, quem vai usá-la e o quanto o agente de IA agiu de forma autônoma para criá-la. Se qualquer um desses quatro pontos for alto ou crítico, a aplicação inteira deve ser tratada nesse nível — o pior critério decide, não a média entre eles.

Todo app vibe-coded precisa de revisão técnica antes de ir ao ar?

Não. Aplicações de baixo e médio risco — protótipos sem dado real, ferramentas internas de apoio para um grupo pequeno — podem seguir sem revisão técnica formal, só com registro no inventário. Exigir o mesmo processo pesado para tudo é o que trava a adoção sem reduzir o risco que de fato importa.

Qual a diferença entre os riscos do vibe coding e os riscos gerais da IA generativa?

Vibe coding produz um artefato que age no mundo — um app, uma automação, uma integração — não apenas uma resposta em texto. Isso muda o tipo de risco: além de viés ou informação incorreta, entram vulnerabilidades de segurança, dependências inseguras e shadow IT, riscos próprios de software em produção que uma resposta de chatbot não carrega.

O vibe coding é uma forma de shadow IT?

Pode virar, se a empresa não tiver visibilidade sobre o que foi criado. A diferença para o shadow IT tradicional é a velocidade: hoje qualquer área constrói uma aplicação em horas, sem passar pela TI, o que multiplica o volume de shadow IT potencial em muito menos tempo do que levava antes.

Quem deve aprovar uma aplicação vibe-coded de alto risco?

TI e segurança da informação, no mínimo — com jurídico ou compliance envolvido quando o dado for sensível ou o público for externo. A aprovação não deve ser da própria área que construiu o app, exatamente porque o objetivo da revisão é ter um olhar de fora avaliando o que quem criou não tem como enxergar sozinho.

Como reduzir o risco sem proibir o vibe coding nas áreas de negócio?

Classificando antes de proibir. A maior parte dos casos de uso de uma área de negócio cai em baixo ou médio risco e pode seguir livre; o framework existe para identificar rápido os poucos casos que precisam de revisão pesada, em vez de aplicar a mesma trava para todo mundo.

Conclusão: risco não se governa em bloco, se classifica caso a caso

Os riscos do vibe coding nas empresas são reais, mas tratá-los como um risco único — travando tudo ou liberando tudo — é o que gera tanto lentidão desnecessária quanto exposição desnecessária. Um framework de classificação por dados, criticidade, público e autonomia do agente transforma "isso é arriscado" numa decisão objetiva: baixo risco segue livre, alto e crítico param na mesa certa antes de ir ao ar.

É esse tipo de estrutura, aplicada com método, que a Jetpacks instala dentro de grandes empresas como parceira oficial da Replit no Brasil — não uma trava genérica, uma régua que calibra a revisão pelo risco real de cada aplicação. Para mapear os casos de uso de vibe coding já em curso na sua empresa e classificar o risco de cada um, comece pelo diagnóstico gratuito, uma conversa de 30–45 minutos sem custo.