Como reduzir um processo de 3 dias para 2 horas com IA?

Para reduzir um processo de três dias para duas horas com IA, você não automatiza as tarefas que as pessoas fazem: você troca o insumo do processo por texto e desenha o fluxo de trás pra frente, a partir do artefato final que o cliente recebe. Na Frons, entre abril e julho de 2026, aplicamos isso ao processamento de aulas gravadas e o ciclo caiu de aproximadamente três dias com três pessoas para cerca de duas horas sem nenhuma delas no fluxo, com 18 aulas convertidas em cerca de 199 blocos temáticos. O preço foi aceitar 22% de processamentos com falha no período e dois meses de scripts improvisados antes de qualquer coisa virar processo previsível.

O que exatamente levava três dias e por que isso não era um problema de edição?

Um processo de três dias raramente é lento por causa de execução. Ele é lento por causa de espera entre pessoas que precisam entender alguma coisa antes de agir.

Na Frons, até março de 2026, uma aula gravada percorria este caminho até chegar ao aluno. A gravação caía do Zoom e ia para o editor de vídeo. Ele cortava olhando a imagem, sem ser técnico no assunto da aula, então o ponto de corte saía errado com frequência: ele cortava onde a câmera mudava, não onde o professor mudava de assunto. Depois alguém do time assistia os cortes para entender os temas e renomear os arquivos um a um. Dali ia para o design, que produzia a thumbnail de cada bloco. E do design para o suporte, que subia tudo na plataforma.

Quatro passagens de bastão, três pessoas no mínimo, e um aluno esperando três dias por uma aula que ele já tinha assistido ao vivo na terça-feira.

O que eu demorei a enxergar é que nenhuma dessas etapas era demorada em si. Cortar um vídeo leva minutos. Fazer uma capa leva minutos. Subir arquivo leva minutos. O que consumia os três dias era o intervalo em que cada pessoa esperava a anterior e, principalmente, o tempo que cada uma gastava para entender o conteúdo antes de conseguir executar a parte dela. O editor precisava entender do que a aula falava. O time precisava reassistir para nomear. O design precisava saber o tema para desenhar a capa.

Custo de entendimento, repetido três vezes sobre o mesmo material. Esse é o gargalo real da maioria dos processos que passam por várias mãos, e ele é invisível em qualquer mapeamento que só cronometre tarefa.

Quais foram os números antes e depois na Frons?

Os dados abaixo saem do log interno do pipeline de processamento de aulas da Frons e cobrem o período de abril a julho de 2026. São 23 processamentos registrados, 18 aulas concluídas e cerca de 199 blocos temáticos gerados.

O número que não me favorece está na penúltima linha. Cerca de 22% dos processamentos registrados falharam em algum ponto, e o pipeline parou duas vezes em silêncio, sem avisar ninguém. Eu publico esse número junto com os outros porque case de automação sem taxa de erro é folheto, e quem for copiar o método precisa saber o tamanho do buraco antes de pisar nele.

Como o corte deixou de exigir um editor e passou a exigir uma transcrição?

O corte de vídeo na Frons deixou de ser tarefa de edição e virou leitura de texto. Hoje a IA lê a transcrição inteira da aula, identifica onde o professor muda de assunto, nomeia cada bloco e devolve a minutagem. O software de vídeo apenas executa o corte nos pontos indicados.

O erro de corte sumiu, e ele não sumiu porque o editor melhorou. Sumiu porque cortar deixou de exigir entender o vídeo e passou a exigir entender o texto. Texto é exatamente o que um modelo de linguagem lê melhor do que qualquer pessoa lendo rápido.

Essa é a troca central e ela se transfere para praticamente qualquer área. Enquanto o insumo do seu processo for imagem, áudio, conversa de corredor ou conhecimento na cabeça de alguém, a máquina não entra. No momento em que o insumo vira texto estruturado, a máquina entra na etapa mais cara, que é a de compreensão, e sobra para as ferramentas comuns só a execução mecânica.

Um gerente de RH tem o mesmo movimento disponível: a entrevista de desligamento que hoje mora na memória de quem conduziu vira texto e passa a alimentar relatório, plano de ação e alerta de turnover. Um gerente de fábrica tem o mesmo: o relato verbal do turno vira formulário curto e passa a alimentar o histórico de parada de máquina. O insumo muda de natureza e o processo inteiro muda de custo.

