Demonstração não é processo: o que um piloto de IA precisa provar
Uma demonstração não prova que o processo melhora. Veja como definir o que um piloto de IA precisa provar antes de construir.
Mauricio Zaffari
Você assistiu a uma demonstração de IA. Ela leu um PDF, extraiu os campos e preencheu a tela com o resultado em segundos. A decisão na sua frente agora é concreta: comprometer orçamento para construir, ou encomendar antes algo que prove que o processo realmente melhora.
Não comprometa o orçamento de construção só com a demonstração. Defina antes os critérios do piloto e use um exemplo de extração de documentos para testar as decisões de continuar, ajustar ou parar.
O que a demonstração vale como evidência
Uma demo roda sobre um conjunto pequeno de casos preparados. Quem apresenta escolhe os arquivos que representam melhor o modelo, o ambiente está limpo e o resultado aparece em segundos. Isso responde a uma pergunta: o modelo consegue produzir a saída esperada em um exemplo escolhido. É evidência útil sobre a tecnologia, mas não prova o desempenho no processo real.
O que a demo deixa de fora é justamente o que decide a sua construção:
- a qualidade dos arquivos que chegam de verdade;
- a variação entre fornecedores e formatos;
- o esforço de integração com o ERP ou o banco de dados;
- o volume diário;
- o custo de um erro;
- e quem revisa o que a máquina não resolve.
No exemplo de documentos, uma demo mostra um PDF limpo lido corretamente. A sua operação pergunta o que acontece com um documento digitalizado torto, um campo em branco, um valor que não bate com o pedido. A demo não responde isso, e nenhum aplauso responde.
Os critérios: o que o piloto precisa provar
Um piloto testa um fluxo delimitado com dados, usuários e critérios definidos antes da construção. Para a extração de documentos, as perguntas viram números que o negócio define, não a tecnologia:
- quais campos precisam ser extraídos e com que nível de acerto aceitável, campo por campo;
- qual volume de documentos o fluxo precisa processar em um dia;
- quanto tempo o processo leva hoje e quanto deveria levar;
- e como as divergências são encaminhadas para conferência.
Um nível de acerto aceitável depende do custo de um erro naquele campo. Um campo que decide um pagamento tem exigência diferente de um campo usado apenas para relatório. O diagnóstico costuma ser planejado para 2 a 3 semanas. É a etapa em que esses critérios, os dados e o escopo são organizados antes de qualquer construção. Compare o acerto por campo, o tempo total e o volume de divergências encaminhadas à revisão com o processo atual.
Definir os critérios antes impede que eles sejam ajustados ao resultado da ferramenta. Critério definido depois do resultado vira justificativa, não medição.
Demo ou piloto: a comparação
Lado a lado, no exemplo de documentos, as duas opções respondem perguntas diferentes e expõem riscos diferentes:
| Dimensão | Demonstração | Piloto |
|---|---|---|
| Pergunta respondida | O modelo consegue fazer em um exemplo escolhido? | O processo melhora com dados reais e exceções? |
| Dados | Casos preparados, escolhidos por quem apresenta | Arquivos reais da operação, em um período definido |
| Volume | Alguns exemplos ideais | Volume diário, com digitalizações tortas incluídas |
| Exceções | Fora da pauta | Encaminhadas para uma fila de revisão com responsável |
| Custo de errar | Um projeto construído sobre uma premissa não testada | Um período medido, com critérios para parar |
O piloto costuma ser estimado em 4 a 6 semanas após a definição do escopo, condicionado à disponibilidade de acessos, dados e responsáveis. Isso compra a resposta que a demo não dá.
Quando construir direto após a demo pode ser aceitável
Construir direto pode fazer sentido se:
- o fluxo é pequeno, barato de construir e totalmente reversível;
- uma pessoa confere a saída antes que um erro afete o processo;
- e o volume é baixo o suficiente para que a revisão manual cubra tudo.
Repare que são condições sobre consequência, não sobre o modelo. Quando o pior caso é barato, o critério de evidência desce. Quando uma saída errada libera um pagamento, toca um contrato ou alimenta um registro de conformidade, exija validação controlada antes de ampliar o investimento.
Escalar, ajustar ou parar
No exemplo de documentos, um campo em branco ou um valor divergente do pedido deve ir à revisão. Se os documentos digitalizados não permitirem extrair os campos necessários, ajuste os dados e teste novamente; se nem assim os critérios definidos forem atingidos, pare antes de ampliar o fluxo.
Ao fim do piloto, os resultados observados são comparados com os critérios definidos no início. A comparação produz uma decisão com três saídas, e todas são legítimas:
flowchart TD
A["Critérios definidos antes"] --> B["Executar o piloto"]
B --> C["Medir contra os critérios"]
C --> D{Resultado vs critério?}
D -- atingido --> E["Escalar"]
D -- novo teste justificado --> F["Ajustar escopo ou dados"]
D -- abaixo --> G["Parar"]
Escale quando o resultado observado atende os critérios e as dependências, como acessos, dados e usuários, estão resolvidas. Ajuste quando os critérios não forem atingidos, mas uma mudança documentada no escopo ou nos dados justificar um novo teste. Pare quando o processo não se mostrou adequado, os dados não sustentam o fluxo ou o benefício não aparece. Parar cedo custa menos que escalar no escuro, e um piloto tratado como pergunta torna essa saída possível sem drama.
Em resumo
A demonstração mostrou um resultado em um exemplo escolhido; o piloto testa o processo com dados e exceções reais. A decisão é se o seu processo melhora com ela, e essa é uma pergunta que o piloto responde com números definidos antes: campos, acerto por campo, volume, tempo e rota das exceções. Construa direto após a demo somente quando uma saída errada é barata e reversível. Caso contrário, execute o piloto, meça contra os critérios e escolha entre escalar, ajustar ou parar.
Leitura relacionada: Como identificar onde a IA faz sentido na sua operação.
Quer definir o que um piloto precisa provar na sua operação? Solicitar diagnóstico