O checklist de auditoria antes de publicar um app feito com IA

Um app montado com Lovable, Cursor ou n8n costuma chegar rápido a um estado que parece pronto: login funciona, o fluxo principal roda do início ao fim, o time já mostrou para o primeiro cliente e ouviu elogio. Esse estado engana. Funcionar e estar pronto para publicar são dois testes diferentes, e o segundo raramente acontece sozinho, porque construir e auditar exigem atenção em direções opostas: quem constrói foca em fazer o caminho feliz funcionar; auditoria foca em como cada peça falha quando alguém faz algo que não estava no roteiro.

O que muda quando entra cliente de verdade

Na demonstração, um único usuário faz um único caminho, geralmente o mesmo que já foi testado dez vezes. Em produção, dezenas de contas diferentes acessam o sistema ao mesmo tempo, cada uma com dado que não pode vazar para a outra, e alguém, cedo ou tarde, vai tentar um caminho que ninguém previu, de propósito ou não. O código que a IA escreveu pode estar correto para o roteiro testado e ainda assim não ter nenhuma dessas camadas, porque elas raramente aparecem no prompt que pediu a funcionalidade. Isso não é falha da ferramenta de IA, é o tipo de coisa que exige revisão deliberada, feita por alguém procurando especificamente por isso.

O checklist antes de publicar

Nenhum item aqui exige reescrever o projeto do zero. Cada um responde a uma pergunta específica, e vale passar pelos oito antes de colocar o primeiro cliente real dentro do sistema.

1. Quem entra, e com qual permissão

Login funcionar não é o mesmo que controle de acesso funcionar. Vale testar na mão se uma conta comum consegue chegar numa tela ou numa rota pensada só para administrador, digitando o endereço direto em vez de clicar num botão. Se conseguir, o problema não é o botão que sumiu da interface, é a rota que segue aberta por trás dele.

2. Segredos e chaves de API fora do código

Chave de API, senha de banco de dado e token de integração não podem estar escritos direto no código nem, pior, num commit antigo do histórico do repositório. O lugar certo é variável de ambiente, fora do controle de versão. Quando esse tipo de segredo fica exposto, alguém que nunca deveria ter acesso ao sistema pode acabar com a chave que abre a porta inteira dele.

3. Isolamento de dado entre contas e usuários

Cada usuário só pode enxergar e alterar o que é dele. Parece óbvio, mas é o tipo de regra que precisa estar garantida no banco de dado, não só escondida na interface: trocar um número na URL não pode abrir o cadastro do cliente vizinho. Num app que guarda dado de paciente, de segurado ou de comprador de imóvel, essa é a checagem que decide se um vazamento vira incidente isolado ou vira caso de LGPD.

4. Tratamento de dado pessoal, mapeado de verdade

Vale listar, sem pressa, todo dado pessoal que o app coleta, onde ele fica guardado, quem no time consegue acessar e por quanto tempo ele é mantido depois que deixa de ser necessário. Se essa lista não existe, a empresa não tem como responder com segurança quando um cliente pedir para saber o que foi coletado sobre ele, e é exatamente esse pedido que a LGPD garante.

5. Superfície de entrada que não é confiável

Todo campo que um usuário preenche é uma porta de entrada que precisa validar o que chega, não só o que era esperado chegar. Se o app usa algum agente de IA lendo mensagem de cliente ou documento anexado, essa porta ganha um risco a mais: alguém pode escrever um texto pensado para fazer o agente ignorar a instrução original, o chamado prompt injection. Revisar essa superfície é checar se o agente tem escopo fixo, ou se ele obedece a qualquer coisa que chega no texto.

6. Dependências de terceiro, sem ficar para trás

Boa parte de um app feito com IA usa dezenas de bibliotecas de código aberto por baixo. Cada uma delas pode ter uma falha de segurança conhecida e publicada, e o app continua exposto a ela enquanto ninguém atualizar a versão. Isso não exige acompanhar notícia de segurança todo dia, exige rodar, antes de publicar, a checagem automática que já vem com o gerenciador de pacote.

7. Um caminho de volta quando algo quebra

Backup do banco de dado, com teste real de restauração, e um jeito de reverter um deploy que saiu errado, sem depender de reescrever tudo na hora, sob pressão, com cliente reclamando. A pergunta que decide se isso está pronto não é "o app funciona", é "o que a gente faz quando ele parar de funcionar às três da tarde de uma sexta".

8. Ambiente de teste separado do ambiente de produção

Mudança nova entra primeiro num ambiente separado, com dado de teste, nunca direto na base que o cliente já usa. Sem essa separação, cada ajuste vira um experimento feito com dado real de gente real, e o primeiro sinal de que algo deu errado é o próprio cliente encontrando o erro.

Por que esse checklist não aparece sozinho

A velocidade de construir com IA é real, e não é o problema. O problema é que essa velocidade não vem com nenhuma dessas oito camadas por padrão, porque nenhuma delas costuma estar no prompt que pediu a funcionalidade. É essa a diferença entre protótipo e produção: protótipo pode nascer solto, produção exige uma estrutura mínima em volta do que foi construído, regra que a IA segue, teste automatizado, esteira de deploy e proteção que barra o erro antes de ele chegar no cliente. Esse conjunto tem nome, harness, e é o que sustenta a velocidade depois da primeira semana, em vez de deixar o débito se acumular no escuro até travar o time.

Se a sua empresa já construiu algo com Lovable, Cursor, n8n ou outra ferramenta de IA e está perto de colocar o primeiro cliente de verdade dentro, o diagnóstico gratuito do Construa com IA em /construa-com-ia dura 45 minutos com um engenheiro e devolve o mapa de risco do que já existe, feche ou não com a gente depois.