A demonstração sempre funciona: Como diferenciar um sistema de IA verdadeiro de um ensaiado

Leve seus próprios dados

A coisa mais útil que você pode fazer em uma reunião com um fornecedor é pegar o teclado. Entregue ao sistema um documento do seu próprio negócio: um contrato bagunçado, um thread de suporte com três pessoas falando uma sobre a outra, uma fatura do seu fornecedor com o formato mais ruim. Peça para eles rodarem isso ao vivo, sem preparação.

Observe as mudanças. O tempo de resposta, as hesitações, o formato, a confiança da resposta. Um sistema que mantém sua forma em um dado que ninguém preparou já enfrentou o mundo real pelo menos uma vez.

Se o fornecedor recusar, pergunte por quê. "Seus dados não estão carregados no sandbox" é uma resposta justa. Aceite isso, então coloque o teste por escrito como uma condição antes de assinar, com seus arquivos e sua definição do que é um sucesso.

Pergunte o que acontece quando está errado

Ignore a porcentagem de precisão por um momento e pergunte sobre os 8% restantes. Se o sistema acerta 92% das vezes, o que acontece com os outros 8% na visão do usuário? Existem apenas três opções: ele diz que não sabe, escala para uma pessoa ou produz uma resposta confiante errada.

Sistemas que falham de forma barulhenta são fáceis de operar. Sistemas que falham silenciosamente são caros, porque o custo recai sobre o cliente que age com base em informações ruins e o funcionário que gasta uma semana resolvendo tudo.

Então, peça para ver um caso onde o sistema se recusou a responder. Equipes com um produto funcional geralmente mostram esses casos com algum orgulho, pois a moderação é a parte difícil de construir.

Pergunte de onde vem a resposta

Qualquer coisa que toque nos seus próprios materiais - políticas, preços, contratos, especificações de produtos - deve citar sua fonte. Peça uma citação e abra-a. A questão não é se um link apareceu. É se o documento citado realmente diz o que a resposta afirma.

Faça isso duas vezes. Duas verificações te dizem mais sobre um sistema do que uma hora de slides.

Pergunte sobre o dia seguinte aos dados mudarem

As demos rodam em um snapshot congelado. O seu negócio não está congelado. Essas perguntas separam um produto de um protótipo:

Como novas ou corrigidas informações entram, com que frequência e quem é responsável?
Quando um documento é excluído ou substituído, quanto tempo leva até o sistema parar de usá-lo?
O sistema respeita suas permissões existentes, ou todos recebem as mesmas respostas independentemente do papel?
Quando o modelo subjacente muda, você consegue testar antes que chegue aos seus usuários?
Quem está de plantão quando ele quebra às 9h de uma segunda-feira e qual é o tempo de resposta?

Respostas vagas aqui são o sinal mais forte que você receberá durante toda a reunião. Uma equipe que já operou algo em produção passou por todos esses cinco pontos.

Peça números que custam algo para produzir

Porcentagens em um slide são grátis. Peça números com forma: quantos usuários, durante quantos meses, em relação a qual base e quem os mediu? "Resolve 60% dos tickets de primeiro nível" significa pouco até você saber o que os outros 40% custam para redirecionar e se essa figura veio de um piloto com dez pessoas ou de um ano com mil.

Fornecedores bons respondem com especificidades e cautelas. Alguém que já lançou um sistema real sabe exatamente onde ele tem problemas e diz isso sem ser pressionado.

Pergunte o que não pode fazer

Peça ao fornecedor para descrever os casos de uso em que seu sistema é uma má adaptação. Uma equipe confiante terá essa resposta pronta e geralmente é precisa: documentos longos em formato digital, idiomas fora do conjunto de avaliação, qualquer coisa que exija um julgamento com exposição legal.

Uma equipe que diz que lida com tudo está te contando que ainda não rodou o sistema o suficiente para encontrar as bordas. Você encontrará elas em vez disso, depois que o contrato for assinado.

A última pergunta

Antes de sair, pergunte para ver o que um cliente real vê numa terça-feira comum. Não a demo: o painel, os logs, a fila de casos escalonados, o relatório que alguém lê na sexta-feira de manhã. Sistemas reais acumulam essa mobília pouco glamourosa porque alguém teve que operá-los. Uma demo ensaiada não tem terças-feiras.

Sentamos muitas vezes do lado comprador da mesa e o padrão se mantém: os sistemas que sobrevivem a essas perguntas raramente parecem impressionantes em uma demo. Eles parecem chatos, específicos e instrumentados. Isso é como funciona o trabalho.