A Automação Tornou-se Mortal: O MCAS e o Max

Como um recurso de segurança automatizado tornou-se parte de uma catástrofe

Quando dois aviões Boeing 737 MAX caíram com poucos meses de diferença entre 2018 e 2019, os investigadores rastrearam um fio comum até o software de controle de voo da aeronave. Um sistema projetado para ajudar o avião a lidar com motores de formatos diferentes — o Maneuvering Characteristics Augmentation System, ou MCAS — foi reformulado no final do desenvolvimento de maneiras que tornaram seu comportamento mais assertivo e, criticamente, dependente de um único sensor de ângulo de ataque. Essas mudanças removeram camadas de proteção e deixaram as tripulações expostas a um modo de falha rápido e confuso que não haviam sido treinadas para reconhecer ou combater.

MCAS: o que ele deveria fazer

O MCAS foi introduzido para ajudar o MAX a ter um comportamento semelhante aos modelos 737 anteriores, após motores maiores e montados mais à frente alterarem a aerodinâmica. Sua função nominal era modesta: quando certas condições sugeriam que o nariz poderia subir demais (cabrar), o MCAS compensava o estabilizador horizontal levemente para baixo para manter a pilotagem consistente para os pilotos. Em sua concepção original, o sistema deveria ser sutil e operar raramente.

Como o sistema mudou — e por que isso importava

Durante o desenvolvimento, a Boeing expandiu o papel do MCAS. A versão implementada podia ser ativada com mais frequência e aplicar comandos de estabilizador maiores do que os projetos iniciais, e foi configurada para reagir a dados de um único sensor de ângulo de ataque, em vez de cruzar informações de múltiplas fontes. Em ambos os acidentes, da Lion Air e da Ethiopian Airlines, dados errôneos de ângulo de ataque acionaram repetidos comandos de nariz para baixo que os pilotos combateram, mas não conseguiram superar a tempo. A mudança de um design conservador e redundante para uma implementação de sensor único e mais agressiva foi um fator decisivo nas falhas.

Por que chamar o MCAS de “I.A.” é enganoso — e por que o rótulo ainda importa

Na mídia e no debate público, os acidentes às vezes são enquadrados como uma falha de “I.A.”. Esse atalho linguístico é tentador, mas impreciso. O MCAS não era um modelo de aprendizado de máquina que treinava a si mesmo a partir de dados; era uma lógica de controle de voo determinística: regras codificadas para agir com base em entradas específicas de sensores. O perigo, no entanto, é o mesmo com o qual as pessoas se preocupam em relação aos sistemas de IA opacos — um comportamento automatizado oculto dos usuários finais e reguladores, interagindo com sinais complexos do mundo real de maneiras que seus projetistas não anteciparam totalmente.

Rotular o MCAS apenas como “automação” pode minimizar como as escolhas de design — especialmente em torno da transparência, redundância e interação homem-máquina — transformaram um recurso de proteção em um perigo. Os voos revelam que mesmo algoritmos que não envolvem aprendizado exigem engenharia de segurança rigorosa, os mesmos tipos de requisitos rastreáveis e testes independentes que agora exigimos de sistemas de IA em outros domínios.

Falhas organizacionais e regulatórias ampliaram falhas técnicas

As escolhas técnicas não ocorreram em um vácuo. Múltiplas revisões e audiências descobriram que problemas na supervisão, comunicação e cultura corporativa ampliaram o risco. Os reguladores nem sempre receberam os detalhes completos do MCAS conforme ele evoluía; os manuais dos pilotos inicialmente omitiram o recurso; e as suposições de que o MCAS raramente seria ativado reduziram o treinamento dos pilotos sobre como responder quando ele ocorresse. Essas rupturas institucionais transformaram um erro de engenharia em uma crise de segurança pública.

As correções que a Boeing e os reguladores implementaram

Após a interdição da frota MAX, a Boeing e as autoridades de aviação exigiram mudanças de software e operacionais. O design revisado limita o MCAS para que ele atue apenas quando ambos os sensores de ângulo de ataque concordarem, restringe-o a uma única ativação por evento e modera a magnitude dos comandos de compensação. Os reguladores também endureceram os requisitos de documentação, treinamento de pilotos e verificação independente antes que o modelo fosse liberado para retornar ao serviço. Essas mudanças abordaram os modos de falha imediatos, mas não apagam as questões de governança mais amplas expostas pela crise.

Lições para o debate mais amplo sobre IA e automação

A história do Max é um guia preventivo para qualquer pessoa que implemente automação em escala. Quatro lições se destacam:

Esses são refrões familiares nos círculos de ética e segurança de IA, mas o 737 MAX mostra que eles não são abstratos. Em sistemas críticos de segurança, os custos de errar são imediatos e fatais.

Para onde a conversa deve seguir

Correções técnicas devolveram o MAX ao serviço sob condições mais rigorosas, mas o episódio continua sendo uma referência de como não gerenciar a automação em indústrias reguladas. Para formuladores de políticas e engenheiros, o imperativo é traduzir as lições em padrões exigíveis: caminhos de certificação mais claros para sistemas de decisão automatizados, relatórios obrigatórios de mudanças substanciais de design e estruturas institucionais que reduzam conflitos de interesse entre fabricantes e certificadores.

Para jornalistas e o público, é também um lembrete para ser preciso quanto aos termos. “IA” atrai manchetes, mas o problema subjacente no caso do MAX não foi a inteligência artificial no sentido de aprendizado de máquina — foi uma combinação de automação agressiva, falta de transparência e práticas de segurança fragilizadas. Tratar essa combinação como um desafio de engenharia e governança nos dá um caminho mais produtivo para evitar uma repetição.

Conclusão

Os desastres do 737 MAX não foram inevitáveis. Eles foram o resultado de decisões de design específicas, suposições não verificadas e falhas institucionais. À medida que a automação e a IA avançam para mais domínios, o caso do MAX deve servir como um exemplo contundente: sistemas mais seguros surgem não da confiança em um código, mas de um design conservador, comunicação clara com os usuários, revisão independente e supervisão regulatória robusta. Esses não são detalhes técnicos — são pré-condições para a segurança pública.