Na reunião de segunda-feira, alguém diz: "Precisamos colocar IA na empresa".
A primeira ideia costuma chegar rápido. Um chatbot que conheça todos os documentos, responda qualquer pergunta, consulte sistemas e ajude todas as áreas.
No quadro, o projeto parece moderno. Na prática, ninguém sabe dizer qual tarefa ele precisa fazer primeiro, quais respostas seriam consideradas boas ou quem assumiria quando a IA errasse.
Esse é um jeito caro de começar.
Uma empresa não precisa encontrar "onde usar inteligência artificial" em toda a operação. Precisa encontrar uma tarefa específica em que a tecnologia consiga produzir um resultado útil, verificável e seguro.
Este artigo mostra como fazer essa escolha. Para implementar IA na empresa, comece pelo processo: delimite uma tarefa, defina o resultado esperado e só então escolha a arquitetura.
A tarefa vem antes da tecnologia
Escolher o modelo antes do processo é parecido com comprar uma máquina antes de decidir o que será fabricado.
Talvez a empresa realmente precise de um assistente conversacional. Talvez precise apenas classificar mensagens, extrair informações de documentos ou preparar uma resposta para uma pessoa revisar.
O formato mais chamativo nem sempre resolve o problema mais valioso.
Vamos acompanhar uma empresa de serviços que recebe pedidos de orçamento por e-mail e WhatsApp. Cada mensagem chega de um jeito. Algumas têm todas as informações. Outras esquecem prazo, quantidade ou endereço. Uma pessoa lê, copia os dados para o sistema e pede o que ficou faltando.
A direção imaginou um chatbot para atender clientes do começo ao fim. Depois de observar o trabalho, a equipe encontrou um primeiro projeto mais simples:
- ler a solicitação recebida;
- identificar os dados principais;
- apontar o que está faltando;
- classificar o tipo de pedido;
- preparar uma resposta;
- deixar uma pessoa revisar antes do envio.
A IA não assume o atendimento inteiro. Ela reduz a parte repetitiva e mantém a decisão com a equipe.
Esse recorte é menos impressionante em uma apresentação. Também é muito mais fácil de testar.
O que torna um processo um bom candidato para IA
Cinco perguntas ajudam a separar uma boa oportunidade de uma ideia vaga.
1. A tarefa acontece com frequência?
Um processo repetitivo oferece mais casos para aprender e medir. Se a equipe executa a tarefa uma vez por semestre, talvez não valha construir uma solução específica.
Frequência não significa que todas as entradas sejam iguais. Pedidos de orçamento variam bastante, mas a equipe procura quase sempre os mesmos dados.
2. A entrada e a saída são compreensíveis?
No nosso exemplo, a entrada é uma mensagem. A saída é um conjunto de campos, uma categoria e um rascunho de resposta.
"Ajudar o comercial" é amplo demais. "Extrair produto, quantidade, prazo e local de entrega" permite criar critérios de teste.
A equipe precisa conseguir mostrar exemplos de resultado bom, ruim e incompleto.
3. Os dados necessários existem e podem ser usados?
A IA depende das informações disponíveis. Se tabelas estão desatualizadas, documentos se contradizem ou ninguém sabe qual regra está valendo, o projeto começa com um problema de dados.
Também é preciso verificar acesso e finalidade. Ter um documento não significa que qualquer usuário ou sistema pode consultá-lo.
4. Um erro pode ser percebido e corrigido?
No primeiro projeto, prefira erros reversíveis.
Um rascunho incorreto pode ser corrigido antes do envio. Uma classificação errada pode voltar para a fila certa. Já uma cobrança automática ou uma decisão médica cria um risco muito maior.
Quanto maior o impacto do erro, mais fortes precisam ser os controles e a participação humana.
5. Existe uma forma de medir o resultado?
Antes do piloto, a empresa precisa saber como o processo funciona hoje.
No caso dos orçamentos, a linha de base pode registrar:
- tempo entre a chegada da mensagem e a primeira resposta;
- minutos gastos para organizar cada solicitação;
- percentual de pedidos com informações faltando;
- quantidade de correções antes do envio;
- retrabalho causado por dados copiados de forma errada.
Sem essa referência, qualquer demonstração parece uma melhoria.
Uma matriz simples para comparar oportunidades
Liste três a cinco processos e dê uma nota de 1 a 5 para cada critério:
| Critério | Pergunta | Uma nota alta significa |
|---|---|---|
| Frequência | A tarefa acontece bastante? | Há volume suficiente para gerar valor |
| Clareza | Entrada e saída são definidas? | O resultado pode ser testado |
| Dados | A informação existe e está acessível? | O piloto não depende de organizar tudo antes |
| Risco | O erro é reversível e detectável? | É possível começar com segurança |
| Medição | Existe uma linha de base? | O ganho pode ser demonstrado |
Não some as notas de forma cega. Um processo com ótimo volume e risco inaceitável continua sendo uma escolha ruim.
A matriz serve para provocar uma conversa objetiva. Ela não substitui a análise do processo.
Bons primeiros usos de IA
Alguns tipos de tarefa aparecem com frequência em projetos iniciais.
Classificar e encaminhar
A IA lê uma mensagem, identifica o assunto e envia para a fila correta.
Funciona bem quando as categorias são conhecidas e a empresa tem exemplos históricos. A equipe ainda precisa tratar mensagens ambíguas e acompanhar classificações erradas.
Extrair dados de documentos
Notas, formulários, contratos e pedidos contêm informações que alguém copia para outro sistema.
A IA pode localizar campos e devolver uma estrutura definida. O software valida formatos, valores obrigatórios e referências antes de gravar.
Consultar uma base interna
Em vez de pedir que o modelo responda pela própria memória, o sistema procura trechos em políticas, manuais ou catálogos autorizados.
Essa técnica é chamada RAG. Ela é útil quando a resposta depende de informação privada ou atualizada. O artigo sobre engenharia de IA explica como busca, modelo, permissões e avaliações trabalham juntos.
Preparar respostas para revisão
A IA cria um primeiro rascunho com base no pedido e nas regras disponíveis. Uma pessoa confere, ajusta e envia.
Esse formato ajuda a empresa a observar os erros antes de aumentar a autonomia.
Comparar e verificar
O sistema pode comparar uma solicitação com uma política, verificar se faltam documentos ou apontar divergências entre versões.
A saída precisa mostrar evidências. Apenas dizer "está correto" não ajuda quem vai decidir.
Apoiar uma decisão sem tomá-la
A IA organiza informações, resume histórico e apresenta opções. A decisão continua com uma pessoa responsável.
Esse desenho costuma ser mais seguro para áreas financeiras, jurídicas, médicas ou de recursos humanos.
Processos ruins para começar
Alguns projetos deveriam acender um alerta logo na primeira conversa:
- “Um chatbot que responda sobre tudo”. A promessa é grande e o critério de sucesso quase não existe. Cada área tem fontes, permissões e riscos diferentes. Começar por um assunto e um grupo de usuários torna o aprendizado muito mais útil.
- Decisões irreversíveis sem revisão. Aprovar crédito, negar atendimento, movimentar dinheiro ou alterar um cadastro crítico exige mais do que uma resposta convincente. Se o piloto já nasce com efeito difícil de desfazer, a empresa aprende sob risco alto demais.
- Processos que ninguém consegue explicar. IA não conserta uma operação confusa por conta própria. Quando duas pessoas executam a mesma tarefa de formas incompatíveis, o primeiro passo pode ser mapear e organizar o processo.
- Projetos sem acesso aos dados. Um assistente de propostas não funciona se preços, regras e disponibilidade estão espalhados em arquivos que ninguém mantém. O piloto pode revelar a necessidade de organizar dados. Só não deve fingir que essa dependência não existe.
- Autonomia antes de confiança. Dar acesso amplo a e-mail, banco de dados e sistemas torna a demonstração interessante. Também transforma uma interpretação errada em efeito real. Aumente permissões depois que o sistema provar qualidade no escopo menor.
Comece pela arquitetura mais simples
Depois de escolher a tarefa, a equipe decide quanta tecnologia precisa:
- Uma chamada estruturada. O modelo recebe a mensagem e devolve campos conhecidos. Isso pode bastar para classificação, extração ou transformação de texto.
- Consulta a conhecimento. Se a resposta depende de documentos da empresa, entra uma busca como RAG. O sistema recupera fontes permitidas antes de responder.
- Workflow com ferramentas. Se a tarefa precisa consultar ou atualizar outro sistema, o software oferece funções específicas. O caminho continua definido pelo código.
- Agente. Um agente escolhe parte do caminho durante a execução. Ele faz sentido quando a tarefa exige investigação, uso variável de ferramentas e adaptação.
A Anthropic recomenda começar pela solução mais simples e adicionar complexidade somente quando ela melhora o resultado de forma mensurável. Workflows previsíveis costumam ser melhores para tarefas bem definidas. Agentes trocam tempo, custo e previsibilidade por flexibilidade.
Como testar o piloto
Uma equipe não deveria avaliar a IA perguntando se "pareceu boa".
No exemplo dos orçamentos, o conjunto de testes precisa incluir:
- mensagens completas e incompletas;
- abreviações e erros de digitação;
- pedidos com dois produtos;
- informações contraditórias;
- anexos ausentes;
- clientes com regras diferentes;
- mensagens que não são pedidos de orçamento;
- casos em que a IA deve pedir ajuda.
A equipe mede cada etapa:
- extraiu os campos corretos?
- identificou o que faltava?
- escolheu a categoria certa?
- usou a regra válida?
- preparou uma resposta aceitável?
- reconheceu quando não deveria continuar?
A documentação de boas práticas de avaliação da OpenAI recomenda testes específicos do caso de uso, critérios definidos cedo e cobertura de situações comuns, difíceis e adversariais.
Cada erro real vira um novo teste. Assim, a próxima versão precisa provar que não repetiu o problema.
O que medir além de tempo economizado
Velocidade chama atenção, mas não conta a história inteira.
Um painel simples pode acompanhar:
- taxa de resultados aceitos sem alteração;
- taxa de resultados aceitos após correção;
- casos enviados para revisão;
- erros por tipo;
- tempo por tarefa;
- custo por tarefa concluída;
- retrabalho depois da execução;
- satisfação de quem usa e de quem revisa.
Imagine que o sistema responde mais rápido, mas a equipe passa o mesmo tempo corrigindo os rascunhos. A automação apenas mudou o lugar do trabalho.
O resultado precisa aparecer no processo, não só na tela da IA.
Um plano prático para os primeiros 30 dias
- Semana 1 — observar e escolher. Acompanhe o processo real. Converse com quem executa a tarefa, reúna exemplos e registre a linha de base. Escolha um recorte pequeno. Defina o que entra, o que sai e quais situações ficam fora do piloto.
- Semana 2 — prototipar com casos reais. Construa a versão mais simples que possa executar a tarefa. Use dados representativos e remova informações sensíveis que não sejam necessárias. O objetivo dessa semana não é criar uma interface bonita. É descobrir se a IA ajuda no trabalho.
- Semana 3 — avaliar e proteger. Monte os testes, classifique erros e adicione validações. Defina permissões, limites de custo, revisão humana e comportamento quando faltar informação. O perfil de IA generativa do NIST AI RMF recomenda incorporar confiança e gestão de risco ao desenho, desenvolvimento, uso e avaliação do sistema. O risco não entra somente depois do piloto.
- Semana 4 — testar com poucos usuários. Escolha um grupo pequeno, acompanhe cada execução e mantenha o processo anterior como alternativa. Compare os resultados com a linha de base. Se o sistema ajuda, avance gradualmente. Se não ajuda, descubra se o problema está na tarefa, nos dados, na interface ou na tecnologia.
Um piloto que mostra cedo que a ideia não funciona também economiza dinheiro.
Quem precisa participar
O projeto não pertence apenas à equipe técnica.
Quem executa o processo conhece exceções que não aparecem no fluxograma. A liderança define prioridade e tolerância a risco. Tecnologia cuida da integração, segurança e operação. Especialistas da área julgam a qualidade do resultado.
Uma pessoa pode acumular funções em uma empresa pequena. As responsabilidades continuam existindo.
Se a empresa não tem todas essas competências internamente, uma equipe de TI terceirizada pode ajudar no diagnóstico, desenvolvimento e acompanhamento do piloto.
Como saber se vale avançar
Ao final do piloto, a empresa deveria conseguir responder:
- o sistema melhora um indicador do processo?
- a qualidade é suficiente para o nível de autonomia atual?
- os erros são conhecidos e controláveis?
- os dados e permissões estão organizados?
- o custo faz sentido para o valor da tarefa?
- a equipe consegue investigar uma execução?
- existe um plano claro para a próxima etapa?
Se as respostas dependem de opinião ou entusiasmo, ainda faltam evidências.
Onde a Foyth Tech entra
Muitas empresas sabem que a IA pode ajudar, mas não querem gastar meses construindo um assistente genérico para depois procurar uma utilidade.
A Foyth Tech começa pelo processo. Mapeamos a tarefa, avaliamos dados e riscos, definimos o recorte do piloto e construímos uma solução que possa ser testada com casos reais.
O projeto pode envolver classificação, extração, busca em documentos, preparação de respostas, workflows ou agentes. A arquitetura depende da necessidade encontrada.
Se existe uma tarefa repetitiva consumindo tempo da sua equipe, converse com a Foyth Tech. A primeira conversa serve para descobrir se IA é mesmo a ferramenta certa e qual seria o menor teste útil.