Por que a transcrição virou a primeira etapa e não um extra do processo?

Uma fonte única de verdade é um documento do qual todas as etapas seguintes derivam, sem que nenhuma delas produza sua própria versão dos fatos.

No fluxo atual da Frons, a aula baixa do Zoom e em cerca de trinta segundos vira texto. Tudo que vem depois deriva desse texto: os temas identificados, os nomes dos arquivos, a capa de cada bloco e o PDF de insights, que sai em versões diferentes por perfil de aluno, do analista ao gestor.

Quando a fonte de verdade é uma só, as etapas param de discordar entre si. No processo antigo isso acontecia toda semana: o editor via uma aula, o time que renomeava via outra e o design batizava uma terceira. Ninguém estava errado, cada um tinha construído seu próprio entendimento a partir do mesmo vídeo, em momentos diferentes, com atenção diferente. O retrabalho nascia dessa divergência silenciosa, e não de falta de capricho.

Aqui vale uma distinção que eu levei tempo para fazer. Transcrever a aula parecia um subproduto simpático, algo que a gente faria depois, para acessibilidade. Colocá-la como primeira etapa obrigatória mudou a arquitetura inteira, porque transformou um arquivo de mídia em um documento consultável por todas as etapas ao mesmo tempo. O custo dessa decisão foi de trinta segundos por aula. O retorno foi a eliminação de quatro passagens de bastão.

O que significa desenhar um fluxo de trás pra frente?

Desenhar um fluxo de trás pra frente significa começar pela lista dos artefatos que o destinatário final precisa receber e só aceitar no processo as etapas que produzem um desses artefatos.

A pergunta de partida na Frons não foi “como automatizar a edição de vídeo”. Foi “o que precisa existir na pasta final quando isso acabar”. A resposta foi específica: vídeo separado por tema, capa padronizada por bloco e material de apoio por perfil de aluno.

Com essa lista na mesa, cada etapa candidata passou por um teste único. Ela deixa um desses artefatos na pasta final? Se sim, entra. Se não, fica de fora. É por isso que o pipeline atual tem tão poucas partes, e é por isso que ele não tem etapa de revisão intermediária, reunião de alinhamento ou aprovação de meio de caminho. Nenhuma delas produzia artefato.

Esse teste é brutal quando você aplica em processo administrativo. Boa parte das etapas de um fechamento de mês, de uma admissão ou de uma aprovação de proposta existe para dar conforto a alguém, não para produzir um item entregável. Elas sobrevivem porque o processo foi desenhado de frente pra trás, acumulando controle a cada incidente. Desenhar de trás pra frente devolve a pergunta certa: se essa etapa some, falta alguma coisa na mão de quem recebe?

Por que aceitar que a máquina erre mais que as pessoas no começo?

A decisão mais difícil desse projeto não foi técnica. Foi aceitar tirar as três pessoas do fluxo justamente nas primeiras semanas, quando a máquina errava mais do que elas.

Maio de 2026 teve seis reprocessamentos no log. Aula que saiu com bloco cortado no lugar errado, PDF que veio raso, arquivo que precisou rodar de novo. Naquele mês, um observador honesto diria que o processo antigo entregava melhor.

Se a regra fosse “o humano confere tudo até a máquina ficar boa”, o humano estaria conferindo até hoje. E o custo das três pessoas continuaria inteiro dentro do processo, apenas escondido atrás de uma palavra respeitável, que é revisão. Revisão permanente é o disfarce mais comum do trabalho que a automação deveria ter eliminado. O gestor sente que reduziu, o organograma diz que reduziu, o calendário das pessoas continua igual.

A escolha que quase ninguém autoriza é essa: aceitar um período pior de propósito para comprar todos os períodos seguintes. Ela exige duas coisas concretas. Primeiro, um limite declarado de dano, porque aceitar erro não é aceitar prejuízo indefinido; no nosso caso o dano máximo era atraso na entrega de um bloco, nunca conteúdo errado no ar. Segundo, uma data de reavaliação, porque período pior sem prazo vira processo pior permanente.

