O protótipo rodou redondo na demo de quinta. Na madrugada de segunda, parou. Ninguém percebeu até quarta de manhã — quase 48 horas de erro 500 para cada cliente que tocava em uma fila de atendimento. O modelo estava intacto. O processo simplesmente morreu em algum pico de tráfego do início da semana, e não havia nada no sistema configurado para notar.

O abismo entre a demo e a produção

Esse abismo entre demo e produção é o problema real de quem leva IA para rodar em 2026. Demo tem alguém olhando. Produção, não. Produção roda semanas, meses, enquanto o time esquece dela — e quando alguém se lembra, é porque algo já caiu. A diferença quase nunca está no modelo. Está nas peças que mantêm o sistema vivo sem supervisão constante.

A primeira peça é o contêiner

A primeira peça é o contêiner. Docker é o nome que quase todo time encontra primeiro — e com razão. Empacota código, dependências e configuração numa unidade que sobe igual em qualquer máquina: laptop do dev, servidor do cliente, instância na nuvem. Mata uma classe inteira de incidente, aquele clássico "funcionava na minha máquina" que consome uma tarde inteira atrás de uma versão diferente do Python ou de uma variável de ambiente que ninguém documentou. O contêiner não impede o bug; impede que o bug dependa de qual máquina executa o código.

A segunda peça é o healthcheck com reinício automático

A segunda peça é o healthcheck com reinício automático. Um endpoint trivial — /health que devolve 200 enquanto o processo responde — e uma regra que reinicia o contêiner quando o endpoint para de responder. Parece simples. Cobre a maioria dos incidentes de madrugada: vazamento de memória que acumula até travar, conexão de banco que fica pendurada, fila que enche. O sistema percebe o problema e reinicia antes de qualquer humano acordar. Cobre o sintoma, não a causa — você vai investigar pela manhã por que houve dez reinícios entre 3h e 4h. Mas o cliente não viu sistema fora do ar.

A terceira peça é o agendador

A terceira peça é o agendador. Cron, systemd timer, ou um orquestrador como Kubernetes — qualquer coisa que dispare o processo no horário certo sem alguém apertar um botão. Para um chatbot que fica 24/7 é o orquestrador que o segura. Para um job de extração de dados às 3h da manhã é o cron que acorda. O ponto comum: dispara sozinho, no horário combinado, mesmo no feriado em que o time está todo fora.

As três peças juntas não têm mágica. Resolvem quase tudo que separa um protótipo de um sistema em produção — e nada disso custa proporcionalmente ao preço do modelo de IA. Configurar contêiner, healthcheck e agendador em um projeto novo é uma tarde. Engenharia barata que paga muito caro toda semana que existe — e é exatamente o tipo de peça que a procrastinação manda adiar.

O custo de deixar para depois

"Depois eu coloco" aparece em quase todo projeto de IA que quebra em produção. Depois da demo aprovada, depois do MVP, depois do próximo cliente. O problema é que cada incidente noturno — aquele em que alguém acorda a 3h por WhatsApp do cliente — consome mais horas da equipe do que teria levado configurar as três peças no primeiro dia. Multiplique por incidentes ao longo de seis meses e o custo acumulado é maior que qualquer rodada de otimização de prompt que o time vá fazer.

Engenharia paga uma vez. Operação paga toda semana. Antes de discutir qual modelo usar no próximo projeto, faz sentido perguntar: se ninguém olhar para esse sistema por trinta dias, ele continua rodando?