A IA raramente é o ponto de partida

A conversa sobre IA nas organizações segue quase sempre o mesmo caminho: começa na tecnologia e só depois procura um sítio onde a aplicar. É uma inversão discreta, e é por causa dela que tantos pilotos ficam a meio.

A pressão é real e percebe-se. Ninguém quer explicar ao conselho de administração porque é que não fez nada. Mas o maior risco raramente é ficar para trás. É gastar um ano e um orçamento em demonstrações que nunca chegam à operação.

Porque é que tantos pilotos de IA ficam a meio?

Porque foram desenhados para provar que a tecnologia funciona, e não para mudar uma decisão concreta. São objetivos diferentes, e só o segundo sobrevive ao fim do entusiasmo inicial.

Um piloto que prova capacidade termina com uma demonstração e uma pergunta em aberto: «e agora?». Um piloto que muda uma decisão termina com alguém a fazer o trabalho de outra maneira na segunda-feira seguinte. O primeiro é interessante. O segundo é o único que se consegue defender quando chega a altura de orçamentar a fase seguinte.

Há ainda uma razão menos confortável. Muitos pilotos param porque, a meio, se descobre que o problema não era de tecnologia, era de processo, de responsabilidade ou de dados. E ninguém quer ser a pessoa que o diz depois de o projeto ter sido anunciado.

Que perguntas fazer antes de avançar com um piloto de IA?

Três: que decisão é que isto muda, e de quem; o que acontece se correr bem; e como é que sabemos que falhou. Respondem-se numa folha, e se alguma ficar em branco ainda não há um caso de uso, há apenas uma intenção.

• Que decisão muda, e de quem? A resposta tem de ter um nome e um cargo. «Melhorar a eficiência» não é uma decisão; «o gestor de operações deixa de precisar de reconciliar duas listas à segunda-feira» já é.
• O que acontece se correr bem? Se ninguém conseguir descrever a operação no dia seguinte (quem faz o quê, com que sistema, com que controlo), o piloto não tem para onde ir e o sucesso técnico não se converte em nada.
• Como sabemos que falhou? Um critério de insucesso definido antes de começar vale mais do que qualquer relatório escrito depois. Sem ele, um piloto nunca falha formalmente: apenas deixa de ser mencionado.

Em que situações é que a IA muda mesmo o resultado de uma organização?

Quando existe um grande volume de julgamento repetido, feito por pessoas experientes, sobre informação que está dispersa mas é acessível. É nesse cruzamento que a IA deixa de ser uma demonstração e passa a ser capacidade instalada.

As três condições contam. O julgamento tem de ser repetido, porque se cada decisão é única não há padrão a captar. As pessoas têm de ser experientes, porque é o critério delas que dá valor ao resultado; sem ele, automatiza-se uma decisão que já era má. E a informação tem de estar dispersa mas acessível, porque o trabalho que a tecnologia poupa é precisamente o de a juntar, e se ela não existe em lado nenhum não há nada para juntar.

Quando as três estão presentes, o efeito é mensurável e mantém-se. Quando falta uma, o piloto funciona em laboratório e desaparece na operação.

Que dados é preciso ter antes de usar IA?

Não é preciso ter dados perfeitos. É preciso ter dados que existam de forma consistente no momento em que a decisão é tomada. A falta de volume raramente é o que trava um projeto; o que trava é cada equipa usar o mesmo campo com significados diferentes, ou o histórico relevante estar guardado em emails e notas soltas.

Há um teste simples para saber se os dados chegam: dar a uma pessoa experiente apenas a informação que o sistema teria e pedir-lhe que tome a decisão. Se ela não conseguir, a IA também não vai conseguir, e o primeiro trabalho é arrumar a informação, não escolher um modelo.

Quanto tempo deve durar um piloto de IA?

O suficiente para cobrir pelo menos um ciclo completo da decisão que se quer mudar, e não mais do que isso. Se a decisão é mensal, o piloto tem de atravessar um fecho de mês; se é diária, umas semanas chegam para perceber se funciona.

Mais importante do que a duração é quem o usa. Um piloto conduzido por uma equipa paralela, longe de quem faz o trabalho, mede a tecnologia e não a operação. Se as pessoas que vão usar a ferramenta no dia a dia não a usarem durante o piloto, o resultado diz pouco sobre o que acontecerá depois. E se um piloto precisa de mais de um trimestre para mostrar alguma coisa, o mais provável é que o âmbito esteja demasiado largo.

Como saber se um problema não precisa de IA nenhuma?

Se a mesma dificuldade desaparecesse com uma regra escrita, uma responsabilidade atribuída ou um campo obrigatório num formulário, então não é um problema de inteligência, é um problema de desenho. Resolvê-lo com IA custa mais, demora mais e deixa a causa intacta por baixo.

Acontece com frequência, e dizê-lo faz parte do trabalho. Dizê-lo a um cliente que já anunciou internamente um projeto de IA é desconfortável. Mas é a única forma de não gastar o orçamento dele naquilo que não vai mudar nada, e de o manter disponível para o que muda.

As perguntas que estamos a investigar

Como se começa um projeto de tecnologia pelo problema, e não pela ferramenta?

Começa-se por uma decisão, não por um sistema. Escolhe-se uma decisão concreta que hoje é tomada com dificuldade, identifica-se quem a toma e descreve-se o que lhe falta nesse momento: informação que não tem, tempo que não tem ou critério que não está escrito em lado nenhum.

Só depois se pergunta que tecnologia fecha essa falta. A resposta pode ser IA, pode ser uma automação simples, e pode ser uma reunião que passa a existir. Nenhuma é mais nobre do que as outras; a que serve é a que muda a decisão.

Não começamos pela tecnologia. Começamos pelo problema. Não por princípio, mas porque é a ordem que dá resultado.