Na minha visão, é aqui que a maioria dos projetos de automação morre, e morre de forma silenciosa. A ferramenta funciona, o piloto roda, e alguém decide manter a conferência humana “só por enquanto”. Esse “só por enquanto” tem três anos de idade em muita empresa que eu conheço.

Qual é o pré-requisito invisível que ninguém copia dos cases de automação?

O pré-requisito do pipeline da Frons era organizacional, não tecnológico. As três contas de Zoom da instituição já estavam centralizadas, e as aulas já seguiam padrão de gravação e de nomenclatura antes de existir qualquer linha de código.

O download automático só funciona porque a máquina sabe onde procurar e o que cada gravação significa. Quem tem aula espalhada na conta pessoal de cada professor, com nome livre, não trava na IA. Trava um passo antes dela, naquele que ninguém acha glamouroso: arrumar a casa.

Organização não rende post, então ela fica invisível em todo case que você lê por aí. O texto começa na ferramenta e termina no resultado, e o leitor conclui que comprar a ferramenta reproduz o resultado. Não reproduz. O que reproduz é a base de dados minimamente padronizada que estava lá antes.

Vale traduzir isso para outros contextos, porque o formato do pré-requisito muda mas a natureza é sempre a mesma. Em RH, é ter os currículos e as fichas de admissão no mesmo repositório, com campos iguais, em vez de espalhados em caixas de e-mail de cada recrutador. No comercial, é ter as propostas com estrutura comum, em vez de cada vendedor com seu modelo pessoal. Na indústria, é ter o apontamento de parada com a mesma lista de causas em todos os turnos.

Em todos os casos a pergunta é idêntica: a máquina consegue saber onde procurar e o que cada arquivo significa, sem perguntar para uma pessoa? Enquanto a resposta for não, qualquer investimento em IA vai render demonstração bonita e nenhum processo novo.

Como foram os dois meses entre a ideia e o processo funcionando?

Do jeito que esse tipo de caso costuma ser contado, parece que a gente desenhou o fluxo e ele funcionou. Não foi assim, e a pasta de logs entrega a verdade.

Em abril e maio de 2026 não existia um pipeline na Frons. Existia um script por turma. Um para o pessoal de Business Analytics, um para o de Gestão de Risco, um para o Projetando. Cada turma tinha o seu arquivo, com o seu jeitinho, porque toda vez que uma aula quebrava eu preferia criar um script novo a arrumar o antigo. Tinha até um arquivo chamado executar_amanha, que é exatamente o que o nome diz: rodar de novo amanhã e torcer.

Os nomes dos logs de maio contam o resto da história. Tem um chamado retry. Tem um chamado retry2. Tem um BA_retry, e logo abaixo um BA_only, que foi quando eu desisti de processar o lote inteiro e fui rodar uma turma só. E tem um arquivo no meio do projeto onde eu salvava a última resposta crua da IA, que era para onde eu corria toda vez que o resultado vinha estranho e eu precisava ver o que ela tinha respondido de verdade.

Só em junho isso virou um comando único, com um parâmetro de quantos dias processar. Foram dois meses entre a ideia e a coisa funcionando de forma chata e previsível, que é exatamente como processo bom se parece quando está pronto.

Eu conto isso porque a distância entre o slide bonito e a pasta de logs é onde mora quase todo projeto de automação que você vai começar. A fase de gambiarra não é sintoma de incompetência, ela é a fase em que você descobre quais exceções o processo real tem e que nenhum mapeamento previu. Se os seus dois primeiros meses forem confusos, você não está atrasado. Está no meio.

O que deu errado depois que o processo já estava rodando?

Cinco dos vinte e três processamentos registrados entre abril e julho de 2026 falharam em algum ponto, cerca de 22%. Duas falhas merecem descrição, porque elas não foram erro de modelo nem de código.

Em junho, a cota da ferramenta de transcrição estourou no meio de um lote e o run morreu com a aula pela metade. O arquivo existia, incompleto, e nada no sistema indicava que aquilo era um pedaço.

