Seleção de Casos de Uso

O que “Seleção de Casos de Uso” significa em produtos de IA

Seleção de casos de uso é a disciplina de decidir onde a IA melhora significativamente os resultados, onde ela adiciona custo e risco sem benefício e quais oportunidades perseguir primeiro. Na prática, ela fica na interseção entre estratégia de produto, viabilidade de engenharia e mudança organizacional.

Um bom caso de uso de IA não é “podemos aplicar aprendizado de máquina (machine learning) aqui”, mas:

  • Um problema real de usuário ou de negócio com valor mensurável
  • Uma decisão ou fluxo de trabalho em que previsões, ranqueamentos ou geração de conteúdo melhores mudam resultados
  • Uma configuração de aprendizado viável (dados, ciclos de feedback, avaliação, restrições de implantação)
  • Uma postura de risco e um plano de contingência alinhados com como erros afetam os usuários

A seleção de casos de uso se conecta diretamente a:

Onde a IA ajuda (e por quê)

A IA é mais valiosa quando o problema tem padrões complexos difíceis de codificar manualmente, e quando a saída pode ser avaliada e melhorada ao longo do tempo.

A IA se destaca quando existem padrões e regras não escalam

A IA brilha quando:

  • O mapeamento de entrada → saída é confuso (messy) ou de alta dimensionalidade
    Exemplos: linguagem natural, imagens, áudio, sequências de comportamento do usuário.
  • Regras seriam frágeis (brittle) ou caras de manter
    Exemplo: detecção de spam evolui continuamente; adversários se adaptam.
  • Você consegue aprender com resultados históricos
    Exemplo: quais leads convertem, quais sinistros são fraudulentos.
  • “Bom o suficiente” tem valor e erros são toleráveis com proteções (guardrails)
    Exemplo: sugerir respostas de e-mail que o usuário edita (aumentação).
  • Personalização importa
    Exemplo: sistemas de recomendação e ranqueamento que se adaptam por usuário.

Em termos de aprendizado de máquina, esses são cenários em que é plausível aprender uma função ( f(x) ) que generaliza a partir dos dados, tipicamente usando Aprendizado Supervisionado, Aprendizado Auto-Supervisionado ou Aprendizado por Reforço, dependendo do feedback.

Arquétipos comuns de casos de uso de IA

Uma forma útil de selecionar casos de uso é combinar problemas com arquétipos de tarefas de IA — cada um com padrões conhecidos de avaliação e modos de falha.

  1. Classificação (escolher um rótulo)

    • Exemplos: fraude vs não fraude, tóxico vs seguro, categoria de bug
    • Métricas típicas: precisão/recall, ROC-AUC, erro ponderado por custo

  2. Regressão / Estimação (prever um número)

    • Exemplos: tempo de entrega, probabilidade de churn, custo de sinistro
    • Métricas: MAE/RMSE, calibração, curvas de custo de negócio

  3. Ranqueamento / Recomendação (ordenar itens)

    • Exemplos: ranqueamento de busca, ordenação de feed, “próxima melhor ação”
    • Métricas: NDCG, MAP, CTR, retenção de longo prazo

  4. Previsão (prever séries temporais futuras)

    • Exemplos: planejamento de demanda, previsão de capacidade
    • Métricas: MAPE/MASE, cobertura de intervalos, custo de ruptura de estoque

  5. Detecção de anomalias (encontrar desvios raros)

    • Exemplos: alertas de segurança, defeitos de manufatura
    • Métricas: precisão em K, fadiga de alertas, tempo de investigação

  6. Extração de informações (converter não estruturado → estruturado)

    • Exemplos: campos de fatura, codificação médica, extração de cláusulas de contratos
    • Métricas: acurácia por campo, distância de edição, tempo de correção humana

  7. Geração (produzir texto/código/imagens) usando Modelos de Linguagem Grandes (Large Language Models)

Um caso de uso forte se encaixa claramente em um (ou em um pequeno número) desses arquétipos e tem um plano de avaliação mais concreto do que “parece bom”.

