Conceber a permissão

Durante anos, grande parte do design de interação partiu de uma premissa bastante simples: o utilizador decide e o sistema responde.

Clicamos, escolhemos uma opção, confirmamos uma ação, enviamos um formulário. Mesmo quando o sistema automatiza parte do processo, costuma existir um momento claro em que a pessoa inicia, valida ou executa o que está a acontecer.

A inteligência artificial está a começar a mudar essa relação.

Um sistema já não tem de se limitar a esperar por uma instrução concreta. Pode interpretar uma intenção, antecipar o passo seguinte, preparar uma ação e até executá-la sem que o utilizador tenha de intervir novamente a cada momento.

E é aí que surge uma nova questão de design.

Já não basta perguntarmo-nos o que uma IA pode fazer tecnicamente. Também temos de decidir o que deveria poder fazer sem nós.

Porque capacidade e permissão não são a mesma coisa.

O facto de um sistema conseguir redigir um e-mail não significa que o deva enviar. O facto de conseguir reorganizar uma agenda não significa que deva alterar qualquer reunião. O facto de conseguir encontrar uma alternativa mais barata não significa que deva efetuar automaticamente uma compra.

Em cada um desses casos, a tecnologia pode ser capaz de concluir a ação. O que muda é o grau de autonomia que estamos dispostos a conceder-lhe.

Por isso, conceber produtos com IA implica começar a trabalhar com uma fronteira que antes era muito mais simples: até onde o sistema pode avançar antes de devolver a decisão à pessoa.

Essa fronteira não será igual para todas as ações, nem para todos os utilizadores, nem para todos os contextos.

E, provavelmente, uma das decisões de design mais importantes dos próximos anos não será que funcionalidades incorporamos na IA, mas sim quais delas pode executar sem voltar a perguntar-nos.

Sugerir, preparar, confirmar e agir são permissões diferentes

Quando falamos de autonomia em sistemas com inteligência artificial, é fácil cair numa simplificação: ou a pessoa mantém o controlo ou a máquina age de forma automática.

Mas entre ambos os extremos existem muitas possibilidades.

Uma IA pode limitar-se a sugerir uma ação, preparar o passo seguinte e deixá-lo pronto, pedir uma confirmação antes de o executar ou agir diretamente quando o contexto o permite.

A diferença entre uma opção e outra não está necessariamente na capacidade técnica do sistema, mas na permissão que tem para avançar.

Um assistente pode recomendar vários horários livres para uma reunião. Também pode redigir o convite e selecionar os participantes. Pode deixar tudo preparado e pedir uma confirmação final ou, se já existirem condições definidas, enviar diretamente a convocatória.

A tecnologia pode ser praticamente a mesma. O que muda é o momento em que a pessoa deixa de intervir.

E esse momento não tem de ser fixo.

A mesma IA pode agir com muita autonomia numa tarefa rotineira e, poucos segundos depois, pedir confirmação para outra ação com maiores consequências. Pode reorganizar uma lista sem perguntar, preparar uma resposta sem a enviar e parar antes de efetuar uma compra.

Por isso, falar de sistemas “autónomos” como uma categoria única pode ser enganador.

O importante não é decidir se uma IA é autónoma ou não, mas sim que grau de autonomia tem em cada ação concreta.

Conceber essa diferença permite que a automatização não seja uma propriedade geral do produto, mas uma decisão de interação que pode adaptar-se ao contexto, ao risco e às expectativas do utilizador.

A permissão deveria depender da ação, não do agente

Falar de uma IA como “autónoma” pode ser útil para descrever uma capacidade geral, mas é uma categoria demasiado ampla quando chega o momento de conceber a experiência.

O mesmo sistema pode comportar-se de formas muito diferentes consoante aquilo que está a fazer.

Pode reorganizar automaticamente uma lista, preparar uma resposta que ainda precisa de revisão, sugerir uma alternativa ou parar antes de executar uma ação com consequências maiores.

