Champion/Challenger: promover um modelo não pode ser um ato de fé
Guilherme Zuccolotto (Zucco), Senior Manager de Data & AI na Globant, abriu a trilha de Governança de IA avisando a plateia: "vou falar de inteligência artificial, machine learning" — não de LLM ou chatbots. O foco foi a estratégia Champion/Challenger, usada para trocar modelos em produção sem colocar o negócio em risco.
O ponto de partida é um problema conhecido por quem já operou modelo em produção: a degradação silenciosa. Como ele resumiu, "quando a gente coloca um modelo em produção, ele costumeiramente começa a errar de forma silenciosa", porque "o drift de dados lá na frente é a regra". Sem instrumentação, o negócio só percebe quando já é tarde — "aí é aquela correria de tentar resolver o problema em produção".
A solução proposta segue uma progressão de risco controlado: backtest (dados históricos) → shadow mode (o Challenger roda em paralelo sem afetar decisões reais) → experimento controlado (teste A/B com parte do tráfego real). Só depois disso entram os gates: seis dimensões (performance estatística, estabilidade entre segmentos, robustez a mudanças de parâmetros, valor de negócio, performance operacional/latência e auditabilidade) que combinadas decidem se o modelo é promovido.
Um ponto que Zucco destacou como frequentemente ignorado: as decisões de promoção precisam sobreviver à variação dos pesos atribuídos a cada métrica. "Será que meu modelo só performou melhor que o outro porque eu falei que a viabilidade estatística vale 35% e a de negócio 15%?" A resposta é testar a sensibilidade, variando os pesos (o material da palestra cita o método de Monte Carlo com distribuição Dirichlet) para garantir que o Challenger "seja tão bom quanto ou melhor independente do quanto de peso eu vou atribuir".
A auditabilidade — um dos seis pilares — ganhou ênfase por conta da experiência dele no mercado financeiro: "você não pode dar um crédito ou negar um crédito sem você conseguir explicar o porquê". Modelos que não permitem explicar suas features viram um hard gate: reprovados "independente se as outras métricas são boas ou não".
A promoção final, segundo ele, deve ser gradual (estratégia Canary, com tráfego crescente por percentual) e sempre registrada em uma ferramenta de Model Registry (ele demonstrou o MLflow), guardando métricas do modelo vencedor e do perdedor para permitir rollback e rastreabilidade — "eu tenho a rastreabilidade de que modelo entrou, por que entrou, com quais métricas, quem fez essa deploy em produção".
Harness Engineering: o gargalo não é mais digitar, é revisar
Em seguida, Yasmin Oliveira, staff engineer no iFood, trouxe uma reflexão sobre como equipes de desenvolvimento estão (ou deveriam estar) lidando com agentes de código no dia a dia. Ela começou admitindo a frustração inicial: baixou o Claude Code, "instalar 500 skills, 10 MCPs, 30 plugins" — e o resultado foi um agente que "rodava e não entregava nada".
O conceito central da palestra é o de harness — tudo aquilo que não é o modelo em si, mas que envolve e direciona seu comportamento (arquivos como AGENTS.md, specs, linters, CI). Citando um artigo de Martin Fowler, ela separou duas camadas: o harness construído por quem cria o agente (Claude Code, Codex) e o harness do usuário, que é onde a engenharia de fato pode agir — "não faz muito sentido a gente usar do nosso tempo" tentando modificar o primeiro.
Um dos pontos mais técnicos foi sobre o mecanismo de atenção dos LLMs. Citando o artigo Lost in the Middle, ela explicou que janelas de contexto muito grandes fazem o modelo "se perder" das instruções iniciais — por isso é preciso filtrar o que entra na janela, evitando, por exemplo, jogar logs enormes de teste diretamente no contexto principal. Sua recomendação prática: usar subagentes para isolar tarefas ruidosas (como rodar suítes de teste) e devolver ao contexto principal só o resultado relevante — "você usa o subagente só para dizer, ó, passou ou não passou?".
Outra distinção importante: instruções em markdown são apenas sugestões, porque o LLM é probabilístico; regras em linter e CI são forçadas. "Ela errar não é um bug [...] é a probabilidade, é o mecanismo como funciona. E cabe a gente entender como usar esse mecanismo ao nosso favor."
O case prático veio de uma migração de API no checkout do iFood, estimada em um mês e meio a dois meses e entregue em cerca de um mês — mas o dado mais interessante foi outro: a equipe gastou uma semana só estruturando o contexto da codebase antes de codar, o que não atrasou a entrega final, mas acelerou entregas seguintes. Ela também citou colegas que reduziram uma migração de framework, historicamente de três meses, para uma semana usando esses princípios de engenharia de contexto.
Provocando as lideranças presentes, Yasmin questionou a métrica de "produtividade 10x" vendida por quem lucra com consumo de tokens, defendendo em vez disso uma produtividade sustentável, onde a equipe entende o que está acontecendo dentro do sistema — sobretudo em contextos críticos como o checkout de um app com milhões de pedidos, onde erros gerados por atalhos de IA podem se tornar incidentes difíceis de reverter.
As duas palestras, de domínios distintos — ML clássico e agentes de código — convergem numa mesma lição para quem constrói software hoje: dar mais autonomia a um sistema de IA sem mecanismos explícitos de controle, revisão e rastreabilidade é trocar um problema visível por outro, silencioso, que aparece mais tarde e custa mais caro para corrigir.