Quando uma diretoria decide que precisa de IA na operação, a primeira pergunta costuma ser qual ferramenta comprar ou qual demonstração assistir. São perguntas razoáveis, mas estão fora de ordem. Em uma grande empresa, o que decide se a IA chega a operar não é a ferramenta. É a sequência das primeiras decisões, e quem as toma.
A resposta curta: escolha um único processo com volume, regra explicável e dado em sistema; dê a ele um dono na operação; peça os acessos logo no início; meça como o processo funciona hoje; decida as regras de governança antes de construir; e só então escolha quem constrói e com qual plataforma. Um agente em produção nesse processo vale mais do que dez pilotos espalhados.
As seções abaixo detalham cada decisão, na ordem em que ela precisa ser tomada. O motivo de tantos projetos pararem na demonstração está no texto sobre por que projetos de IA morrem na POC. Aqui o assunto é o que fazer antes de chegar lá.
1. Escolha um processo, não uma tecnologia
O primeiro processo não precisa ser o mais importante da empresa. Precisa ser o que prova, com número, que a IA funciona na sua operação, e que ensina a empresa a fazer o segundo. Uma pergunta ajuda a encontrar candidatos: onde a sua operação tem fila? Fila é volume esperando decisão, e é ali que um agente costuma se pagar primeiro.
Na economia real, os candidatos costumam aparecer no pré-atendimento e na qualificação de contato comercial, na fila de solicitações que hoje depende de uma pessoa e em rotinas de back-office como cadastro de fornecedor e conciliação. Para escolher entre eles, aplique cinco testes:
- Acontece muito. O volume é suficiente para o ganho aparecer no indicador do mês, e não só em casos isolados.
- Tem regra que alguém consegue explicar. Mesmo com exceções, quem executa sabe dizer como decide. Se ninguém consegue descrever o processo, o problema é de processo, e o agente não vai resolver.
- O dado está em sistema. A informação que a pessoa usa para decidir está no ERP, no CRM, numa base ou em documento, e não só na memória de quem faz.
- O erro é recuperável. Se o agente errar, alguém percebe e corrige antes de o dano ficar caro. Decisão irreversível de alto valor não é lugar para o primeiro agente.
- Já existe um número que a diretoria acompanha. Ou, no mínimo, dá para medi-lo antes de começar.
Os processos que passam nos cinco testes ainda precisam ser ordenados. O critério que funciona é cruzar o valor do caso com a viabilidade de colocá-lo em produção:
| Valor do caso | Viabilidade alta | Viabilidade baixa |
|---|---|---|
| Alto | Comece aqui. | Segundo da fila. Comece agora a resolver o acesso ao dado, para ele estar pronto quando chegar a vez. |
| Baixo | Bom para o time aprender, fraco para convencer a diretoria. | Descarte, por enquanto. |
2. Dê nome a quem responde pelo resultado
Antes de falar com qualquer fornecedor, nomeie as pessoas. Projeto de IA sem dono na operação vira projeto de tecnologia, e projeto de tecnologia sem dono na operação vira demonstração. São quatro papéis, e todos precisam ter nome e sobrenome:
- Patrocinador executivo. O diretor que responde pelo indicador que o projeto vai mover e que tem autoridade para mudar o processo. Não precisa entender de IA. Precisa querer o número.
- Dono do processo. O gestor da área que conhece as exceções e sabe por que o processo é como é. É quem valida se o agente está decidindo certo.
- Responsável por acessos e sistemas. A pessoa de TI que consegue liberar credencial, API e ambiente. Sem ela, o cronograma depende de favores.
- Ponto focal de risco e privacidade. Alguém de segurança, jurídico ou compliance que participa das regras desde o começo, e não só da aprovação final.
O erro mais comum aqui é de endereço. Quando o projeto nasce numa área central de tecnologia ou de transformação digital e a operação é apenas consultada, ele tende a terminar tecnicamente correto e sem ninguém na operação que o queira. O patrocinador precisa estar onde o indicador mora.
3. Resolva dado e acesso antes de construir
O jeito mais concreto de mapear o que o agente vai precisar é acompanhar quem executa o processo hoje e anotar cada sistema, planilha e tela que a pessoa abre. Essa lista é o mapa de integração do agente. Para cada item dela, três perguntas: existe API ou conector? Quem concede o acesso? Há algum canal que precisa de homologação, como o WhatsApp oficial?
Peça os acessos no dia em que o processo for escolhido. Credencial, liberação de rede e homologação de canal seguem o ritmo da empresa, não o do projeto, e é aí que cronogramas estouram. O sistema legado sem API merece atenção própria, porque costuma virar um projeto dentro do projeto. O texto sobre integração com ERP, CRM e WhatsApp detalha os níveis possíveis.
Comece com leitura. Um agente que só consulta e recomenda já mostra se entende o processo, e o risco é baixo. A escrita nos sistemas entra depois, uma operação de cada vez, quando o acerto da leitura justificar.
4. Meça o processo como ele é hoje
Sem linha de base, nenhum resultado é demonstrável, e a conversa sobre continuar ou parar vira questão de opinião. Antes de mexer no processo, meça como ele funciona. Os quatro números do business case (volume, tempo por ocorrência, taxa de sucesso e custo do atraso) são o ponto de partida.
Com eles em mãos, escreva o critério de sucesso em uma frase com quatro partes: qual indicador, partindo de qual valor, até qual valor, medido por quem. E escreva também o critério de parada: o que, se acontecer, encerra o projeto. Se o patrocinador não assina essas duas frases, o projeto ainda não tem objetivo.
- Prefira indicador de resultado a indicador de atividade. Conversas atendidas é atividade. Casos resolvidos sem passar para uma pessoa é resultado.
- Use o número do sistema, não a estimativa. A estimativa de quem vive o processo costuma ser otimista ou pessimista, e nunca exata.
- Se o indicador não existe hoje, medi-lo é o primeiro entregável. Antes de qualquer agente.
5. Decida as regras antes da primeira linha de código
Governança decidida no começo vira requisito de desenho. Decidida no fim, vira motivo de atraso, porque as perguntas que a área de risco faz costumam exigir mudança de arquitetura, e não de configuração. São cinco perguntas, e todas têm resposta antes de o agente existir:
- O que o agente pode ler, e em quais sistemas.
- O que ele pode fazer sozinho, e o que só recomenda para uma pessoa executar.
- Onde uma pessoa aprova antes da ação, por tipo de operação ou por valor. O texto sobre human-in-the-loop trata dos critérios.
- Que dado não pode chegar ao modelo sem tratamento, como dado pessoal e informação sob sigilo.
- O que fica registrado, para reconstruir qualquer decisão do agente depois.
Leve as cinco ao ponto focal de risco e privacidade logo no começo, e não às vésperas do go-live. Há um efeito colateral útil: a área que ajudou a escrever as regras tende a aprovar o go-live com menos atrito, porque já sabe o que vai encontrar. O texto sobre governança de IA e LGPD traz o checklist completo.
6. Decida quem constrói, e quem fica depois
Esta decisão vem por último de propósito. Com processo, donos, acessos, linha de base e regras definidos, você sabe exatamente o que pedir a quem vai construir, e consegue comparar propostas pelo mesmo critério. Se você já sabe que vai trabalhar com um parceiro, ele pode entrar desde a primeira decisão; o ponto é que o parceiro seja escolhido pelo que o processo exige, e não o processo pelo que o parceiro oferece.
| Modelo | Quando faz sentido | O risco que precisa de resposta |
|---|---|---|
| Time interno | Existe engenheiro sênior com tempo dedicado, a IA é prioridade dele e o processo está documentado. | O tempo até produção e a dependência de quem construiu. |
| Parceiro que entrega e sai | Escopo fechado, processo estável e um time interno capaz de sustentar o agente depois. | O handoff: quem herda o agente não participou de nenhuma decisão. |
| Misto: parceiro constrói com o seu time | Primeiro projeto, prazo que importa e intenção de ter mais agentes depois. | Exige clareza sobre propriedade do que for construído e sobre como o conhecimento passa para dentro de casa. |
No primeiro projeto, a pergunta decisiva não é quem escreve o código. É quem sustenta o agente depois do go-live, e onde o conhecimento fica quando o projeto termina. A conta completa entre os modelos está em construir com framework ou comprar plataforma, e a régua para escolher a plataforma, em como avaliar uma plataforma de agentes de IA.
Os primeiros 90 dias
Pense nos primeiros 90 dias como horizonte de planejamento, e não como prazo prometido. O que importa é a ordem das etapas e o que precisa estar pronto ao fim de cada uma.
- Escolher e medir. Processo escolhido pelos cinco testes, os quatro donos nomeados, acessos pedidos, linha de base medida e critério de sucesso assinado pelo patrocinador. Regras de governança escritas junto com a área de risco.
- Construir e integrar. Agente ligado ao sistema real, e não a uma planilha. Testado com dado de verdade, incluindo as exceções. Começa lendo e recomendando; a ação continua com a pessoa até o acerto justificar mais autonomia.
- Colocar em produção e decidir o próximo passo. Go-live acompanhado de perto, com quem trabalha no processo treinado para operar junto do agente. O indicador é comparado com a linha de base, e a decisão é explícita: ampliar, ajustar ou parar. Se for ampliar, o segundo processo sai da mesma lista de candidatos.
Ao fim do período, a pergunta para a diretoria não é se a IA funciona. É quanto o indicador mudou contra a linha de base, e qual processo vem a seguir.
O que evitar no começo
- Começar pela demonstração mais vistosa. O caso que impressiona na reunião raramente é o que tem volume, dono e dado acessível. A demonstração aprova o orçamento e depois não tem para onde ir.
- Comprar a ferramenta antes de escolher o processo. Com a licença assinada, o time passa a procurar um problema que justifique a compra, e o processo é escolhido pelo que a ferramenta faz bem, e não pelo que a operação precisa.
- Espalhar o esforço em dez pilotos. Um piloto por diretoria agrada a todos e não entrega nenhum: acessos, donos e a atenção de quem sabe construir ficam divididos por dez, e no fim há dez demonstrações e nenhuma operação. Um agente em produção ensina mais do que dez em piloto, porque só a produção mostra o dado real, a exceção e o custo.
- Esperar o dado da empresa inteira ficar pronto. Um projeto de organizar todos os dados antes de começar com IA dificilmente termina. Organize o dado do processo escolhido; o resto se organiza processo a processo.
- Confundir acesso com operação. Liberar um assistente de IA para a empresa toda pode ser útil para quem escreve e pesquisa, mas não muda processo. O processo continua igual, só que com rascunhos mais rápidos.
Como a Runflow começa
Na Runflow, o começo segue essa mesma ordem. O primeiro passo é uma conversa de 45 minutos, sem custo, sobre a sua operação. Para quem avança, o diagnóstico prioriza os casos da operação por valor e viabilidade em cerca de duas semanas. Na fase de Descoberta, o Client Manager e o AI Deployment Strategist mapeiam os processos, entrevistam as pessoas envolvidas e entregam um roadmap de agentes priorizado por impacto e complexidade. Depois, o AI Solution Engineer constrói o primeiro agente, integra aos seus sistemas e o coloca em produção com o seu time, em semanas, não em meses.
Quem trabalha com o agente é treinado durante o go-live, e não num handoff no fim. A plataforma cobre criar, operar e mensurar cada agente, com aprovação humana onde o risco exige, cada execução registrada e reproduzível e métricas de negócio montadas a partir de eventos que o próprio agente emite, para comparar com a linha de base. O método completo está na página do time de AI Deployment. Se a conclusão do diagnóstico for que o seu caso não pede um agente, nós dizemos.
