A automação industrial deixou de ser novidade — mas um erro silencioso ainda compromete boa parte dos projetos antes mesmo de qualquer modelo de inteligência artificial entrar em ação.
Imagine um motorista que envia a foto do documento de entrega pelo celular. O sistema recebe o arquivo, interpreta como confirmação e avança o status da carga. Horas depois, alguém percebe que a imagem era de outra parada, o envio estava duplicado, e a mercadoria não saiu do lugar. Nada quebrou. Nenhum erro foi lançado. O software fez exatamente o que foi programado para fazer — e esse é justamente o problema. 😅
Em operações reais, documentos chegam atrasados, fora de ordem e por canais não oficiais como o WhatsApp. Funcionários experientes desenvolvem métodos próprios para contornar essas situações. E quase nada disso aparece no diagrama oficial de processos. Quando uma empresa decide automatizar antes de entender como o trabalho realmente acontece, ela corre o risco de codificar a versão errada do próprio processo — e aí nenhum modelo de inteligência artificial vai salvar a situação.
Esse cenário está no centro de um debate crescente sobre descoberta de processo em ambientes corporativos, especialmente à medida que países como a Coreia do Sul aceleram a adoção de IA nas fábricas com metas ambiciosas para os próximos anos. A questão que fica é direta: o que exatamente está sendo automatizado?
A Coreia do Sul aposta pesado em IA industrial — e levanta uma questão mais básica
A Coreia do Sul está levando a inteligência artificial industrial cada vez mais fundo em ambientes reais de produção. Em agosto de 2026, o ministério da indústria informou que o programa AI Factory já havia apoiado cerca de 170 locais de trabalho. Entre 42 sites que avançaram o suficiente para serem avaliados, a produtividade média subiu 30,1% e as taxas de defeitos caíram 15,5%. O governo mira estabelecer 500 fábricas de IA até 2030.
O mesmo plano trata de uma necessidade menos visível da IA na manufatura. A Coreia pretende converter a experiência e o conhecimento prático de técnicos mestres e trabalhadores qualificados em conjuntos de dados que possam apoiar o desenvolvimento de modelos e soluções de IA. O ministério ligou esse esforço à perda do conhecimento tácito de manufatura, à medida que os trabalhadores experientes diminuem em número e as gerações mudam.
Capturar conhecimento, no entanto, não gera automaticamente uma especificação de automação utilizável. Uma empresa ainda precisa determinar como o trabalho realmente avança quando a documentação está incompleta, quando as sequências padrão quebram, quando os funcionários improvisam ou quando sinais operacionais carregam significados que o processo formal nunca definiu.
O mapa não é o território — e o processo documentado raramente é o processo real
Existe uma diferença enorme entre o fluxo de trabalho que aparece no manual da empresa e o que de fato acontece no chão de fábrica todo dia. Diagramas são construídos em reuniões, por pessoas que descrevem como as coisas deveriam funcionar — não necessariamente como funcionam quando o sistema trava, quando falta um aprovador ou quando o fornecedor envia o documento com o campo errado. Essa lacuna, que parece pequena no papel, vira um abismo quando uma solução de automação é construída com base nessa versão idealizada da realidade.
Esse é justamente o problema que Deniz Cihan Tiryaki encontrou ao construir sistemas em logística e automação empresarial. Tiryaki, que atua como Venture CTO e Product Systems Architect na Venture Labs e cofundador da DocsFra, contou ao KoreaTechDesk que essa lacuna surgiu repetidamente em seu trabalho.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
O processo documentado por uma organização raramente é o processo completo que realmente conduz a operação. Na prática, o conhecimento crítico costuma viver nas exceções, na experiência dos funcionários, na comunicação informal e nas decisões tomadas sob pressão.
Em um projeto de logística, o fluxo formal parecia bem simples: uma remessa era criada, o motorista coletava a carga, a mercadoria era transportada, um documento de entrega era assinado e devolvido, e a viagem era encerrada. Na prática, porém, a operação era muito mais variável. Documentos podiam chegar por aplicativos de mensagem e nem sempre na ordem esperada. Motoristas podiam enviar um documento para o ponto de entrega errado, submeter duplicatas ou fornecer informações faltantes horas depois.
É aqui que entra o conceito de descoberta de processo — ou process discovery, como é amplamente chamado nas discussões técnicas internacionais. A ideia central é mapear o processo a partir de dados reais de execução, como logs de sistemas, registros de acesso, timestamps de aprovação e até padrões de comunicação entre equipes, em vez de depender apenas de entrevistas e fluxogramas feitos à mão. Ferramentas modernas de process mining conseguem reconstruir automaticamente os caminhos que as tarefas percorrem dentro de uma organização, revelando desvios, gargalos e variações que ninguém havia documentado formalmente.
Um diagrama pode estar correto e ainda descrever a realidade errada
Quando esse mapeamento é feito de verdade, os resultados costumam surpreender até os gestores mais experientes. Um processo que parecia linear no diagrama pode ter dezenas de variações reais, cada uma criada por um time diferente para resolver um problema específico que surgiu em campo. Ignorar isso ao projetar um fluxo de trabalho automatizado significa construir uma solução que vai funcionar bem em uma parte dos casos e travar silenciosamente nos outros — exatamente como no exemplo do motorista que enviou a foto errada.
Segundo Tiryaki, se aquele diagrama de processo tivesse sido convertido diretamente em software, o sistema construído teria sido o errado. A equipe optou por comparar o procedimento formal com registros de sistema, registros de comunicação e as ações que os funcionários experientes tomavam quando o fluxo normal quebrava. A reconstrução focou em quatro perguntas: o que aconteceu, quais evidências estavam disponíveis, a que conclusão o funcionário chegou e qual ação se seguiu.
As empresas não deveriam automatizar seus procedimentos padrão diretamente. Elas deveriam primeiro descobrir a realidade operacional que existe por baixo deles.
Inteligência artificial aplicada ao processo: quando ela ajuda e quando ela complica
A inteligência artificial entrou com força nas discussões sobre automação industrial prometendo resolver justamente esse tipo de problema. Modelos de machine learning conseguem identificar padrões em grandes volumes de dados operacionais, antecipar falhas, sugerir otimizações e até adaptar o fluxo de trabalho em tempo real com base no comportamento observado. Na teoria, parece a solução perfeita. Na prática, a IA só entrega esse valor quando os dados que ela consome refletem o processo real — não a versão do PowerPoint. 🤖
Um exemplo concreto vem da Indústria 4.0, onde sensores IoT geram volumes massivos de dados sobre cada etapa da produção. Esses dados alimentam modelos preditivos que conseguem identificar, por exemplo, que uma máquina tende a falhar após determinado padrão de temperatura e vibração, bem antes que qualquer alarme convencional dispare. Esse uso da IA é poderoso justamente porque parte de dados brutos do mundo real, não de um processo idealizado. O modelo aprende com o que acontece de verdade, incluindo os desvios, as adaptações e as exceções que os operadores criaram ao longo dos anos.
O problema surge quando as empresas tentam usar IA para automatizar tarefas administrativas ou fluxos de trabalho de aprovação sem antes fazer esse mapeamento honesto. Um modelo de linguagem treinado para processar solicitações vai aprender com os dados históricos disponíveis — e se esses dados refletem um processo cheio de inconsistências e adaptações não documentadas, o modelo vai aprender exatamente essas inconsistências. A automação então amplifica os problemas em vez de eliminá-los, porque passa a executá-los em escala e velocidade que nenhum humano conseguiria.
Por que os logs de sistema não são suficientes
Pesquisas recentes sobre processos de negócio reforçam o risco por trás da experiência de Tiryaki. Um estudo de 2025 publicado no periódico Business & Information Systems Engineering examinou 13 adaptações de trabalho em quatro organizações e identificou descompassos entre modelos formais de processo, dados de eventos registrados e a execução real no mundo real. Algumas dessas adaptações feitas pelos funcionários não estavam adequadamente representadas nos sistemas de informação usados para analisar o processo.
Isso cria três versões diferentes do mesmo fluxo dentro de uma empresa. O processo prescrito descreve o que a organização diz que deveria acontecer. Os registros digitais mostram o que os sistemas de informação de fato capturaram. E o processo executado reflete o que funcionários e sistemas realmente fizeram, incluindo adaptações e exceções. Nenhuma dessas versões, sozinha, deveria ser tratada automaticamente como o retrato completo de como a operação funciona.
O movimento global e o que ele revela sobre prioridades
A Coreia do Sul é um dos casos mais emblemáticos quando o assunto é adoção acelerada de IA na indústria. O país anunciou metas agressivas para integrar inteligência artificial em processos fabris até 2030, com investimentos públicos e privados direcionados especialmente para manufatura avançada e logística. O movimento faz sentido dado o perfil industrial do país — mas especialistas em descoberta de processo alertam que a velocidade de adoção pode estar à frente da maturidade operacional necessária para sustentar esses sistemas.
Esse não é um problema exclusivo da Coreia do Sul. No Brasil, na Europa e nos Estados Unidos, empresas que investiram pesado em plataformas de automação durante a pandemia estão agora revisando esses projetos porque os resultados ficaram abaixo do esperado. Em muitos casos, a tecnologia funcionou — o problema estava na fundação. Os processos que foram automatizados não eram os processos reais, e os dados usados para treinar os modelos de IA eram incompletos ou distorcidos pela maneira como os sistemas legados registravam informações.
Exceções revelam as regras que os casos normais escondem
O julgamento tácito cria outro desafio, porque funcionários experientes nem sempre sabem explicar decisões que já tomaram milhares de vezes. Como Tiryaki descreve, perguntar diretamente a um especialista como uma decisão é tomada pode gerar uma resposta como o documento não parece certo. Isso pode ser preciso para o especialista, mas oferece pouco que uma equipe de engenharia consiga traduzir em comportamento de sistema.
Por isso a abordagem dele é trabalhar de trás para frente, a partir de casos reais. As equipes podem comparar duas transações parecidas e perguntar por que uma foi aprovada e a outra rejeitada. Podem mudar uma única condição e verificar se a decisão mudaria. O método transforma o julgamento intuitivo em condições observáveis, como fatos, limites, exceções, incertezas e gatilhos de ação.
As exceções são particularmente úteis. Dez casos incomuns às vezes ensinam mais do que cem casos normais.
Para a descoberta de processo apoiada por IA, uma exceção não deveria ser imediatamente tratada como dado sujo que precisa ser removido. Ela pode representar mau uso, mas também pode expor uma condição operacional legítima que o fluxo formal deixou de capturar.
Um evento digital nem sempre é um evento de negócio
Tiryaki encontrou as consequências desse problema em um fluxo de documentos de logística. Naquele momento, o sistema assumia que o upload de um documento pelo motorista significava que a operação subjacente havia avançado. Essa interpretação parecia razoável até que os motoristas começaram a enviar imagens duplicadas, subir documentos para a parada errada ou mandar versões corrigidas mais tarde.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Um operador humano entende que outro upload não significa necessariamente outro evento operacional. O software não. Cada envio recebido corria o risco de ser interpretado como nova atividade, o que poderia disparar processamento duplicado, avanço incorreto do fluxo ou notificações desnecessárias. A arquitetura precisou separar dois conceitos que inicialmente eram tratados como um só: a submissão do documento e a transição de estado operacional.
Registrar um evento com precisão não é a mesma coisa que entender o que aquele evento significa para o negócio. Um arquivo que chega às 14h02 confirma apenas que o sistema recebeu um arquivo naquele horário. Não prova que uma remessa foi entregue, que uma aprovação foi concluída ou que uma inspeção passou.
Process discovery como base para automação que funciona de verdade
A descoberta de processo bem feita não é um projeto de consultoria que termina com um relatório engavetado. É uma prática contínua que alimenta a evolução dos sistemas de automação ao longo do tempo. Ferramentas como Celonis, UiPath Process Mining e SAP Signavio permitem que as organizações monitorem seus processos em tempo real, identificando onde os desvios estão acontecendo, por que estão acontecendo e qual impacto eles têm sobre a operação. Essa visibilidade é o que separa uma automação que melhora com o tempo de uma que vai acumulando dívida técnica e operacional silenciosamente.
Na prática, o fluxo mais eficiente começa com a coleta de dados dos sistemas existentes — ERPs, CRMs, plataformas de logística, sistemas de aprovação — e a reconstrução automática dos caminhos que as transações percorreram. Esse mapa, gerado a partir de dados reais, revela variantes do processo que podem ser agrupadas, simplificadas ou tratadas com lógicas específicas dentro do fluxo de trabalho automatizado. A inteligência artificial entra depois, para classificar casos, prever desvios e sugerir rotas alternativas quando o contexto muda — com uma base sólida embaixo.
Tiryaki resume o limite com cuidado: não automatize o especialista, automatize aquilo que pode ser tornado explícito sobre o processo de decisão do especialista. Essa abordagem evita a suposição de que todo julgamento experiente precisa virar uma regra determinística de software. Algum conhecimento pode ser formalizado. Outros casos permanecem incertos porque a própria evidência é incompleta ou a situação é genuinamente incomum.
O resultado é um sistema de automação que não quebra quando o motorista envia a foto errada, porque foi projetado sabendo que isso acontece. Ele reconhece o padrão, sinaliza a inconsistência e redireciona o caso para revisão humana antes de avançar o status da carga. Pequeno no detalhe, mas enorme no impacto operacional — especialmente quando multiplicado por milhares de transações por dia em um ambiente de Indústria 4.0. 🏭
O impulso da Coreia rumo às fábricas de IA vai criar mais oportunidades para automatizar decisões que antes dependiam de pessoas. A qualidade desses sistemas dependerá de modelos, infraestrutura e dados, mas existe uma pergunta anterior que pode determinar silenciosamente tudo o que vem depois: alguém precisa decidir o que o processo realmente é. E a falha de automação mais perigosa pode ser justamente aquela que parece um sucesso — o software roda exatamente como projetado, enquanto impõe silenciosamente um processo que nunca correspondeu ao negócio de verdade.
A automação que funciona não começa com a escolha da tecnologia. Começa com a honestidade sobre como o trabalho realmente acontece.