Em julho, a chave de API de IA ficou sem saldo e o pipeline parou em silêncio. Não houve erro na tela, não houve e-mail, não houve nada. A parada só apareceu quando alguém sentiu falta do material que deveria estar na plataforma.

O contorno para os dois casos não foi técnico. Foi de processo. Falha agora aparece em um lugar que alguém olha todos os dias, e existe um comando de reprocessamento que recupera lote perdido sem obrigar a refazer o mês inteiro. Duas mudanças baratas, nenhuma delas em modelo de IA.

A lição que eu tiro dessas duas paradas é a que mais custa dinheiro nas empresas que estão automatizando agora. Automação sem monitoramento funciona como um estagiário invisível: trabalha bem até o dia em que some, e ninguém percebe que sumiu. Enquanto tinha três pessoas no fluxo, a falha se anunciava sozinha, porque alguém ficava sem trabalho para fazer. Quando você tira as pessoas, você tira também os sensores humanos, e precisa repor isso de forma explícita antes de comemorar a redução de tempo.

Como aplicar esse método em qualquer processo da sua empresa?

Você provavelmente não tem aula para cortar, e não é disso que se trata. O que se copia aqui é o caminho para descobrir onde a máquina entra no seu processo. Ele serve para admissão de funcionário, fechamento de mês, proposta comercial, ordem de serviço, laudo, atendimento de garantia, o que for seu.

Passo 1. Escolha um processo que passa por três ou mais pessoas e liste as passagens de bastão. Uma linha por passagem, no formato “quem entrega para quem, e o quê”. Faça hoje, sozinho, em vinte minutos, sem reunião. Artefato: uma lista de três a seis linhas em um documento.

Passo 2. Em cada passagem, escreva o que aquela pessoa precisa entender antes de conseguir executar. O gargalo quase nunca é executar, é entender. Na Frons, o editor precisava entender do que a aula falava, e era isso que custava três dias, não o corte em si. Artefato: uma coluna nova na sua lista, com a frase “precisa entender que…”.

Passo 3. Para cada entendimento, pergunte se ele já existe escrito em algum lugar. Ata, e-mail, formulário, contrato, planilha, laudo, transcrição, ficha de apontamento. Onde já existe texto, você tem a matéria-prima e pode testar hoje. Onde não existe, criar esse texto é o seu primeiro passo, e é o mais barato de todos. Artefato: cada linha da lista marcada com “existe texto” ou “não existe texto”.

Passo 4. Pegue só a passagem mais lenta e faça um teste único. Cole o texto correspondente em uma IA e peça que ela entregue exatamente o que a próxima pessoa da fila receberia pronto. Uma passagem, um teste, esta semana. Artefato: o resultado do teste colado lado a lado com o que a pessoa entrega hoje, para comparação direta.

Passo 5. Liste os artefatos que o destinatário final precisa receber e corte do processo toda etapa que não produz um deles. Escreva a lista de entregáveis antes de olhar para o fluxo atual, senão você vai justificar o que já existe. Artefato: lista de entregáveis finais e, ao lado, as etapas atuais marcadas como “produz” ou “não produz”.

Passo 6. Defina o dano máximo aceitável e a data de reavaliação antes de tirar gente do fluxo. Escreva as duas frases: “o pior que pode acontecer é X” e “em [data] eu decido se mantenho ou volto atrás”. Sem isso, você mantém a conferência humana para sempre e não reduz nada. Artefato: as duas frases no mesmo documento, com data.

Passo 7. Antes de comemorar, defina onde a falha vai aparecer e quem olha aquilo todo dia. Pode ser um canal no seu comunicador interno, uma planilha compartilhada ou um relatório na primeira reunião do dia. Nomeie a pessoa. Artefato: o local de alerta criado e o nome de quem confere registrado.

Passo 8. Em duas semanas, conte quantas passagens de bastão sumiram. Se nenhuma sumiu, o gargalo que você escolheu não era o certo. Volte ao passo 1 com outro processo, não com outra ferramenta. Artefato: a lista original do passo 1, com as linhas eliminadas riscadas.

Se você não comanda um processo com várias pessoas, aplique o mesmo raciocínio à sua própria semana. Onde você fica esperando alguém entender alguma coisa para poder seguir? Essa espera é o seu equivalente aos três dias.

