Primeiro projeto de IA na empresa: como escolher o caso certo

A diretoria decide que a empresa precisa "fazer alguma coisa com IA". Alguém monta uma demonstração: um chat que responde perguntas sobre os produtos, ou um resumo automático de contratos. A apresentação impressiona. Três meses depois, ninguém usa, e a conclusão informal é que "IA ainda não serve para o nosso negócio".

Quase sempre o problema não foi a tecnologia. Foi a escolha do caso. O projeto começou pela ferramenta ("vamos usar um modelo de linguagem") e não por uma tarefa concreta, com volume, dono e um número que pudesse melhorar. Sem isso, não há como dizer se o piloto deu certo, e projeto sem critério de sucesso morre por falta de defensor.

Em resumo: o primeiro projeto de IA deve ser uma tarefa repetitiva, em que um erro seja barato de corrigir, com dados já acessíveis e um resultado que dê para medir. Este texto detalha esse critério: o que procurar, o que evitar e como desenhar um piloto pequeno que, se funcionar, já nasce com caminho para virar operação.

A resposta curta: quatro critérios

Um bom primeiro projeto de inteligência artificial atende, ao mesmo tempo, a quatro condições:

1. Volume. A tarefa se repete muitas vezes por semana, feita por pessoas que poderiam estar fazendo outra coisa. Tarefa rara não paga o esforço de montar, avaliar e manter.
2. Tolerância a erro. Um erro da IA é barato de detectar e de corrigir, porque existe revisão humana ou uma conferência automática no caminho. Nada de decisões irreversíveis no primeiro projeto.
3. Dados disponíveis. Os documentos, mensagens ou registros que a IA precisa já existem, são acessíveis e há exemplos suficientes para testar.
4. Retorno mensurável. Dá para medir hoje quanto tempo, quantos erros ou quanto retrabalho a tarefa consome, e comparar depois.

Se um candidato falha em qualquer um dos quatro, ele pode até ser um bom segundo ou terceiro projeto. Como primeiro, tende a virar demonstração.

Por que tantos projetos de IA não saem do piloto

Antes de olhar os bons candidatos, vale entender os padrões que levam um piloto a morrer. São quase sempre os mesmos:

• Começar pela ferramenta. "Temos acesso a um modelo, vamos ver o que dá para fazer" produz soluções procurando problema. O resultado é bonito e inútil.
• Caso amplo demais. "Um assistente que sabe tudo da empresa" não tem fronteira, não tem base de teste e não tem dono. Cada pergunta errada vira motivo para desconfiar do resto.
• Nenhuma linha de base. Se ninguém mediu quanto tempo a equipe gasta hoje, não há como provar que o piloto ajudou. A discussão vira opinião.
• Demonstração feita com exemplos escolhidos. Funciona com os dez documentos limpos que alguém separou e falha com o PDF torto que chega toda segunda-feira.
• Piloto isolado do sistema. A IA gera uma resposta numa tela à parte, e alguém precisa copiar e colar no ERP. A economia some no copia e cola, e a equipe abandona.
• Sem dono na operação. O projeto pertence à TI ou à inovação, não à área que faz a tarefa. Quando o patrocinador muda de prioridade, o piloto fica órfão.

Repare que nenhum desses motivos é técnico. Todos são de escolha e de desenho, e todos podem ser evitados antes de escrever a primeira linha de código.

Bons candidatos: tarefas repetitivas com texto e documentos

Os modelos de linguagem atuais são especialmente bons em uma coisa: ler texto não estruturado e transformá-lo em algo estruturado, ou o contrário. É aí que o primeiro projeto costuma render mais. Qual modelo usar comparamos em ChatGPT, Gemini ou Claude. Exemplos do dia a dia de empresas brasileiras:

• Extrair dados de documentos que chegam por e-mail: contratos, laudos, comprovantes de fornecedores pequenos, pedidos em PDF. A IA lê, preenche os campos e o sistema confere contra o cadastro. O desenho completo desse fluxo está no texto sobre extração de dados de documentos com IA.
• Classificar e encaminhar mensagens. E-mails do SAC, chamados internos, solicitações de clientes: a IA identifica o assunto, a urgência e a fila certa, e a pessoa recebe já triado.
• Responder com base em documentos internos. Manuais, políticas, procedimentos, tabelas técnicas. Um assistente que consulta essa base e cita a fonte reduz a pergunta repetida ao colega mais experiente. Os cuidados de arquitetura estão em assistente de IA que responde com os documentos da empresa.
• Resumir e padronizar registros. Relatórios de visita técnica, anotações de atendimento, atas: a IA transforma texto livre num formato padrão que alimenta o sistema.
• Rascunhar respostas para e-mails ou propostas recorrentes, sempre revisadas por uma pessoa antes do envio.

O que esses casos têm em comum: a tarefa já existe, alguém já faz à mão, o resultado pode ser conferido e o volume costuma ser alto.

