Quando acrescentar funcionalidades de IA à sua aplicação — e quando dispensá-las

Neste momento há uma pressão silenciosa sobre cada responsável de produto para aparafusar IA a tudo o que esteja a construir. Os investidores perguntam por ela. Os concorrentes põem-na nos títulos. Um membro do conselho reenvia um artigo. E assim uma aplicação perfeitamente boa ganha um pequeno ícone cintilante e uma janela de conversação que ninguém pediu e que quase ninguém usa. A funcionalidade é lançada, sai o comunicado de imprensa e, seis meses depois, os gráficos de utilização estão planos. A questão nunca foi se <em>conseguia</em> acrescentar IA. Era se devia fazê-lo.

Desenvolvo software e funcionalidades de IA para pequenas e médias empresas, o que significa que tenho um incentivo financeiro para lhe dizer que junte IA a tudo. Vou fazer o contrário. A coisa mais valiosa que lhe posso oferecer é uma forma de saber — antes de comprometer orçamento — se uma funcionalidade de IA vai carregar o seu peso em silêncio ou apodrecer em silêncio. Porque aqui o fracasso não é dramático. As funcionalidades de IA raramente explodem. Ficam simplesmente ali, sem uso e sem afeto, custando-lhe dinheiro a cada chamada de API e um pouco de credibilidade sempre que um utilizador lhe mexe e segue caminho.

Este guia é o esquema que uso de facto nessas conversas. Sem palavras da moda, sem nomes de modelos na berra, sem fingir que um modelo de linguagem é a resposta a uma pergunta que ainda não fez. Apenas uma forma prática de decidir o que pertence à sua app, o que pertence ao código simples e o que pertence ao caixote do lixo.

Porque é que a maioria das IA aparafusadas falha em silêncio

Quando uma funcionalidade de IA fracassa num produto pequeno, quase nunca é porque o modelo não era suficientemente esperto. Fracassa porque a funcionalidade foi escolhida pelas razões erradas. Alguém quis ter IA, em vez de querer resolver algo concreto e doloroso que por acaso precisava de IA. A tecnologia era o objetivo, e o problema do utilizador um pensamento posterior. Os utilizadores cheiram isso de imediato.

O segundo fracasso comum é mais subtil: a funcionalidade resolve um problema real, mas um problema que o código simples teria resolvido de forma mais barata e fiável. Um botão com a etiqueta «com IA» que apenas ordena uma lista por data é um peso morto, não uma funcionalidade. Pegou em algo determinístico, tornou-o mais lento, mais caro e por vezes errado, e depois anunciou a degradação. Também isso os utilizadores reparam.

O terceiro fracasso é a confiança. As funcionalidades de IA são probabilísticas: acertam na maioria das vezes e erram com aprumo algumas vezes. Se largar uma num fluxo onde uma resposta errada sai cara e o utilizador não tem como a apanhar, não acrescentou uma funcionalidade, colocou uma mina. A boa notícia é que os três modos de fracasso são previsíveis, o que significa que são evitáveis. Basta fazer as perguntas certas antes de começar, e não depois de lançar.

O teste honesto: isto é mesmo um problema de IA?

Eis o filtro mais útil que conheço. Para qualquer funcionalidade que esteja tentado a tornar «inteligente», pergunte: esta tarefa segue regras fixas ou exige compreender uma entrada humana e desarrumada? Se a tarefa segue regras — ordena por isto, calcula aquilo, envia um lembrete duas horas antes —, quer código simples. É mais barato, mais rápido, totalmente previsível e nunca alucina. Chamar-lhe IA é apenas marketing caro.

A IA merece o seu lugar onde a entrada é mesmo desarrumada e de feitio humano: texto livre que as regras não conseguem antecipar, imagens, fala, documentos em cem disposições diferentes, linguagem que tem de ser compreendida em vez de comparada. São as coisas que antes era impossível automatizar de todo. Se a sua funcionalidade vive aí, a IA não é um truque — é a única forma prática de a construir. A perícia está em distinguir honestamente as duas categorias, sobretudo quando há pressão para chamar IA a tudo.

Onde a IA pertence mesmo a uma app

Sejamos concretos. Ao fim de anos a construir estas coisas, uma curta lista de padrões continua a provar o seu valor — não por estarem na moda, mas porque a tarefa subjacente é mesmo sobre compreender entrada não estruturada. São as funcionalidades a que os utilizadores voltam de facto.

• Transformar texto livre em dados estruturados — ler um e-mail desconexo de um cliente e dele extrair a encomenda, a morada, o prazo.
• Redigir uma primeira versão — uma resposta, um resumo, uma descrição — que uma pessoa depois edita, em vez de a IA a enviar sem supervisão.
• Uma pesquisa que entende o significado, não só as palavras-chave, para que os utilizadores encontrem o documento certo mesmo quando o formulam de forma diferente de como o arquivou.
• Classificar ou encaminhar uma enxurrada de elementos que entram — pedidos de apoio, e-mails, carregamentos — para que cada coisa chegue ao sítio certo.
• Extrair informação de documentos e imagens: faturas, recibos, formulários, fotografias tiradas no terreno.
• Ajuda conversacional sobre os seus próprios dados, em que o utilizador faz uma pergunta simples e obtém uma resposta ancorada no seu conteúdo.

Repare no padrão. Em cada um destes casos, a entrada é imprevisível e humana, e um pequeno grau de erro é tolerável porque há uma pessoa no circuito ou o custo de uma falha é baixo. Essa combinação — entrada desarrumada, riscos indulgentes — é a casa natural de uma funcionalidade de IA. Quando encontra uma tarefa que encaixa em ambas as metades, provavelmente encontrou uma funcionalidade que vale a pena construir.

Onde mais vale deixar a IA em paz