A IA é especialmente eficaz para “aumentação” antes de “automação”

Muitas organizações obtêm ganhos mais rápidos usando IA para assistir humanos antes de tentar automação total:

  • Sugerir, triar, resumir, extrair, recomendar
  • Manter um humano “no loop” para aprovações e casos de borda
  • Usar as correções humanas como dados de treino/feedback (quando apropriado)

Isso reduz risco e frequentemente melhora a adoção, porque a IA é apresentada como uma ferramenta de produtividade, e não como substituição.

Onde a IA não ajuda (ou é uma má primeira escolha)

IA não é um martelo universal. Ela pode ser a abordagem errada por razões técnicas, econômicas ou organizacionais.

1) Problemas que já são bem resolvidos com regras ou software padrão

Se a lógica é estável, de baixa dimensionalidade e fácil de especificar, software tradicional costuma ser melhor:

  • Cálculo de impostos com base em regras publicadas
  • Fórmulas determinísticas de precificação
  • Validação de dados com restrições claras (“deve ser uma data ISO válida”)

Uma boa heurística: se você consegue escrever regras corretas em poucas páginas e elas não vão mudar semanalmente, IA pode ser desnecessária.

2) Decisões de alto risco com baixa tolerância a erros e supervisão fraca

Se erros causam dano severo e você não consegue detectar erros de forma confiável:

  • Diagnóstico médico sem revisão de um clínico
  • Orientação jurídica apresentada como autoritativa
  • Sistemas de controle críticos à segurança sem verificação formal

Ainda é possível usar IA, mas muitas vezes em um papel restrito (por exemplo, sinalizar casos para revisão de especialistas) com governança forte, auditabilidade e Modos de Falha & UX de Fallback.

3) Problemas “sem sinal”: dados são escassos, rótulos são pouco confiáveis, ou resultados não são aprendíveis

Modos de falha comuns:

  • Você tem poucos exemplos do evento raro que importa (por exemplo, falhas catastróficas)
  • Rótulos são inconsistentes (“fraude” tem definições diferentes entre equipes)
  • O ambiente muda rapidamente (deriva de conceito) e você não consegue retreinar rápido o suficiente
  • O alvo é inerentemente ruidoso ou ambíguo (baixa concordância até entre especialistas)

Quando a qualidade do rótulo é o gargalo, investir em mensuração e processo muitas vezes é melhor do que investir em um modelo maior.

4) Previsões que não mudam decisões

Um modelo pode ser preciso e ainda assim inútil se ninguém conseguir agir com base nele.

Exemplo: um modelo de churn que prevê churn, mas o negócio não tem alavancas de retenção, ou as intervenções são caras demais para aplicar. Uma boa seleção de casos de uso pergunta: Qual decisão vai mudar? e Qual ação se segue?

5) Custos ocultos superam benefícios

IA introduz custos contínuos:

  • Pipelines de dados, monitoramento, retreinamento, infraestrutura de avaliação (MLOps)
  • Custos de computação e latência (especialmente para modelos grandes)
  • Revisões de segurança, privacidade e compliance
  • Operações humanas: rotulagem, filas de revisão, escalonamento de suporte

Se um caso de uso economiza 30 segundos por semana por funcionário, mas exige uma equipe em tempo integral para manter, não é uma boa troca — a menos que seja estratégico de outras formas (por exemplo, habilitar uma nova linha de produto).

Um framework prático para selecionar casos de uso de IA

Um framework útil é avaliar cada candidato em Valor, Viabilidade e Risco, partindo do problema do usuário, e não do modelo.

Etapa 1: Comece com uma tarefa concreta do usuário e um fluxo de trabalho

Escreva o caso de uso como um problema de fluxo de trabalho, não como uma capacidade de IA.

Ruim: “Usar GPT para ajudar com contratos.”
Melhor: “Reduzir o tempo para revisar NDAs extraindo cláusulas não padronizadas e sugerindo redlines, com aprovação do advogado.”

Defina:

  • Quem é o usuário?
  • Qual é o fluxo de trabalho atual?
  • Onde estão os gargalos (tempo, custo, erros, atrasos)?
  • Como é o “melhor”?