O que deixar para depois

Alguns casos são legítimos, mas não são bons como primeiro projeto:

• Decisões com impacto direto e irreversível, como aprovar crédito, demitir, negar um sinistro ou definir preço sem revisão.
• Previsões que dependem de histórico longo e limpo, como demanda ou cancelamento de clientes, quando os dados ainda estão espalhados em planilhas. O aprendizado de máquina tradicional (machine learning) funciona bem nesses casos, mas exige preparar os dados primeiro; veja o que esperar em previsão de demanda com machine learning.
• Atendimento direto ao cliente final sem nenhuma retaguarda humana, quando a empresa ainda não tem base de conhecimento organizada.
• Projetos que dependem de integrar cinco sistemas antes de entregar qualquer valor.

Tolerância a erro e revisão humana

Todo modelo de IA erra. A pergunta certa não é "qual a taxa de erro", mas "quanto custa um erro, e quem percebe antes que ele cause dano".

Uma forma prática de pensar é cruzar o custo do erro com a facilidade de detectá-lo:

O desenho que funciona no primeiro projeto é IA propõe, pessoa confirma, com dois refinamentos:

• Validação automática antes da pessoa. Se a IA extraiu um CNPJ, o sistema confere o dígito verificador e o cadastro. Se extraiu um valor, confere com o pedido. A pessoa só olha o que não bateu.
• Revisão proporcional à confiança. Casos em que tudo bate passam direto ou com amostragem; casos duvidosos vão para uma fila com o motivo visível.

Com o tempo, medindo os acertos, a empresa decide com dado onde a revisão pode ser reduzida. No primeiro projeto, ela é o que dá segurança para a operação aceitar a mudança.

Dados disponíveis e qualidade

Na maioria dos projetos com IA generativa, a empresa não precisa treinar um modelo do zero, porque ele já vem treinado. Mas o projeto precisa de três coisas que muita empresa não tem organizadas:

• Acesso. Os documentos estão num servidor de arquivos, no e-mail de uma pessoa, num sistema sem API? Se buscar o insumo exige alguém baixando arquivos à mão, o projeto começa pela integração.
• Exemplos reais para avaliar. Uma amostra representativa, com os casos feios incluídos, e a resposta certa conhecida para cada um. Sem essa base, não há como medir a qualidade do piloto.
• Conteúdo atualizado. Um assistente que responde com base em políticas desatualizadas erra com confiança. Alguém precisa ser dono da base.

Há ainda a questão de privacidade. Documentos de clientes, funcionários e fornecedores carregam dados pessoais, e a LGPD se aplica ao projeto de IA como a qualquer outro sistema: finalidade definida, acesso restrito, cuidado com o que é enviado a serviços externos e com o que fica em log. Os pontos que o sistema precisa suportar estão em LGPD no desenvolvimento de sistemas; para a base legal de cada tratamento, valide com o jurídico.

Como medir o retorno antes de começar

O retorno do primeiro projeto precisa ser medido antes de construir qualquer coisa, porque é a linha de base que permite provar resultado depois. Para a tarefa candidata, levante:

• Volume: quantas vezes a tarefa acontece por dia ou por semana.
• Tempo por unidade: quanto a pessoa leva para fazer cada uma, cronometrado numa amostra, não estimado de memória.
• Taxa de erro ou retrabalho: quantas voltam, quantas precisam de correção, quantas geram reclamação.
• Tempo de ciclo: quanto tempo o item espera entre chegar e ser tratado.
• Custo de oportunidade: o que essas pessoas fariam se a tarefa encolhesse.

Com esses números, o critério de sucesso deixa de ser "a IA funciona" e vira algo como "reduzir o tempo de triagem por item e manter a taxa de erro igual ou menor que a atual". Repare que o critério inclui qualidade, não só velocidade: um sistema rápido que erra mais não é ganho.

Se ninguém consegue levantar esses números, isso já é um diagnóstico útil. Talvez o primeiro passo seja mapear o processo, e não aplicar IA nele.

Piloto pequeno com critério de sucesso

Com o caso escolhido, o piloto deve ser pequeno de propósito. Um roteiro que funciona:

1. Escolha um recorte estreito. Um tipo de documento, uma fila de atendimento, uma área. "Contratos de prestação de serviço recebidos pelo jurídico", não "todos os documentos".
2. Monte a base de avaliação com casos reais, incluindo os difíceis, e a resposta esperada para cada um.
3. Defina o critério de sucesso por escrito, com a linha de base ao lado, antes de testar qualquer modelo.
4. Construa o fluxo mínimo integrado: a entrada vem do lugar onde a tarefa já acontece e a saída cai no sistema onde ela é usada. Nada de tela isolada.
5. Rode em paralelo com o processo atual por um período, comparando os resultados da IA com os da equipe.
6. Meça contra o critério e decida: escalar, ajustar ou encerrar.

