A 3,70 km e a poucos segundos de colidir sobre as Canárias, dois aviões com 472 pessoas foram salvos por um sistema. Vale a pena perceber porquê — antes de integrarmos automação e IA nos serviços que usamos todos os dias.
Eram 2h23 da madrugada, no espaço aéreo controlado pelas Canárias. Um Airbus A321 da Iberia e um Boeing 787 da Air Europa voavam à mesma altitude, em sentidos opostos, um a caminho do outro. A bordo, 472 pessoas.
Os sistemas de bordo dos dois aviões falaram entre si e dividiram a solução: um recebeu ordem para descer, o outro para subir. Os pilotos obedeceram. Segundos depois, com os aviões a menos de 3,70 km, soou o aviso de “livre de conflito”. Ninguém se magoou. Quase ninguém deu por nada.
A notícia resumiu tudo numa frase: um alarme evitou a tragédia. É verdade, mas fica curta. O que evitou a tragédia não foi um alarme a tocar, foi uma cadeia de decisões de design, pensada para o dia em que tudo o resto falha: a rota, a vigilância em terra, a coordenação.
A pergunta que a aviação e outros sistemas críticos foram respondendo à custa de sustos e de acidentes está agora a chegar às nossas secretárias. À medida que a inteligência artificial e a automação entram na banca, nos serviços públicos, na saúde e nas ferramentas com que trabalhamos, voltamos ao mesmo: o que deixamos a máquina fazer, o que guardamos para as pessoas e como desenhamos o momento em que as duas se cruzam?
Este caso deixa algumas lições, que valem para um cockpit e valem para uma app de banco:
- Desenhar em camadas, para o dia em que uma falha
O sistema que salvou aqueles aviões, o TCAS, deteta outro avião em rota de colisão e ordena uma manobra. É a última linha de defesa, mas não a única: antes dela estão o planeamento das rotas, a vigilância em terra, os controladores. Desenhar para o pior dia é isto, não uma proteção, mas várias, decidir as redundâncias.
A maior parte do design que fazemos foca-se no happy path: o pagamento que corre bem, o formulário sem erros. Mas a experiência decide-se muitas vezes no “percurso infeliz”: a confirmação antes de uma transferência sem volta, o “cancelar envio” que salva um email, o pagamento que fica suspenso quando algo cheira a fraude. Cuidar dessas camadas como cuidamos do sucesso não é pessimismo, é a diferença entre um erro que se evita e um que já não se corrige.
- Um sistema é tão bom quanto o contexto que consegue ler
Tudo isto aconteceu de madrugada, sobre o oceano, num espaço com “limitações inerentes de vigilância e cobertura de comunicações” face ao território continental. Ou seja: onde os sistemas em terra viam menos e ouviam pior. A automação vale o que vale dependendo da sua capacidade de “ler” a situação, aquilo a que, em fatores humanos, chamamos situational awareness.
Conhecemos isto no dia a dia. O cartão bloqueado por “atividade suspeita” mal aterramos noutro país, porque o sistema não percebeu que íamos viajar, ensina-nos a desconfiar dos avisos que deviam proteger-nos. É o equilíbrio difícil entre alarmes a mais e alarmes a menos: um sistema demasiado sensível grita por tudo até deixar de ser ouvido; um pouco sensível cala-se quando devia falar. Esse ponto não se afina só com mais dados, afina-se conhecendo o contexto real de quem usa e testando com pessoas, não com médias.
- Manter a pessoa no ciclo, às vezes só para obedecer à máquina
“Human-in-the-loop” entrou no nosso vocabulário, muitas vezes mal usado, como se a solução fosse pôr sempre um humano a validar tudo. Este caso mostra outra coisa: o papel decisivo dos pilotos não foi corrigir o sistema, foi confiar nele e agir depressa, descer quando o TCAS mandou, sem hesitar.
Não é um detalhe. Em Überlingen, em 2002, dois aviões colidiram porque, num deles, o sistema mandava subir e o controlador mandava descer, e a tripulação não sabia a quem obedecer. A ambiguidade sobre quem tem mais peso para a decisão foi a origem do acidente. A regra mudou: em conflito, obedece-se ao sistema de bordo.
Automatizar não elimina o julgamento humano, redistribui-o, e não dispensa pessoas: uma das perguntas feitas no parlamento espanhol, em reação a este incidente, foi quantos controladores estavam de serviço naquela madrugada. Já sabemos, aliás, onde as pessoas querem estar no ciclo. Largam de bom grado a tarefa aborrecida, repetitiva ou insegura, e agradecem que o IRS venha pré-preenchido, que o banco categorize as despesas, que a fatura da água se submeta sozinha. Mas querem o controlo quando a decisão é irreversível, quando se sentem responsáveis, quando o que está em jogo lhes importa. Desenhar automação é, sobretudo, decidir com honestidade que decisões devolver à pessoa e em quais lhe pedir que confie.
- Tratar o quase-acidente como um tesouro
Reparem no que veio a seguir ao susto: um relatório preliminar, uma investigação, perguntas incómodas. Ninguém morreu e, ainda assim, o sistema aprendeu. É esta disciplina de estudar o que quase correu mal, e não só o que correu mal, que faz da aviação o transporte mais seguro que temos.
Um quase-erro que passa despercebido tende a ser esquecido, quando devia ser ouro. Por isso, testamos antes de lançar, com protótipos, com utilizadores reais, em contexto, incluindo os cenários que preferíamos não imaginar. E testamos para todos: um alarme que só serve a quem ouve bem, vê bem e reage depressa não é um alarme, é um privilégio. Uma legenda automática que falha, um aviso que só existe em cor, um passo que exige uma rapidez que nem toda a gente tem, são falhas de contingência.
Desenhamos artefactos, mas temos de desenhar também os psicofactos
Há uns anos, na minha primeira talk na Tangível, chamei psicofactos àquilo que se constrói com trabalho cognitivo: a confiança, o sentido de controlo, a consciência da situação, a perceção de que ainda temos agência. Não se veem no ecrã, mas decidem se um sistema é usado, ignorado ou temido.
A notícia dizia que um alarme evitou a tragédia. A leitura mais fiel é que o que a evitou foi um sistema desenhado para avisar a tempo, para que as pessoas soubessem quando confiar nele e para que uma última camada aguentasse quando as outras cederam, testado até merecer essa confiança.
É aqui que o design deixa de ser apenas uma questão de interfaces e passa a ser uma disciplina de decisão, risco e confiança. Na Tangível, é este o trabalho que fazemos com as organizações que estão a integrar automação e inteligência artificial: ajudar a decidir o que automatizar, onde manter o controlo humano, que salvaguardas criar e como testar o sistema antes de o colocar nas mãos das pessoas.
É essa a diferença entre pôr tecnologia num serviço e desenhar um serviço com tecnologia. A tecnologia é o meio. As pessoas são sempre o fim.
Sandra Mouta,
Head of Training and Innovation da Tangível
