Como identificar um caso de uso de IA que vale a pena

A maioria dos projetos de IA que ficam pelo caminho não falha no modelo. Falha porque o caso de uso estava errado antes de alguém escrever uma linha de código.

O padrão repete-se. Uma empresa escolhe um projeto porque soa bem numa apresentação à administração, constrói durante três meses, faz uma demonstração que arranca aplausos e, pouco depois, arquiva-o em silêncio. O modelo funcionava. O caso de uso não. Os dados não existiam, ninguém era dono do resultado, a tarefa era demasiado rara para fazer diferença, ou uma regra simples teria feito o mesmo trabalho por uma fração do custo.

Este é o erro mais caro na IA aplicada, e acontece antes de o trabalho técnico começar. Escolher o caso de uso certo é mais barato do que qualquer modelo que se construa por cima dele, e determina se o investimento se paga ou se torna uma rubrica que alguém corta no ano seguinte.

Este é um guia prático para essa escolha: os seis pré-requisitos que preveem o impacto, uma grelha de pontuação, dois exemplos práticos e os sinais de fracasso a vigiar.

Porque é que a escolha do caso de uso é o verdadeiro estrangulamento

O modelo raramente é a limitação hoje em dia. Modelos fundacionais, fine-tuning, retrieval, agentes — o conjunto de ferramentas está maduro e mais barato a cada trimestre. O que separa um projeto que entra em produção e poupa dinheiro de um que morre num slide é se o problema era, à partida, adequado à automação.

Pense nisto como um filtro. Entram dezenas de ideias. A maioria deve ser rejeitada depressa e a baixo custo — no papel, numa tarde — para que o esforço de engenharia recaia sobre as poucas que ainda estarão a funcionar daqui a um ano. Os pré-requisitos abaixo são esse filtro.

Os seis pré-requisitos

1. A tarefa é frequente e repetitiva

A IA compensa no volume. Uma tarefa feita 500 vezes por semana tem 500 vezes o retorno de uma tarefa feita uma vez. Se uma pessoa a faz constantemente, com pouca variação, é aí que a automação se acumula. Se acontece duas vezes por trimestre, a construção custará mais do que o tempo que poupa — sempre.

A conta simples: (vezes por semana) × (minutos por vez) × (custo horário carregado) dá a superfície de retorno semanal. Uma tarefa feita 400 vezes por semana, a 6 minutos cada, são 40 horas — uma pessoa a tempo inteiro. Uma tarefa feita 5 vezes por semana a 30 minutos são 2,5 horas; interessante, mas a construção tem de ser barata para a justificar.

• Bom encaixe: classificar e encaminhar 800 pedidos de suporte por dia.
• Mau encaixe: escrever o memorando anual de estratégia. Muito valor, mas acontece uma vez, e o juízo é o ponto central.

Pergunte: com que frequência, e quanto tempo de cada vez? Multiplique. Se o número for pequeno, pare aqui — nenhuma qualidade de modelo compensa uma superfície de retorno fina.

2. Os dados já existem e consegue aceder-lhes

Não há IA sem os dados por baixo. Se responder à tarefa exige informação espalhada por três sistemas que ninguém juntou, ou em PDF que ninguém processou, o verdadeiro projeto é um projeto de dados — e deve ser dimensionado e orçamentado como tal, não descoberto a meio da construção.

Seja específico sobre três coisas: onde vivem os dados, quem lhes pode aceder e em que estado estão. "Está tudo no CRM" não é uma resposta enquanto alguém não confirmar que os campos estão preenchidos, atuais e exportáveis.

• Bom encaixe: os últimos dois anos de faturas, já no sistema de contabilidade, num formato consistente.
• Mau encaixe: "conhecimento tribal" que vive na cabeça das pessoas e num histórico de Slack que ninguém consegue pesquisar.

Pergunte: consegue pôr as mãos numa amostra limpa dos dados exatos de que a tarefa precisa, hoje? Se não, o trabalho de dados vem primeiro.

3. O custo de uma resposta errada é limitado

A IA é probabilística. Vai errar às vezes. A questão é o que acontece quando erra, e se alguém o apanha antes de causar dano.

Uma tarefa em que uma pessoa revê o resultado antes de ser usado, ou em que um erro é barato de notar e reverter, encaixa bem. Uma tarefa em que uma resposta errada move dinheiro, viola uma regra ou chega a um cliente sem revisão, não — pelo menos não sem um controlo à frente.

É também aqui que se decide o nível de autonomia. "A IA propõe, uma pessoa aprova" serve trabalho de risco elevado. "A IA corre sem supervisão" serve trabalho em que os erros são visíveis, baratos e raros. A maioria dos bons primeiros projetos começa em propor-e-aprovar e ganha mais autonomia à medida que a taxa de erro se prova.

Pergunte: qual é o pior que uma resposta errada pode fazer, e quem a apanha antes de ter efeito? Se a resposta for "nada a apanha" e "o dano é grande", o caso de uso precisa de um controlo antes de precisar de um modelo.

4. Há um dono e um processo a melhorar

A IA melhora um processo que já existe. Raramente inventa um bom processo do nada. Os casos de uso que entram em produção têm um dono com nome, que executa o fluxo de trabalho hoje e sente a dor pessoalmente. Os que se desfazem são "da empresa" e não têm ninguém que os defenda.

Este é o pré-requisito que nada tem a ver com tecnologia e que prevê o sucesso melhor do que qualquer outro. Um dono define o que é "bom", fornece exemplos reais, apanha os casos-limite e defende o projeto na altura do orçamento. Sem um dono, a construção fica à deriva.

