Diário de um Portfólio de Robôs (9): No Ar em Simulado, e Por Que a Validação Operacional é Metade do Trabalho

Atualizado em 21/08/2026

O capítulo anterior entregou o portfólio honesto de 34 robôs, depois da auditoria que cortou de 60. Este é sobre pôr ele no ar. E sobre uma verdade que todo mundo que pesquisa estratégia esquece: o backtest mais robusto do mundo não vale absolutamente nada parado no disco. Ele precisa virar ordem.

Construir é metade, subir é a outra metade

Eu passei meses na pesquisa e nas auditorias com a sensação de que o deploy seria um detalhe, o último passo fácil depois do trabalho duro. Foi o oposto. Levar 34 robôs de uma planilha para uma conta operando exigiu tanto esforço quanto descobrir quais robôs entrar, com a diferença de que esse esforço é invisível, porque ele não vira gráfico nem estatística citável em lugar nenhum. E é exatamente aí que a maioria dos projetos morre, com a estratégia pronta e nunca operando.

E o pior é o tipo de problema que aparece na última milha. Ele é um problema silencioso, do tipo que falha sem registrar erro nenhum no log, e que te faz perder horas achando que está tudo certo quando não está.

Os três nós que sumiam sem dar erro

Foram três nós, e os três tinham a mesma maldade: falhavam em silêncio.

O primeiro era o formato do arquivo de perfil da plataforma, o que diz quais robôs anexar a quais gráficos, e eu montava o bloco de configuração de um jeito que parecia certo, mas a plataforma abria o gráfico e simplesmente ignorava o robô, sem registrar nenhum erro. O gráfico subia vazio. Nada avisava. Resolvi pelo único caminho que funciona com formato proprietário sem documentação: fiz a própria plataforma gerar um exemplo correto. Anexei um robô na mão pela interface, salvei e reli o arquivo que ela mesma gravou, para descobrir a estrutura exata. Com o formato certo copiado do exemplo real, os 34 subiram de primeira.

O segundo nó era uma lenda que eu mesmo tinha escrito. O runbook dizia que o robô “saía sozinho depois de uns 32 segundos”, e eu perdi horas caçando a causa desse sumiço. Ela não existia. O próprio processo que eu usava para ler o log fechava a plataforma para inspecioná-la, e o robô saía junto, então o sintoma que eu estava investigando era o meu próprio comando de leitura. Eu tinha inventado o defeito e depois fui caçá-lo.

O terceiro: 6 dos 22 robôs de tendência falhavam ao iniciar, de forma determinística. Sempre os mesmos 6. A causa era um arquivo de apoio que faltava, necessário para um tipo específico de indicador, e assim que instalei esse arquivo os 6 voltaram e os 34 passaram a subir limpos.

A lição transferível é essa. A última milha do deploy, o formato de arquivo proprietário, a ordem de inicialização, um arquivo de apoio faltando, engole tanto tempo quanto a pesquisa, e some sem dar erro. Contra formato proprietário sem documentação, o caminho é fazer a própria ferramenta gerar um exemplo correto e copiar dele. Eu já sabia disso de engenharia. É o tipo de coisa que a gente esquece quando está empolgado com a estratégia.

Quando os três nós caíram, veio o momento que valeu a maratona toda: na primeira hora de operação, os 34 robôs estavam carregados, sem nenhuma falha registrada, com 21 deles já segurando posição e nenhum identificador repetido entre os gráficos. Pela primeira vez, a metodologia inteira, dos primeiros testes até aqui, virou ordem executada num book de verdade.

O disjuntor ao vivo: a troca automática

Subir os robôs era só parte do deploy. A peça que eu mais fazia questão de ter pronta era o disjuntor operando ao vivo, aquele do capítulo quatro, com a mesma regra de lá: quando um robô fura o teto de drawdown que ele herdou do Monte Carlo, ele sai da conta. Construí o atuador que faz isso sozinho. Ele monitora cada robô, detecta quando um estoura o teto, fecha as posições daquele robô e regenera o perfil sem ele, deixando o lugar pronto para entrar um substituto. É a fábrica de descartáveis do capítulo quatro virando engrenagem que executa.

