Industrial automation is nothing new — but a silent mistake still undermines a huge number of projects before any artificial intelligence model even enters the picture.
Imagine a driver who snaps a photo of a delivery document and sends it from their phone. The system receives the file, interprets it as confirmation, and advances the shipment status. Hours later, someone realizes the image was from a different stop, the submission was a duplicate, and the goods never left the dock. Nothing broke. No error was thrown. The software did exactly what it was programmed to do — and that is precisely the problem. 😅
In real-world operations, documents arrive late, out of order, and through unofficial channels like WhatsApp. Experienced employees develop their own workarounds to handle these situations. And almost none of it shows up in the official process diagram. When a company decides to automate before understanding how work actually gets done, it risks encoding the wrong version of its own process — and at that point, no artificial intelligence model is going to save the day.
This scenario sits at the heart of a growing debate around process discovery in corporate environments, especially as countries like South Korea accelerate AI adoption in factories with ambitious targets for the years ahead. The question is straightforward: what exactly is being automated?
South Korea is going all in on industrial AI — and raising a more fundamental question
South Korea is pushing industrial artificial intelligence deeper and deeper into real production environments. By August 2026, the Ministry of Industry reported that the AI Factory program had supported roughly 170 workplaces. Among 42 sites that had progressed far enough to be evaluated, average productivity rose 30.1% and defect rates dropped 15.5%. The government is targeting 500 AI factories by 2030.
The same plan addresses a less visible need for AI in manufacturing. South Korea intends to convert the hands-on experience and practical knowledge of master technicians and skilled workers into datasets that can support AI model development and solutions. The ministry tied this effort to the loss of tacit manufacturing knowledge as experienced workers dwindle in number and generations shift.
Capturing knowledge, however, does not automatically produce a usable automation specification. A company still needs to figure out how work actually moves forward when documentation is incomplete, when standard sequences break down, when employees improvise, or when operational signals carry meanings the formal process never defined.
The map is not the territory — and the documented process is rarely the real one
There is a massive gap between the workflow that appears in a company manual and what actually happens on the factory floor every day. Diagrams are built in meetings, by people describing how things should work — not necessarily how they work when the system crashes, when an approver is missing, or when a supplier sends a document with the wrong field filled in. That gap, which looks minor on paper, becomes a chasm when an automation solution is built on top of that idealized version of reality.
This is exactly the problem Deniz Cihan Tiryaki encountered while building systems in logistics and enterprise automation. Tiryaki, who serves as Venture CTO and Product Systems Architect at Venture Labs and is co-founder of DocsFra, told KoreaTechDesk that this gap came up repeatedly in his work.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
The process an organization documents is rarely the complete process that actually drives the operation. In practice, critical knowledge tends to live in the exceptions, in employee experience, in informal communication, and in decisions made under pressure.
In one logistics project, the formal flow looked pretty straightforward: a shipment was created, the driver picked up the cargo, the goods were transported, a proof of delivery was signed and returned, and the trip was closed out. In practice, though, the operation was far more variable. Documents might arrive via messaging apps and not always in the expected order. Drivers might submit a document for the wrong delivery stop, send duplicates, or provide missing information hours later.
This is where the concept of process discovery comes into play. The core idea is to map the process based on actual execution data — system logs, access records, approval timestamps, and even communication patterns between teams — instead of relying solely on interviews and hand-drawn flowcharts. Modern process mining tools can automatically reconstruct the paths that tasks follow within an organization, revealing deviations, bottlenecks, and variations that nobody had formally documented.
A diagram can be perfectly accurate and still describe the wrong reality
When this mapping is done properly, the results tend to surprise even the most experienced managers. A process that looked linear on the diagram might have dozens of real-world variations, each created by a different team to solve a specific problem that came up in the field. Ignoring this when designing an automated workflow means building a solution that will work fine for some cases and silently stall on the rest — exactly like the example of the driver who sent the wrong photo.
According to Tiryaki, if that process diagram had been converted directly into software, the system they built would have been the wrong one. The team chose instead to compare the formal procedure against system records, communication logs, and the actions experienced employees took when the normal flow broke down. The reconstruction focused on four questions: what happened, what evidence was available, what conclusion the employee reached, and what action followed.
Companies should not automate their standard procedures directly. They should first discover the operational reality that exists underneath them.
AI applied to process: when it helps and when it makes things worse
Artificial intelligence has entered the industrial automation conversation in a big way, promising to solve exactly this kind of problem. Machine learning models can identify patterns in large volumes of operational data, anticipate failures, suggest optimizations, and even adapt the workflow in real time based on observed behavior. In theory, it sounds like the perfect solution. In practice, AI only delivers that value when the data it consumes reflects the real process — not the PowerPoint version. 🤖
A concrete example comes from Industry 4.0, where IoT sensors generate massive volumes of data about every stage of production. That data feeds predictive models capable of identifying, for instance, that a machine tends to fail after a certain pattern of temperature and vibration — well before any conventional alarm goes off. This use of AI is powerful precisely because it starts with raw, real-world data, not an idealized process. The model learns from what actually happens, including the deviations, adaptations, and exceptions that operators created over the years.
The problem comes when companies try to use AI to automate administrative tasks or approval workflows without doing that honest mapping first. A language model trained to process requests will learn from whatever historical data is available — and if that data reflects a process riddled with inconsistencies and undocumented workarounds, the model will learn exactly those inconsistencies. Automation then amplifies the problems instead of eliminating them, because it starts executing them at a scale and speed no human could match.
Why system logs alone are not enough
Recent research on business processes backs up the risk behind Tiryaki’s experience. A 2025 study published in the journal Business & Information Systems Engineering examined 13 work adaptations across four organizations and found mismatches between formal process models, recorded event data, and actual real-world execution. Some of those employee-driven adaptations were not adequately represented in the information systems used to analyze the process.
This creates three different versions of the same flow within a single company. The prescribed process describes what the organization says should happen. The digital records show what the information systems actually captured. And the executed process reflects what employees and systems really did, including adaptations and exceptions. None of these versions, on its own, should automatically be treated as the complete picture of how the operation works.
The global movement and what it reveals about priorities
South Korea is one of the most prominent cases when it comes to accelerated AI adoption in industry. The country announced aggressive targets for integrating artificial intelligence into manufacturing processes by 2030, with public and private investment aimed especially at advanced manufacturing and logistics. The move makes sense given the country’s industrial profile — but process discovery specialists warn that the pace of adoption may be running ahead of the operational maturity needed to sustain these systems.
This is not a problem unique to South Korea. In Brazil, Europe, and the United States, companies that invested heavily in automation platforms during the pandemic are now revisiting those projects because results fell short of expectations. In many cases, the technology worked — the problem was in the foundation. The processes that were automated were not the real processes, and the data used to train AI models was incomplete or distorted by the way legacy systems recorded information.
Exceptions reveal the rules that normal cases hide
Tacit judgment creates another challenge, because experienced employees cannot always explain decisions they have made thousands of times before. As Tiryaki describes it, asking a specialist directly how a decision is made might get you an answer like the document just does not look right. That may be accurate for the specialist, but it gives an engineering team very little to translate into system behavior.
That is why his approach is to work backward from real cases. Teams can compare two similar transactions and ask why one was approved and the other rejected. They can change a single condition and check whether the decision would change. The method transforms intuitive judgment into observable conditions — facts, thresholds, exceptions, uncertainties, and action triggers.
Exceptions are particularly useful. Ten unusual cases sometimes teach more than a hundred normal ones.
For AI-assisted process discovery, an exception should not be immediately treated as dirty data that needs to be removed. It might represent misuse, but it could also expose a legitimate operational condition that the formal flow failed to capture.
A digital event is not always a business event
Tiryaki ran into the consequences of this problem in a logistics document flow. At the time, the system assumed that a document upload by a driver meant the underlying operation had moved forward. That interpretation seemed reasonable until drivers started sending duplicate images, uploading documents for the wrong stop, or submitting corrected versions later on.
A human operator understands that another upload does not necessarily mean another operational event. Software does not. Every submission received risked being interpreted as new activity, which could trigger duplicate processing, incorrect flow advancement, or unnecessary notifications. The architecture had to separate two concepts that were initially treated as one: the document submission and the operational state transition.
Recording an event accurately is not the same thing as understanding what that event means for the business. A file that arrives at 2:02 PM only confirms that the system received a file at that time. It does not prove a shipment was delivered, an approval was completed, or an inspection passed.
Process discovery as the foundation for automation that actually works
Process discovery done right is not a consulting project that ends with a report gathering dust in a drawer. It is an ongoing practice that feeds the evolution of automation systems over time. Tools like Celonis, UiPath Process Mining, and SAP Signavio allow organizations to monitor their processes in real time, identifying where deviations are happening, why they are happening, and what impact they have on operations. That visibility is what separates automation that improves over time from automation that silently accumulates technical and operational debt.
In practice, the most effective approach starts with collecting data from existing systems — ERPs, CRMs, logistics platforms, approval systems — and automatically reconstructing the paths that transactions actually followed. That map, generated from real data, reveals process variants that can be grouped, simplified, or handled with specific logic within the automated workflow. Artificial intelligence comes in afterward, to classify cases, predict deviations, and suggest alternative routes when the context changes — all on top of a solid foundation.
Tiryaki sums up the boundary carefully: do not automate the expert — automate what can be made explicit about the expert’s decision-making process. This approach avoids the assumption that every piece of experienced judgment needs to become a deterministic software rule. Some knowledge can be formalized. Other cases remain uncertain because the evidence itself is incomplete or the situation is genuinely unusual.
The result is an automation system that does not break when the driver sends the wrong photo, because it was designed knowing that this happens. It recognizes the pattern, flags the inconsistency, and redirects the case for human review before advancing the shipment status. Small in detail, but massive in operational impact — especially when multiplied across thousands of transactions per day in an Industry 4.0 environment. 🏭
South Korea’s push toward AI factories will create more opportunities to automate decisions that previously depended on people. The quality of those systems will depend on models, infrastructure, and data, but there is a prior question that can silently determine everything that follows: someone needs to decide what the process actually is. And the most dangerous automation failure may be the one that looks like a success — the software runs exactly as designed, while silently enforcing a process that never matched the real business.
Automation that works does not start with choosing the technology. It starts with being honest about how work actually gets done.