Encerrar é um resultado legítimo. Um piloto que mostra, com dados, que o caso não compensa custou pouco e ensinou muito. O que não pode acontecer é o piloto ficar indefinidamente "quase pronto".

Essa etapa de entender o problema antes de construir é o que chamamos de descoberta; o método está descrito em discovery de software.

Checklist para decidir entre candidatos

Antes de escolher, passe cada candidato por estas perguntas:

• A tarefa acontece com frequência suficiente para justificar o esforço?
• Existe um dono na área de negócio que quer a mudança?
• Um erro é detectável e corrigível antes de causar dano?
• Os dados de entrada estão acessíveis sem trabalho manual?
• Dá para montar uma amostra real com a resposta certa conhecida?
• Existe uma medida atual de tempo, erro ou retrabalho?
• O resultado pode cair direto no sistema que a equipe já usa?
• O recorte cabe num piloto de algumas semanas, sem depender de outros projetos?

O candidato com mais respostas "sim" é o seu primeiro projeto. Empates se resolvem pelo dono mais engajado.

Do piloto à operação

Um piloto que deu certo ainda não é um sistema em produção. A passagem exige trabalho que a demonstração não mostra:

• Monitoramento de qualidade. A base de avaliação continua rodando, e uma amostra das saídas em produção é revisada periodicamente. Fornecedores mudam o layout dos documentos, o provedor atualiza a versão do modelo, e a qualidade pode cair sem ninguém perceber.
• Fila de exceções com dono. O que a IA não resolveu precisa ir para alguém, com o motivo legível e a opção de reprocessar.
• Registro do que foi decidido. Quem confirmou, o que a IA propôs, o que foi alterado. Isso alimenta a melhoria e responde a auditorias.
• Controle de custo de uso. Serviços de modelos de linguagem costumam cobrar pelo volume de texto processado. O sistema precisa registrar o consumo para que não haja surpresa quando o volume crescer.
• Independência de fornecedor. O desenho deve permitir trocar o modelo por outro sem reescrever o sistema, porque esse mercado muda rápido.

É aqui que o projeto de IA vira um projeto de software como qualquer outro, com integração, segurança, logs e manutenção. Por isso a decisão sobre como encaixar a IA no ecossistema da empresa é uma decisão de arquitetura de software, não só de escolha de modelo.

Depois do primeiro caso em produção, o segundo fica mais fácil: a base de documentos, a integração, a fila de revisão e o monitoramento já existem e podem ser reaproveitados. Outros casos e ideias estão reunidos na categoria de inteligência artificial do blog.

Perguntas frequentes

Precisa treinar um modelo de IA próprio no primeiro projeto?

Na maioria dos casos, não. Em projetos com IA generativa, o modelo de linguagem já vem treinado, e o trabalho está em dar acesso aos documentos certos, montar uma base de exemplos reais para avaliar e integrar o resultado ao sistema da equipe. Treinar um modelo próprio é exceção, não ponto de partida.

Quanto tempo dura um piloto de inteligência artificial?

Um piloto de inteligência artificial bem recortado costuma caber em algumas semanas, mas o prazo depende do acesso aos dados e das integrações necessárias. O recorte estreito, como um tipo de documento ou uma fila de atendimento, é o que mantém o piloto curto. O cronograma real só é definido depois do diagnóstico.

A LGPD se aplica a projetos de inteligência artificial?

Sim. A LGPD se aplica a um projeto de inteligência artificial como a qualquer outro sistema que trate dados pessoais de clientes, funcionários ou fornecedores. Isso exige finalidade definida, acesso restrito e cuidado com o que é enviado a serviços externos e com o que fica registrado em log. A base legal deve ser validada com o jurídico.

O que fazer quando o piloto de IA não dá certo?

Encerrar é um resultado legítimo. Um piloto de IA que mostra, com dados medidos contra a linha de base, que o caso não compensa custou pouco e ensinou muito. O que não pode acontecer é o piloto ficar indefinidamente quase pronto. O próximo candidato da lista pode então ser avaliado com os mesmos critérios.

Como a Pervian Tech trabalha projetos de IA

Na Pervian Tech, começamos pelo diagnóstico, não pela ferramenta: listamos as tarefas candidatas com a equipe, levantamos volume, tempo e erro de cada uma e aplicamos os critérios deste texto para escolher o primeiro caso. Só então desenhamos o piloto, com base de avaliação, critério de sucesso escrito e integração com os sistemas que a equipe já usa. O diagnóstico inicial é gratuito.

Cada projeto é sob medida, porque depende dos documentos, dos sistemas e das regras da sua operação; detalhes de como abordamos esse tipo de solução estão na página de inteligência artificial para empresas. O cronograma segue fases (diagnóstico, piloto com avaliação, primeiro caso em produção, evolução) e é definido depois do diagnóstico. O investimento é sob consulta.

Se a sua empresa quer começar com IA e ainda não sabe por onde, conte quais tarefas mais consomem a sua equipe hoje.