Quando é que a supervisão humana não funciona num sistema de IA

Ao desenvolver sistemas de IA para organizações, uma das primeiras coisas pedidas é a aprovação humana. Este artigo explica como perceber se essa aprovação funciona de facto no sistema.

Quando se fala de governação da inteligência artificial, a frase mais ouvida é esta. "Há aprovação humana, a decisão não fica entregue à máquina."

Quando ouço essa frase, só faço uma pergunta. Qual é a vossa taxa de aprovação?

Não chega resposta, porque não se mede. Nos poucos lugares onde se mede, o resultado costuma ultrapassar os noventa e oito por cento. Ou seja, a pessoa supervisora contraria o modelo uma vez em cada cinquenta decisões. Dizer que nesse quadro existe supervisão humana é formalmente correto mas funcionalmente falso. Quem decide de facto é o sistema; a pessoa apenas assina.

Por que razão o botão de aprovação não funciona

A causa não é má-fé, é o desenho.

Se a um utilizador se mostram trezentas recomendações por dia e se lhe pede que aprove cada uma, esse utilizador automatiza-se rapidamente. Se a taxa de acerto do modelo for alta, isso acelera ainda mais, porque também nos poucos casos em que rejeita, o modelo costuma ter razão, e o utilizador deixa de confiar no seu próprio critério.

Na literatura chama-se a isto confiança excessiva na automação, e é um fenómeno bem conhecido. Ou seja, quanto melhor o sistema funciona, mais fraca fica a supervisão humana. É um facto que tem de ser tido em conta ao conceber a supervisão.

As três condições que tornam a supervisão significativa

Para que a supervisão seja funcional, é preciso que três coisas existam em simultâneo.

A pessoa supervisora tem de conseguir ver o fundamento da recomendação. Se não se mostrar a partir de que dados de entrada o modelo chegou àquele resultado, a pessoa só pode avaliar o resultado, e para avaliar o resultado teria de decidir tudo de novo por conta própria. Isto torna a supervisão praticamente impossível.

A rejeição tem de ser gratuita. Um utilizador a quem rejeitar exige preencher um formulário adicional, escrever uma justificação e obter a aprovação do superior, opta por não rejeitar. O fluxo de rejeição deve ser pelo menos tão simples quanto o de aprovação.

A rejeição tem de ter uma consequência. Se as recomendações rejeitadas ficarem anotadas algures e ninguém as vir, a pessoa supervisora nota isso e, com o tempo, perde o interesse. Fazer com que os casos rejeitados alimentem o aperfeiçoamento do modelo mantém a supervisão viva.

Não existe supervisão que não se meça

Mesmo depois de cumpridas estas três condições, a medição continua a ser necessária.

Há pelo menos três indicadores que devem ser acompanhados. A taxa de rejeição, o tempo médio gasto por decisão e a taxa de acerto posterior das decisões rejeitadas. Se o tempo por decisão tiver descido para a ordem dos segundos, não se está a supervisionar. Se a taxa de rejeição se aproximar de zero, a conclusão é a mesma.

Muito poucas organizações têm resposta quando estes indicadores são pedidos numa auditoria. No entanto, não são medições difíceis, extraem-se de dados que o próprio sistema já produz.

O direito de contestação determina a arquitetura

O artigo 11.º da Lei 6698 reconhece à pessoa o direito de contestar um resultado desfavorável resultante exclusivamente da análise por sistemas automatizados.

A consequência técnica desta disposição é direta. Quando chega uma contestação, tem de ser possível mostrar como a decisão foi tomada. Se não for possível mostrar, não é possível defender a decisão.

Daí resulta esta regra arquitetónica. Num fluxo que produz consequências para uma pessoa não pode usar-se um modelo que não gere justificação. Isto deve ficar escrito desde o início como uma restrição na escolha do modelo. Acrescentar explicabilidade a posteriori não é possível na maioria das arquiteturas.

Registar não basta, é preciso registar a coisa certa

Ao falar de registo de auditoria, o que vem logo à mente é manter um registo, mas o que é determinante é o conteúdo desse registo.

Para que uma decisão possa ser revista mais tarde, é preciso registar em conjunto cinco elementos. Os dados que entraram no sistema, a versão do modelo, o resultado produzido, a justificação em que esse resultado se baseia e a decisão final tomada pela pessoa. Se estes cinco forem mantidos em sistemas separados, depois não podem ser cruzados. Se a versão do modelo não tiver sido registada, meses depois não há forma de responder à pergunta sobre o que o modelo dizia naquela data.

A versão do modelo por registar é, na prática, a lacuna que vejo com mais frequência. O modelo é atualizado, tentam-se explicar decisões antigas com o modelo novo, e não bate certo.

É preciso mostrar a diferença entre certeza e incerteza

Um último ponto. O sistema deve mostrar de forma distinguível o resultado que produz com baixa confiança do que produz com alta confiança.

Se essa distinção não existir, o utilizador confia igualmente em todos e não recebe qualquer aviso precisamente onde o erro é mais provável. No entanto, a incerteza do próprio modelo pode normalmente ser medida. Levar essa medição até à interface é a melhoria mais barata e mais eficaz da supervisão.

Se tivesse de escolher uma única coisa a fazer hoje num projeto de inteligência artificial, seria esta a minha escolha.