A conta de um piloto de inteligência artificial parece barata, licença temporária, escopo pequeno, três meses de prazo e uma área disposta a testar. Quando o piloto termina sem virar produção, a leitura mais comum é a de que se perdeu pouco: o custo estava contido, o risco estava isolado, o aprendizado ficou.

O aprendizado raramente fica, o que quase nunca entra na conta é o que a operação gastou para que a demonstração funcionasse. Alguém exportou a base e limpou à mão, alguém padronizou o nome de exame que na rotina aparece com mais de uma grafia e alguém preencheu o campo que o sistema aceita vazio. Esse esforço não aparece em nenhuma linha de orçamento, porque foi feito por gente que já estava na folha, em cima do próprio expediente.

O padrão não é exclusivo da saúde, segundo o levantamento do MIT NANDA, 95% dos projetos de IA generativa falham, e o número costuma ser lido como problema de modelo. Em operação diagnóstica, quase nunca é, o modelo faz o que foi contratado para fazer, o que não existe é a base que ele precisaria consumir todo dia, sem preparo especial, para continuar fazendo.

O piloto que passou no teste errado

Todo piloto responde a uma pergunta, vale conferir qual, um piloto pode provar que o modelo funciona: dado um conjunto de exemplos preparados, o sistema classifica, extrai ou sugere com precisão aceitável. Outro piloto, bem mais raro, prova que a operação alimenta o modelo: no fluxo de rotina, com a equipe de sempre e sem tratamento prévio, o dado chega completo, no formato certo e no momento certo.

Só a segunda pergunta tem relação com produção.

A primeira quase sempre é respondida com sim, é rápida e cabe no trimestre, e por isso é a que se faz. A segunda exige olhar o cadastro, o protocolo, o campo livre onde a atendente escreve o que não coube em lugar nenhum e a lista de exceções que só existe na cabeça de duas pessoas. Não há demonstração possível dessa segunda pergunta: ela só se responde em operação, é por isso que o projeto morre depois do piloto, e não durante.

A conta que ninguém soma

Quando um piloto é encerrado, o custo registrado é o da licença, a conta real tem pelo menos seis linhas.

Horas de operação fora do orçamento
Coordenador, analista e atendente experiente foram deslocados para preparar dado, validar saída e explicar exceção. Nenhuma dessas horas foi debitada do projeto, e todas saíram da capacidade de atender.

O preparo que virou processo paralelo
A extração manual que sustentou a demonstração continua sendo feita à mão enquanto o piloto durar. É trabalho novo, criado pelo projeto, que ninguém dimensionou porque nunca foi chamado de trabalho.

A exceção que voltou para o humano sem virar regra
Todo caso que o modelo não resolveu voltou para a fila de alguém, e voltou sem critério escrito. O atendente decidiu de novo pelo que sabe, e o que ele sabe continuou fora do sistema. O piloto consumiu conhecimento tácito e não converteu nenhum.

O retrabalho de reconciliar
Houve o que o sistema sugeriu e o que a operação de fato fez. Alguém acertou a diferença depois, no cadastro, na agenda ou no faturamento.

A janela de estruturação perdida
Durante o projeto, a operação continuou registrando do jeito antigo. Nenhum campo passou a ser obrigatório, nenhum protocolo foi unificado, nenhuma regra de encaixe foi escrita. No dia em que o piloto termina, a base está onde estava, e o próximo projeto começa do mesmo lugar com um ano a menos.

O crédito interno
É a linha mais cara e a única que orçamento não recupera. A diretoria aprova o primeiro piloto com facilidade, o segundo com desconfiança, e o terceiro já encontra a organização convencida de que “aqui isso não funciona”. A partir daí, a discussão deixa de ser técnica.

Quantas dessas seis linhas entraram na avaliação do último piloto que sua operação encerrou?

A regra que deveria vir antes do piloto

Existe um critério simples e pouco usado: um piloto de IA só deveria ser aprovado quando o dado que ele consome já é produzido pela operação de rotina, no formato de que ele precisa, sem intervenção especial. Se o dado precisou ser preparado para a demonstração, o que foi demonstrado foi o preparo.

Aplicar essa regra costuma adiar o piloto, pois para isso, pode ser necessário ampliar o escopo da solução. Essa é a parte que contraria quem compra tecnologia com o objetivo de obter benefícios rapidamente, e quem vende tecnologia prometendo soluções rápidas sem necessidade de ações estruturantes. Boa parte do que hoje se compra como projeto de IA deveria ser comprado antes como projeto de estruturação de processos e de regras de negócio.

Vale exigir isso do fornecedor, com especificidade, e da área de negócio responsável pela avaliação do projeto, que o piloto rode sobre extração automática do ambiente de rotina, não sobre base preparada, que o critério de sucesso inclua a proporção de casos que a operação conseguiu alimentar sem tratamento manual, que o contrato diga se a regra de negócio explicitada durante o piloto fica na instituição ou vai embora junto com o projeto. Tudo isso força a revisão do escopo do projeto, e pode significar a implantação de soluções mais estruturantes, que, se por um lado vão exigir mais tempo e esforço, por outro vão de fato resolver o problema, e gerar valor real para o negócio.

Onde a base precisa existir antes da IA

Na porta de entrada de uma operação diagnóstica, essa base tem endereço. O WiseTouch é a camada que explicita as regras de negócio do agendamento. Com o WiseTouch, as regras precisam ser estruturadas em sistema. A própria solução exige que a etapa de organização de informações e processos seja feita, pois ela é a base de funcionamento da própria solução. Regras como: sequenciamento de exames com preparos personalizados por paciente, respeito aos prazos de autorização, avaliação de cobertura por local, respeito aos tempos de deslocamento dentro das unidades, controle de encaixes e múltiplos pedidos resolvidos em um único fluxo. É o único sistema que automatiza todas as regras de negócio do agendamento de SADT. É essa explicitação que transforma decisão de atendente em regra de sistema, o pré-requisito de qualquer automação posterior.

Os módulos de autosserviço da jornada digital do WiseTouch são construídos sobre essa base: autoagendamento, leitura de pedidos médicos, leitura automática de carteirinhas, entrega on-line de laudos e imagens, atendimento por WhatsApp e chat com agente de IA, e direcionamento entre a IA e a equipe humana. A IA entra aí sobre processo já estruturado. Assume a carga repetitiva e encaminha para a equipe o que exige julgamento.

Além do benefício do uso da IA, em operações que já rodam esse fluxo estruturado, temos observado redução de até 15% no tempo de visita em agendamentos com múltiplos exames e queda de cerca de 10% em erros e rechamadas no call center. É resultado de porta de entrada organizada, antes de qualquer modelo.