Construímos um Solucionador de Escalas de Tripulação Mais Rápido. Ele Só Falhou Mais Rápido.
A primeira vez que estive em um centro de controle de operações de uma companhia aérea durante uma cascata real, era um pouco depois das 3h da manhã e uma tempestade de inverno havia fechado uma estação-chave horas antes. O painel de vídeo ao longo da frente da sala estava se enchendo de vermelho — cancelamento após cancelamento — e a coisa de que mais me lembro é que ninguém estava usando o solucionador de escalas de tripulação de milhões de dólares que a companhia havia pago. Os despachantes tinham empurrado os teclados para o lado e trabalhavam manualmente as combinações de tripulação quebradas, em planilhas e em um quadro branco, exatamente no momento em que o software deveria justificar seu custo.
Essa imagem foi o que acabou nos levando a construir uma IA de escalas de tripulação aérea para recuperação de IROPS — mas não da forma que eu esperava, e não antes de eu apostar na correção errada e vê-la falhar. IROPS, se você nunca teve o prazer, é a palavra do setor para operações irregulares: as tempestades, os fechamentos, a bagunça em cascata quando uma escala se desfaz. Isso custa ao setor aéreo cerca de US$ 60 bilhões por ano, aproximadamente 8% da receita global das companhias aéreas, segundo a IATA. Cerca de um em cada cinco voos no mundo é afetado por isso. E o segredo sujo que aprendi naquela noite é que o software de otimização mais sofisticado da aviação é essencialmente projetado para ser inútil durante justamente os eventos que custam mais caro.
O Solucionador Estava Otimizando uma Companhia Aérea Que Já Não Existia
Ajuda entender o que os solucionadores de tripulação legados realmente fazem. Eles executam geração de colunas — uma técnica de otimização por branch-and-price que é genuinamente brilhante em encontrar a maneira legal mais barata de escalar uma programação conhecida. O problema está na palavra conhecida. O solucionador tira um instantâneo da rede, congela o tempo e calcula a atribuição ideal de tripulação para aquele mundo congelado. Ele roda em ciclos de lote, normalmente a cada 30 a 60 minutos.
Durante operações normais, isso funciona. O mundo mal se move entre os ciclos. Mas durante uma cascata, o estado da rede muda a cada poucos minutos. As tripulações se deslocam. As conexões se rompem. As aeronaves ficam retidas. Quando o solucionador retorna uma solução, os dados de entrada que ele recebeu já estão errados — então a resposta é um plano perfeito para uma companhia aérea que já não existe.
Comecei a chamar isso de Lacuna entre Otimização e Execução: a distância entre o mundo que o solucionador presumiu e o mundo que está realmente lá fora, na pista. A lacuna é inofensiva durante um atraso isolado. Durante uma cascata, ela é fatal, porque o solucionador foi construído para eficiência — a programação mais barata em um mundo conhecido — e o que você precisa desesperadamente às 3h da manhã é resiliência: uma programação que sobreviva em um mundo desconhecido.
A parte mais cruel de um solucionador de tripulação legado é que, durante um colapso, ele continua funcionando — entregando calmamente um plano impecável para uma rede que se desfez enquanto ele calculava.
Por Que Não Podíamos Simplesmente Deixar o Solucionador Mais Rápido?
Esta é a parte de que não me orgulho, e é a parte que realmente importa.
Quando minha equipe olhou pela primeira vez para o problema, nosso diagnóstico foi o diagnóstico óbvio de engenheiro: o solucionador é lento demais. O mundo muda a cada cinco minutos e o otimizador leva de trinta minutos a uma hora, então feche a lacuna — deixe-o mais rápido. Passamos um bom tempo construindo um motor de recuperação mais rápido, apoiando-nos em heurísticas mais baratas para obter uma resposta viável dentro da janela de decisão operacional, em vez de esperar por uma comprovadamente ideal.
E funcionou, no sentido estrito de que retornava respostas mais rápido. Então o testamos contra dados reais de disrupção e o vi produzir com confiança planos de recuperação que já eram inválidos, só que mais cedo. Havíamos construído uma máquina que otimizava uma companhia aérea fantasma em maior velocidade.
O erro foi tratar a velocidade como o gargalo. Não era. O gargalo era que os dados de entrada eram ficção. O solucionador — o nosso incluído — precisa de fatos concretos: "O comandante Smith está no Portão B7 em Denver." Mas durante uma cascata, o comandante Smith pode estar no hotel, pode estar no ônibus dos funcionários, pode ter alugado um carro e estar no meio do caminho para Colorado Springs. O estado honesto do mundo é "provavelmente em Denver", e um solucionador de geração de colunas não consegue fazer nada com provavelmente. Havíamos estado afiando a resposta a uma pergunta cujos dados eram lixo.
Essa falha é a razão pela qual o produto existe. Se tivéssemos lançado o solucionador rápido, teríamos vendido às companhias aéreas uma forma mais veloz de cometer o mesmo erro caro.
O Buraco Negro de Dados de US$ 1,2 Bilhão
Se você quiser ver essa falha exata em plena escala, veja o que aconteceu com a Southwest em dezembro de 2022. O colapso custou à companhia aérea cerca de US$ 1,2 bilhão, cancelou por volta de 16.900 voos e deixou perto de dois milhões de passageiros retidos durante as festas de fim de ano.
A história popular é "software antigo". A história real é mais específica e mais útil. O sistema de escalas de tripulação da Southwest, o SkySolver, atingiu uma explosão combinatória que não conseguiu computar. Mas por baixo disso, a companhia perdeu o controle de onde seus próprios pilotos e comissários estavam fisicamente. O relato de posição da tripulação corria em grande parte por telefone — tripulações retidas em estações remotas ligando para uma central de escalas onde os tempos de espera chegavam a horas. Essa latência criou o que eu penso como um buraco negro de dados: o sistema estava gerando escalas para tripulações que não estavam onde ele pensava que estavam. Ele estava otimizando uma rede fantasma, e a estrutura de rotas ponto a ponto significava que não havia "pontos de regeneração" em hubs onde tripulações e aeronaves naturalmente reconvergem, de modo que o raio de destruição simplesmente continuou se espalhando de estação em estação.
Isso não é história antiga que todos já corrigiram desde então. Em julho de 2024, o sistema de escalas da Spirit criou atribuições conflitantes para 43% de suas tripulações de voo disponíveis, um evento estimado em US$ 50 a 100 milhões, porque o sistema não tinha a flexibilidade de reatribuir tripulações de forma limpa durante a disrupção. O padrão se repete porque a arquitetura subjacente — otimizar um instantâneo congelado, exigir dados de entrada certos — é a mesma em todo o setor.
A Southwest, é preciso reconhecer, respondeu gastando: cerca de US$ 1,7 bilhão em tecnologia em 2024 como parte de um programa maior de vários anos, uma migração para a AWS que reduziu drasticamente a pegada de seus data centers, e um algoritmo de escalas cerca de 30% mais rápido. Esse é o instinto certo. Mas uma versão mais rápida da mesma arquitetura — que é a armadilha na qual quase caímos nós mesmos — fecha a lacuna de velocidade enquanto deixa a lacuna de certeza dos dados escancarada.
O Que Acontece Agora Quando um Atraso Ultrapassa Três Horas?
Durante a maior parte da história da aviação, uma recuperação lenta custava sua boa vontade. Passageiros irritados, má imprensa, alguns vouchers. Essa conta mudou em 28 de outubro de 2024.
Foi quando entrou em vigor a regra de reembolso automático do Departamento de Transportes dos EUA — a primeira exigência obrigatória de reembolso automático de todos os tempos. Qualquer atraso doméstico superior a três horas (seis para voos internacionais) agora aciona um reembolso em dinheiro, pago dentro de sete dias úteis, sem que o passageiro sequer precise pedir. Não é um voucher. Não é uma remarcação. Dinheiro.
Faça a conta para uma companhia aérea de médio porte que voa 300 partidas por dia. Em um dia realmente ruim, se apenas um sexto delas — 50 voos — passar da marca das três horas, a um valor médio de passagem de US$ 280 e 150 passageiros por voo, você está diante de cerca de US$ 2,1 milhões em exposição a reembolsos obrigatórios em um único dia. A recuperação lenta de IROPS costumava ser um problema de reputação. Agora é uma rubrica que atinge você na mesma semana.
Agora há um cronômetro rodando a cada hora em que sua recuperação fica para trás e, desde outubro passado, ele paga em dinheiro, automaticamente, a cada passageiro que atinge.
Esta é a parte que reformulou toda a conversa para mim. O custo da Lacuna entre Otimização e Execução já não é abstrato. Ele se acumula, em dólares, contra um relógio que começou no exato momento em que a tempestade começou.
Aumente o Solucionador, Não o Substitua
Aqui está a decisão que define nossa abordagem, e é uma decisão deliberadamente sem glamour: nós não substituímos o seu solucionador.
Os solucionadores estabelecidos codificam décadas de conhecimento de domínio específico das companhias aéreas, e o campo em torno deles está se consolidando, não entrando em colapso. A Jeppesen — o padrão do setor, com mais de cem clientes de companhias aéreas — foi vendida pela Boeing à Thoma Bravo por US$ 10,55 bilhões em abril de 2025, uma das maiores desincorporações de tecnologia da história aeroespacial, e desde então lançou o Stratosphere, uma camada de IA para gestão preditiva de disrupções. A plataforma iFlight da IBS Software está conquistando implantações modernas e nativas em nuvem — a Korean Air entrou em operação no início de 2026, com companhias como a Aeroitalia e as aéreas do Groupe Dubreuil também migrando para ela — apoiada por um acordo de coengenharia com a AWS. O CrewSolver da Optym entrega uma redução documentada de 3 a 7% no custo de tripulação no lado do planejamento.
Nenhum deles é o inimigo. Mas repare em que cada um é forte: otimização de fase de planejamento e análise preditiva — o mundo conhecido, computado lindamente. O problema da recuperação em tempo real, com dados de entrada incertos, é a lacuna que permanece aberta. A substituição completa de uma plataforma também é um projeto de 12 a 18 meses, e nenhum líder de operações quer arrancar o sistema que funciona 350 dias por ano para consertar os 15 que não funcionam. Para o CIO que de fato assina o contrato, a conta é pior do que o calendário: arrancar um sistema com décadas de lógica de CBA específica da companhia codificada nele — justamente no momento em que a própria propriedade da Jeppesen acaba de trocar de mãos por US$ 10,55 bilhões e seu roteiro de longo prazo é uma questão em aberto — é uma aposta que a maioria das organizações de tecnologia não fará. Ficar ao lado da instalação existente, consumindo seus feeds em vez de substituir seu esquema, é a única integração que eles aprovarão.
Então construímos um motor de recuperação de IROPS movido a ML que fica ao lado de uma instalação existente da Jeppesen ou IBS e lida com aquilo que o solucionador central não consegue: disrupções em cascata com posições de tripulação incertas, análise de raio de destruição em toda a rede e planos de recuperação produzidos em minutos, em vez das 4 a 12 horas que a recuperação manual normalmente leva. Dados regionais de casos sugerem que a automação pode reduzir esse tempo de recuperação em cerca de 78%. O objetivo não é ser mais inteligente que o solucionador estabelecido. É ser útil exatamente nas condições para as quais o solucionador estabelecido nunca foi projetado.
Ensinando um Modelo a Trabalhar com "Provavelmente em Denver"
Assim que paramos de tentar deixar o solucionador mais rápido, o verdadeiro problema de engenharia entrou em foco: construir algo que prospere na incerteza em vez de engasgar com ela.
A primeira peça é a inteligência de posição da tripulação. Em vez de exigir uma localização certa, alimentamos um modelo com posições probabilísticas — fundindo quaisquer sinais em tempo real que existam com o comportamento histórico, de modo que o sistema raciocine sobre onde uma tripulação provavelmente está em vez de esperar por um telefonema que está quatro horas mergulhado numa fila de espera. Essa única mudança — de "certo ou nada" para "distribuição de probabilidade" — é o que permite que um plano de recuperação sobreviva ao contato com uma cascata real.
A segunda peça é tratar a rede como um grafo e analisar onde as falhas vão se propagar antes que elas se propaguem — o raio de destruição, mapeado para a estrutura de rotas específica desta companhia aérea, de modo que você possa ver qual fechamento de estação cancela silenciosamente seis voos a jusante daqui a duas horas.
A terceira peça é um simulador de cenários, na prática um gêmeo digital da operação, para que uma equipe de operações possa ensaiar antecipadamente um cenário de tempestade de inverno e testar estratégias de recuperação quando não há tempestade de verdade nem relógio de verdade. A aviação já confia em gêmeos digitais onde os dados são ricos — a plataforma AVIATAR da Lufthansa ingere 23,7 terabytes por dia em 34 integrações de companhias aéreas e alcança 93,6% de precisão na previsão de falhas de manutenção. Os gêmeos de tripulação e de escalas ainda são incipientes, o que é precisamente onde está a oportunidade.
E permeando tudo isso está o motor de restrições. Toda recomendação tem de ser legal sob as regras de fadiga da Parte 117 da FAA — os limites de 8 a 9 horas de tempo de voo, os períodos de serviço de 9 a 14 horas — e sob o contrato sindical da companhia aérea, que é frequentemente mais restritivo do que a regulamentação. A maioria dos fornecedores trata essas regras como "configuração". Nós tratamos a codificação do acordo coletivo específico de uma companhia aérea, por frota e por base, como engenharia central, porque um plano de recuperação que viola uma cláusula do CBA não é um plano — é uma reclamação trabalhista.
Por Que Rodamos Primeiro em Modo Sombra
As pessoas deste setor têm razão em desconfiar de uma caixa-preta dizendo a elas como movimentar pilotos às 3h da manhã. Então vou lhe contar a objeção que mais ouço, porque eu mesmo a tive.
Um VP de operações nos disse, no início, mais ou menos, que eles tinham acabado de licenciar o complemento de IA para disrupções de seu fornecedor estabelecido e não viam por que precisariam de nós. Justo. Então veio a tempestade seguinte, o complemento lhes deu previsões e não uma recuperação de tripulação executável, e os despachantes estavam de volta ao quadro branco. A distinção que aquela conversa me ensinou: há uma diferença enorme entre IA agêntica para chat voltado ao passageiro — o jargão do circuito de conferências de 2026 — e IA que toma decisões operacionais sobre tripulações e aeronaves. Um chatbot que reacomoda um passageiro é uma coisa ótima. Não é o mesmo problema de engenharia que recuperar uma rede.
É por isso que, na primeira vez em que qualquer companhia aérea roda nosso motor, ele não toca nas operações. Ele roda em modo sombra: a recomendação do nosso modelo fica ao lado da decisão real do despachante humano, e medimos a lacuna, dia após dia, nas próprias disrupções da companhia aérea. A confiança não é afirmada em uma apresentação de vendas. Ela é conquistada em uma planilha de comparação, sem risco operacional, até que a equipe de operações decida por conta própria que as recomendações são melhores do que o quadro branco.
Você não conquista o direito de redirecionar os pilotos de alguém com um benchmark. Você o conquista estando certo, discretamente, ao lado de um humano, por semanas, antes que alguém precise acreditar em você.
A verdade honesta é que assistir ao modo sombra foi quando entendi o que estávamos realmente vendendo. Não um otimizador. Não velocidade. Estávamos vendendo uma forma de um líder de operações acreditar em uma máquina na pior noite do ano — e a crença tem de ser construída antes da tempestade, não durante ela.
O Que os 15 Dias Realmente Valem
Se você comanda a operação de uma companhia aérea de médio porte, seu solucionador de tripulação funciona bem 350 dias por ano. Não estou aqui para argumentar o contrário. A questão é o que acontece nos 15 dias em que ele não funciona — e esses são os dias que produzem as manchetes de bilhões de dólares, as auditorias de 43%-das-tripulações-mal-atribuídas e agora, desde outubro passado, os reembolsos automáticos em dinheiro tarifados por hora.
O erro que o setor inteiro insiste em cometer — o erro que eu cometi primeiro, com meu próprio solucionador mais rápido — é tratar esses 15 dias como um problema de velocidade a ser resolvido computando com mais força. Não são. São um problema de certeza, e você não resolve um problema de certeza exigindo mais certeza de um mundo que está se desfazendo ativamente. Você o resolve construindo algo que raciocine sob incerteza, ensaie o desastre antes que ele chegue e prove seu valor nas sombras antes de algum dia ser confiável à luz do dia. Esse é o motor que construímos, e ele é descrito por completo em nossa solução de IA de escalas de tripulação aérea.
Em algum lugar esta noite há um centro de controle de operações onde o painel de vídeo está calmo e verde, e um solucionador de tripulação zumbe através de seu ciclo de lote exatamente como projetado. O trabalho que fazemos é para a noite em que aquela sala fica vermelha — quando os telefones se acumulam, as combinações se quebram mais rápido do que qualquer um consegue anotá-las, e um despachante estende a mão para um quadro branco porque a certeza que o software exige saiu discretamente do prédio. Todo o objetivo é garantir que, naquela noite, a máquina ainda esteja raciocinando com honestidade sobre uma companhia aérea que ela já não consegue enxergar por completo.
