O líder que sai para continuar mandando: lições para engenheiros de software sobre controle residual em sistemas de IA

No último congresso do Livre, partido político português, Rui Tavares fez algo que poucos líderes fazem: saiu da liderança formal, mas deixou claro que o controlo total permanecia em suas mãos. A jogada é digna de um tratado de estratégia — e, para quem trabalha com engenharia de software e inteligência artificial, ecoa um padrão conhecido: como garantir que um sistema continue a operar segundo a intenção original mesmo depois que o "líder" (seja um desenvolvedor, um modelo ou um serviço central) é removido da linha de frente.

O que parece uma manobra política é, na verdade, um problema técnico profundo: o que chamamos de controle residual — a capacidade de manter influência, direção e coerência em um ecossistema distribuído sem depender de um ponto único de autoridade. Em sistemas de IA, microserviços e produtos digitais, esse desafio surge toda vez que um arquiteto sênior muda de projeto, um modelo base é descontinuado ou um serviço de orquestração é substituído. A fonte, do programa E o Vencedor é, da Rádio Observador, narra a jogada de Tavares com detalhes que poderiam descrever uma arquitetura de governança — e é por aí que vamos navegar.

O padrão "sair para continuar" na engenharia de software

Em times de produto, é comum vermos um tech lead ou product owner que, ao mudar de área, tenta manter o veto moral sobre decisões arquiteturais. A abordagem, quando não estruturada, gera atritos e retrabalho. Mas quando bem executada, lembra o padrão Mediator de GoF: uma entidade central que coordena interações, mas que pode ser substituída sem quebrar o fluxo, desde que o contrato de comunicação seja mantido. A diferença é que o mediador, ao sair, deixa um log de decisões — os ADRs (Architecture Decision Records) — que funciona como a "vontade" do líder perpetuada.

No caso de Rui Tavares, a saída da liderança formal foi acompanhada por uma estrutura de influência que não dependia do cargo. Em engenharia, o equivalente é Infrastructure as Code (IaC): quando um engenheiro deixa a empresa, a configuração da nuvem, os pipelines de CI/CD e os runbooks permanecem. Se o código está versionado e documentado, a "intenção" do líder técnico continua a ser executada pelos agentes automatizados. O problema é quando essa intenção não é explícita — e aí o líder continua "mandando" de forma opaca, gerando débito técnico e dependência invisível.

Controle residual em sistemas de IA: fine-tuning e modelos base

Na inteligência artificial aplicada, o fenômeno é ainda mais sutil. Um modelo de linguagem de grande porte, como o GPT-4 ou o Llama 3, é treinado por uma equipe e depois disponibilizado como base. Quem faz o fine-tuning para uma tarefa específica muitas vezes não é o mesmo time que treinou o modelo original. A pergunta que surge é: quanto do controle original permanece? A resposta está nos pesos congelados e na arquitetura de adaptadores (LoRA, por exemplo).

Quando um líder político sai mas mantém o controle, ele usa canais informais, alianças e um discurso que define o "norte". Em IA, o "norte" é o loss function e os dados de pré-treinamento. Mesmo que o modelo seja submetido a fine-tuning com novos dados, se a base não for reavaliada, o viés e as restrições originais persistem. É como se o líder original continuasse a "mandar" através dos pesos congelados. Isso pode ser desejável — estabilidade — ou perigoso — propagação de vieses não explicitados.

Em um projeto recente, precisei adaptar um modelo de recomendação treinado em dados de um cliente antigo para um novo domínio. O fine-tuning superficial funcionou, mas o modelo continuava a favorecer padrões do domínio original. A solução foi revisitar a arquitetura de transferência de aprendizado, adicionando camadas de adaptação específicas e, principalmente, documentando as decisões de trade-off como se fossem ADRs. Sem isso, o "controle residual" do modelo original estava a sabotar a nova aplicação.

Orquestração descentralizada: quando o líder é um serviço

Outro paralelo direto está na orquestração de microsserviços. O padrão Saga (coreografia vs. orquestração) discute exatamente isso: quem coordena as transações distribuídas? Em uma orquestração centralizada, há um serviço "líder" que gerencia o fluxo. Se ele falha ou é removido, o sistema quebra. Na coreografia, cada serviço reage a eventos, e o controle é distribuído. Mas, na prática, ainda existe um "projeto mental" — a sequência de eventos esperados — que funciona como o líder invisível.