Etapa 2: Transforme em uma decisão e defina métricas de sucesso

IA é aplicada de forma mais produtiva quando dá suporte a uma decisão:

  • “Quais tickets devem ser escalados?”
  • “Quais transações devem ser bloqueadas?”
  • “O que devemos recomendar em seguida?”
  • “Qual deve ser a resposta em rascunho?”

Em seguida, defina:

  • KPI de produto: resultado que o negócio valoriza (tempo de resolução, conversão, taxa de perdas)
  • Métrica de modelo: medida proxy (precisão/recall, qualidade de ranqueamento, acurácia de extração)

É aqui que você se alinha com KPIs (Métricas de Modelo vs Métricas de Produto): métricas offline são necessárias, mas o impacto online é o objetivo.

Etapa 3: Estabeleça uma linha de base (sempre)

Antes de IA, registre a linha de base que você precisa superar:

  • Desempenho somente humano (velocidade, taxa de erro, custo)
  • Heurística baseada em regras
  • Modelo estatístico simples (regressão logística, gradient boosting)
  • Abordagem somente de recuperação (para tarefas de conhecimento)

Linhas de base evitam “teatro de IA”, em que um modelo complexo substitui algo mais simples e confiável.

Etapa 4: Avalie viabilidade: dados, ciclos de feedback e restrições

Faça estas perguntas cedo:

Disponibilidade de dados

  • Você tem exemplos suficientes de casos típicos e casos de borda?
  • Rótulos estão disponíveis — ou você consegue definir um processo de rotulagem?
  • As entradas são estáveis e acessíveis (logs, texto, imagens)?
  • Há restrições de privacidade ou de propriedade intelectual (IP)?

Ciclos de feedback

  • Você terá dados de resultado após a implantação (por exemplo, o usuário aceitou a sugestão)?
  • É possível capturar correções humanas?
  • Com que rapidez você consegue iterar?

Restrições operacionais

  • Requisitos de latência (tempo real vs batch)
  • Requisitos de disponibilidade (uptime)
  • Complexidade de integração (onde isso vive na stack?)
  • Custo por inferência (especialmente relevante para LLMs)

Etapa 5: Mapeie riscos e desenhe mitigações

Diferentes casos de uso têm perfis de risco diferentes:

  • Riscos de segurança (conselhos nocivos, discriminação, assédio)
  • Riscos de compliance (PII, dados regulados, auditabilidade)
  • Riscos de reputação (falhas em produtos voltados ao público)
  • Riscos de segurança da informação (injeção de prompt, exfiltração de dados em apps de LLM)

Mitigações frequentemente incluem:

Etapa 6: Faça um modelo econômico simples

Mesmo um modelo de ROI aproximado esclarece prioridades. Inclua:

  • Volume (tarefas por dia)
  • Tempo economizado ou redução de erro
  • Custo dos erros (falsos positivos/negativos)
  • Custos de construção e operação (engenharia + computação + operações)

Lógica de exemplo:

  • “Se reduzirmos o tempo de atendimento em 30 segundos para 50.000 tickets/mês, isso dá ~416 horas/mês.”
  • Depois compare com o custo total (all-in) de construir e manter o sistema.

Etapa 7: Decida construir vs comprar (e quando “comprar” é estratégico)

A seleção de casos de uso deve considerar se você consegue entregar valor mais rápido via:

  • APIs de fornecedores (APIs de LLM, OCR, fala-para-texto)
  • Modelos abertos hospedados internamente
  • Treinamento totalmente customizado

Isso é coberto em profundidade em Construir vs Comprar, mas o principal insight de seleção é: alguns casos de uso só são atraentes se você puder comprar a capacidade barato; outros justificam investimento porque se tornam diferenciados com dados proprietários.

Etapa 8: Planeje a experiência do produto para incerteza

Diferente de software determinístico, saídas de IA são probabilísticas. Um bom caso de uso inclui:

  • Quando o sistema deve se abster
  • Como os usuários corrigem erros
  • O que acontece quando a IA está indisponível
  • Como comunicar incerteza sem sobrecarregar os usuários

