O primeiro caso de uso de IA começa pelo processo, não pela ferramenta

O primeiro caso de uso de inteligência artificial deve partir de um trabalho que a empresa consegue observar e conferir. Antes de escolher uma ferramenta, identifique o problema, como ele é resolvido hoje e quem pode dizer se a mudança ajudou. Isso vale para uma empresa com várias áreas e para um pequeno negócio em que o dono também atende clientes.

Imagine uma assistência técnica com o proprietário e duas pessoas na equipe. Pedidos chegam por mensagem, e alguém precisa separar orçamento, agendamento e dúvida sobre um reparo. Sugerir essa classificação para conferência é diferente de deixar o sistema prometer um preço ao cliente. O cenário é hipotético, sem implantação ou resultado da Axion Spark: ele mostra por que uma tarefa pequena pode oferecer um começo mais verificável.

Ao final, a ideia pode seguir para um teste controlado, voltar para preparação dos dados, ser resolvida sem IA ou sair da prioridade. Não é preciso criar um departamento para decidir. É preciso saber o que será testado, quem confere e como o atendimento continua se a sugestão estiver errada.

O canvas de decisão em uma página pode ser usado desde o início da leitura. Comece com o que já sabe e deixe o restante como pergunta. “Baseline” significa situação atual registrada; “gates” são condições mínimas para um teste útil, sem exigir um comitê ou uma estrutura de grande empresa.

1. A pior forma de começar é perguntar qual ferramenta usar

“Onde podemos usar IA?” parece uma pergunta ambiciosa, mas mistura problemas, tecnologias e riscos que não podem ser comparados. A discussão passa a girar em torno de modelos e fornecedores antes que alguém descreva a fila, a decisão ou a tarefa que precisa melhorar.

Um agente de atendimento, por exemplo, pode significar desde sugerir uma resposta para revisão até alterar um cadastro, conceder um benefício ou assumir um compromisso comercial. A interface pode ser parecida; a responsabilidade não é. Priorizar pelo nome da tecnologia esconde justamente aquilo que determina custo, risco e viabilidade.

A pergunta útil é mais estreita: qual processo tem um problema observável, um responsável e uma mudança que pode ser testada com segurança? Esse recorte desloca a conversa da novidade para a operação. Também permite reconhecer uma conclusão importante: em alguns cenários, uma regra estável, uma integração ou software sob medida quando IA não é necessária resolve melhor.

2. Um caso de uso só existe quando cabe em um processo

“Usar IA no atendimento” é uma direção, não um caso de uso. Falta dizer o que entra, qual trabalho acontece, quem utiliza a saída e o que ocorre quando o sistema não sabe responder. Uma formulação operacional seria: “classificar solicitações recebidas, sugerir prioridade e encaminhar casos ambíguos para revisão da equipe”. Agora existe algo que pode ser observado, delimitado e comparado.

O recorte mínimo descreve seis elementos: a entrada que inicia o fluxo; a tarefa ou decisão afetada; a saída esperada; a pessoa responsável; as exceções conhecidas; e os sistemas que já participam da rotina. Não é uma especificação completa. É informação suficiente para impedir que uma ideia genérica receba orçamento como se já fosse projeto.

Essa disciplina se conecta ao método da Axion Spark: processo, situação atual, risco e responsável vêm antes da escolha tecnológica. O AI Risk Management Framework 1.0, do NIST, segue uma lógica compatível ao pedir que propósito, contexto, usuários, impactos e tolerância a risco sejam compreendidos e documentados. A referência ajuda a formular perguntas; não escolhe o projeto nem exige reproduzir uma estrutura de grande empresa.

Um bom teste é pedir que quem decide o investimento descreva o caso sem citar “IA”, “modelo” ou “agente”. Se o problema continuar claro — reduzir retrabalho, identificar uma ocorrência fora do padrão ou preparar uma decisão — há um processo a investigar. Se desaparecer, a tecnologia provavelmente era a ideia inteira.

