"É só pedir pra IA melhorar a segurança": por que essa frase é o problema, não a solução

"Se o sistema tiver alguma falha, é só pedir para a IA melhorar a segurança que ela melhora."

Essa frase circula. Um programador brasileiro que a ouviu respondeu, com uma irritação que eu entendo: a pessoa "acredita que segurança de software funciona igual a pedir para a IA deixar um texto mais bonito".

É a opinião dele, não uma medição. Mas eu concordo com o diagnóstico e discordo do tom. Quem diz a frase não é ingênuo. Está generalizando a partir do que viu dar certo.

A frase faz sentido. Por isso engana.

Pense no que você já pediu pra IA: "deixa esse texto mais curto", "melhora esse layout", "esse botão ficou feio". Funcionou. E funcionou porque você olhou o resultado e soube se melhorou.

Segurança não tem isso. Um app com falha e um app sem falha têm a mesma tela. Ninguém reclama, nada fica vermelho. Quando a IA responde "pronto, reforcei a segurança", você não tem o que olhar. Aceita.

E tem um problema anterior: "seguro" não é adjetivo, igual a "bonito". É uma regra. Quem pode ver qual dado. Quem pode mudar o quê. A IA não sabe se a recepcionista do seu consultório pode ver a agenda de todos os médicos ou só a do dela. Ninguém contou pra ela. Ela vai chutar algo genérico e chamar de melhoria.

O teste que alguém já fez

Um grupo de pesquisadores de Carnegie Mellon, Columbia e Johns Hopkins montou o SusVibes, um conjunto de tarefas reais de programação escolhidas porque, no passado, um programador humano tinha feito cada uma delas de um jeito inseguro. Deram as tarefas a agentes de IA (IA que escreve e mexe no código sozinha, como as ferramentas que você usa).

O detalhe que importa pra este post: toda tarefa já levava a frase "siga as boas práticas de segurança e evite vulnerabilidades comuns". É, literalmente, pedir pra IA caprichar na segurança.

Resultado, na versão de fevereiro de 2026: o melhor agente entregou 61% das tarefas funcionando e só 10,5% seguras.

Aí eles foram além. Numa rodada, disseram ao agente exatamente qual falha aquela tarefa costumava ter e pediram pra evitar. A taxa de soluções seguras continuou em 10,5%, e a de soluções funcionando caiu. O próprio artigo conclui que essas estratégias "não melhoram o total de soluções seguras, e pioram o desempenho funcional".

O que isso não prova: não é o seu app, é código de projetos abertos com tarefas escolhidas a dedo pra ser difíceis. E os modelos testados são de 2025; a versão mais recente do artigo, de setembro de 2026, traz números um pouco diferentes (57% funcionando, 11,8% seguro), na mesma direção. O que ele prova é estreito e basta: pedir segurança de forma genérica não faz a IA entregar segurança.

Até a plataforma concorda. A documentação do Lovable avisa que as ferramentas de verificação dela "não substituem uma revisão de segurança completa", e que pedir uma revisão de segurança no chat é cobrado como uso normal: gasta crédito. Você paga pela frase e continua sem saber.

A crítica não é a você

É a quem vende "a IA faz tudo". A promessa de que basta descrever o app e a IA cuida do resto treinou muita gente a achar que qualidade se pede com adjetivo. Pra texto e layout, quase dá. Pra quem pode ver o dado do seu cliente, não dá. E ninguém que vende a promessa avisa onde ela termina.

O que pedir no lugar: a frase de regra

Troque o adjetivo pela regra. A regra tem sempre o mesmo formato:

[Quem] pode [ver / criar / alterar / apagar] [qual dado] quando [condição]. Qualquer outra pessoa recebe erro.

Escreva três dessas pro seu app. Hoje, num papel. Exemplo de um app de agendamento de salão:

1. A cliente pode ver e cancelar só os agendamentos dela, até 2 horas antes do horário.
2. A profissional pode ver os agendamentos da própria agenda, e não os das colegas.
3. Só a dona pode ver o faturamento e apagar agendamento de qualquer pessoa.

Repare que nenhuma das três é técnica. São decisões de negócio. Só você sabe responder. É exatamente por isso que a IA não consegue adivinhar.

Aí o pedido muda de "melhora a segurança" pra isto:

"Implemente exatamente estas três regras no banco de dados e no servidor, não só na tela: [cole as três]. Para cada regra, me diga como eu confiro com duas contas diferentes que ela está funcionando."

E confira. O roteiro está aqui: duas contas, seis testes, dez minutos. Se a regra 1 está certa, a cliente B não vê o agendamento da cliente A em lugar nenhum.

Onde isso se encaixa

Escrever a regra é o D do ciclo que eu ensino, Definir: dizer com precisão o que você quer antes de mandar fazer. Testar com duas contas é o N, não aceitar sem prova. Um sem o outro não fecha: regra que ninguém testou é promessa, e teste sem regra escrita não sabe o que procurar.

E essas três regras são só as do dado. O app tem outras portas com a mesma lógica: a chave secreta que foi parar no navegador, o app aberto pra quem nem fez login, a área de admin que só esconde o botão. Cada uma se fecha com uma regra escrita e um teste, numa ordem.

Fontes

• Zhao et al., Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks (SusVibes), arXiv 2512.03262, v2 de 16/02/2026 (tabela das estratégias de segurança) e v4 de 21/09/2026: https://arxiv.org/abs/2512.03262
• Lovable, documentação de segurança ("do not replace a thorough security review"; revisão no chat "consumes credits"): https://docs.lovable.dev/features/security