Por isso, talvez a questão não devesse ser quanto controlo tem o agente em termos gerais, mas sim que permissão tem para cada ação concreta.

Esta diferença é importante porque nem todas as ações têm o mesmo peso.

Alterar a ordem de alguns elementos, modificar uma reserva, enviar uma mensagem ou efetuar um pagamento podem fazer parte do mesmo fluxo, mas não deveriam necessariamente partilhar o mesmo nível de autonomia.

Conceber a partir da ação obriga a observar com mais detalhe o que acontece em cada momento: o que muda, quem pode ser afetado, que consequências pode ter e que margem existe para o corrigir depois.

Também evita uma ideia perigosa: a de que, depois de concedida uma certa autonomia ao sistema, essa autonomia deva aplicar-se de igual forma a tudo o que faz.

A permissão pode ser granular.

Uma pessoa pode sentir-se confortável em deixar que a IA resolva determinadas tarefas sem intervenção e, ao mesmo tempo, querer manter a decisão final noutras.

Por isso, a verdadeira unidade de design não é o agente em abstrato, mas sim a ação, o seu contexto e as suas consequências.

Quando introduzir fricção

Durante anos, uma parte importante do design digital tentou reduzir a fricção: menos passos, menos cliques, menos interrupções.

Mas quando um sistema pode agir por nós, eliminar a fricção nem sempre melhora a experiência.

Por vezes, parar faz parte de um bom design.

A questão não é acrescentar confirmações por precaução, mas compreender que tipo de ação está prestes a ser realizada e que consequências pode ter.

Há ações em que o custo de errar é praticamente irrelevante. Noutras, uma decisão pode envolver dinheiro, comprometer outra pessoa, modificar informação importante ou ser difícil de desfazer.

Também importa a reversibilidade.

Não é o mesmo uma ação que pode ser corrigida imediatamente e outra cujos efeitos são permanentes ou muito difíceis de reverter. Quanto menor for a possibilidade de voltar atrás, mais sentido faz que o sistema reduza a sua autonomia ou solicite uma intervenção explícita.

Outro fator importante é saber se a ação afeta apenas o utilizador ou também terceiros.

Reorganizar informação pessoal pode exigir muito pouca supervisão. Enviar uma mensagem, cancelar uma reunião ou aceitar determinadas condições em nome de alguém introduz consequências que vão para além da própria interface.

E há ainda o contexto.

Uma decisão que era válida quando uma tarefa foi iniciada pode deixar de o ser alguns minutos depois. Um preço pode mudar, uma disponibilidade pode desaparecer, um destinatário pode ser alterado ou pode surgir nova informação que mude a decisão.

Por isso, conceber autonomia também significa decidir quando vale a pena interromper o fluxo.

Nem toda a fricção é um obstáculo. Em determinados momentos, pode ser precisamente aquilo que permite ao utilizador compreender o que está prestes a acontecer, rever uma decisão ou manter o controlo quando isso realmente importa.

A boa experiência nem sempre será a que pergunta menos, mas aquela que sabe quando faz sentido perguntar.

Do “confirmas?” à permissão condicionada

Pedir confirmação antes de cada ação pode ser uma forma simples de manter o controlo, mas também tem um limite.

Se um sistema pergunta constantemente, a confirmação deixa de ser uma decisão consciente e pode tornar-se um gesto automático.

Em muitos casos, uma alternativa mais útil é permitir que o utilizador defina antecipadamente as condições em que a IA pode agir.

Não se trata de conceder uma permissão geral, mas de estabelecer limites concretos.

“Faz isso se custar menos de 50 euros.”

“Reserva apenas se puder ser cancelada.”

“Responde automaticamente apenas a este tipo de mensagens.”

“Reorganiza a minha agenda, mas não alteres reuniões com clientes.”

Este tipo de interação muda de forma importante o papel da interface.

Já não concebemos apenas o momento em que alguém carrega em “Confirmar”. Concebemos também as regras que delimitam até onde o sistema pode ir sem voltar a perguntar.

