Checklist para publicar um app feito com IA: o que conferir antes de divulgar

O checklist para publicar um app feito com IA começa quando a tela parece pronta, mas você ainda precisa saber quem abre cada porta. É como receber a chave de uma loja reformada: a vitrine pode estar impecável enquanto o depósito continua acessível pela rua. Antes de divulgar o endereço, alguém precisa conferir os acessos, os serviços ligados e o que acontece quando algo falha.

Este roteiro atende quem criou uma calculadora, formulário ou pequena ferramenta para marketing. Ele organiza a conversa com quem cuida da implementação e registra evidências para decidir a publicação. É uma proposta operacional do Club Martech, sem certificação de segurança ou substituição de revisão técnica.

A edição da Growth Insight sobre segurança para quem publica com IA, escrita pelo convidado Eduardo Belotti, motivou a pauta. Aqui, o foco é a conferência de uma aplicação específica. A decisão sobre o que diferencia experimento e operação contínua está no artigo Protótipo vs Produto.

Comece pela função e pelo caminho dos dados

Escreva o que a ferramenta faz em uma frase verificável: recebe valores digitados e calcula um resultado, por exemplo. Depois desenhe o caminho da informação. Ela fica no navegador? Vai para um servidor? É enviada a um modelo? Entra no CRM? Uma interface simples pode esconder várias integrações, cada uma com acesso e responsável próprios.

Faça esse mapa com dados fictícios. Registre serviços, contas administrativas, responsável pela hospedagem e dependências externas. Não coloque senhas no documento. O objetivo é permitir que outra pessoa localize os sistemas sem receber um arquivo cheio de credenciais.

Considere duas calculadoras hipotéticas. A primeira faz uma conta no navegador e não envia o resultado a outro serviço. A segunda pede e-mail, consulta uma API paga e grava o contato no CRM. A segunda exige conferir coleta, acesso, integração e custo, além da fórmula. Copiar a aprovação da primeira para ela ignora justamente o que mudou.

Use o mapa para responder: “Que informação sai desta página, para onde vai e quem pode acessá-la depois?” Quando a resposta depende apenas de uma afirmação do gerador de código, peça demonstração e revisão. A governança de IA ajuda a definir quais dados e ações a empresa permite.

Confira acesso e segredos antes de usar dados reais

Login e autorização resolvem perguntas diferentes. O primeiro identifica quem entra; a segunda determina o que essa pessoa pode fazer. Uma conta comum conseguir abrir dados de outra conta é uma falha mesmo que a tela de login funcione. Peça ao responsável técnico testes com usuários e permissões diferentes.

A orientação de autorização da OWASP recomenda privilégio mínimo, negação por padrão e verificação das permissões a cada requisição. É referência de implementação, não prova de que sua aplicação cumpre esses controles. A evidência precisa vir dos testes no sistema que será publicado.

Confira também como a aplicação usa chaves de API. Pergunte se alguma credencial está exposta nos arquivos entregues ao navegador, no repositório ou nos registros de erro. A referência de gestão de segredos da OWASP trata de armazenamento, acesso e ciclo de vida dessas credenciais.

Uma captura com a chave escondida não basta. O responsável precisa demonstrar onde ela é armazenada, quem pode utilizá-la e como revogá-la. Se houve exposição, peça uma avaliação do incidente e da substituição da credencial. Não adianta apagar a chave de um arquivo e presumir que nenhuma cópia continua utilizável.

Teste entrada, resultado e falha de integração

Uma calculadora precisa acertar as contas nos limites do domínio previsto. Defina com alguém que conhece a regra exemplos de resultado esperado, arredondamento e entradas inválidas. Campo vazio, valor negativo e separador decimal merecem uma resposta combinada quando forem possíveis na tarefa.

Para um formulário, acompanhe o envio até o destino. Confirme que o contato chega uma vez, com os campos necessários e a origem correta. Uma mensagem de sucesso na página não comprova gravação no CRM. A revisão de Vibe Coding em MarTech precisa incluir essa passagem, além da aparência da tela.

Teste o que acontece quando a integração fica indisponível, usando ambiente controlado. A pessoa recebe uma informação compreensível? O sistema evita perder ou repetir a ação? Quem fica sabendo do erro? Se houver tentativa automática, peça ao técnico que confira o tratamento de duplicidade e de limites do serviço.

Inclua uso no celular e com teclado, rótulos de campos e entendimento do erro. O visitante precisa conseguir corrigir uma entrada sem adivinhar a regra. Registre o comportamento observado, o caso usado e a versão testada. Esse material permite repetir a conferência depois de uma mudança, em vez de depender da memória de quem criou a ferramenta.