Igualmente importante é saber onde não recorrer à IA, porque a colocação errada não desperdiça apenas dinheiro — corrói ativamente a confiança que o seu produto conquistou. Algumas tarefas parecem tentadoras e revelam-se armadilhas.

Há também um custo mais discreto. Cada funcionalidade de IA é agora algo que tem de monitorizar, avaliar e pagar a cada chamada. Três funcionalidades de IA em que os seus utilizadores confiam valem mais do que dez que de vez em quando o envergonham. Um modelo que erra à frente de um cliente no momento errado pode desfazer um ano de credibilidade cuidadosamente construída. A contenção aqui não é timidez — é tino de produto.

Um mapa rápido: construir, dispensar ou fazer mais tarde

Para tornar isto menos abstrato, eis como um punhado de ideias comuns do tipo «vamos juntar IA» tende a cair quando as passa pelo teste acima. Encare-o como um ponto de partida sensato para contestar, não como evangelho.

A forma da tabela é a lição. Os sins agrupam-se onde a entrada é desarrumada e os riscos são indulgentes. Os nãos agrupam-se onde a tarefa é mesmo baseada em regras, ou onde uma resposta errada dói e ninguém verifica. Se conseguir colocar a sua ideia nessa grelha com honestidade, já tomou a maior parte da decisão.

Momento: até uma boa funcionalidade de IA pode ser acrescentada cedo demais

Por vezes a funcionalidade encaixa mesmo e a resposta continua a ser ainda não. As funcionalidades de IA têm um pré-requisito traiçoeiro que os fundadores subestimam: só são tão boas quanto os dados e o fluxo de trabalho sobre os quais assentam. Uma pesquisa semântica sobre os seus documentos é maravilhosa — depois de os seus documentos estarem mesmo organizados. Um assistente que responde a perguntas sobre o seu produto é brilhante — depois de o conteúdo do seu produto deixar de ser uma confusão contraditória. A IA amplifica tudo aquilo sobre que é construída, o caos incluído.

Por isso, antes de acrescentar a camada engenhosa, garanta que a camada aborrecida por baixo é sólida. Se a sua app principal ainda está a encontrar os seus pés, despejar tempo de engenharia numa funcionalidade de IA é, normalmente, pedir emprestado da conta errada. A verdade pouco glamorosa é que a melhor altura para juntar IA é muitas vezes depois de ter os fundamentos consolidados — quando tem utilizadores reais, dados reais e uma dor clara e repetitiva que a IA está em posição única para eliminar.

Como acrescentar uma funcionalidade de IA sem arrependimentos

Digamos que encontrou uma funcionalidade que passa no teste: entrada desarrumada, riscos indulgentes, alicerce sólido por baixo, uma dor real a eliminar. Ótimo. Vem agora a parte em que as equipas constroem algo duradouro ou algo que vão arrancar em silêncio para o ano. Trate-a como uma experiência cuidadosa, não como um lançamento.

1. 1
   Escreva a tarefa numa só frase

   «O assistente lê um e-mail recebido e preenche o formulário de encomenda, que uma pessoa confirma.» Se não conseguir escrever essa frase, a funcionalidade não está pronta — continua apaixonado pela tecnologia, não pela tarefa.
2. 2
   No início, mantenha uma pessoa no circuito

   Deixe a IA redigir, sugerir ou pré-preencher — e deixe uma pessoa aprovar. Vai aprender onde ela é fiável e onde não é antes sequer de lhe confiar agir sozinha, se alguma vez o fizer.
3. 3
   Decida o que acontece quando ela erra

   As funcionalidades probabilísticas precisam de uma falha airosa. Como é que o utilizador repara? Como é que corrige? Uma funcionalidade de IA sem um «anular» ou um «isto não está certo» visível é uma funcionalidade em que não pode confiar em produção.
4. 4
   Meça a utilização, não a novidade

   Acompanhe se as pessoas a usam mesmo depois da primeira semana, e se poupa o tempo que prometeu. Uma funcionalidade que dispara no lançamento e estabiliza a zero depois está a dizer-lhe algo. Oiça.
5. 5
   Esteja disposto a removê-la

   Se os números disserem que não merece o lugar, corte-a. Um produto mais pequeno que faz poucas coisas de forma fiável bate um inchado, cravejado de funcionalidades de IA em que ninguém toca.

O fio que percorre os cinco passos é a humildade perante o erro. O código simples ou funciona ou tem um bug que se corrige. A IA acerta na maioria das vezes e erra algumas, para sempre — é a sua natureza, não um defeito que se remenda. Desenhe a funcionalidade em torno dessa realidade e ela torna-se um trunfo. Finja que a IA está sempre certa e construiu a mina de que falámos atrás.

O quadro mais amplo: a IA é uma ferramenta, não uma estratégia

Recue o suficiente e toda a questão fica mais simples. A IA é uma ferramenta, tal como uma base de dados ou uma barra de pesquisa são ferramentas. Não se constrói um produto à volta de ter uma base de dados; usa-se uma base de dados onde ela torna o produto melhor. A mesma contenção serve-o bem aqui. As empresas que tiram valor real da IA não são as que juntaram mais — são as que a juntaram exatamente nos poucos sítios onde ela elimina um atrito genuíno, e resistiram em todos os outros.

Essa contenção é também, já agora, o que torna impressionante a IA que de facto junta. Quando cada ecrã tem um assistente meio cozido, nenhum parece especial. Quando uma funcionalidade lê em silêncio o e-mail de um cliente e poupa dez minutos à sua equipa de cada vez, as pessoas lembram-se. Menos, mais afiada, genuinamente útil — é essa a versão da IA que vale a pena construir, e a versão pela qual os seus utilizadores lhe vão mesmo agradecer.

Perguntas frequentes