Pergunte: quem executa este processo hoje, e quer mudá-lo? Se não consegue dar um nome a essa pessoa, ainda não tem um caso de uso — tem uma ideia.

5. Consegue medir o antes e o depois

Se não consegue medir, não consegue provar que resultou, e um projeto que não se prova é cortado na primeira revisão de orçamento. Precisa de uma referência antes de começar: tempo de ciclo, taxa de erro, custo por unidade, horas gastas, dimensão da fila. Algo concreto e atual.

"Vai tornar-nos mais eficientes" não é um número. "O tempo médio de tratamento é de 14 minutos; a fila é de 3 dias" é. A segunda frase permite dizer, três meses depois, exatamente o que mudou — e é essa frase que financia o projeto seguinte.

Pergunte: que número é que isto move, e qual é esse número hoje?

6. Uma regra simples não faria melhor

Este é o pré-requisito que as pessoas saltam, e saltá-lo é o que desperdiça mais dinheiro. Algumas tarefas não precisam de IA — precisam de um script, de um filtro ou de uma regra fixa. Se a lógica é determinística ("encaminha todas as faturas acima de 10 000 € para validação financeira"), escreva a regra. É mais barata, mais rápida, totalmente previsível e nunca inventa.

Recorra à IA quando a tarefa envolve juízo, linguagem natural, imagens ou input desordenado que as regras não captam — ler uma reclamação em texto livre e decidir do que se trata, extrair campos de documentos todos ligeiramente diferentes, redigir uma resposta que encaixa no contexto. O teste honesto: um engenheiro competente resolveria isto com uma semana de código simples e alguns if? Se sim, faça isso.

Pergunte: a parte difícil é o juízo e o input desordenado, ou é só lógica que ninguém escreveu ainda?

Pontue antes de construir

Pegue num candidato e classifique-o de 1 a 5 em cada pré-requisito. Os dois que funcionam como portões — dados e dono — devem pesar mais, porque uma pontuação baixa em qualquer um deles mata o projeto por melhor que tudo o resto pareça.

Pré-requisito	Peso	Pontuação (1–5)
Frequente e repetitiva	×2
Dados existem e acessíveis	×3 (portão)
Custo do erro limitado	×2
Dono claro	×3 (portão)
Referência mensurável	×2
Supera uma regra simples	×1

Um total ponderado é útil, mas os portões prevalecem: se dados ou dono pontuarem 1 ou 2, pare, independentemente da soma. Um caso de uso que pontua alto em entusiasmo e baixo em dados é a armadilha clássica.

Dois exemplos práticos

Candidato A — "Um assistente de IA que responde a qualquer pergunta interna." Frequência: alta. Dados: espalhados por wikis, drives e Slack, nada limpo (portão falha, pontuação 2). Custo do erro: médio. Dono: "toda a gente", logo ninguém (portão falha, 2). Mensurável: vago. Supera uma regra: sim. Veredicto: rejeitar por agora. São duas falhas de portão com um título entusiasmante. O verdadeiro primeiro projeto é pôr o conhecimento num único sítio pesquisável e atual — um projeto de dados.

Candidato B — "Extrair fornecedor, valor e data de vencimento das faturas recebidas e pré-preencher o lançamento." Frequência: 600/semana (forte). Dados: as faturas já chegam por email em PDF, dois anos de histórico (portão passa, 5). Custo do erro: limitado — uma pessoa revê antes de lançar (4). Dono: o responsável de operações financeiras, farto do lançamento manual (portão passa, 5). Mensurável: 6 minutos por fatura hoje, 4% de erros de digitação (5). Supera uma regra: não, os layouts variam demasiado para regras (5). Veredicto: construir. Todos os pré-requisitos verdes, com uma referência clara contra a qual provar o resultado.

A diferença entre A e B não é ambição nem tecnologia. É que B passa nos portões e A não.

Sinais de alerta de que um caso de uso vai falhar

• Sem dono, ou o dono é um comité. Entusiasmo sem uma única pessoa responsável é o indicador mais fiável de um projeto que se desfaz.
• "Tratamos dos dados depois." Os dados são o projeto. "Depois" quer dizer nunca, ou um desvio surpresa de três meses.
• A métrica de sucesso é uma sensação. "Mais eficiente", "melhor experiência", "moderno". Se não se consegue estabelecer uma referência, não se consegue defender.
• Só funciona na demonstração. As demonstrações usam inputs limpos e escolhidos a dedo. Pergunte o que acontece nos 10% de casos reais mais difíceis — é aí que o valor se escapa.
• Uma regra serviria. Se if valor > X resolve, a IA é a resposta cara a uma pergunta barata.
• Âmbito a ferver o oceano. "Automatizar o departamento inteiro" não é um caso de uso. A primeira fatia entregável é que é.

Como conduzimos isto

A maior parte do que fazemos numa discovery sprint é exatamente isto: pegar numa lista curta de casos de uso candidatos, testar cada um contra estes pré-requisitos, pontuá-los e sair com um ou dois que valem a pena construir e uma razão clara para arquivar os restantes. Duas semanas, preço fixo, antes de alguém se comprometer com uma construção. O resultado não é o projeto mais impressionante — é o que ainda estará a funcionar, e ainda a poupar tempo, daqui a um ano.

A tecnologia raramente é a limitação. A escolha de onde a apontar é. Acerte nisso e o resto é engenharia.