Inclua uma conferência das mensagens apresentadas. Uma falha pode expor detalhes internos do serviço ou instruir o visitante a repetir um envio já recebido. Peça ao técnico que diferencie a informação útil ao usuário do registro necessário à investigação. A equipe de atendimento precisa saber como reconhecer o caso e evitar uma segunda ação por engano.

Guarde os exemplos aprovados junto à versão da ferramenta. Quando o formulário ou a integração mudar, eles permitem conferir se o comportamento anterior foi preservado. O registro deve conter dados fictícios ou autorizados, com acesso restrito quando necessário. Um histórico cheio de informações pessoais cria outro problema de operação em vez de apenas documentar a qualidade.

Também avalie se a ferramenta continua compreensível quando o serviço externo demora. A pessoa deve saber se a solicitação está sendo processada, se foi recebida e o que pode fazer em seguida. O tempo aceitável depende da função. Combine uma resposta para demora e teste esse caminho antes de anunciar a ferramenta numa campanha.

Use uma matriz de liberação com evidência e responsável

A matriz abaixo é um ponto de partida. Cada equipe precisa acrescentar os riscos da sua aplicação. O campo decisivo é a evidência observável: teste, registro de execução ou demonstração técnica adequada. Marcar uma caixa porque a IA respondeu que está correto deixa o problema sem conferência.

Defina quem fornece a evidência e quem decide a liberação. Em uma equipe pequena, a mesma pessoa pode executar várias verificações, mas uma aplicação com dados ou consequências relevantes pede o olhar adequado ao risco. Caso um item não se aplique, registre por quê. Uma calculadora sem armazenamento não precisa fingir ter o mesmo fluxo de recuperação de um banco de contatos.

Use estados simples: confirmado, pendente e não aplicável com justificativa. Evite porcentagem de prontidão que esconda um bloqueio grave. Nove itens aprovados não compensam uma credencial exposta. A pergunta para a reunião é: “Qual pendência ainda pode causar um efeito que a gente não consegue controlar?”

Combine monitoramento, custo e recuperação

Depois da publicação, alguém precisa perceber quando a ferramenta deixa de cumprir sua função. Escolha sinais concretos: envio não recebido, aumento inesperado de uso da API ou resultado inválido. Defina o canal do alerta e teste se a pessoa responsável o recebe. Configuração salva e alerta entregue são evidências diferentes.

Considere o custo de uso indevido e de repetição. Se a aplicação chama um serviço pago, confira com o técnico quais mecanismos limitam solicitações e como o orçamento é acompanhado. Um alerta pode avisar sem interromper o gasto; pergunte o que acontece depois que ele dispara. Os limites devem refletir a tarefa e as condições do fornecedor.

Documente o rollback adequado. Restaurar uma página e restaurar dados são ações diferentes. Teste a recuperação antes de depender dela e registre quem pode autorizar uma interrupção. A página de segurança de aplicações web aprofunda a organização técnica desse trabalho.

Inclua prazo de revisão das dependências e um responsável quando o criador não estiver disponível. O custo de manter precisa entrar na escolha de continuar. Uma ferramenta usada raramente pode exigir uma alternativa mais simples; uma aplicação essencial precisa de continuidade compatível com sua função.

Na liberação, guarde a versão aprovada, a data da decisão e a lista de pendências aceitas pelo responsável. Esse registro permite investigar uma alteração posterior sem atribuir a aprovação antiga a um sistema que já mudou.

Próximos passos para publicar um app com evidência

Escolha uma ferramenta que esteja prestes a divulgar. Preencha sua função, mapa de dados e matriz de liberação. Marque como pendente tudo o que você ainda não consegue demonstrar e leve essas perguntas ao responsável técnico. Isso produz uma conversa específica, em vez de um pedido genérico para verificar se está seguro.

Faça um ensaio completo no ambiente de teste, da entrada ao resultado e à falha. Depois confira se a versão que será publicada corresponde à revisada. Qualquer alteração posterior que mude dados, acesso ou integração precisa voltar às verificações afetadas. A aprovação não acompanha automaticamente uma implementação diferente.

Registre a decisão e as condições de acompanhamento. Se a liberação for limitada a um experimento, combine público, duração, informação permitida e data de desligamento. Se for operação contínua, confirme manutenção e recuperação. O checklist ajuda a tornar essas condições visíveis; a decisão continua com as pessoas responsáveis pela ferramenta e por suas consequências.

Comece hoje pela primeira pergunta: quem consegue mostrar, no sistema, que o resultado anunciado realmente acontece? Se ninguém souber, essa demonstração é a próxima tarefa antes de divulgar o link.