O ritmo operacional de 45 dias para times potencializados por IA
A regra de cadência que mata os dois modos de falha da adoção de IA — avaliação infinita e compromisso congelado — e transforma ferramentas dispersas em infraestrutura que compõe.
Dois modos de falha destroem a adoção de IA em negócios estabelecidos. Os dois parecem progresso enquanto acontecem. Os dois te deixam 18 meses atrás quando você percebe.
Modo de falha um: avaliação infinita. Todo trimestre o time escolhe um novo fornecedor, roda um piloto, gera um memo, decide não comprometer, recomeça. Depois de dois anos avaliaram 18 coisas e enviaram duas para produção — nenhuma das quais compõe porque nada foi integrado num sistema de verdade. Só uma série de testes pontuais que produziu opiniões.
Modo de falha dois: compromisso congelado. O time escolhe um fornecedor cedo, embute fundo, e se recusa a revisitar porque o custo de troca parece enorme. Depois de dois anos estão trancados num stack que os concorrentes passaram no mês nove. O custo de migração agora é cinco vezes o que teria sido se eles tivessem mantido a arquitetura vendor-agnostic.
Os dois modos compartilham uma causa raiz: nenhuma cadência de decisão. A correção é o ritmo operacional de 45 dias.
A regra
A cada 45 dias, seu time sênior se compromete com uma das três ações para cada capacidade de IA na qual está investido:
Ship (Enviar)
O piloto vira produção com arquitetura, dono e SLA documentados. Acabou o "estamos testando." Ou roda o negócio ou não.
Enviar força clareza. No momento em que você tem que escrever quem é dono, qual o modo de falha, e como é a latência de p99, descobre se entende a capacidade de verdade ou se vinha admirando de longe.
Cut (Cortar)
A capacidade é removida do stack com motivo escrito. Ferramentas que não graduaram depois de dois ciclos são cortadas, ponto.
Soa duro. É o oposto. É a única forma de parar de acumular ferramentas que ninguém possui. Toda capacidade não-cortada é um custo de migração futuro quando você consolidar. O viés tem que ser para a subtração.
Escreva o motivo. "Achávamos que X faria Y, eis o que de fato fez, eis por que estamos cortando." Esse documento vale mais do que a ferramenta — ele faz a próxima decisão acontecer mais rápido.
Compound (Compor)
Uma capacidade já em produção recebe um upgrade deliberado — um novo modelo, uma integração mais profunda, uma melhoria estrutural no runtime. Composição não acontece por negligência. Acontece porque alguém é responsável por mover o sistema para frente todo ciclo.
Esse é o passo que a maioria dos operadores pula. Enviam algo, funciona, seguem adiante. Seis meses depois, foi silenciosamente ultrapassado por todo análogo na fronteira. A ação compound mantém seus sistemas internos na curva ou à frente dela.
Por quê 45 dias
Tempo suficiente para avaliar algo contra workflows reais. Curto o bastante para a avaliação não virar estado permanente. Oito ciclos por ano. A cadência força decisões enquanto as variáveis ainda estão frescas.
Trimestral é lento demais — releases de modelo acontecem entre revisões trimestrais. Você estaria tomando decisões com informação velha. Mensal é rápido demais — você cicla avaliações sem dar espaço para nada se provar.
45 dias acerta o intervalo certo para o ritmo atual de melhoria dos modelos de fronteira. Revisaríamos se esse ritmo mudasse materialmente. Não mudou, três anos seguidos.
Quem é o dono
Uma pessoa. Não um comitê.
O dono é quem roda a infraestrutura de IA dentro da org — geralmente um operador técnico sênior, não o CTO, não o head de inovação. Roda a cadência, redige os memos ship/cut/compound, apresenta três decisões por ciclo para o time sênior.
Se você não tem alguém que pode ser dono disso hoje, a primeira decisão "ship" do ciclo um é contratar ou alocar essa pessoa. O papel não é opcional. Sem dono, o ritmo morre na semana dois.
A gente assume esse papel para clientes durante buildouts iniciais — operando a cadência por dois ou três ciclos enquanto a empresa contrata ou treina o dono interno. O handoff é o entregável.
O resultado compounding
Doze meses sob essa regra e o operador típico:
- Enviou 3–4 capacidades centrais com arquitetura e dono reais
- Cortou 6–7 que não justificaram seu espaço
- Compôs 1–2 em infraestrutura que concorrentes não conseguem replicar comprando
Doze meses sem ela, o mesmo operador tem 14 relações de fornecedor ativas, ninguém no time sênior consegue mapear a arquitetura, e o custo de migração quando (não se) algo quebra triplicou. Mesmo ano. Mesmo orçamento. Resultado diferente.
A cadência é o sistema. As capacidades são o output.
Como isso se parece na prática
A gente roda esse ritmo dentro de engajamentos com clientes como parte da camada operacional que constrói. Não é deck. São três documentos por ciclo — um inventário, um memo de decisão por capacidade em revisão, um comprovante de execução dos compromissos do ciclo anterior. O formato é o mesmo em todo engajamento; o que muda é quais capacidades estão em cada lista.
O primeiro ciclo é o mais difícil. O primeiro ship parece rápido demais (não é — está atrasado). O primeiro cut parece caro (não é — a ferramenta já estava custando). O primeiro compound parece indulgência (não é — é como juros compostos antes de compor).
No ciclo três, o time está rodando sozinho e você está gastando os 90 minutos mais ouvindo as decisões serem tomadas do que conduzindo elas. Esse é o objetivo.
Como começar o ciclo um
Se você leu isso e reconheceu o modo de falha em que está:
- Hoje: liste toda ferramenta de IA, fornecedor, agente e automação no negócio. Uma linha por item. Sem editorializar. Só conte.
- Esta semana: identifique o dono. Se ainda não existe, esse é o primeiro ship.
- 45 dias a partir de hoje: primeira revisão. 90 minutos. Uma decisão por capacidade. Três documentos.
Se o inventário sozinho expor demais (o primeiro inventário de todo mundo expõe), é o diagnóstico funcionando. O trabalho do ciclo um é cortar, não enviar. A maioria dos times descobre que precisa de menos ferramentas no mês três do que começou — e as que sobram fazem trabalho de verdade.
Esse é o sistema operacional que instalamos para clientes junto com a infraestrutura. Infraestrutura sem o ritmo decai. Ritmo sem a infraestrutura não tem o que operar. Os dois juntos compõem.
Perguntas frequentes
Por que exatamente 45 dias?
Tempo suficiente para avaliar uma capacidade contra workflows reais (a maioria dos pilotos precisa de ~30 dias de uso para ser honesta sobre qualidade). Curto o bastante para nenhuma avaliação virar estado permanente sem compromisso. Oito ciclos por ano, rápido o suficiente para acompanhar o ritmo de release dos modelos de fronteira. Trimestral é lento demais — releases de modelo acontecem entre as revisões trimestrais. Mensal é rápido demais — você ciclaria avaliações sem dar espaço para nenhuma se provar.
O que "compor" significa aqui?
Uma capacidade já em produção recebe um upgrade deliberado no ciclo — um modelo mais novo, uma integração mais profunda, uma melhoria arquitetural no runtime. Compor não é "deixar rodando sem mexer." É que, a *cada* ciclo de 45 dias, o sistema fica significativamente melhor no mesmo trabalho. É assim que um sistema de 6 meses fica 10× mais útil que um novo.
Quem é o dono do ritmo de 45 dias?
Uma pessoa. Não um comitê. Geralmente um operador técnico sênior que roda a infraestrutura de IA — não o CTO, não o head de inovação. Eles redigem os memos ship/cut/compound, apresentam três decisões por ciclo, e são donos das chamadas de corte. Se essa função não existe na sua org, a primeira decisão "ship" do ciclo um é contratar ou alocar essa pessoa.
E se uma capacidade estiver em zona cinza no momento da decisão?
Trate zona cinza como "cut." O viés tem que ser para a subtração. O custo de mais uma ferramenta que ninguém possui é invisível até você tentar consolidar; o custo de cortar cedo demais é visível imediatamente (sempre dá para readotar). Rode o ciclo por um ano e vai ver: nada que você "cortou cedo demais" realmente importou. Muita coisa que ficou "por garantia" virou peso morto.