Todo mês o mesmo roteiro acontece em reuniões de empresas brasileiras que investiram em IA nos últimos dois anos. Alguém abre o laptop, mostra um dashboard bonito, demonstra um chatbot que responde bem em casos escolhidos, e conclui que "está funcionando". Três meses depois, a mesma pessoa liga perguntando por que o cliente continua ligando na operadora, a automação caiu de novo ontem e ninguém consegue explicar por que.
O problema raramente está no modelo. Está no fato de que a avaliação do que é "funcionar" foi feita com critério errado. Demo não é prova. Confiança do fornecedor não é prova. Resposta correta em três casos selecionados não é prova.
Este post entrega cinco perguntas em ordem de prioridade. Se sua solução de IA não passa nas cinco, ela vai te custar mais do que te entregou.
Origem das perguntas
As cinco perguntas vêm de um framework interno que usamos para validar todo sistema que construímos, chamado N5. Elas são a versão em linguagem de negócio de critérios mais técnicos (empírico, explanatório, parsimonioso, consistente, lógico). A ordem importa. Aplicar na ordem errada é o que faz empresa gastar meses validando coerência teórica de uma solução que nunca rodou em produção real.
A ordem é: funciona, prediz, é mínimo, é coerente, é perfeito.
1. Funciona?
Esta é a pergunta que mais empresa pula porque é a que parece óbvia.
Funcionar significa: rodou na operação real, com dados reais, por tempo suficiente para cobrir os casos que aparecem na vida da empresa, e o resultado veio. Não "funcionou na demo". Não "funcionou no piloto de três semanas". Não "funciona para esse tipo de caso".
Teste prático: peça ao fornecedor o log bruto dos últimos 30 dias de execução em produção, com os inputs completos e as saídas correspondentes. Se não existe log ou ele não pode ser auditado, a solução não funciona. Funciona é estado observável, não declaração.
Empresas que têm IA rodando sem log auditável não têm IA rodando. Têm uma caixa preta que ocasionalmente produz resultado.
2. Prediz?
Funcionar é necessário. Prever é o que separa sistema de roleta.
Prever significa: você consegue saber, antes de rodar, se o caso X vai dar certo ou vai falhar. Você entende o mecanismo. Você sabe onde estão os limites da solução e consegue explicar para um cliente novo por que funciona neste contexto e pode quebrar no outro.
Teste prático: pergunte ao fornecedor em que tipo de entrada a solução falha previsivelmente. Se a resposta for "em nenhum caso que testamos", a solução não prevê. Prever exige conhecer os limites, não ignorá-los. Quem não sabe onde o próprio sistema falha está operando fora do regime da engenharia.
A diferença prática entre funcionar e prever é a diferença entre atender bem por dois meses e atender bem por dois anos. Solução que funciona mas não prevê vai te surpreender no pior momento possível.
3. É mínimo?
Esta pergunta elimina metade das soluções que passaram nas duas primeiras.
Mínimo significa: toda peça do sistema está ali porque remover quebra alguma coisa. Se você puder tirar um módulo, um pipeline, um passo da automação, e nada acontecer de ruim, esse pedaço não deveria estar lá. Complexidade desnecessária é custo sem contrapartida, tanto em manutenção quanto em probabilidade de falha.
Teste prático: peça um desenho de fluxo com cada componente e pergunte, componente por componente, qual o efeito de remover. Se o fornecedor hesita em mais de um, há gordura. Solução inchada é solução que alguém construiu sem saber exatamente o que cada peça resolvia.
A regra interna que usamos é de dez por cento. Se ao tirar um componente você precisa restaurar dez por cento do que tirou, o componente é essencial. Se restaura noventa por cento, o componente estava lá por hábito, não por necessidade.
4. É coerente?
Coerência vem depois de funcionar, prever e ser mínimo. Não antes. Muita empresa trava no debate de arquitetura elegante antes de ter algo rodando em produção. É inversão de prioridade.
Coerente significa: as partes do sistema falam a mesma língua, usam os mesmos conceitos, obedecem às mesmas regras de negócio. Se o módulo de cobrança chama o cliente de "usuário" e o módulo de suporte chama de "contato", você tem dois sistemas fingindo ser um. Vai dar problema.
Teste prático: peça ao fornecedor a lista de entidades que o sistema reconhece (cliente, pedido, contrato, lead) e verifique se a definição é a mesma em todos os pontos da solução. Se um pedido em cobrança é diferente de um pedido em logística, há débito semântico. Esse débito vira bug em produção.
Coerência é o que permite o sistema crescer sem virar espaguete. Sem ela, cada funcionalidade nova custa o dobro da anterior.
5. É perfeito?
Perfeito não significa sem erro. Significa sem contradição interna. As premissas levam à conclusão sem atalho. Não há regra que diga uma coisa num lugar e o oposto em outro. Não há exceção não documentada que só o desenvolvedor original entende.
Esta é a última pergunta porque ela é a mais cara de responder e a menos urgente no começo. Uma solução que funciona, prevê, é mínima e é coerente, mas tem uma contradição lógica remota, ainda é melhor que uma solução logicamente perfeita que nunca rodou.
Teste prático: peça a documentação de regras de negócio do sistema e procure conflitos. "O preço é definido pela tabela X, exceto para clientes Y, exceto em feriados, exceto quando..." é sinal de que a lógica não foi reconciliada. Cada "exceto" não documentado é uma bomba relógio.
Perfeição vem no final porque só vale a pena reconciliar lógica de algo que já provou valor no mundo real.
Checklist para sua próxima reunião com fornecedor de IA
Use estas cinco perguntas na ordem, em qualquer reunião de avaliação:
- Mostre o log bruto de 30 dias em produção
- Em que tipo de entrada sua solução falha previsivelmente
- Para cada componente, qual o efeito de remover
- As entidades do sistema são definidas da mesma forma em todos os módulos
- Quais contradições conhecidas existem na documentação de regras
Se o fornecedor trava em qualquer das três primeiras, a conversa acabou. Se trava nas duas últimas mas passou nas três primeiras, há trabalho de refinamento, mas o núcleo está sólido.
Por que este método ancora em Ontologia Operacional
O que chamamos de Ontologia Operacional é exatamente isso: um sistema que passa nas cinco perguntas por construção, não por sorte. Pin e Spec (as duas camadas de regras de um projeto) garantem que a solução funcione em operação real com log auditável. A tríade Dados, Lógica e Ação garante que cada decisão seja previsível, mínima, coerente e lógica.
Não é ferramenta. É método. E é o que permite construir IA que não quebra no terceiro mês.
Se você está avaliando uma solução de IA e as cinco perguntas acima te deixaram desconfortável, envie uma mensagem para contato@fstech.digital. A primeira conversa existe só para mapear os pontos da operação em que os critérios não estão sendo cumpridos. Decisão sobre próximos passos vem depois, com dado em mão.
