Fit for Purpose: como saber se a sua IA serve para alguma coisa

A maioria dos sistemas de IA que morrem em produção não morre por ser tecnicamente ruim. Morre porque ninguém, em momento nenhum, escreveu o que seria "bom o suficiente". O modelo entrega 82% de acerto, isso é sucesso ou fracasso? Responde em três segundos, rápido ou lento? Sem um critério definido antes, a resposta vira opinião, e opinião não sustenta um sistema rodando todo dia. O método que resolve isso não nasceu na IA. Nasceu na gestão de serviços, e se chama Fit for Purpose.

O que é Fit for Purpose

A ideia foi popularizada por David J. Anderson, o mesmo nome por trás do método Kanban, no livro Fit for Purpose. A tese é desconfortavelmente simples: a qualidade de um serviço não se mede pela sua elegância interna, e sim por uma única pergunta. Ele atende ao propósito de quem o usa? Um carro de luxo é um péssimo serviço se o seu propósito é estacionar num centro histórico apertado. Um modelo de IA topo de benchmark é um péssimo sistema se o seu propósito é responder em 200 milissegundos e ele leva dois segundos.

O deslocamento é do produto para o propósito. Você para de perguntar "quão bom é o meu modelo?" e passa a perguntar "bom para quê, para quem, e segundo qual critério?". Essa virada parece óbvia escrita assim, mas quase nenhum projeto de IA a faz antes de começar. Compra-se o modelo, monta-se a demo, e só lá na frente, quando o usuário reclama, alguém descobre que "bom o suficiente" significava algo que nunca foi acordado.

Critérios de aptidão aplicados a IA

O coração do método são os fitness criteria: as poucas métricas que, do ponto de vista do cliente, definem se o serviço serve. Anderson observa que clientes não avaliam um serviço por uma lista infinita de atributos, eles têm um punhado de critérios que realmente importam, e o resto é ruído. O trabalho é descobrir quais são esses poucos, e onde fica a linha entre aceitável e inaceitável.

Para um sistema de IA em produção, esses critérios costumam morar em quatro eixos:

• Precisão mínima aceitável. Não a precisão média do paper, e sim o piso abaixo do qual o sistema causa mais dano que valor. Para uma triagem de spam, 95% pode ser ótimo; para uma sugestão de dosagem clínica, 99% é catastrófico.
• Latência tolerável. O tempo máximo de resposta que o uso real comporta. Um assistente de chat e um sistema de detecção de fraude em tempo real vivem em mundos diferentes.
• Custo por chamada. O quanto cada inferência pode custar para o caso ainda fazer sentido econômico. Um modelo brilhante e caro demais por transação é inapto, por definição.
• Taxa de escalonamento. Com que frequência é aceitável que o sistema diga "não sei, passa para um humano". Esse número não é fraqueza, é um critério de design.

A diferença entre um projeto sério e um teatro de inovação está em quando esses números são definidos. No projeto sério, eles vêm antes, são o contrato que a solução tem de cumprir. No teatro, eles aparecem depois, espremidos para justificar o que já foi construído.

Classes de serviço: nem tudo merece o mesmo rigor

O segundo conceito útil de Anderson é o de classes de serviço. Nem toda demanda tem a mesma urgência ou o mesmo custo de atraso. Um pedido padrão, um item acelerado, uma obrigação com data fixa e uma emergência são tratados de formas diferentes, e tentar dar a todos o mesmo tratamento é como tratar todo paciente do hospital como se estivesse infartando.

Traduzido para uma operação de IA, isso vira uma pergunta de portfólio: quais casos de uso merecem o modelo mais caro e o monitoramento mais rigoroso, e quais podem rodar com algo mais simples e barato? Atendimento de baixo risco e alto volume talvez tolere um modelo menor e uma taxa de erro maior. Uma decisão de crédito ou um resumo que vai para um cliente paga o custo do rigor. Definir classes de serviço impede os dois erros simétricos: gastar demais protegendo o que não importa, e gastar de menos no que importa.

Como aplicar em quatro passos

Na prática, dá para transformar isso num ritual leve antes de qualquer implantação. Primeiro, escreva o propósito em uma frase, do ponto de vista de quem usa, não "implantar um chatbot", e sim "responder dúvidas de cobrança sem fila e sem erro de valor". Segundo, derive os critérios de aptidão: os quatro eixos acima, com um número em cada e a linha do aceitável. Terceiro, defina a classe de serviço desse caso, qual o custo de um erro, qual a urgência, e calibre o rigor a partir daí. Quarto, meça contra os critérios, não contra o benchmark: o painel de produção acompanha precisão real, latência real, custo real e taxa de escalonamento real, e dispara quando qualquer um cruza a linha.

Um sistema de IA sem critérios de aptidão definidos não é um sistema, é uma demo que ainda não sabe que vai falhar.

Esse é o elo que conecta Fit for Purpose a tudo o que separa um piloto de uma operação. É a mesma razão pela qual escolher um modelo pelo placar mais alto é um erro: o benchmark mede uma média genérica, não a aptidão ao seu propósito, algo que fica evidente quando se compara modelos abertos e fechados pelo critério certo. E é parte do que faz a diferença entre um piloto bonito e um sistema que aguenta segunda-feira de manhã: a disciplina de dizer, antes de subir, o que "funcionar" significa.

Se a sua equipe está prestes a colocar um sistema de IA no ar sem ter escrito os critérios de aptidão dele, vale meia hora de conversa pelo WhatsApp antes do deploy. Definir isso cedo custa uma reunião; descobrir tarde custa o projeto.