The six prerequisites that decide whether an AI use case is worth building, with a scoring rubric, two worked examples, and the red flags that say walk away.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
if valor > X resolve, a IA é a resposta cara a uma pergunta barata.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.
A practical playbook for optimising operations with AI: find the one slow step, automate it, keep a person in the loop, and measure the before and after.
Miguel Vicente Jr
Built a few AI tools and now fighting duplication and drift? The case for an internal AI marketplace: what goes in it, how to layer it, and how to curate it.
Miguel Vicente Jr
Um guia completo para implementar sistemas de IA que geram valor mensurável para o negócio. Aprenda estratégias práticas para construir, implementar e escalar soluções de IA que entregam retorno real sobre o investimento.
Equipa dypsis.aiQuer aplicar estas ideias no seu negócio? Fale com os nossos consultores de IA.
Marcar uma chamada