Por que ainda é simulado

Um ponto que eu faço questão de deixar claro: isto está em conta simulada, demo, e não em dinheiro real. É de propósito. O deploy em simulado é o passo de validação operacional, onde eu vejo a metodologia inteira virar ordem executada num book, com o disjuntor e a troca funcionando, sem arriscar capital. O cálculo já fechou no papel. Falta ver o sistema executar.

Código e pesquisa acabaram. O que falta agora é tempo de mercado. Preciso ver os 34 operarem por semanas, ver o disjuntor disparar de verdade numa troca real, e acompanhar o drawdown em aberto, aquele do capítulo seis, num gráfico ao vivo. Só depois disso a conversa sobre dinheiro real faz sentido. Pular essa etapa seria desfazer toda a disciplina dos capítulos anteriores no último metro.

A série não acaba aqui

Aqui termina o arco que eu podia contar olhando para trás, do primeiro teste até o portfólio no ar, e é só isso que termina, porque a história em si não acabou e esta série não tem final fechado. O portfólio está rodando agora, em simulado, e daqui para frente eu vou postar o que ele for de fato fazendo.

Vem por aí o mês de simulação e o que ele me ensinar, o veredito honesto desse mês, a decisão de levar ou não para o dinheiro real, e, se levar, o acompanhamento ao vivo com os números reais. Não prometo final feliz, porque o projeto inteiro foi sobre não se enganar. Prometo continuar contando a verdade, ganhando ou perdendo, do mesmo jeito que contei até aqui. Se você acompanhou os nove capítulos, fica de olho. A parte mais interessante, o encontro da metodologia com o mercado de verdade, começa agora.

Acompanhe a série para não perder os próximos. O diário continua.

Perguntas frequentes

Por que o deploy é tão difícil quanto a pesquisa?

Porque a última milha, levar a estratégia pronta para uma conta operando, esbarra em formato de arquivo proprietário, ordem de inicialização e dependências que falham em silêncio, sem dar erro. Esses problemas não viram gráfico nem estatística, mas consomem tanto tempo quanto descobrir a estratégia, e é onde a maioria dos projetos morre, com a pesquisa pronta e nada operando.

Como resolver um formato de arquivo proprietário sem documentação?

Fazendo a própria ferramenta gerar um exemplo correto. No meu caso, anexei um robô pela interface, salvei e reli o arquivo que a plataforma mesma gravou, para descobrir a estrutura exata, porque copiar de um exemplo real que a própria ferramenta produziu é bem mais rápido e seguro do que tentar reconstruir o formato adivinhando campo por campo.

Por que rodar em simulado antes do dinheiro real?

Porque o simulado é a validação operacional: ver a metodologia inteira virar ordem executada, com o disjuntor e a troca de robôs funcionando, sem arriscar capital. É o passo entre saber que o cálculo fecha e ver o sistema operar de verdade. Só depois de semanas de tempo de mercado a decisão sobre dinheiro real faz sentido.

A série termina no deploy?

Não. Os nove capítulos contam a história do primeiro teste até o portfólio no ar, mas o projeto está em andamento. Daqui para frente o diário continua com o mês de simulação, o veredito desse mês, a decisão sobre dinheiro real e, se for o caso, o acompanhamento ao vivo com os números reais.

Referências

• Perold, A. F. (1988). The Implementation Shortfall: Paper Versus Reality. Journal of Portfolio Management, 14(3), 4-9. A distância entre a estratégia no papel e a sua execução real.
• López de Prado, M. (2018). Advances in Financial Machine Learning. Wiley. Sobre a lacuna entre o backtest e a produção, e por que a maior parte do risco mora na implementação.