Vernon Yai stands at the intersection of complex data systems and human behavior, serving as a seasoned authority on how organizations protect and leverage their most sensitive information. As a specialist in privacy protection and data governance, he has spent years navigating the high-stakes world of risk management, where the difference between a successful system and a catastrophic failure often lies in the details that machines miss. His approach transcends mere technical implementation, focusing instead on the innovative detection and prevention techniques that allow businesses to automate safely without losing the nuance of human expertise. In a landscape where many leaders rush toward digital transformation, his insights offer a grounded, strategic perspective on why the most sophisticated algorithms still rely on the integrity of the people who guide them.
This discussion explores the inherent friction between the promise of automation and the messy reality of operational data. We delve into the psychological gap where CIOs mistake “data-informed” processes for “data-driven” ones, leading to what is described as “expensive theater” rather than true efficiency. The conversation outlines a spectrum of decision-making, from the rare instances of truly scriptable tasks to the common “data-ignored” scenarios where employees must manually override incorrect system inputs. By deconstructing the hidden layers of complex decisions and advocating for an “exception library” approach, this dialogue provides a roadmap for building resilient, high-value automated systems that actually improve margins and operational resilience.
The push for automation is often framed as a straightforward path to efficiency, yet so many projects fail to deliver. Where does the initial disconnect between executive vision and operational reality typically begin?
The failure usually starts with a fundamental misunderstanding of how data is actually handled at the ground level. Executives often listen to business teams describe themselves as data-driven, and they take that claim at face value without seeing the manual workarounds happening behind the scenes. We often see a massive gap between the documented rules in an ERP system and the “gut-feeling” adjustments employees make to keep the business running. When a CIO believes the sanitized version of the process, they end up automating a ghost version of the business that doesn’t actually exist. This belief is the first mistake, and it sets the stage for a project that will eventually stall because it was built on a foundation of data that the operational team has been quietly ignoring for years.
You’ve mentioned that “truly data-driven” decisions are actually quite rare in the corporate world. Could you elaborate on the “data-ignored” category and how it sabotages automation?
Data-ignored decisions happen when the information in the system is so consistently wrong that the staff has trained itself to look elsewhere. I recall a mid-size manufacturer where a project had been stalled for eight months because they were trying to automate inventory replenishment based on supplier lead times that hadn’t been updated in years. The planning team wasn’t being lazy; they were being smart by ignoring the system and relying on two senior employees who kept the real delivery schedules in their heads. If you automate that process without fixing the data, you aren’t creating efficiency; you are just scaling a mistake at high speed. It’s a situation where the system says one thing, but the reality on the warehouse floor says another, and the human judgment is the only thing preventing a total stock-out.
When a company finds itself in the middle of the spectrum—making “data-informed” decisions—why is it so difficult to transition those tasks over to an algorithm?
The difficulty lies in the fact that data-informed decisions require a level of judgment that is hard to put into words, let alone code. In these scenarios, workers use the data as a starting point, but they apply a layer of analysis and context before they pull the trigger on an action. Automating this requires those decision-makers to articulate every nuance of how they transform raw inputs into results, which is an incredibly taxing and often overlooked part of discovery. If the technical team tries to bypass this “judgment” layer, they end up with a tool that misses the subtle signals a human would catch instantly. It’s not about a lack of data; it’s about the “tacit knowledge” that hasn’t been formalized into the system yet.
There is a significant financial warning in your work regarding “expensive theater.” What are the real costs when an organization ignores the discovery phase of automation?
Rushing into automation without deconstructing the decisions first can lead to costs that balloon to ten times the original budget. You aren’t just paying for the software; you’re paying for the time spent building a system that doesn’t work, the retraining of teams who now have to find new ways to work around the new system, and the eventual scrapping of the project. It becomes “theater” when you have a shiny new automated dashboard that requires 100% human review anyway, meaning you’ve gained zero efficiency. The 10X cost isn’t the price of doing automation right; it’s the penalty you pay later for trying to skip the hard work of mapping data and sitting shoulder-to-shoulder with the operational team. True discovery should be viewed as a high-yield investment rather than overhead, because it ensures the final product actually sticks.
If an organization wants to get this right, how should they approach the challenge of locating where their critical data actually lives?
The idea that everything lives in a one-stop-shop ERP is often a fantasy because every organization has nuances that the standard software doesn’t capture perfectly. You have to start with a literal inventory of every piece of information used to make a call, which often leads you to stray spreadsheets and the private notes of veteran employees. AI can be a great help in systematizing how we access this information, but you first have to acknowledge that if you can’t locate it, you can’t automate it. This stage requires a lot of heavy lifting in terms of infrastructure to pull disparate data into a form that a machine can actually process. It’s a slow process, but without it, your automation is essentially flying blind.
During the discovery process, you talk about “going deep with the team.” What are some of the surprising challenges or signals that only emerge when you observe the team in action?
When you sit with the people doing the work, you see things that aren’t in any manual, like how a team handles counterfeit products in an ecommerce environment. A simple algorithm might see a sudden drop in sales and suggest lowering prices to stay competitive, but a human knows that the right move is actually to take legal action against the fraudulent seller. We also see how people handle “bad” data, like a requested delivery date that is always defaulted to exactly one week from the order date, regardless of reality. In one instance, we found an organization was relying on a simple 30-day rolling history for inventory, which was incredibly limited and inefficient. By observing these flaws, we don’t just automate the old process; we use the project as an opportunity to build a much higher-quality decision-making model.
You’ve described a method of “stacking” decisions to create a model. Could you walk us through how a seemingly simple choice, like where to produce an order, is actually more complex than it appears?
Take a large milling company trying to decide where to route a production order; on the surface, it looks like a single choice, but it’s actually five distinct sub-decisions happening at once. The planner has to check which facilities have the capacity, which routes will minimize the transit time and cost, and whether shifting production will put existing customer commitments at risk. On top of that, they have to navigate quality specifications and then calculate if the resulting combination is even still profitable for the company. A human does all of this in minutes, but for an automated system to succeed, each of those five layers needs its own logic and its own threshold for when to alert a human. It’s only after this deconstruction that you can truly say you understand what you are trying to automate.
How does an “exception library” help balance the speed of automation with the necessity of human judgment?
The goal shouldn’t be to automate 100% of the cases; it should be to automate the 80% that are safe and routine while making the 20% of exceptions highly visible. We worked with a food manufacturer where the team was manually reviewing every single system output because the automation couldn’t flag things like an unreliable supplier during harvest season. By building a library of these “broken rule” scenarios—like a warehouse running at 95% capacity or a sudden promotional spike—we allowed the system to handle the easy stuff automatically. This meant the team could stop reviewing every daily inventory replenishment and instead focus their energy on the few cases that actually required their expertise. The result is that those 20% of difficult cases get resolved in minutes rather than hours because the system provides the necessary context for the human to act quickly.
In your experience, what is the ultimate outcome for a CIO who chooses to resist the pressure to “move fast and break things” in favor of a more methodical approach?
The CIOs who get this right are the ones who build an operational advantage that is incredibly difficult for competitors to replicate. They don’t just move faster; they make fundamentally better calls that show up in their margins and their ability to meet customer commitments even when things go sideways. Their systems are auditable and consistent, creating a record of why every decision was made, which builds a level of organizational resilience that “fast” automation can’t match. They understand that the question isn’t whether to automate, but whether they have done the work to understand their own decisions well enough to do so responsibly. In the end, there are a hundred ways to automate a bad decision, but only a few ways to build a system that consistently delivers good ones.
What is your forecast for the future of decision automation as businesses become more reliant on AI and complex data models?
I believe we are heading toward a period of “automation correction” where companies will move away from trying to replace humans and instead focus on augmenting them through better exception-handling frameworks. As AI makes it easier to process vast amounts of information, the value of high-quality human judgment will actually increase, not decrease, because the cost of an automated mistake will be much higher. We will see more organizations investing in “decision modeling” as a core competency, treating their operational logic as a valuable asset that needs to be refined and protected just like their physical assets. The winners in the next decade won’t be the companies with the most automation, but the ones with the most reliable automation—those who have successfully mapped the “human-in-the-loop” for the 20% of cases where the data simply doesn’t tell the whole story.