3. Sem baseline, melhoria vira opinião

Baseline é o registro de como o trabalho funciona antes da mudança. Pode incluir quantidade de pedidos, tempo de atendimento, prazo combinado, retrabalho e exceções. Na assistência hipotética, a equipe poderia anotar quais mensagens exigem releitura e por quê. Não precisa medir tudo: precisa registrar algo que permita comparar a mesma tarefa antes e depois, sem escolher apenas os exemplos favoráveis.

Essa referência também não é uma meta. Uma descreve o estado atual; a outra define o que precisa mudar para o investimento fazer sentido. Confundir as duas facilita promessas: a empresa escolhe um número desejado e o apresenta como se já tivesse observado aquela oportunidade.

O NIST trata benefícios, custos, métricas, escopo e supervisão como elementos que devem ser examinados no contexto do sistema. Isso inclui custos não monetários e o impacto de erros, não apenas uma projeção de ganho. Na mesma direção, a pesquisa original Hidden Technical Debt in Machine Learning Systems mostra por que o modelo é apenas uma parte do sistema: dependências, dados, integrações e mudanças operacionais também acumulam custo.

Quando esse registro não existe, observar o trabalho pode ser o primeiro resultado do projeto. Acompanhe uma amostra que inclua dias e situações diferentes, registre as exceções e identifique de onde vieram os dados. A iniciativa passa de “testar IA” para “entender o problema”. O tamanho e o período dessa observação dependem da rotina, não de um prazo padrão prometido antes de conhecê-la.

4. Antes de comparar valor, aplique os gates de prontidão

Os gates são critérios mínimos para começar, não uma cerimônia de aprovação. Confira cinco pontos: tarefa delimitada; pessoa que responde pelo trabalho e pelo aceite; situação atual observável; dados acessíveis; e um caminho seguro quando a solução falhar. O responsável pode ser o próprio dono. A exigência é conseguir conferir o trabalho, não ter uma equipe técnica interna.

Esses critérios não formam uma nota. Se ninguém pode confirmar a resposta correta, compensar essa ausência com um suposto “alto impacto” não resolve o problema. Primeiro, combine como será a conferência. O mesmo vale quando o resultado não pode ser comparado ou ninguém definiu quem assume a tarefa em caso de falha.

O NIST AI RMF Playbook oferece ações voluntárias organizadas em Govern, Map, Measure e Manage. Ele próprio alerta que não é uma lista a ser aplicada por inteiro. Para a priorização, a lição prática é adaptar o controle ao contexto sem eliminar perguntas essenciais. Já a ISO/IEC 42001:2023 situa IA dentro de um sistema de gestão com políticas, objetivos, responsabilidades, avaliação e melhoria contínua. Citar essas referências não significa alegar certificação; significa reconhecer que responsabilidade e ciclo de vida não começam depois do piloto.

Se houver dados pessoais ou decisão com efeito sobre pessoas, a análise precisa considerar finalidade, necessidade, transparência e risco desde o recorte. A orientação da ANPD sobre Relatório de Impacto à Proteção de Dados Pessoais reforça que fatores de risco, probabilidade, impacto e justificativa das decisões devem ser documentados. Isso não torna todo piloto um projeto jurídico complexo; torna inadequado tratar privacidade como ajuste posterior.

5. Entre os casos prontos, priorize tempo até evidência

Depois dessa conferência, compare os candidatos pelo valor esperado, pelo esforço para testar, pelos sistemas envolvidos e pela consequência de um erro. Considere também se é possível desfazer a mudança e se a equipe consegue utilizá-la. Cada avaliação exige uma justificativa: “alto”, “médio” e “baixo” sem contexto apenas substituem um palpite por uma cor.

