Prova de conceito de IA: como testar antes de investir

Escolher um caso pequeno e real

Uma prova de conceito de IA é um teste curto, feito com dado real e com um critério de sucesso escrito antes de começar. A pergunta que ele responde é objetiva: esta IA resolve este caso bem o bastante para valer um projeto? O resultado pode ser seguir, ajustar ou encerrar. Os três são resultados válidos, desde que a decisão venha do critério e não do entusiasmo com a demonstração.

Neste texto, "prova de conceito" quer dizer um teste curto e descartável. "Piloto" é um sinônimo corrente, e usamos os dois. Se você ainda está decidindo o que testar, o texto sobre chatbot ou agente de IA termina recomendando começar por um piloto. Este explica como fazê-lo.

O que torna um caso bom para piloto

Um bom caso tem quatro características:

• Processo repetitivo. Quanto mais vezes a tarefa se repete, mais rápido o teste reúne evidência.
• Entrada e saída definidas. Dá para dizer o que entra (um e-mail, um documento, uma pergunta) e o que deve sair (uma classificação, um resumo, uma resposta).
• Dono identificado. Alguém conhece o processo de ponta a ponta e consegue dizer se o resultado está certo.
• Custo baixo de errar. Se a IA falhar, o prejuízo é pequeno e a correção é simples.

Se uma dessas quatro falta, o piloto tende a gerar discussão em vez de resposta.

O que deixar de fora do primeiro teste

Deixe de fora o que transforma um teste curto em projeto disfarçado:

• Integração ampla. Conectar a IA a vários sistemas já é parte do projeto. No piloto, basta que ela receba os dados e devolva o resultado para alguém conferir.
• Vários processos ao mesmo tempo. Com mais de um, fica impossível saber o que funcionou e o que não funcionou.
• Decisão que afeta direito de pessoa. Conceder, negar ou classificar alguém não é lugar para começar. Nesses casos, a IA no máximo apoia e uma pessoa decide.

A IA que age sobre outros sistemas também fica para depois. O risco de errar uma ação é diferente do risco de errar uma resposta, como detalha o texto sobre chatbot ou agente de IA.

Critério de sucesso definido antes do teste

Sem critério escrito antes, qualquer resultado pode ser defendido depois. Quem gostou da demonstração vai encontrar motivos para seguir. Quem desconfiava vai encontrar motivos para parar. O critério existe para tirar essa disputa da conversa.

Medir contra o que já existe

A linha de base é o processo atual. Antes do teste, registre como a tarefa é feita hoje: quem faz, quanto tempo leva, com que frequência há erro e retrabalho. A IA precisa ser comparada com isso, e não com um ideal.

Não existe número que valha como padrão de mercado para aprovar um piloto. O que serve é o número do seu próprio processo. Um nível de acerto que é suficiente numa tarefa pode ser inaceitável em outra.

Limite de erro aceitável

Toda IA erra. A pergunta é qual erro você tolera e quem corrige.

Defina, por escrito, quais erros são aceitáveis (uma classificação duvidosa que uma pessoa revisa) e quais não são (um dado trocado que segue adiante sem ninguém ver). Defina também quem revisa e em que momento. Um erro tolerável com revisão é um custo conhecido. Um erro tolerável sem revisão é um risco escondido.

Quem assina o critério

Escreva o critério, coloque a data e valide com as pessoas que vão conviver com a decisão:

• o gestor da área, que responde pelo processo;
• a equipe de TI, que avalia o que será preciso para sustentar a solução;
• o jurídico, quando houver questão contratual ou de responsabilidade;
• o encarregado de dados, se o teste envolver dado pessoal.

A data importa. Um critério alterado depois de ver o resultado deixa de ser critério.

Amostra de dados para o piloto

Um piloto vale tanto quanto os dados com que foi testado. A amostra precisa parecer com o dia a dia, e não com o melhor dia.

Dado real, não o dado limpo

É tentador testar com exemplos bem escolhidos, e a demonstração fica ótima. Em produção, porém, chegam o documento digitalizado torto, o campo preenchido errado, a mensagem com erro de digitação, o caso que foge da regra. Se a amostra não tem essas exceções, o resultado do piloto não diz nada sobre o uso real.

Separe a amostra em duas partes. Uma serve para ajustar: é onde a equipe testa instruções, corrige falhas e melhora a configuração. A outra serve para o teste final e não pode ser vista durante os ajustes. Assim como numa prova, quem já conhece as questões não está sendo avaliado. Se você ajusta e mede nos mesmos exemplos, o resultado fica otimista e não se repete depois.

Dado pessoal no piloto

Se a amostra tiver dado de pessoas, trate isso antes do teste, não depois. Três cuidados resumem o ponto de partida:

• use só o dado de que o teste precisa;
• anonimize quando for possível;
• valide o uso com o encarregado de dados.

Um piloto pequeno não dispensa esses cuidados. O texto sobre LGPD no desenvolvimento de software mostra o que levantar antes de especificar.

Do piloto ao projeto, ou ao arquivo

Terminado o teste, a conversa é curta: o resultado atingiu o critério? Quem escreveu o critério antes tem a resposta pronta. Quem não escreveu começa a negociar o que "bom" significa.

Ler o resultado contra o critério

Há três saídas possíveis:

• Seguir. O critério foi atingido, e o caso vira projeto.
• Ajustar e repetir uma vez. O resultado ficou perto, e a causa do desvio é conhecida e corrigível. Repita com o mesmo critério. Repetir mais de uma vez, mudando o critério a cada rodada, é sinal de que a decisão já foi tomada e o teste virou justificativa.
• Encerrar. O critério não foi atingido, ou o custo de chegar lá supera o valor do caso.

Ao virar projeto, o escopo muda. Entram a integração com os sistemas, o monitoramento do que está em produção e a definição de quem responde quando a IA erra. O resultado do piloto também não garante o mesmo desempenho em produção, porque o volume, a variedade de casos e o ritmo de uso são outros. Por isso o projeto precisa de acompanhamento, e não só de implantação. É o tipo de trabalho que cabe em sistemas sob medida, em que a IA passa a fazer parte do fluxo da organização.

Se quiser apoio para o diagnóstico do processo e para montar o piloto, conheça o trabalho de inteligência artificial para empresas.

Encerrar também é resultado

Um piloto encerrado não é um piloto fracassado. Foi uma decisão tomada com evidência e a um custo pequeno, antes de um projeto grande.

O que importa é registrar o aprendizado: o caso testado, o critério, o resultado, o motivo da decisão e o que mudaria a resposta no futuro (um modelo melhor, dados mais organizados, outro processo). Em órgão público, esse registro pode alimentar o estudo técnico preliminar de uma contratação futura.

Antes de começar o seu piloto, confira:

1. O caso é pequeno, repetitivo e tem um dono?
2. A linha de base do processo atual foi registrada?
3. O limite de erro e o responsável pela revisão estão escritos?
4. A amostra tem dado real, com exceções, e está dividida entre ajuste e teste?
5. O critério foi datado e validado por quem decide?

Se você tem um caso concreto em mente, traga-o para a conversa. Ele não precisa estar pronto: o primeiro passo é entender o processo e escolher o que vale testar.