--- title: "Como colocar software feito com IA em produção | WIP" description: "Guia para quem criou um app com Claude Code, Codex, Cursor, Lovable ou Bolt: segredos, banco, backup, domínio, deploy, alertas e custos." url: https://workinprogress.company/pt/conteudo/colocar-software-feito-com-ia-em-producao updated: 2026-10-27 lang: pt-BR --- # Como colocar em produção, com segurança, um software feito com IA Por [Hermes Alves](https://workinprogress.company/pt/time/hermes-alves), consultor da WIP Atualizado em 27 de outubro de 2026 ![A janela de um aplicativo montada em blocos, com partes ainda tracejadas, ao lado de um checklist em andamento.](https://workinprogress.company/_astro/artigo-ia-producao.BmKfgOlB_ZoCc6x.png) ## Em resumo - Funcionar no seu computador não é o mesmo que estar pronto para produção: usuários reais exigem dados protegidos, backup, alertas e custo previsível. - Senhas e chaves de API ficam fora do código e do navegador. Chave que vazou precisa ser trocada e revogada, não só apagada. - Backup só conta depois de restaurado com sucesso em um teste, com o tempo de restauração medido. - Todo deploy precisa ser repetível e ter um caminho testado para voltar à versão anterior. - Monitoramento externo e alertas de orçamento avisam você antes do cliente e antes da fatura. Para colocar em produção um software feito com IA, trate-o como qualquer software que vai receber usuários reais: tire os segredos do código, proteja o banco de dados com backup testado, configure domínio, HTTPS e e-mail, automatize o deploy com caminho de volta, monitore o que importa e controle os custos. A ferramenta que gerou o código muda pouco essa lista; o que muda é quanto dela já foi feito. Este guia é para quem criou um produto com Claude Code, Codex, Cursor, Lovable, Bolt ou ferramentas parecidas e não tem formação em operação de sistemas. Cada seção diz o que fazer e como conferir. ## O que muda entre “funciona no meu computador” e produção? No seu computador, o software atende uma pessoa, com dados de teste, e se algo der errado você reinicia. Em produção, ele atende pessoas que você não conhece, a qualquer hora, com dados que não podem ser perdidos, e cada erro tem custo. Assistentes de IA constroem o que você pede. Se ninguém pediu backup testado, alerta de queda ou limite de gastos, essas partes provavelmente não existem. Três diferenças pesam mais: - **Dados reais:** a partir do primeiro cadastro, você responde pelos dados de outras pessoas, inclusive perante a LGPD. - **Disponibilidade:** quem usa espera que o sistema funcione, e você precisa saber quando ele não funciona. - **Custo:** cada serviço cobra pelo uso, e um erro pode virar fatura. ## Como cuidar de segredos e variáveis de ambiente? Mantenha os segredos fora do código, do repositório e do navegador. Segredos são senhas, chaves de API e tokens que dão acesso a serviços: banco de dados, pagamentos, e-mail, modelos de IA. - **Use variáveis de ambiente.** O código lê o valor do ambiente (por exemplo, `process.env.DATABASE_URL`), e o valor fica configurado no provedor de hospedagem ou em um cofre de segredos. No computador, use um arquivo `.env` listado no `.gitignore`. - **Separe chaves públicas de chaves privadas.** Algumas chaves são feitas para o navegador, como a chave publicável de um meio de pagamento. Chaves privadas, como a de acesso total ao banco, só podem existir no servidor. Se o navegador acessa o banco diretamente, confira se as regras de segurança por linha (row level security) estão ativas em todas as tabelas. - **Procure vazamentos.** Ferramentas como o gitleaks varrem o repositório inteiro, inclusive o histórico. Abra também o site com as ferramentas de desenvolvedor do navegador e procure chaves nos arquivos JavaScript. - **Troque o que vazou.** Apagar a chave do código não basta: ela continua no histórico e pode já ter sido copiada. Gere uma nova e revogue a antiga. ## Como proteger o banco de dados e testar o backup? Proteger o banco de dados exige três coisas: acesso restrito, backup automático e restauração testada. Ele guarda o que não pode ser refeito: cadastros, pedidos, conteúdo dos usuários. - **Acesso restrito:** o banco não deve aceitar conexões de qualquer lugar da internet, só da aplicação. - **Backup automático:** com frequência compatível com quanto de dados você aceita perder. - **Cópia fora do ambiente principal:** se o backup fica no mesmo servidor ou na mesma conta, um erro ou uma invasão leva os dois de uma vez. - **Arquivos enviados pelos usuários:** imagens e documentos geralmente ficam fora do banco e precisam de cópia própria. Depois, teste a restauração. Restaure o backup mais recente em um ambiente separado, abra a aplicação com os dados restaurados e anote quanto tempo levou. Backup que nunca foi restaurado é uma hipótese: o teste revela cópias incompletas, senhas perdidas e passos esquecidos antes da emergência. Repita o teste de tempos em tempos e sempre que a estrutura do banco mudar. ## Como configurar domínio, HTTPS e e-mail? Registre o domínio no seu nome, use HTTPS em tudo e autentique o e-mail. O domínio é o endereço do seu produto e, muitas vezes, do seu e-mail: perder o domínio derruba os dois. - **Registre no seu nome**, com renovação automática e um e-mail de contato que você lê. Ative a autenticação em dois fatores no registrador. - **Use HTTPS em tudo:** o certificado deve renovar sozinho, e todo acesso por `http://` deve redirecionar para `https://`. - **Autentique o e-mail:** configure SPF, DKIM e DMARC no DNS para cada serviço que envia e-mail pelo seu domínio. Sem eles, e-mails de cadastro e de recuperação de senha podem cair no spam, e fica mais fácil alguém se passar pela sua marca. ## Como tornar o deploy repetível e reversível? Deploy é o ato de publicar uma nova versão. Ele precisa ser repetível: feito sempre do mesmo jeito, por um processo automatizado e versionado, e não por comandos lembrados de cabeça. - **Automatize:** use um pipeline (por exemplo, no GitHub Actions) ou o deploy integrado do provedor, disparado a partir do repositório. - **Separe ambientes:** teste em um ambiente que não seja o de produção, com banco de dados e chaves próprios. - **Tenha um caminho de volta:** saiba voltar à versão anterior com um comando ou um clique, e teste isso antes de precisar. - **Cuide do banco:** mudanças na estrutura do banco são a parte difícil da reversão. Faça-as por migrações versionadas e, de preferência, compatíveis com a versão anterior do código. ## Que monitoramento e alertas são necessários? O mínimo é um monitor externo que acessa o site e a API periodicamente e manda alerta quando eles param de responder. Monitorar é saber que algo deu errado antes que o cliente avise. Depois, acrescente: - **rastreamento de erros**, que registra cada falha com contexto (página, versão e mensagem); - **logs guardados fora do servidor**, para investigar o que aconteceu ontem; - **alertas de vencimento** do certificado e do domínio. O alerta precisa chegar a uma pessoa, por um canal que ela vê. Alerta que cai em uma caixa de e-mail esquecida é igual a não ter alerta. ## Como manter os custos previsíveis? Três hábitos mantêm o custo previsível: alerta de orçamento, limites de uso e revisão mensal da conta. Em produção, cada serviço cobra pelo uso: hospedagem, banco de dados, armazenamento, e-mail e, em muitos produtos feitos com IA, chamadas a modelos de linguagem. - **alerta de orçamento** em cada provedor, abaixo do valor que doeria pagar; - **limites de uso** nas APIs mais caras, principalmente as de IA, e limite de requisições por usuário, para que um robô ou um erro em laço não gere uma fatura inesperada; - **revisão mensal** da conta, procurando recursos que ninguém usa. Escolha a infraestrutura pelo tamanho real do produto. Uma VPS simples pode bastar no começo; serviços gerenciados custam mais, mas exigem menos operação. A melhor opção depende do seu caso, não de uma regra geral. ## Quando pedir ajuda? Peça ajuda quando o que está em jogo for maior do que a sua capacidade de conferir sozinho. Alguns sinais: - você vai receber pagamentos ou dados sensíveis e não tem certeza de que as regras de acesso estão corretas; - há um lançamento ou uma campanha com data marcada; - você não sabe dizer onde está o backup nem quando ele foi restaurado pela última vez; - o sistema já caiu e você descobriu pelos usuários; - a conta da infraestrutura subiu e você não sabe por quê. Para conferir por conta própria, use o [checklist From Code to Production](https://workinprogress.company/pt/checklist), que traz cada item com o modo de verificar. Se preferir que alguém faça por você, o [WIP Launch](https://workinprogress.company/pt/servicos/colocar-software-em-producao) publica a aplicação com domínio, HTTPS, deploy automatizado, ambientes separados, configuração segura, backup testado e documentação. E se quiser primeiro saber o tamanho do problema, o [WIP Check](https://workinprogress.company/pt/servicos/diagnostico-tecnico) faz o diagnóstico técnico antes de qualquer mudança. ## Perguntas frequentes ### Software feito com IA é seguro para colocar em produção? Pode ser, desde que passe pelas mesmas verificações de qualquer software: segredos fora do código, regras de acesso aos dados, backup testado, deploy com caminho de volta e monitoramento. A ferramenta que gerou o código importa menos do que essas verificações. ### Onde devo guardar as chaves de API do meu aplicativo? Em variáveis de ambiente configuradas no provedor de hospedagem ou em um cofre de segredos, nunca no código, no repositório ou no navegador. No computador, use um arquivo .env que não vá para o repositório. Se uma chave vazou, gere uma nova e revogue a antiga. ### Como sei se o meu backup funciona? Restaurando. Restaure o backup mais recente em um ambiente separado, confira se a aplicação funciona com os dados restaurados e anote quanto tempo levou. Repita o teste periodicamente e sempre que a estrutura do banco de dados mudar. ### Preciso de um servidor caro para colocar meu app no ar? Não necessariamente. Uma VPS simples ou um plano básico de hospedagem pode bastar no começo. Mais importante que o tamanho do servidor é ter alerta de orçamento, limite de uso nas APIs mais caras e uma revisão mensal da conta. ## Quando chamar a WIP Colocar em produção ### [WIP Launch](https://workinprogress.company/pt/servicos/colocar-software-em-producao) O software funciona no seu computador, mas você não sabe como publicá-lo com segurança e sem sustos. a partir de R$ 2.500 Diagnóstico técnico ### [WIP Check](https://workinprogress.company/pt/servicos/diagnostico-tecnico) Você não sabe se o sistema está seguro, se o backup funciona nem por onde começar a melhorar. a partir de R$ 790 ## Comece pelo diagnóstico Antes de investir em mudanças, entenda os riscos, gargalos e desperdícios do seu sistema. O WIP Check entrega um relatório executivo e um plano de ação priorizado. [Solicitar diagnóstico técnico](https://workinprogress.company/pt/diagnostico)