Tempo até evidência não é sinônimo de projeto mais curto. É o intervalo até a organização conseguir aprender algo que mude uma decisão: o dado tem qualidade suficiente, o usuário incorpora a sugestão, o erro cabe no limite, a integração sustenta a rotina ou o custo de manutenção invalida o caminho. Um piloto que entrega essa resposta pode ter valor mesmo sem virar produção.

A regra é preferir o menor recorte capaz de produzir evidência útil, desde que o valor potencial justifique o esforço. Casos de impacto maior não precisam ser descartados, mas exigem mais controle, teste e autoridade humana. Os princípios de accountability da OCDE relacionam responsabilidade ao papel, ao contexto e à capacidade de agir, além de defender rastreabilidade ao longo do ciclo de vida.

Quando a proposta envolve execução assistida, explicite o que o sistema prepara, o que uma pessoa aprova e o que nunca deve ocorrer sem autorização. Essa distinção também orienta o desenho de agentes de IA com limites e supervisão, em vez de transformar autonomia em objetivo por si só.

6. Três ideias competem pelo primeiro piloto

O exemplo abaixo é hipotético. Ele não representa cliente, prazo, precisão ou resultado real da Axion Spark. Sua função é mostrar como iniciativas atraentes podem receber encaminhamentos diferentes sem depender de uma nota agregada.

O primeiro candidato avança porque permite observar e corrigir erro antes da ação final. O segundo pode ter valor superior, mas sua baixa reversibilidade pede uma etapa anterior. O terceiro mostra que risco moderado não basta: sem base confiável, a busca responde com mais velocidade sobre informação desorganizada.

7. O caso de maior valor pode não ser o primeiro — e isso não é covardia

Existe um contra-argumento legítimo: às vezes o problema mais relevante é também o mais difícil. Uma obrigação regulatória, um gargalo industrial crítico ou uma decisão que concentra perdas pode justificar investimento mesmo sem o caminho mais curto. Priorizar sempre o caso mais simples criaria uma coleção de pilotos seguros, mas irrelevantes.

A resposta não é ignorar risco nem abandonar impacto. É mudar o objetivo do primeiro ciclo. Em vez de prometer implantação, o trabalho pode mapear dados, testar uma hipótese em ambiente isolado, definir critérios de contestação ou provar que uma integração é viável. A evidência reduz uma incerteza por vez e deixa registrado o que ainda impede produção.

Por isso, a dificuldade de desfazer uma mudança não deve funcionar como veto automático. Ela determina a intensidade de supervisão, teste e aprovação. Um caso complexo pode vir primeiro quando o dono ou a direção assume a decisão e o esforço necessário para investigar as incertezas. O erro é tratá-lo como atalho só porque seu benefício projetado parece grande.

8. A decisão final precisa caber em uma página

O Canvas Axion do Primeiro Caso de Uso de IA organiza a conversa sem fingir precisão matemática. Ele é uma síntese metodológica da Axion Spark, não uma certificação NIST ou ISO e não foi apresentado como instrumento estatisticamente validado. Seu propósito é tornar premissas, bloqueios e responsabilidades visíveis na mesma página.

Preencher o canvas não encerra a decisão; melhora a qualidade dela. Um caso segue para teste quando atende aos critérios mínimos e permite aprender algo proporcional ao investimento. Volta para preparação quando faltam processo, dado, responsável ou controle. Segue por software convencional quando IA não acrescenta valor. Sai da prioridade quando não justifica o próximo passo.

Se a sua empresa tem várias ideias de IA e nenhuma prioridade clara, veja como estruturamos uma Inovação e estratégia digital a partir do processo real.

Quando a prioridade for consulta documental, o roteiro de RAG com fontes e permissões ajuda a especificar o teste. Se a dúvida for uma nova oferta para clientes, a validação de uma ideia de produto investiga experiência e viabilidade antes da construção.

Esse desafio aparece na sua empresa?

Conte o que acontece hoje. A conversa inicial ajuda a avaliar escopo, dados e sistemas antes de propor uma implementação.

Conversar no WhatsAppPrefiro contato por e-mail