O algoritmo que quase derrubou o Show do Milhão: lições de gestão de produto para o ecossistema de IA

Em 1989, o SBT enfrentava um dilema que, à primeira vista, nada tinha a ver com tecnologia. O Show do Milhão, um dos programas de maior audiência da história da emissora, quase foi cancelado antes mesmo de estrear. O motivo não era falta de orçamento, problemas de elenco ou baixa qualidade de produção. O motivo era um embate de poder entre Silvio Santos e Hebe Camargo sobre uma mudança de horário. O executivo Walter Zagari, em entrevista recente, detalhou como a briga quase inviabilizou a atração.

O que isso tem a ver com inteligência artificial, gestão de produto digital e engenharia de software? Muito mais do que você imagina. O episódio não é apenas uma curiosidade da TV brasileira; é um estudo de caso sobre como decisões aparentemente não técnicas podem derrubar os projetos mais promissores. Em um mundo onde a IA é cada vez mais integrada a produtos digitais, entender os trade-offs de ecossistema, alinhamento de stakeholders e gestão de mudanças é tão crítico quanto dominar a arquitetura de um modelo de linguagem.

Vou propor uma leitura técnica deste caso. Não para reescrever a história, mas para extrair dela lições que aplico diariamente em projetos de engenharia de software e produtos de IA. Prepare-se para uma análise que conecta a briga de horário da TV ao desalinhamento de prioridades em times de machine learning.

O conflito como metáfora de desalinhamento de produto

No centro da briga estava um recurso escasso: o horário nobre. Hebe Camargo era a âncora da grade noturna do SBT, e Silvio Santos queria realocar esse horário para o Show do Milhão. A decisão não era trivial. Ambas as atrações tinham audiência consolidada, e a mudança implicava em perda de receita publicitária, queda de expectativa de telespectadores e, acima de tudo, um choque de imagem entre duas marcas poderosas.

No universo de produtos digitais, esse cenário se repete de forma estrutural. Quando uma empresa decide migrar recursos de um produto legado — que ainda gera receita — para uma nova plataforma baseada em IA, o conflito é inevitável. O time de engenharia do produto antigo defende sua estabilidade e métricas conhecidas. O time de inovação quer explodir a régua com um modelo preditivo ou um assistente inteligente.

O erro mais comum que vejo em startups e empresas de tecnologia é tratar esse conflito como um problema de priorização técnica, quando na verdade é um problema de alinhamento de incentivos. Silvio Santos e Hebe Camargo não estavam discutindo a qualidade do Show do Milhão; estavam discutindo quem controlava o ativo mais valioso: o horário. Da mesma forma, times de produto e engenharia frequentemente brigam por recursos computacionais, tempo de GPU ou capacidade de deploy sem jamais discutir quem, de fato, detém a decisão sobre o roadmap do produto.

O princípio do recurso escasso em sistemas de IA

Em infraestrutura de nuvem, o recurso escasso raramente é o dinheiro — é a latência, o custo de inferência ou a capacidade de processamento em tempo real. Quando dois times disputam um mesmo cluster de GPUs para treinar modelos distintos, o conflito é análogo ao da grade de TV. Um time quer liberar uma feature de recomendação em tempo real; o outro quer rodar um batch de validação de um modelo de classificação.

A solução que implementei em um projeto recente foi criar um conselho de governança de recursos, onde cada time apresentava não apenas o custo do recurso, mas o custo de oportunidade de não tê-lo. Isso é raro. A maioria das empresas trata a GPU como um bem infinito, terceirizando a decisão para a nuvem. Mas quando a conta chega, o conflito aparece — e a briga é tão pessoal quanto a de Silvio e Hebe.

Quando o cancelamento do projeto é uma opção racional

Walter Zagari revelou que o Show do Milhão quase foi cancelado. Isso não é um sinal de fracasso; é um sinal de que a organização estava disposta a sacrificar um ativo promissor para preservar a estabilidade do ecossistema. Em engenharia de software, a decisão de cancelar um projeto de IA antes de ir para produção é frequentemente vista como um erro de gestão. Na prática, é um dos atos mais corajosos que um líder técnico pode tomar.

Já estive em reuniões onde discutimos o encerramento de um sistema de recomendação baseado em redes neurais porque o retorno sobre o investimento em infraestrutura superava o ganho de receita projetado. O time de produto queria continuar; o time de engenharia apontava a insustentabilidade. O que salvou o projeto não foi um argumento técnico, mas uma renegociação dos critérios de sucesso. Reduzimos a cobertura do modelo de 80% para 40% da base de usuários, focando apenas nos segmentos de maior valor. O custo de inferência caiu pela metade, e o projeto sobreviveu.

O cancelamento não precisa ser o fim. Pode ser uma redução de escopo forçada por restrições reais. No caso do SBT, a solução foi um acordo de compromisso: Hebe cedeu o horário, mas ganhou garantias de produção e exposição em outras faixas. No mundo de IA, o equivalente é um sizing de modelo: você mantém a arquitetura, mas reduz a profundidade, a largura ou a frequência de atualização para caber no orçamento.

Trade-offs que todo engenheiro de IA precisa conhecer

Existem três trade-offs que aparecem em praticamente todos os projetos de IA que liderei ou consultei. Eles são diretos, mas raramente discutidos com a profundidade que merecem:

• Precisão versus custo operacional: Um modelo com 99% de acurácia pode custar 10x mais em inferência do que um com 95%. A diferença de 4% é relevante para o seu caso de uso? Muitas vezes, não. A decisão de Silvio Santos não foi sobre a qualidade do programa, mas sobre o custo do horário. O mesmo vale para o seu modelo.
• Velocidade de deploy versus estabilidade do ecossistema: Colocar um modelo em produção rápido demais pode quebrar dependências com outros sistemas. No caso do SBT, a mudança de horário quebraria a expectativa do público de Hebe. Em um sistema de microsserviços, uma API de IA mal dimensionada pode derrubar o front-end inteiro. O trade-off é entre agilidade e confiabilidade.
• Inovação versus manutenção do legado: O novo produto (Show do Milhão) prometia alta audiência, mas o produto legado (Hebe) ainda gerava receita consistente. Em IA, o novo modelo de linguagem pode ser mais eficiente, mas o sistema legado baseado em regras ainda funciona e não requer retreinamento. A decisão de migrar ou não é uma aposta política, não técnica.

O papel do líder técnico como mediador de conflitos

A história do Show do Milhão mostra que o maior desafio de Silvio Santos não era produzir um programa de perguntas e respostas. Era administrar a relação com Hebe Camargo, que era uma figura de peso na emissora. No mundo corporativo de tecnologia, o CTO ou o engenheiro sênior muitas vezes precisa fazer o mesmo papel: mediar a disputa entre o time de produto que quer surfar a hype da IA generativa e o time de infraestrutura que precisa manter a estabilidade do sistema.

Em uma experiência pessoal, atuei como mediador em um conflito entre o time de dados e o time de produto. O time de dados queria implementar um modelo de recomendação complexo, que consumiria 70% da capacidade de processamento do cluster. O time de produto precisava de uma feature mais simples, mas que entrasse no ar em duas semanas. A solução foi criar um modelo híbrido: uma versão leve baseada em regras para o lançamento imediato, e uma versão avançada baseada em aprendizado profundo para o roadmap de seis meses. O time de dados não ficou feliz, mas o produto foi para o ar. O compromisso não foi técnico; foi político.

O líder técnico precisa entender que, em muitos casos, a melhor arquitetura não é a mais eficiente, mas a que maximiza a probabilidade de adoção pelo time. Isso é particularmente verdadeiro em projetos de IA, onde a resistência a mudanças é alta. Se você força um modelo de caixa-preta sem explicar os trade-offs, o conflito será inevitável — e o projeto pode ser cancelado, como quase foi o do Show do Milhão.

Lições de governança para produtos de IA

Existem três práticas que adoto em projetos de IA para evitar que o conflito de recursos mate o produto antes do lançamento:

• Comitê de recursos compartilhados: Reuniões semanais onde os times de engenharia, produto e dados discutem alocação de GPU, armazenamento e largura de banda. A decisão não é do CTO, é do grupo. Isso tira o peso pessoal da briga e coloca a responsabilidade no coletivo.
• Acordos de nível de serviço (SLAs) para modelos: Defina claramente o que cada modelo deve entregar em termos de latência, custo e cobertura. Se um modelo não cumpre o SLA, ele é despriorizado. Isso é análogo ao contrato de horário que Hebe exigiu: garantias de que sua audiência não seria prejudicada.
• Documentação de trade-offs: Cada decisão de arquitetura ou de alocação de recursos deve ser registrada com os prós e contras. Isso não é burocracia; é uma forma de blindar o time contra revisões futuras. Quando o projeto cresce, a memória do conflito original se perde. A documentação serve como a "grade de programação" que define o que estava em jogo.

O que a engenharia de software pode aprender com a TV brasileira

Pode parecer estranho um engenheiro de software escrever sobre um programa de auditório dos anos 1980. Mas a verdade é que a gestão de produto digital é, em sua essência, uma atividade de negociação de recursos escassos. O Show do Milhão não era apenas um programa; era um sistema complexo que dependia de horário, elenco, produção e audiência. Um sistema de IA não é diferente: depende de dados, modelo, infraestrutura, orçamento e, principalmente, de pessoas que concordam sobre o que é prioritário.

A lição central é que o cancelamento de um projeto técnico raramente é causado por falha técnica. É causado por desalinhamento entre os stakeholders. Silvio Santos e Hebe Camargo quase inviabilizaram o maior sucesso do SBT não por incompetência, mas por falta de uma estrutura de governança que resolvesse o conflito de horário de forma racional. Se você está liderando um projeto de IA, pergunte-se: quem é a Hebe Camargo do seu time? Qual recurso escasso está sendo disputado? E o mais importante: você está preparado para cancelar o projeto se o custo político for maior que o benefício técnico?

Minha recomendação é que você, como engenheiro ou líder técnico, invista tanto tempo na gestão de conflitos quanto na otimização de hiperparâmetros. O modelo mais preciso do mundo não vale nada se o time não conseguir colocá-lo em produção. E, para isso, você precisa de um acordo que, assim como na TV, depende de quem senta na cadeira de decisão. O Show do Milhão estreou, fez história e virou referência. Mas a história não contada — e que Walter Zagari agora revela — é que o sucesso depende de um alinhamento que vai muito além do código.