O que esse caso ensina sobre automação que não aparece nos cases prontos?

Três conclusões, na ordem em que elas custaram caro na Frons entre abril e julho de 2026.

A primeira: o ganho não veio de fazer as tarefas mais rápido, veio de eliminar a necessidade de entender o mesmo conteúdo três vezes. Quem tenta acelerar a execução de cada etapa chega a um processo de dois dias e meio. Quem ataca o custo de entendimento chega a duas horas.

A segunda: o pré-requisito é sempre organizacional e sempre invisível. Contas centralizadas, padrão de nome, padrão de gravação. Nada disso aparece em apresentação e tudo isso decide se o projeto vai existir. Arrumar a casa é o trabalho que ninguém quer assinar e sem o qual nada disso teria rodado.

A terceira: o processo só ficou bom quando ficou chato. Enquanto tinha script por turma, arquivo chamado executar_amanha e três logs de retry na mesma pasta, existia atividade e não existia processo. Disciplina e constância transformaram gambiarra em comando único em junho, e é essa parte que não cabe em um post, porque leva dois meses e não tem foto bonita.

Nós construímos essa máquina em quatro meses, com 18 aulas processadas, cerca de 199 blocos entregues e 22% de falhas registradas no caminho. O número de falhas está publicado junto com o resto de propósito. Quem for copiar precisa saber que o caminho inclui os dois meses de pasta bagunçada, e que isso não é o desvio. É o percurso.

Perguntas frequentes

Quanto tempo leva para automatizar um processo com IA na prática?

Na Frons, entre abril e julho de 2026, foram dois meses entre a primeira versão funcional e o processo virar um comando único e previsível. Abril e maio foram feitos de scripts separados por turma, reprocessamentos e arquivos com nomes como retry2, e só em junho o fluxo ficou estável. A fase confusa não é sintoma de erro, é onde você descobre as exceções que nenhum mapeamento previu.

Por que automações de IA param de funcionar sem ninguém perceber?

Porque quando você tira as pessoas do fluxo, você tira junto os sensores humanos que denunciavam a falha. No pipeline da Frons, em julho de 2026, a chave de API ficou sem saldo e o processo parou em silêncio até alguém sentir falta do material. A correção não é técnica: é definir um lugar onde a falha aparece e nomear quem olha aquele lugar todos os dias.

Qual é o pré-requisito para usar IA em um processo interno da empresa?

O pré-requisito é organizacional: a máquina precisa saber onde procurar o arquivo e o que cada arquivo significa, sem perguntar para uma pessoa. Na Frons, as contas de Zoom já estavam centralizadas e as aulas já seguiam padrão de nome antes de existir qualquer código. Quem tem os dados espalhados em contas pessoais e nomes livres trava antes da IA, no passo de padronizar o repositório.

Como identificar o gargalo certo para automatizar com IA?

Liste as passagens de bastão do processo e escreva, em cada uma, o que aquela pessoa precisa entender antes de conseguir executar. O gargalo quase nunca é a execução, é o entendimento: na Frons, o editor de vídeo levava dias porque precisava compreender o assunto da aula, não porque cortar fosse demorado. Onde esse entendimento já existe em texto, a IA entra imediatamente.

Vale a pena tirar as pessoas do processo antes da IA estar boa?

Vale, desde que com dano máximo declarado e data de reavaliação. Na Frons, maio de 2026 teve seis reprocessamentos e a máquina errava mais que as três pessoas que saíram do fluxo, mas manter a conferência humana até a IA ficar perfeita mantém o custo inteiro dentro do processo, escondido atrás da palavra revisão. Aceitar um período pior de propósito é o que compra todos os períodos seguintes.

O que significa desenhar um processo de trás pra frente?

Significa listar primeiro os artefatos que o destinatário final precisa receber e só aceitar no fluxo as etapas que produzem um desses artefatos. Na Frons, a lista final era vídeo por tema, capa padronizada e PDF de insights por perfil de aluno, e toda etapa que não deixava uma dessas peças na pasta final ficou de fora. É por isso que o pipeline resultante tem poucas partes e nenhuma reunião de alinhamento no meio.