Isso é uma preocupação de design de produto tanto quanto de modelagem.

Priorizando oportunidades: como escolher o que fazer primeiro

Depois de ter múltiplos casos de uso candidatos, priorize com uma rubrica consistente.

Pontuação Impacto–Viabilidade–Risco (um padrão prático)

Um modelo simples de pontuação:

  • Impacto (1–5): quanto valor se funcionar?
  • Viabilidade (1–5): conseguimos construir e implantar com os dados e restrições disponíveis?
  • Risco (1–5): qual é a desvantagem de estar errado? (maior = mais arriscado)

Então calcule um score de prioridade como:

def priority_score(impact, feasibility, risk, risk_weight=1.0):
    # Higher is better; risk reduces priority.
    return (impact * feasibility) - (risk_weight * risk)

candidates = [
    {"name": "Support triage", "impact": 4, "feasibility": 5, "risk": 2},
    {"name": "Auto-approve loans", "impact": 5, "feasibility": 3, "risk": 5},
    {"name": "Invoice extraction", "impact": 3, "feasibility": 4, "risk": 2},
]

for c in candidates:
    c["score"] = priority_score(c["impact"], c["feasibility"], c["risk"], risk_weight=1.5)

sorted(candidates, key=lambda x: x["score"], reverse=True)

Isso não é “científico”, mas força trade-offs explícitos e torna divergências produtivas (“Por que a viabilidade é só 2?”).

Pensamento de portfólio: equilibrar ganhos rápidos e apostas estratégicas

Organizações frequentemente se beneficiam de uma combinação de:

  • Ganhos rápidos: baixo risco, alta viabilidade (automação de extração, triagem, sumarização)
  • Diferenciadores centrais: viabilidade moderada, alto impacto (ranqueamento, personalização, copilotos específicos do domínio)
  • Apostas longas: alto impacto, mas exigindo investimento em dados (otimização em ciclo fechado, aprendizado por reforço, automação profundamente integrada)

Isso se conecta a Estratégia de Dados: alguns casos de uso de alto impacto só se tornam viáveis após meses melhorando instrumentação e qualidade de dados.

Sequencie com “fatias finas” que chegam à produção

Projetos de IA falham quando miram um sistema final sem valor intermediário. Prefira fatias finas:

  1. Entregue uma funcionalidade segura e assistiva com métricas claras
  2. Adicione coleta de feedback e harnesses de avaliação
  3. Expanda cobertura e automatize mais do fluxo de trabalho ao longo do tempo

Fatias finas reduzem risco, aceleram aprendizado e criam dados do mundo real.

Exemplos práticos (como é uma boa seleção)

Exemplo 1: Triagem de tickets de suporte ao cliente (bom caso de uso inicial)

Problema: Agentes perdem tempo roteando e etiquetando tickets de entrada.
Abordagem de IA: Classificar intenção + urgência; sugerir roteamento e rascunhar respostas.

Por que é um bom candidato:

  • Gargalo claro no fluxo de trabalho (tempo de roteamento, tempo até a primeira resposta)
  • Tolerante a erro com humano no loop (o agente pode sobrescrever)
  • Fácil coletar feedback (sinais de sobrescrita viram rótulos)
  • Pode começar com aumentação e gradualmente automatizar

Riscos e mitigações:

  • Roteamento incorreto de questões sensíveis → exigir limiares de confiança e categoria “desconhecido”
  • Rascunhos alucinados (LLMs) → restringir a respostas com templates ou ancorar o conteúdo

Exemplo 2: Processamento de faturas e extração de campos (alto ROI se o volume for grande)

Problema: Lançamento manual de campos de faturas em um ERP.
Abordagem de IA: OCR + extração de fornecedor, datas, totais, itens de linha.

Por que é forte:

  • Saídas estruturadas são fáceis de validar (totais devem bater, datas devem ser parseáveis)
  • Alto volume gera economia clara
  • Correção humana fornece sinais de treinamento