Rui Tavares, ao sair da liderança formal, parece ter transformado o partido de uma orquestração centralizada para uma coreografia: ele não precisa mais dar ordens; o sistema já foi programado para reagir aos estímulos certos. Em engenharia, isso exige um design de contratos muito robusto, com schemas de eventos versionados, testes de integração que validem o fluxo esperado e, principalmente, tolerância a falhas que preserve a consistência eventual. Se o "líder" não está mais presente, cada nó precisa saber o que fazer quando um evento não chega — e isso deve estar documentado como comportamento esperado, não como intuição.

Implicações práticas para produtos digitais e carreira

Para quem trabalha com produto digital, a lição é clara: documente a intenção, não apenas a implementação. Ferramentas como evidence-based roadmaps, OKRs e decision logs funcionam como o "legado" do líder que se retira. Um product owner que sai sem deixar um rastro de decisões (por que essa feature foi priorizada? qual trade-off foi aceito?) está criando um "controle residual indesejado", onde as próximas pessoas terão que adivinhar a intenção original.

Na carreira de engenharia, o movimento de "sair para continuar mandando" é arriscado. Se o profissional não formaliza seu conhecimento, ele se torna um gargalo ou um "líder oculto" que gera dependência. Por outro lado, se ele estrutura o conhecimento em playbooks, runbooks e ADRs, ele pode se afastar sem perder influência — e ainda ser lembrado como alguém que construiu sistemas resilientes, não como um centralizador. Em IA, isso se traduz em model cards e datasheets for datasets que explicitam as intenções de treinamento, vieses conhecidos e limitações.

Riscos e pontos de atenção: o lado sombrio do controle residual

O maior risco é a falta de transparência. Quando um líder (ou um modelo) continua a mandar sem estar formalmente no cargo, as decisões se tornam opacas. Em política, isso gera desconfiança. Em engenharia, gera bugs difíceis de rastrear — como um modelo que insiste em recomendar itens de um catálogo descontinuado porque os pesos de fine-tuning não foram resetados. Outro risco é a ossificação: a intenção original pode se tornar obsoleta, mas o sistema continua a segui-la porque ninguém tem autoridade formal para revisar o "legado".

Para mitigar, sugiro incorporar mecanismos de expiração em artefatos de controle residual. Em política, isso seria um mandato temporário para o "conselheiro". Em software, são feature flags com data de expiração, modelos com data de retreinamento e decisões arquiteturais com revisão agendada. No caso do líder que sai, o ideal é que ele deixe não apenas a intenção, mas também um processo para revisar essa intenção periodicamente — como um comitê técnico ou um conselho de arquitetura.

Perspectiva pessoal: o que aprendi com líderes que saem (e com modelos que congelam)

Já vi de perto o impacto de um CTO que saiu da empresa, mas cujo desenho de arquitetura continuou a ser seguido por três anos — mesmo quando o negócio já havia mudado completamente. O time não tinha coragem de questionar, e o "legado" se tornou um fardo. Aprendi que a melhor forma de sair para continuar mandando é sair para ensinar a mandar sozinho. Em vez de manter controle, devemos construir sistemas (políticos ou técnicos) que evoluam com autonomia, mas dentro de limites claros.

Para equipes de IA, recomendo o seguinte: ao finalizar o treinamento de um modelo base, produza um model card que explicite não apenas o desempenho, mas também as intenções de design, os trade-offs aceitos e os cenários de falha conhecidos. Esse documento é o equivalente ao discurso de despedida de um líder que, ao sair, deixa um mapa para os que ficam. E, claro, coloque uma data de revisão nele.

Se Rui Tavares inspirou este artigo, foi justamente por mostrar que a arte de governar — seja um partido, um sistema de IA ou um time de engenharia — está em criar estruturas que perpetuem a boa direção sem depender de uma pessoa ou de um serviço central. O verdadeiro líder não é o que nunca sai, mas o que constrói algo que continua a funcionar bem mesmo quando ele não está mais ali para apertar o botão.