Isso exige que essas condições sejam compreensíveis, visíveis e fáceis de alterar.

O utilizador deveria poder saber o que autorizou, em que circunstâncias será aplicado e que exceções definiu. Caso contrário, a autonomia pode tornar-se rapidamente algo difícil de antecipar.

Surge também uma questão interessante: uma autorização não tem de ser absoluta.

Pode depender de um montante, de um destinatário, de um horário, de uma categoria de tarefa ou de qualquer outro elemento relevante para essa decisão.

Nesse sentido, conceber autonomia assemelha-se menos a ativar uma função automática e mais a definir o espaço dentro do qual o sistema pode agir livremente.

O desafio já não consiste apenas em perguntar antes de fazer algo, mas em permitir que cada pessoa estabeleça com clareza quando não é necessário voltar a perguntar-lhe.

O sistema também deve saber quando voltar a perguntar

Dar permissão a uma IA para agir não deveria significar que essa permissão é válida indefinidamente.

As condições mudam.

O preço, o destinatário, o nível de risco, a informação disponível ou até o objetivo que fazia sentido alguns minutos antes podem mudar.

Uma ação que se enquadrava perfeitamente em determinadas condições pode deixar de o fazer quando o contexto muda.

Por isso, um sistema autónomo não precisa apenas de saber quando pode agir. Também precisa de reconhecer quando a permissão que tinha já não é suficiente.

Imaginemos que alguém autorizou uma reserva automática abaixo de um determinado montante. Se o preço aumentar, se as condições de cancelamento mudarem ou se surgir um custo adicional, o sistema deveria ser capaz de parar.

O mesmo acontece com ações que afetam outras pessoas.

Uma mensagem automática pode ser perfeitamente aceitável num contexto habitual, mas talvez não quando o destinatário muda, o conteúdo se torna mais sensível ou a decisão começa a ter consequências que não estavam previstas.

Aqui surge uma responsabilidade de design especialmente importante: definir que alterações obrigam o sistema a devolver a decisão à pessoa.

Não se trata de fazer com que a IA hesite constantemente, mas de identificar os momentos em que avançar significaria agir em condições diferentes daquelas que o utilizador aceitou.

Nesse sentido, a autonomia não consiste apenas em avançar sem intervenção humana.

Consiste também em saber quando parar.

Um sistema bem concebido não demonstra inteligência apenas quando resolve uma tarefa por si próprio, mas também quando reconhece que o contexto mudou o suficiente para voltar a perguntar.

Conclusão

A evolução da inteligência artificial costuma ser medida em termos de capacidade.

O que pode fazer, quantas tarefas pode concluir, quanto contexto pode interpretar ou até que ponto pode agir sem intervenção humana.

Mas, do ponto de vista do design, talvez a questão mais importante seja outra.

Não quanto uma IA pode fazer, mas sim em que condições deveria poder fazê-lo sem nós.

Porque, à medida que os sistemas ganham autonomia, também aumenta a necessidade de definir limites claros: quando podem avançar, quando precisam de confirmação, que condições devem respeitar e em que momento uma autorização deixa de ser válida.

Isso obriga a conceber mais do que funcionalidades.

Obriga a conceber permissões, exceções, limites e momentos de devolução da decisão ao utilizador.

E aí surge uma diferença importante entre uma automatização simplesmente eficiente e uma experiência realmente bem pensada.

A primeira tenta reduzir ao máximo a intervenção humana.

A segunda compreende que há momentos em que intervir continua a fazer parte do valor da experiência.

Conceber autonomia, portanto, não consiste em eliminar o utilizador do fluxo.

Consiste em decidir com critério quando pode afastar-se e quando deve voltar a intervir.

Porque um sistema não demonstra que está bem concebido apenas quando sabe agir por nós.

Também quando sabe reconhecer que chegou o momento de nos devolver a decisão.

Se uma IA pode concluir uma ação sem nos perguntar, também concebemos as condições que deveriam obrigá-la a voltar a fazê-lo?