Armadilha comum:

  • Casos de borda (qualidade da digitalização, layouts incomuns) dominam a cauda longa
    Mitigação: desenhar para fallback e revisão baseada em filas; medir “taxa sem toque” (percentual processado sem edições humanas).

Exemplo 3: “Assistente especialista” com LLM em um domínio regulado (frequentemente um mau primeiro caso de uso)

Problema: Usuários querem respostas sobre políticas ou compliance.
Abordagem ingênua: Um chatbot que responde livremente a partir dos pesos do modelo.
Risco: Alto — alucinações e afirmações não verificáveis.

Uma versão melhor, com escopo mais bem definido:

  • Usar Geração Aumentada por Recuperação sobre documentos aprovados
  • Fornecer citações e trechos citados
  • Tratar saídas como orientação em rascunho, não decisões autoritativas
  • Registrar queries e adicionar revisão humana para tópicos de alto risco

Isso ilustra um princípio central de seleção: estreite o escopo até conseguir medir correção e controlar modos de falha.

Anti-padrões comuns na seleção de casos de uso

“Temos dados, vamos achar algo para prever”

Inverta o fluxo: comece por uma decisão e um resultado. Caso contrário, você constrói modelos impressionantes, mas não usados.

“Precisamos de 99,9% de acurácia”

Metas altas podem ser irreais ou desnecessárias. Foque em erros ponderados por custo e no design do fluxo de trabalho:

  • Se falsos positivos são caros, otimize precisão e adicione revisão humana
  • Se perder um evento raro é custoso, otimize recall e gerencie carga de alertas

“Vamos automatizar o trabalho inteiro”

Automação ponta a ponta frequentemente é o caminho mais difícil. Comece com:

  • Sugestão
  • Sumarização
  • Extração
  • Roteamento
    Depois automatize decisões incrementalmente conforme confiança e governança amadurecem.

“O modelo vai consertar o processo”

Se o processo subjacente está quebrado — definições pouco claras, resultados inconsistentes, instrumentação ausente — IA geralmente amplifica a bagunça. Melhore a mensuração e o fluxo de trabalho primeiro.

Um “Canvas de Caso de Uso” leve (template)

Use isto para comparar candidatos de forma consistente:

  • Usuário & fluxo de trabalho: Quem faz o quê hoje?
  • Decisão suportada: O que o sistema vai decidir/sugerir?
  • Valor esperado: Tempo economizado, ganho de receita, redução de risco (quantificar)
  • Linha de base: Desempenho e custo atuais
  • Dados & rótulos: O que existe, o que falta, como coletar
  • Abordagem de modelo: Classificação/ranqueamento/geração/etc.
  • Restrições: Latência, custo, privacidade, on-device vs nuvem
  • Riscos: Segurança/compliance/reputação/segurança da informação
  • Plano de fallback: Abstenção, revisão humana, backup determinístico
  • Métricas de sucesso: KPI de produto + métrica de modelo + plano de monitoramento
  • Loop de iteração: Como o feedback é coletado e usado

Checklist: selecionando e priorizando oportunidades de IA

  • Existe uma decisão clara ou gargalo no fluxo de trabalho?
  • Você consegue definir sucesso em termos mensuráveis?
  • Você tem uma linha de base que precisa superar?
  • Os dados estão disponíveis, e os rótulos são confiáveis ou criáveis?
  • Você tem um ciclo de feedback pós-lançamento?
  • Os riscos são aceitáveis com guardrails e UX de fallback?
  • A economia fecha após incluir custos contínuos de manutenção?
  • Você consegue entregar uma fatia fina em produção rapidamente?
  • Este caso de uso se alinha às realidades de construir vs comprar? (Construir vs Comprar)
  • Seu investimento em dados é proporcional ao valor estratégico? (Estratégia de Dados)

A seleção de casos de uso é, em última instância, sobre disciplina: escolher problemas em que a IA é uma alavanca — não um passivo — e sequenciá-los de modo que cada entrega ensine algo, melhore seus dados e se acumule em uma capacidade de produto defensável.