It’s not a crazy question anymore. AI dropped the cost of writing custom software so fast that the old calculus — build is expensive, buy is manageable — no longer holds the way it did. A working internal tool that used to take a team of engineers three months can now take one motivated person a few weeks. The capability is real.

But the cost of compliance didn’t move.

If your organization operates in any environment where SOC 2, ISO 27001, HIPAA, or a growing list of regulatory frameworks apply, you’re not just making a build decision. You’re making a risk decision. And the people who get burned are the ones who evaluated those two things separately.

Why the Old Math No Longer Works

The traditional build-vs-buy framework was simple: weigh upfront development cost against long-term subscription spend, factor in maintenance, add a gut-check on strategic fit, and make the call. That model made sense when building was genuinely expensive and the timeline was measured in quarters.

AI compressed the timeline. Seventy-two percent of developers now use AI-powered coding tools daily, and 41% of all global code generated is AI-assisted. daily.dev Prototypes that used to take weeks take days. Internal tools that used to require a dedicated engineering resource can now be stood up by someone who isn’t even a developer. The cost side of the equation shifted dramatically.

The compliance side didn’t.

According to Veracode’s 2025 GenAI Code Security report, nearly half of all code generated by AI contains security flaws — despite appearing production-ready. Cyber Unit Not rough edges. Not missing features. Security flaws — the kind that show up in audit findings, breach notifications, and customer conversations you don’t want to have.

And here’s the operational dynamic that makes this particularly relevant to business leaders: AI-assisted development rewards momentum over scrutiny. The result is production code that works as intended and passes basic tests, but hasn’t been deeply reviewed, threat-modeled, or validated for security. Functionality becomes the finish line. Security becomes “something we’ll handle later.” Trend Micro

In a compliance environment, later doesn’t exist as a planning horizon. The auditor doesn’t ask whether you intended to have controls in place. They ask whether the controls operated — consistently, documentably, over the entire observation period.

The Uncomfortable Part of This Conversation

Here’s what tends to go unsaid in the build-vs-buy discussion at the leadership level: the compliance risk isn’t just technical. It’s organizational.

When you buy a certified vendor platform, their SOC 2 or ISO 27001 report is part of what you’re purchasing. The shared responsibility model is documented. The controls are their problem to evidence and maintain. Your auditor knows how to evaluate it. Your customers’ procurement teams know what to ask for.

When you build your own system, all of that transfers to you. Insecure code can lead to non-compliance with industry standards like SOC 2 or ISO 27001, jeopardizing key business certifications and contracts. Baytech Consulting Beyond the technical risk, you now own the policy documentation, the access control narrative, the evidence collection, and the ongoing control monitoring — for every audit cycle, indefinitely.

That’s not a one-time cost. That’s an operational commitment that needs to live somewhere on your org chart.

Organizations may simulate compliance by having AI generate technical and risk assessment documentation — but that has no real impact on actual risk exposure. Lawfare The documentation looks right. The audit finds the gap. Those are two different outcomes, and the distance between them is where organizations get hurt.

Running the Real ROI Calculation

So when does building your own system still make sense? It can — but the ROI calculation needs to include the full compliance cost, not just the development cost.

Here’s the framework worth running before the decision gets made:

Build makes sense when your workflow is genuinely differentiated and no vendor has solved it well. You have — or are willing to staff — a security function that can own the control environment. You’re designing compliance in from the start, not treating it as a retrofit. And the long-term subscription cost of the vendor alternative is materially higher than what you’d spend building and maintaining your own compliance posture.

Buy makes sense when you need to close enterprise deals in the next two to three quarters and can’t absorb an audit finding in the process. You don’t have dedicated security staff and don’t plan to add it. The vendor’s existing certification coverage maps cleanly to your own compliance requirements. And the operational overhead of running your own compliance program represents a distraction from the work that actually moves your business.

Neither path is free. The vendor route trades subscription cost for compliance certainty. The build route trades upfront savings for ongoing operational risk — risk that compounds every time the system is modified, every time a team member with access leaves, and every time a new framework requirement lands.

The Tools That Help You Hold the Line Either Way

Whether you build or buy the underlying system, you still need infrastructure to manage your compliance program. Two platforms have become the operational standard for organizations navigating SOC 2, ISO 27001, and adjacent frameworks.

Vanta and Drata both automate the evidence collection, continuous monitoring, and audit-readiness workflows that make compliance manageable for teams without a dedicated GRC function. Vanta now serves 15,000+ customers and positions itself as an agentic trust platform, with AI agents that draft policies, complete questionnaires, and surface risk continuously. Drata serves 8,000+ organizations and has expanded into AI-native trust management, covering SOC 2, ISO 27001, HIPAA, GDPR, DORA, and a growing list of regional frameworks. Comp AI

The practical difference between them: Vanta is designed to feel familiar even if you’ve never run a formal compliance program, making it easier to roll out in weeks. Drata expects more technical maturity and rewards teams that already know what they want from audit workflows and risk management. Complyjet If you’re standing up compliance for the first time to unblock an enterprise deal, Vanta gets you moving faster. If you’re managing multiple frameworks across a more complex environment, Drata’s depth pays off over time.

What both platforms make visible — and this is directly relevant to the build-vs-buy decision — is the ongoing operational cost of maintaining a compliance posture. Drata’s entry-level tier starts around $7,500 per year and can exceed $100,000 annually for advanced GRC operations. Complyjet That number belongs in your build-vs-buy model before you make the call, because it applies whether you’re certifying a vendor platform or a system your team built.

Sprinto and Secureframe are also worth evaluating depending on your stage and compliance complexity. None of these are a substitute for a security lead who can make architectural decisions. But all of them are considerably cheaper than discovering a control gap mid-audit.

The Decision in Plain Terms

AI changed who can build software and how fast. It didn’t change what regulators require of the software you run.

Build when it’s genuinely strategic — when the custom system creates a real competitive advantage and you’ve staffed the compliance function to support it. Buy when the vendor’s certification is a meaningful part of the value you’re purchasing. And in either case, don’t let the reduced cost of development become the ceiling of your risk analysis.

The code got cheaper. The audit didn’t. The frameworks didn’t. And the enterprise customer asking for your SOC 2 report definitely didn’t.

How is your organization thinking through this — are you seeing the build temptation increase as AI tools get better, or are compliance requirements keeping the conversation grounded?

Sources

• Veracode 2025 GenAI Code Security Report: futurecio.tech

• Vibe Coding Statistics & Trends 2026: secondtalent.com

• Vibe Coding and the SaaS Shakeup: cyberunit.com

• When the Vibes Are Off — Lawfare: lawfaremedia.org

• The Real Risk of Vibecoding — Trend Micro: trendmicro.com

• Vanta vs. Drata 2026 Comparison: trycomp.ai

• Vanta vs. Drata — Complyjet: complyjet.com

And now AI is inside that system. Not as a shortcut around the compliance layer — through it, and sometimes faster than the humans who built it.

The Part Nobody Warns You About

Here’s the thing about medical device manufacturing that doesn’t show up in the marketing brochures: it’s not just manufacturing. It’s manufacturing and a living document management system and a regulatory submission pipeline and a corrective action loop — all running simultaneously, all touching each other, all subject to audit.

A Design History File (DHF) for a single device can run hundreds of pages. The Device Master Record behind it? More. Change one component — a supplier switches resin grades, a screw torque spec gets updated — and you’re not just swapping a part. You’re opening a change control, updating the risk analysis, potentially triggering a 510(k) amendment, and re-validating a process that was already validated.

That’s not a workflow. That’s a workflow holding three other workflows hostage.

The floor can hum along beautifully, hitting cycle times, hitting yield targets — and the operation still bogs down in paperwork that would make a tax attorney wince. That disconnect, between what the line can do and what the compliance layer allows it to do at speed, is where AI is starting to earn its keep.

What AI Is Actually Doing in the Clean Room

Medtronic has been running AI-assisted quality monitoring across manufacturing lines — pulling real-time sensor data and flagging process deviations before they become nonconformances. Stryker has embedded machine vision into inspection steps that used to rely entirely on human eyes and a loupe. Becton Dickinson is using predictive analytics to get in front of equipment drift before it touches a batch record.

None of that is magic. It’s pattern recognition applied to data that was already being collected but not acted on fast enough.

The shift isn’t “AI replaces the quality engineer.” The shift is AI stops the quality engineer from spending Tuesday afternoon manually reviewing control charts that could have flagged Monday morning. That’s the real unlock — not headcount reduction, but decision latency. Getting the right information to the right person before the window closes.

And in a regulated environment, windows close fast. A nonconformance that gets caught at inline inspection is a CAPA. The same issue caught at final release is a potential FDA reportable. The same issue caught by a customer is a recall. The cost differential between those three outcomes isn’t linear. It’s exponential.

The Part That Makes Compliance Teams Nervous

Here’s what nobody in a medical device company wants to say out loud at an all-hands: AI-generated outputs need their own validation.

If you’re using an AI tool to assist with document generation — pulling language from predicate devices, drafting risk assessments, summarizing test results — that tool is now part of your quality system. Which means it needs to be validated under 21 CFR Part 11 if it touches electronic records. Which means you need a Software as a Medical Device (SaMD) assessment if it crosses a certain threshold. Which means your AI efficiency project just became a regulatory project.

That’s not a reason to avoid it. It’s a reason to plan it right, upfront, before someone in Regulatory Affairs sees a draft DHF section and asks “what generated this?”

The companies getting traction here — Siemens Healthineers, Abbott — aren’t deploying AI and hoping the auditors don’t notice. They’re documenting the AI as part of the process, building the validation evidence alongside the deployment, and treating the model’s outputs like any other process output: defined inputs, defined acceptance criteria, periodic review.

It’s more work on the front end. It’s considerably less work than explaining your AI tool to an FDA inspector who wasn’t briefed.

The Workflow That Actually Changes

Set the compliance complexity aside for a second and look at what a well-deployed AI layer does to the day-to-day.

Incoming inspection that used to take a shift now takes twenty minutes — vision systems check dimensional conformance against the engineering drawing while a technician reviews the cert. Change control that used to sit in someone’s inbox for a week because they needed to cross-reference three documents now gets a pre-built impact summary drafted from the existing DHF content. Training compliance — who’s qualified on what revision, what’s lapsed, what’s due — gets tracked in real time instead of discovered during an internal audit.

None of these are glamorous. They’re not the AI demos that get shared on LinkedIn. But they’re the ones that actually move throughput, reduce rework, and get the product to the customer inside a regulatory framework that doesn’t bend.

That’s the pattern worth paying attention to. Not AI doing something new — AI doing the grind work so that the skilled people on the floor can do the thing only they can do.

The machine handles the memory. The people handle the judgment.

Same Constraints. Faster Everything.

The FDA isn’t changing its requirements because AI showed up. ISO 13485 didn’t get a carve-out. 21 CFR Part 820 is still 21 CFR Part 820.

What’s changing is how fast a team can move inside those requirements when the documentation layer keeps pace with the production layer. When your quality system is reactive, you’re always catching up. When it’s predictive, you’re running.

AI didn’t loosen the rules in healthcare device manufacturing. It gave the people who follow them rigorously a fighting chance to do it at speed.

What’s your team running into when you try to bring AI into a regulated environment — is the compliance layer the bottleneck, or is it something else? Drop it in the comments.

Sources

• Medtronic AI & Digital Health — medtronic.com

• Stryker Digital Innovation — stryker.com

• Becton Dickinson Data & Analytics — bd.com

• Siemens Healthineers AI-Rad Companion — siemens-healthineers.com

• FDA Guidance on Software as a Medical Device (SaMD) — fda.gov

• 21 CFR Part 820 Quality System Regulation — ecfr.gov

There’s a difference. Adoption is getting people to use the tool. Deployment is making sure the tool produces consistent, usable output across the organization — not just for the three people who figured it out on their own.

Right now, a lot of operations are running on the adoption side of that line. And quietly celebrating results that aren’t actually repeatable.

The Number That Should Be in Your Next Ops Review

OpenAI’s State of Enterprise AI report surveyed nearly 100 companies and landed on a number worth writing on the whiteboard: frontier workers — those at the top of AI usage intensity — are sending 6x more messages and reporting more than 10 hours saved per week OpenAI compared to the median employee.

Same tool. Same login. Same subscription cost per seat. Six times the output.

EY went broader — 15,000 employees, 29 countries — and found the same pattern from a different angle: 88% of employees use AI at work, but almost all of them are stuck on basic tasks like search and summarization. Only 5% are using it in ways that actually transform how they work. EY

So 88% are touching the tool, and 5% are operating it. The other 83% are using it the way someone uses a torque wrench to hang a picture. Technically works. Completely beside the point.

This is not a training problem. It’s a standardization problem. And in operations, we know exactly what variation in process produces — variation in output. The same thing we’ve spent decades eliminating on the floor is now running loose inside our AI deployments, and most organizations haven’t named it yet.

The Superuser Built Their Own Standard Work. Without Telling Anyone.

There’s a person on your team who figured out early that the model isn’t the magic. It’s what you put around it.

They built out a Claude Project — or a custom GPT, or whatever stack they landed on — and loaded it with context before they ever typed a real prompt. Company terminology. Process constraints. The format that actually gets used downstream. The things that always end up wrong in a first draft. Every session they open already knows the operating environment.

Many of the strongest enterprise AI deployments began with exactly these people — employees who had already experimented with tools like ChatGPT or Claude for personal productivity. They understood the capabilities and limits intuitively, and became early champions of internally sanctioned solutions. MLQ

What they built, whether they know it or not, is standard work. For the AI.

The files attached to a Claude Project act as guardrails — not the bureaucratic kind that slow everything down, but the operational kind that define what good looks like before work starts. The AI isn’t guessing. It’s running inside a defined envelope. That’s the same principle behind a well-written work instruction. The goal isn’t to restrict the operator — it’s to make the right output the path of least resistance.

The problem is it only lives with them. When they leave, it walks out the door. Sound familiar? It’s the same knowledge transfer problem we’ve been trying to solve in manufacturing for thirty years, just wearing a different hat.

RAG and MCP — Or, Why the Manual Still Lives in Gary’s Head

Think about the last time someone new joined your team and needed to find a procedure. Maybe it was an engineering spec, a supplier qualification requirement, a deviation process. What happened?

If your organization is like most, one of three things: they found an outdated document in a shared drive, they asked someone who knew where to look, or they asked Gary. Gary’s been here fourteen years. Gary is the knowledge base.

RAG — retrieval-augmented generation — is the infrastructure answer to the Gary problem. It connects AI to your actual source-of-record documents: your QMS, your product specs, your compliance library. When someone asks a question, the AI pulls the current procedure — not its general training, not a hallucinated approximation. The one you wrote. The one that’s been through your change control process.

MCP — Model Context Protocol — goes a level further. It’s how AI connects to the live systems where work actually happens. Not a static export. Not last Tuesday’s data pull. The actual ERP, the actual CRM, current as of right now.

Put those together with well-maintained style guides and project-level instructions, and you’ve built something that does for AI what a good onboarding process does for a new hire — gets them operating inside your standards from day one, without a fourteen-year apprenticeship under Gary.

Roughly one in four enterprises still hasn’t enabled connectors that give AI access to company data — a basic step that dramatically increases the technology’s utility. VentureBeat That’s not a technology gap. That’s a process ownership gap. Nobody decided it was their job.

What the Mirror Is Showing

Here’s the part nobody wants to put in the board deck.

Only about one in four AI initiatives delivers its expected ROI. Fewer than 20% have been fully scaled across the enterprise. Stack AI Deloitte found that just 34% of organizations are actually reimagining how the business operates Deloitte — the rest are running AI on top of existing processes and calling it transformation.

That’s the Lean parallel, and it’s almost exact. Continuous improvement came in. The early practitioners got results. Leadership declared victory. The standard work went stale, the culture never shifted, and a few years later the gains had quietly eroded. Everyone wondered why it didn’t stick.

It didn’t stick because the infrastructure never got built. The methodology was real. The results were real. The system to sustain them wasn’t.

AI is running the same play. The superusers are the early practitioners. The personal Claude Projects are the individual kaizen events. Real results, completely dependent on people who built their own systems in their own corners of the org — and in most enterprises, nobody is keeping track of what’s running, who owns it, or what it’s actually doing. Lumenova AI

That’s not a technology problem. That’s a process governance problem. And process governance is supposed to be our domain.

Standard Work for the AI Layer

The companies pulling ahead aren’t spending the most. They’re the ones that recognized this for what it is — an operations and standardization challenge wearing a technology hat.

The superusers proved the concept. RAG handles the knowledge. MCP handles the connections. Style guides and project-level instructions set the guardrails. What ties it together is someone who thinks in systems deciding to own the AI environment the same way they’d own any other operational standard: documented, versioned, and maintained.

The standard work exists. Someone just has to write it down this time.

Where is your organization — still running on what the superusers built, or starting to build the layer underneath?

Sources: OpenAI — State of Enterprise AI Report 2025: https://cdn.openai.com/pdf/7ef17d82-96bf-4dd1-9df2-228f7f377a29/the-state-of-enterprise-ai_2025-report.pdf EY — Work Reimagined Survey 2025: https://www.ey.com/en_gl/newsroom/2025/11/ey-survey-reveals-companies-are-missing-out-on-up-to-40-percent-of-ai-productivity-gains-due-to-gaps-in-talent-strategy MIT NANDA — State of AI in Business 2025: https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf Deloitte — State of AI in the Enterprise 2026: https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html Anthropic — Claude Projects: https://support.anthropic.com/en/articles/9517075-what-are-projects Anthropic — Model Context Protocol: https://www.anthropic.com/news/model-context-protocol

They’re not. But the more interesting question isn’t whether the fear is justified. It’s why we keep having the exact same conversation, decade after decade, with nothing but the name of the technology changing.

We Have Been Wrong About This Before. Specifically.

In 1961, Time magazine ran a cover story called “The Automation Jobless.” That same year, President Kennedy called full employment “the major challenge of the sixties” — not because the economy was broken, but because automation was about to break it. Congressional hearings. A presidential commission. Serious economists wondering aloud if full employment was even achievable anymore.

The unemployment rate hit 3.5% by the late 1960s. The commission’s report gathered dust.

Jump to 1995. Sociologist Jeremy Rifkin publishes The End of Work — a full book arguing that automation was driving civilization toward a “post-market era” that would “undermine the very foundations of modern society.” Ominous stuff. The United States then posted its best employment numbers since the Kennedy era. Rifkin moved on to catastrophizing about genetically modified foods.

Then Andrew Yang built a presidential platform in 2020 partly on the claim that truck driving — one of the largest employment categories in the country — was functionally gone, automated away within a few years. Today, truck drivers remain very much employed and very much in demand. The autonomous revolution that was supposed to eliminate them is still working out its edge cases in controlled environments.

The predictions aren’t close. They aren’t a little off. They have a zero-for-seven track record across more than a century of trying, covering everything from power looms to the PC to the internet to industrial robots. And each new cycle treats the fear as if it’s never been felt before — as if the last six rounds of wrong didn’t happen.

That’s worth sitting with before we talk about why the track record looks the way it does.

The Pattern Shows Up Every Time You Look for It

The Luddites smashing power looms in 1811 weren’t irrational. They correctly understood that the technology eliminated their specific jobs. What they couldn’t see — what nobody ever sees in the middle of a transition — was what the technology was simultaneously creating. The British textile industry didn’t shrink after the loom. It exploded. Output per weaver increased by a factor of fifty over the following decades, new job categories appeared around operating and maintaining the machines, and England became the center of global manufacturing within a generation. The looms didn’t end work. They ended that work.

The same math plays out across every wave. When the tractor displaced farm labor through the early 20th century, agricultural employment as a share of the U.S. workforce fell from over 40% to under 2% — and yet the workers who left didn’t vanish into permanent unemployment. They moved into manufacturing, services, and trades that barely existed in 1900. America stopped being a subsistence farming economy and started feeding the world, with a fraction of the people doing the farming. [Bureau of Labor Statistics, Current Employment Statistics: 100 Years of Employment]

The ATM is my favorite example because the logic felt airtight at the time. Machine does the transaction. Teller becomes redundant. Simple substitution. Except the ATM made running a bank branch dramatically cheaper, so banks opened more branches — and the total number of tellers actually increased between 1980 and 2010. Their jobs evolved from transaction processing toward relationship banking, the one thing the ATM genuinely couldn’t do. [Federal Reserve Bank of St. Louis, Will Robots Take Our Jobs?]

The spreadsheet did eliminate bookkeeping clerks. No argument there. But it made financial analysis so cheap and accessible that demand for accountants — the higher-skill version of the same function — grew faster than the bookkeeping jobs disappeared. The tool replaced one task while making the surrounding work more valuable, not less. Same thing. [Federal Reserve Bank of St. Louis, Will Robots Take Our Jobs?]

The internet killed travel agents, video store clerks, and newspaper classified ad sales. It also created search engine optimization, cloud infrastructure engineering, UX research, fulfillment logistics, and social media management — none of which had names in 1995, let alone job listings. Amazon, the company that was supposed to hollow out retail, now directly employs more than 1.5 million people. The destruction is always more visible than the creation, because destruction happens to existing things and creation happens to things that don’t exist yet. That asymmetry is the trick the doom headlines play on you every single time.

The Variable That Never Makes the Prediction Models

Here’s where I think the conversation goes wrong at a structural level — and it’s not really about the technology at all.

Every “AI will eliminate X million jobs” projection treats the labor market like a fixed-size pie. Tool takes a slice, worker loses a slice. What the models almost never account for is the denominator: more people means more demand for everything.

When President Kennedy was worried about automation in 1961, there were 180 million Americans. Today there are 342 million. That’s not a minor rounding error — that’s 162 million additional people who need housing, healthcare, food, education, transportation, entertainment, and all the services that require human labor to deliver. The pie wasn’t fixed. It kept getting bigger, and it grew because of the productivity gains the technology enabled, not in spite of them. [CEIC Data / U.S. Census Bureau]

Between 1919 and 2015 — a period that includes the mechanization of agriculture, electrification, the assembly line, the computer, and the internet — U.S. nonfarm payroll employment grew from 27 million to 143 million. That’s across every automation wave anyone bothered to warn us about. [Bureau of Labor Statistics, Current Employment Statistics: 100 Years of Employment] And roughly 60% of the jobs that exist in the U.S. today are in occupations that didn’t exist in 1940 — meaning the overwhelming majority of employment growth since then came directly from the technologies people feared would eliminate work. [Goldman Sachs Research, How Will AI Affect the Global Workforce?]

Population growth funds demand. Demand funds jobs. Technology funds productivity. Productivity funds population growth. It’s a loop, not a linear replacement equation — and the doom models keep treating it like the latter.

There’s a Flip Coming That Nobody’s Covering

This is where the story gets genuinely counterintuitive, and where I think the AI fear narrative is actually looking at the wrong problem.

For most of the 20th century, the U.S. economy needed to create enormous numbers of jobs just to absorb everyone entering the workforce. During the 1970s, when the baby boomers and a surge of women entering the workforce hit simultaneously, the economy needed to generate around 185,000 jobs per month just to keep unemployment steady. That’s the pressure the labor market was running under during the era when robots were supposedly going to eliminate everything. [Federal Reserve Board of Governors, Labor Force Growth, Breakeven Employment, and Potential GDP Growth]

That number has been falling steadily. By the 2010s, as boomers started retiring and birth rates slowed, the monthly breakeven dropped to around 80,000. In 2025, with immigration slowing significantly, it fell to an estimated 85,000. And current Fed projections suggest the breakeven in 2026 could fall to near zero — meaning the labor force is barely growing at all. [Federal Reserve Board of Governors, Labor Force Growth, Breakeven Employment, and Potential GDP Growth]

Sit with that for a second. The AI tools that people fear will produce mass unemployment are arriving at the exact moment when the U.S. labor market is running short of workers — not long. Healthcare is already strained by an aging population demanding more care from a workforce that isn’t growing fast enough to deliver it. Construction can’t find enough skilled tradespeople. Technology hiring is competitive precisely because the pipeline is constrained. The BLS projects that over the next decade, the fastest-growing sectors will all be ones where human judgment, physical dexterity, or relationship-building are central — and AI can assist but not substitute. [Bureau of Labor Statistics, Employment Projections 2024–2034]

The concern isn’t that AI replaces too many workers. The concern, within a generation, may flip to whether AI is powerful enough to compensate for the workers we won’t have.

What the Current Data Actually Shows

The prediction range for AI-driven job loss, compiled across major research institutions, runs from 1.8 million to two billion eliminated jobs. That range isn’t informative — it’s so wide it tells you the researchers don’t actually know, and a Harvard Data Science Review analysis makes exactly that point, arguing the predictions needlessly inflame concern without meaningfully guiding it. [Harvard Data Science Review, Can We Predict What Jobs AI Will Take?]

Meanwhile, the confirmed 2024 data shows roughly 12,700 jobs lost to AI-related automation — against approximately 119,900 AI-related jobs created the same year. Nearly a 10-to-1 ratio. That’s not a prediction. That’s last year’s actuals. [HIGH5 Test Research, AI and Automation Job Loss Statistics in the U.S. 2024–2026]

Goldman Sachs ran the analysis on whether AI exposure was actually showing up in employment data — job growth, layoff rates, earnings — and found no statistically significant correlation. Their estimate for jobs genuinely at risk if AI were deployed at maximum current scale across the entire economy: about 2.5% of U.S. employment. [Goldman Sachs Research, How Will AI Affect the Global Workforce?] Real. Not nothing. Also not the cliff everyone’s standing at the edge of.

And here’s the part that genuinely deserves more attention than it gets: Forrester’s research found that the majority of layoffs currently being attributed to AI aren’t driven by deployed AI systems at all. When companies announce workforce cuts and cite AI as the reason, they usually don’t have a working AI system ready to take over the function — and haven’t started building one. The layoffs are financially motivated. AI is the narrative, not the mechanism. [Forrester Research, The Forrester AI Job Impact Forecast, US 2025–2030]

We are, in a meaningful number of cases, blaming job losses on a tool that hasn’t actually been used yet. That’s a new level of anticipatory fear.

What Gets Unlocked When the Bottleneck Moves

The frame I find more interesting than the fear one is this: every automation wave in history didn’t just reshuffle jobs. It relocated the ceiling on what humans could attempt.

The farmer freed from manual harvest didn’t retire. He became the agricultural engineer, the logistics coordinator, the food scientist. The bookkeeper freed from the ledger became the financial strategist. The developer freed from writing boilerplate code is now taking on architecture problems she didn’t have bandwidth to touch two years ago. The bottleneck was never ambition. It was always time and cognitive capacity.

AI removes a layer of cognitive bandwidth constraint the same way the tractor removed a layer of physical bandwidth constraint. And every time in history that happened, the freed-up capacity didn’t evaporate — it moved to the next harder problem. The one that was always there, always worth solving, always waiting for enough resources to tackle it.

The problems stacking up — aging populations needing care, climate infrastructure needing to be built, personalized medicine needing to be delivered at scale, education needing to reach more people in more ways — none of these go away if AI gets better. They get more tractable. More human judgment applied to more meaningful problems, with better tools underneath it. That’s not a threat to work. That’s the definition of what progress looks like.

The Choice That’s Actually in Front of You

The people who panic-sold farm equipment in the 1920s didn’t end up ahead of the people who learned to operate it. The secretaries who refused to touch a PC in 1985 didn’t outcompete the ones who figured out Word and Excel before anyone told them to. The pattern is that consistent across every transition: the people most exposed to disruption from a new technology are almost never the ones actively using it. They’re the ones assuming it’s someone else’s problem to figure out — until it isn’t.

Understanding a tool while it’s forming is how you end up on the right side of what it creates. Not because the tool is magic, but because the learning curve is real, and the earlier you climb it, the more runway you have on the other side.

More people. More problems worth solving. Better tools to solve them with. The math on this has never actually been scary — it’s just that fear writes better headlines than compounding productivity does.

New technology changes the shape of work. It always has. What it’s never done — in a century of trying — is shrink the total amount of it.

What are you seeing in your own industry — displacement, or evolution wearing a scary mask? And does the population angle change how you read the risk? I’m genuinely curious what the ground truth looks like from where you sit. Drop it in the comments.

Sources

• Goldman Sachs Research, How Will AI Affect the Global Workforce? — goldmansachs.com

• Forrester Research, The Forrester AI Job Impact Forecast, US 2025–2030 — forrester.com

• Harvard Data Science Review, Can We Predict What Jobs AI Will Take? — hdsr.mitpress.mit.edu

• Federal Reserve Bank of St. Louis, Will Robots Take Our Jobs? — stlouisfed.org

• Federal Reserve Board of Governors, Labor Force Growth, Breakeven Employment, and Potential GDP Growth — federalreserve.gov

• Bureau of Labor Statistics, Employment Projections 2024–2034 — bls.gov

• Bureau of Labor Statistics, Current Employment Statistics: 100 Years of Employment — bls.gov

• HIGH5 Test Research, AI and Automation Job Loss Statistics in the U.S. 2024–2026 — high5test.com

• Pessimists Archive Newsletter, Robots Have Been About to Take All the Jobs for 100 Years — newsletter.pessimistsarchive.org

• CEIC Data / U.S. Census Bureau, U.S. Population Historical Data — ceicdata.com

AI is making operations faster. That’s the easy part.

Planning cycles that once took days now take minutes. Reports appear instantly. Schedules recalculate in real time. Decisions that used to require a room full of people now come out of a model before half the people have opened the slide deck. Those gains are real, and they matter. Current industrial and professional signals reflect exactly that push: Hannover Messe 2026 is centering industrial AI, automation, robotics, and digitalization as practical competitive tools, while PMI is framing AI as a force for streamlining execution and enhancing decision-making.

But speed is not the same as improvement.

That distinction sounds obvious until you watch what happens in real operations. A process gets faster, utilization goes up, planning effort goes down, dashboards look cleaner, and everyone assumes the system got better. Sometimes it did. Sometimes all that happened is that the organization got faster at executing the same flawed logic it already had.

That is the uncomfortable part of AI in operations: it does not improve the system by default. It amplifies whatever system is already there—for better or worse.

This is where Industry 5.0 becomes useful, because it changes the question. Industry 4.0 largely asked whether we could connect, automate, instrument, and optimize. Industry 5.0 asks whether those capabilities are producing systems that are human-centric, resilient, and sustainable. That is how the European Commission explicitly frames it: not as a rejection of Industry 4.0, but as a complement that pushes industry beyond speed and automation toward better overall outcomes.

In plain English, Industry 5.0 asks a harder question than Industry 4.0 did.

Not “Can we automate this?”
But “Should we optimize it this way, and what happens to the wider system if we do?”

That sounds philosophical until you see it on a plant floor or in a planning group.

Take a familiar example. A company rolls out AI-assisted scheduling across a production network. The system optimizes for throughput, machine loading, and utilization. It responds faster than any planner could. Within a few weeks, the visible metrics improve. Planning time drops. Utilization rises. Output ticks upward. Someone inevitably says the word “transformational,” which is usually a sign to reach for coffee.

Then the secondary effects show up.

Work-in-process starts rising between operations. Downstream teams get hit with uneven flow. Expedites creep upward. Experienced planners begin overriding certain recommendations. Customer delivery performance stalls, or worse, slips.

Nothing is broken in the technical sense. The AI is doing exactly what it was told to do. The issue is that management encoded an incomplete objective into the system. The model optimized what was defined and ignored what was not.

That is not really an AI failure. It is a management decision, expressed mathematically.

And that is the point more operations leaders need to hear. Most AI disappointments in operations are not failures of machine intelligence first. They are failures of system definition, measurement, and judgment. The model is often faithful. It is the objective that is narrow.

Industry 5.0 helps because it forces the organization to look at the parts of performance that are easy to neglect when efficiency becomes the main story. Human judgment stops being treated as annoying friction and starts being treated as signal. Repeated overrides stop looking like noncompliance and start looking like evidence that the system’s assumptions are incomplete. Resilience stops being a nice extra and becomes a design requirement. The European Commission’s Industry 5.0 work repeatedly emphasizes that broader frame: human-centricity, resilience, and sustainability are not side constraints; they are part of what good industrial performance means.

This is why AI is not replacing Lean, Six Sigma, BPM, or project management. It is changing how they have to be applied.

Lean still matters because flow still matters. Six Sigma still matters because variation still matters. BPM still matters because structure and handoffs still matter. Project management still matters because somebody still has to translate ambition into execution. What changes is that AI speeds up observation, analysis, and response, while Industry 5.0 raises the standard for what “better” actually means. PMI’s current AI positioning and ASQ’s 2026 Lean and Six Sigma conference themes both point in that direction: the conversation is shifting from method purity toward AI-enabled, data-driven improvement that still requires human judgment and responsible application.

A simple test helps.

If AI is now making decisions faster in your operation, ask three questions. What decisions got faster? Which outcomes actually got better? Where are experienced people still stepping in to correct the system?

That last question is often the most revealing. If operators, planners, or supervisors repeatedly override an “optimized” system, the answer is not automatically that they need more training. Sometimes the operation is telling you, quite clearly, that the model is solving the wrong problem.

That is why the real promise of AI in operations is not automation alone. It is better judgment at scale. Faster analysis matters. Faster response matters. But if the system is still optimizing narrow metrics while pushing variability, fragility, or hidden cost somewhere else, then the company has not become more operationally intelligent. It has simply become more computationally efficient.

AI will make operations faster whether companies are ready or not.

Whether it makes them better depends on whether leaders are willing to question what they told the system to optimize.

That is a much harder job than installing the technology.

It is also the one that matters.

References

1. European Commission, Industry 5.0: Towards a sustainable, human-centric and resilient European industry.

2. European Commission, Industry 5.0 overview page.

3. European Commission, news release on Industry 5.0 and its focus on resilience, sustainability, and worker wellbeing.

4. Hannover Messe 2026 press release, Industrial AI as competitive game-changer.

5. Hannover Messe, Industrial AI topic page.

6. PMI, Artificial Intelligence in Project Management.

7. ASQ, 2026 Lean and Six Sigma Conference.

And it’s useful. Really useful.

But it’s also creating a quiet problem that almost nobody is talking about.

AI thinks in milliseconds. Manufacturing learns through material, machines, testing, and time.

That mismatch is where a lot of industrial AI efforts start to wobble. Not because the models are bad. Not because operators are resistant. And not because every factory is secretly waiting for one more dashboard. (Although, to be fair, some are absolutely waiting for one more dashboard.)

The issue is simpler and more stubborn: the digital world and the physical world run on different clocks.

The Gap No One Talks About

A recent IT Revolution piece argues that manufacturers get stuck in AI pilot mode because they lack two things: an integrated digital twin and a real understanding of the physical system they’re trying to optimize. That framing is right. AI can’t improve what it can’t see — and it can’t safely recommend changes when the underlying physics are poorly understood.

But underneath those two problems is another barrier no one lists on the slide: time.

In software, the loop is fast. You test something, it fails, you fix it, you redeploy. Sometimes the rollback happens before most users even notice.

Manufacturing is different. You design something, source it, build it, inspect it, test it — and then you learn whether the idea actually worked. That loop isn’t just data moving through a system. It’s metal, tooling, suppliers, people, test stands, quality gates, and customer requirements.

Those are not the same clock. Treating them like they are is how AI pilots become expensive science projects.

The Impeller Problem

Take an engineered valve impeller.

An AI model can suggest a design improvement in seconds. Maybe it spots a pattern in flow performance, vibration, cavitation risk, or material fatigue that a normal review would miss. Great. That’s exactly the kind of insight we’re after.

Now you have to make it.

Material gets sourced. Machining capacity gets scheduled. Finishing, balancing, inspection, and test all have to happen. Depending on the application, validation isn’t a checkbox — it’s the whole point.

You can easily be weeks or months into the loop before the organization knows whether the AI-backed recommendation was actually right.

If it’s wrong, you don’t simply roll back. You restart. Maybe the second pass is faster because you already know the sourcing path and the fixture strategy — but it’s still not software speed.

The cost of being wrong isn’t computational. It’s physical.

The Opposite Problem

Now flip it.

Think power plugs, fasteners, connectors, stamped parts, plastic housings. The individual unit may be cheap. Cycle times may be measured in seconds. On paper, that looks like a fast system.

But high volume has its own trap: mistakes multiply.

A small process drift, a slightly wrong inspection threshold, a material assumption that doesn’t hold across lots — something that seems harmless at 8:15 a.m. can become thousands of bad units by lunch.

The impeller problem is slow correction. The high-volume problem is fast amplification.

Both are timing problems. They just hurt in different ways.

So What Actually Works?

The answer isn’t “move faster.” That’s how you get faster scrap.

The better answer is to match AI to the learning clock of the system.

For long-cycle engineered products, AI belongs upstream — where mistakes are still cheap. Concept comparison, simulation, tolerance analysis, design-for-manufacturability review, risk flagging, historical failure pattern analysis. Let AI challenge assumptions before metal is cut. The goal isn’t to let AI casually experiment in the real world. The goal is to reduce how often the real world has to teach you an expensive lesson.

For high-volume production, AI belongs closer to the process. Watch for drift. Detect anomalies. Tighten feedback loops. Escalate the small signal before it becomes a large batch of bad product. In this world, AI is less about making one brilliant decision and more about preventing thousands of ordinary decisions from quietly drifting in the wrong direction.

Same technology. Different placement. Different clock.

What AI Is Quietly Exposing

Here’s the honest part. AI is also a mirror.

Companies that thought they had operations under control are discovering their data isn’t clean, their processes aren’t as standard as they believed, and a lot of hard-won institutional knowledge still lives in somebody’s head.

That’s not a technology problem. It’s a process maturity problem. AI just surfaces it faster — and more visibly, which is uncomfortable.

This is why the best industrial AI work still looks a lot like Operational Excellence. Define the process. Understand variation. Clarify what good actually looks like. Reduce noise. Improve the feedback loop. Then layer in the technology.

AI doesn’t remove the need for that discipline. It raises the penalty for not having it.

The Takeaway

Industrial AI isn’t just a data problem or a modeling problem. It’s a timing problem.

Some decisions can be corrected instantly. Some take weeks to validate. Some can’t be reversed without scrap, rework, downtime, or a very uncomfortable meeting with Finance.

Fast AI belongs in monitoring, detection, and adjustment. Medium-speed AI belongs in planning, scheduling, and maintenance strategy. Slow AI belongs in design decisions, tooling changes, qualification plans, and capital commitments.

AI doesn’t make physics optional. It doesn’t eliminate lead times. It doesn’t magically compress validation cycles. But it can help manufacturers learn earlier, see more clearly, and react faster where speed actually matters.

Lean gave us the discipline to improve systems. AI gives us the resolution to see them better. Same goal — better tools, faster signal.

The companies that win won’t be the ones with the fastest models. They’ll be the ones that understand their clocks — and build systems where milliseconds and months can actually work together.

Where are you seeing the timing mismatch play out — long-cycle, high-volume, or somewhere in between? Drop it in the comments.

Sources

IT Revolution — David Ariens and Willem van Lammeren, “Two Problems Standing Between You and Industrial AI at Scale” (2026): itrevolution.com/articles/...

LinkedIn summary by David Ariens on the two barriers (integrated digital twin + physical reality): linkedin.com/posts/davidariens...

That distinction matters, because most confusion about ROI starts when digital twins are treated like software you install instead of what they really are: a decision system built on a model of reality.

And decision systems only create value when decisions actually change.

Where the ROI Actually Comes From

The value of a digital twin does not come from visualization. It comes from improving decisions in places where people are currently guessing, approximating, or arguing.

In practice, that shows up in a few consistent ways.

First, better constraint management. Most operations are governed by a small number of constraints, but those constraints move. A digital twin helps reveal when the bottleneck shifts, when a downstream step becomes limiting, or when local optimization is feeding a larger problem. The ROI shows up when teams stop improving the wrong part of the system.

Second, managing variability. Plans rarely fail because averages are wrong. They fail because variability was misunderstood. A usable model allows teams to see how variability propagates and test responses before committing. The payoff shows up in fewer expedites, more stable lead times, and less firefighting.

Third, faster decision cycles. Many operational decisions are slow not because they are difficult, but because they are uncertain. Without a model, teams debate. With a model, they test. The value is not perfection—it is making directionally correct decisions faster and with less friction.

Finally, alignment. This is one of the most underestimated sources of ROI. Planning, operations, engineering, and leadership often operate from different versions of reality. A shared model reduces the time spent reconciling those differences and shifts conversations from “whose data is right” to “what should we do about it.”

These are not theoretical benefits. Research from National Institute of Standards and Technology describes digital twins as models used to monitor status, detect anomalies, predict behavior, and prescribe actions in manufacturing systems. McKinsey & Company similarly frames digital twins as tools for faster, smarter, and more cost-effective operational decisions rather than standalone visualization platforms.

The Simple ROI Equation

If you strip this down, the economics are straightforward:

ROI ≈ (Decision Value × Decision Frequency × Improvement Rate) − Cost

Where:

• Decision Value = financial impact of getting a decision right (or wrong)

• Decision Frequency = how often that decision is made

• Improvement Rate = how much better decisions become with the model

• Cost = technology, integration, and organizational effort

This equation explains why digital twins can be extremely valuable in some environments and unnecessary in others. If decisions are frequent, high-impact, and currently made under uncertainty, even modest improvements create meaningful returns. If not, the economics fall apart quickly.

A Quantified Example (Illustrative)

The following example is illustrative, not a reported case study. Its purpose is to show how ROI can be evaluated.

Consider a mid-sized manufacturing operation:

• 1,000 production orders per month

• Average order value: $5,000

• On-time delivery: 85%

• Expedite cost per late order: $300

That results in roughly 150 late orders per month, or about $45,000 in expedite-related cost alone.

Now assume a digital twin improves scheduling and flow decisions enough to raise on-time delivery to 92%. Late orders drop from 150 to 80.

The direct monthly savings:

• 70 fewer late orders × $300 = $21,000 per month

That is roughly $250,000 annually, before accounting for secondary effects like reduced WIP, improved labor stability, or better customer retention.

If the total annual cost of building and maintaining the twin is in the $150,000–$200,000 range, the ROI becomes clear.

But notice what actually drove the value:

• frequent decisions (daily scheduling)

• meaningful consequences (delivery performance)

• improved decision quality (better system-level flow)

Not the model itself.

When Digital Twins Make Sense

Digital twins tend to make sense when complexity is high enough that intuition and static tools consistently fall short.

That usually includes operations with multiple interdependencies, shifting constraints, and meaningful variability. It also includes environments where decisions are made frequently—daily or hourly—and where small changes ripple across the system.

Equally important, there needs to be enough data to model behavior. It does not need to be perfect, but there must be usable signal: timestamps, flows, resource usage, and basic process structure.

And finally, there must be willingness to act differently. If decisions will not change, the model will not matter.

When They Don’t

Digital twins are a poor fit when the underlying issue is not visibility, but execution discipline. If the process is simple and already well understood, Lean methods and basic controls are often sufficient.

They also struggle in organizations that expect certainty. A digital twin does not eliminate ambiguity—it makes it more visible. Research from Deloitte emphasizes that the value of digital twins depends heavily on how organizations integrate them into decision-making, not just on the technology itself.

The Hidden Constraint: Behavior

The biggest barrier to ROI is not technical. It is behavioral.

If teams treat the twin as a dashboard instead of a decision tool, nothing changes. If overrides happen without feedback, the model never improves. If results are only accepted when they confirm existing beliefs, the system becomes an expensive way to reinforce the status quo.

That is why organizations like Project Management Institute and American Society for Quality are increasingly emphasizing integrated, data-driven operating models. The shift is not just toward better tools, but toward better use of them.

A Practical Test

Before investing, ask one question:

“What decision would we make differently if we had a reliable model of this system?”

If the answer is unclear, the ROI will be too.

If the answer is specific, frequent, and tied to meaningful outcomes, the case is likely strong.

The Bottom Line

Digital twins are not valuable because they model reality.

They are valuable because they reduce the gap between how the organization thinks the system works and how it actually works—and then change decisions accordingly.

That is a narrower claim than most marketing suggests. It is also the one that holds up.

The companies that see real return will not be the ones with the most detailed models.

They will be the ones that use those models to make better decisions, more often, in places where it actually matters.

References

1. National Institute of Standards and Technology, “Digital Twins” — definition and applications in monitoring, prediction, and decision support.

2. McKinsey & Company, “Digital twins: The next frontier of factory optimization.”

3. Deloitte, “How digital twins can unlock new industry advantages.”

4. Hannover Messe, industrial AI and digital twin applications in manufacturing.

5. American Society for Quality, 2026 Lean and Six Sigma Conference themes.

6. Project Management Institute, AI and data-driven project management direction.

That is why digital twins matter.

Not because “digital twin” is a fashionable phrase that vendors like to put next to glowing blue graphics. And not because every factory suddenly needs a sci-fi command center. Digital twins matter because they address a very old operational problem: management is often trying to improve a system it cannot see clearly enough, quickly enough, or as a whole.

For years, Lean helped teams see waste. BPM helped them map processes. Project management helped them structure execution. Those methods still matter. But they are largely built on snapshots. A value stream map captures a process at a point in time. A BPM diagram shows intended flow. A project plan shows what is supposed to happen next. Even a good dashboard often tells you what happened recently, not what the system is becoming.

That worked reasonably well when processes were slower, less connected, and easier to observe directly. It works less well when the real system stretches across software, machines, suppliers, handoffs, planners, and operators—each one generating its own version of the truth.

This is the real contribution of Industry 4.0. It is not just automation. It is observability. Connected systems, event logs, machine data, workflow traces, and AI-assisted analytics make it possible to see operations as they actually behave, not just as they were designed to behave. That is exactly the direction now being emphasized across industrial forums like Hannover Messe, where industrial AI, digital twins, and end-to-end automation are being discussed as part of the same practical operating stack, not as separate ideas.

A useful way to think about a digital twin is this: it is not valuable because it mirrors the operation. It is valuable because it exposes where management’s mental model is wrong.

That is a much more important job.

Consider a familiar scenario. A plant has long believed its core machining center is the bottleneck. The utilization numbers are high, queues form upstream, and everyone “knows” that machine is the constraint. So the team builds a more connected model using production data, scheduling logic, and flow information. The digital twin confirms the machining center is heavily loaded, and leadership pushes to keep it fed at all times. For a few weeks, the numbers look encouraging. Utilization rises. Output ticks upward. Somebody probably celebrates with a slide containing the word transformation.

Then the uglier numbers show up.

Work-in-process begins piling up after inspection. Expedites increase. Lead times stretch. Supervisors start manually resequencing jobs. Customer delivery performance gets worse even though local efficiency improved.

What happened?

The system did exactly what it was asked to do. It optimized a visible constraint without properly accounting for downstream inspection capacity, rework variability, and the way experienced supervisors were quietly buffering the system. The problem was not that the model failed. The problem was that the organization mistook a partial model for the whole system.

That is why digital twins are useful when they are treated as learning systems, not just control systems.

This is also where Industry 5.0 sharpens the conversation. The European Commission describes Industry 5.0 as complementing Industry 4.0 by emphasizing human-centric, resilient, and sustainable industry. In plain English: faster and more automated is not enough if the system becomes brittle, opaque, or dependent on people cleaning up behind it.

You can usually spot that brittleness before the dashboard admits it:

• planners override “optimized” schedules,

• engineers keep shadow tools because official views lack context,

• operators add manual checks back into automated flows,

• teams hit internal efficiency targets while customer performance slips.

Those are not side stories. They are the story.

The deeper shift here is that digital twins sit between classic improvement methods and modern operational reality. Lean still matters because flow, waste, and variation still matter. BPM still matters because process structure still matters. But digital twins add something those methods have always wanted and rarely had: a continuously updated, data-connected model of how the system is actually behaving.

That is why this topic is bigger than manufacturing technology. ASQ’s 2026 Lean and Six Sigma conference is explicitly framing the future around AI, automation, and advanced methodologies, while PMI is positioning AI as central to both project delivery and managing AI-enabled transformation itself. These are all signs that the professions are moving away from method silos and toward integrated operating systems.

So what should leaders do with this?

First, stop treating the official process map as the system. It is only a claim about the system. Second, pay close attention to repeated overrides, manual interventions, and workarounds. Those are often better sources of truth than the slide deck. Third, when a model improves one metric, ask the rude but necessary question: what got worse somewhere else?

That last question deserves to be asked more often.

The promise of digital twins is not that you can simulate your operation in exquisite detail. The promise is that you can reduce the gap between how the business thinks the system works and how it actually works.

And that gap is where a lot of waste, frustration, and bad management decisions have been hiding for years.

The companies that win here will not be the ones with the flashiest twin. They will be the ones willing to let the twin challenge their assumptions.

That is a much less glamorous use of technology.

It is also the one that matters.

References

1. European Commission, Industry 5.0: Towards a sustainable, human-centric and resilient European industry.

2. European Commission, Industry 5.0 overview page.

3. European Commission news release on Industry 5.0.

4. Hannover Messe, AI Powered Digital Twins: Accelerating Industrial Performance at Factory Scale.

5. Hannover Messe press release, Industrial AI as competitive game-changer (April 2026).

6. Hannover Messe, Ideas Day 2026: Future Skills for an AI-Supported Workplace.

7. ASQ, 2026 Lean and Six Sigma Conference.

8. PMI, Artificial Intelligence in Project Management.

9. PMI, Certified Professional in Managing AI (PMI-CPMAI).

What feels different now is not that one more methodology has shown up. It’s that the operating system underneath all of them is changing.

For a long time, operational improvement depended on good methods and incomplete visibility. Lean helped teams see waste. Six Sigma helped them measure variation. BPM helped them map workflows. Agile helped them shorten feedback loops. All of that still matters. But those approaches shared one practical limitation: you had to reconstruct reality from fragments. You walked the floor, interviewed people, reviewed reports, and built a version of the process that was hopefully close enough to the truth to improve it.

That worked reasonably well when processes were slower, systems were less connected, and a lot of important work still happened in plain sight. It works less well when the process crosses software, machines, suppliers, teams, and handoffs so quickly that “mostly right” can become a very expensive category.

That is why Industry 4.0 matters. The big change was not just more automation. It was more observability. Connected assets, event logs, machine data, workflow traces, and AI-supported analysis make it possible to see operations as they actually behave, not just as people describe them later. Hannover Messe’s 2026 coverage reflects exactly that mix: industrial AI, digital twins, end-to-end automation, and operational excellence are being discussed together, not as separate conversations.[1][2]

This sharper visibility makes older improvement methods more powerful, not less relevant. Waste becomes easier to detect because waiting, rework loops, and handoff delays leave data behind. Bottlenecks show up sooner. Variation becomes easier to monitor in context instead of being inferred from narrow samples. In that sense, Industry 4.0 does not replace Lean or Six Sigma. It gives them better eyesight.

But better eyesight does not guarantee better judgment.

That is the trap many organizations are walking into. They are getting faster. They are getting more instrumented. They are getting dashboards impressive enough to make a conference badge lanyard tremble with pride. But they are not always getting better outcomes.

A useful test is simple: if a process is highly automated, heavily monitored, and still frequently overridden by experienced people, you probably do not have a discipline problem first. You may have a design problem.

That is where Industry 5.0 becomes useful. The European Commission frames Industry 5.0 as complementing Industry 4.0 by emphasizing systems that are human-centric, resilient, and sustainable.[3][4] That may sound abstract until you translate it into everyday operational reality.

It looks like this:

• Supervisors resequence work because the optimization model underweights real-world variability.

• Engineers keep shadow tools because official dashboards omit context they need.

• Teams add manual checkpoints back into automated workflows because the system is efficient but brittle.

Those behaviors are often treated as nuisances, noncompliance, or signs that people “just need more training.” Sometimes that is true. Quite often, though, they are telling you something more important: the system is solving the wrong problem, using the wrong assumptions, or optimizing at the wrong level.

That is why the real shift is not from Lean to something that replaces Lean. It is from method-led improvement to evidence-rich, continuously adjusted operating systems.

At a practical level, the new stack looks more like this:

• Lean and Six Sigma define what good performance should mean.

• BPM and process intelligence show how work actually flows.

• Industry 4.0 technologies provide live visibility into system behavior.

• Industry 5.0 thinking asks whether the system remains workable for people, resilient under stress, and aligned to broader outcomes.

You can see the profession itself moving this way. ASQ’s 2026 Lean and Six Sigma conference is explicitly framing the field around AI, automation, and advanced methodologies.[5] PMI is doing something similar from the project side, positioning AI as part of project delivery and AI transformation rather than treating it like a side topic.[6][7] Meanwhile, BPM 2026 and the vendor-independent process mining community continue to center process visibility, analysis, and practical business application.[8][9]

That does not mean every company suddenly needs a digital twin, a process mining platform, and a philosophy seminar on human-centered systems. It does mean leaders should ask better questions.

When people bypass the official process, is that resistance, or feedback? When a dashboard says performance improved, did the whole system improve, or just one metric? When automation removes effort, did it also remove understanding?

Those questions are not anti-technology. They are what serious operational maturity looks like now.

Industry 4.0 gave organizations more visibility and speed. Industry 5.0 raises the bar. It asks whether that visibility is leading to systems that are not just efficient, but also sound, adaptable, and worth working inside.

The organizations that pull ahead will not be the ones with the most software, the most automation, or the most enthusiastic slide about transformation. They will be the ones that combine clear methods, better evidence, and human judgment under ambiguity.

Not just faster operations. Better ones.

References

[1] Hannover Messe, “Ideas Day 2026: Future Skills for an AI-Supported Workplace.”
[2] Hannover Messe, “Industrial Metaverse in Practice at SmartFactory-KL.”
[3] European Commission, “Industry 5.0.”
[4] European Commission, “Industry 5.0: Towards a Sustainable, Human-Centric and Resilient European Industry.”
[5] ASQ, “2026 Lean and Six Sigma Conference.”
[6] PMI, “Artificial Intelligence in Project Management.”
[7] PMI, “PMI Certified Professional in Managing AI (PMI-CPMAI).”
[8] BPM Conference, “BPM 2026 in Toronto.”
[9] IEEE Task Force on Process Mining, “International Conference on Process Mining (ICPM).”

Join me on this journey.

There I am, watching the Safety Team truck roll out — this beast of a Chevy Silverado covered in sponsor logos, rescue gear, and a mounted vacuum to the bed like someone at a garage project decided to go way too far — and I started thinking less about the racing and more about the operation behind it.

The street sweepers at Long Beach are no joke. These aren’t the slow-rolling machines you see at 6 a.m. in a parking lot. They are fast, coordinated, and working with urgency. The second there’s a debris yellow flag — a loose piece of bodywork at the exit of the fountain, a blown tire sending rubber chunks across the racing line — those trucks are out there. Moving. Cleaning. Restoring the track so the race can continue.

“The show must go on. But it can only go on if the lane is clear.”

Why Does IndyCar Bother?

Here’s the honest answer: because debris kills. A piece of carbon fiber on a street circuit at 170 mph is not an inconvenience. It’s a tire shredder, a steering rack destroyer, a race-ender — or worse. The sweeper trucks aren’t a courtesy. They are safety infrastructure. They are operational continuity tools. If the track isn’t cleared, the race doesn’t restart. If the race doesn’t restart, you’ve got millions of Dollars’ worth of machines and drivers sitting in pit lane going nowhere — and tens of thousands of people in the stands wondering what they paid for.

The same thing happens on Stadium Super Trucks, by the way. Those trucks are literally flying off jumps, throwing dirt and debris everywhere. Between heats, they sweep. They clear. They reset. Because the next run has to be clean.

This is a process problem wearing a racing uniform.

Sound Familiar?

It should. Because this happens every single day on roads, in warehouses, and across supply chains — and we’re not nearly as fast or as organized about it as IndyCar is.

Think about a highway accident. Two cars clip each other on the 405. Nothing catastrophic — but both vehicles are now sitting in lanes two and three at 8 a.m. on a Monday. Police are on the way. Tow trucks are on the way. But until that lane clears, you’ve got a 6-mile backup forming in real time. And somewhere in that backup is a refrigerated truck hauling strawberries from Oxnard to a distribution center in Commerce. That truck has a temperature-controlled delivery window. Miss it, and you’re not just late — you’re throwing product.

The race doesn’t stop for that driver. The perishables don’t negotiate with a traffic jam. The market doesn’t care why the truck is late.

The Real Lesson: Speed of Recovery Matters More Than Absence of Incidents

You’re going to have incidents. Tires blow. Parts fail. Accidents happen. That’s not a pessimistic take — it’s just physics and probability at work. IndyCar knows this. They don’t design races assuming nothing will go wrong. They design the response system to match the speed of the operation.

That’s the part most businesses get backwards. They over-invest in prevention and under-invest in recovery. Then something goes sideways — and everyone’s standing around waiting for the tow truck, with no protocol, no urgency, no clear lane-clearing process.

In lean and continuous improvement terms, we call this Mean Time to Recovery (MTTR). How quickly can you get from “incident identified” to “flow restored”? IndyCar has an entire team dedicated to driving that number down. They practice. They stage the equipment. They communicate with flags, radios, and pit wall timing systems. It is a beautiful, mechanical ballet of incident response.

Meanwhile, back at your business, incident response is probably Karen from accounting calling IT who puts in a ticket that gets triaged sometime Thursday.

What Would Your Sweeper Truck Look Like?

This is the question worth sitting with. In your operation — wherever your “race” is running — what’s the mechanism for clearing debris and restoring flow?

Is it documented? Is it fast? Is the equipment staged and ready, or are you scrambling to find it when the yellow flag flies? Do people know their roles the moment something goes wrong, or is the first 20 minutes just people figuring out who owns the problem?

The Safety Team doesn’t debate ownership at Turn 8. They move.

I’d argue that building your version of a sweeper truck — whether that’s an escalation protocol, a rapid-response team, an emergency supplier contact list, or a 15-minute “clear the lane” meeting process — is one of the highest-leverage investments you can make in your operation. Not sexy. Not a shiny new software tool. Just a fast, reliable, well-rehearsed process for getting back to green.

Because the race isn’t waiting for you. And neither are those strawberries.

I took a photo of my desk. Just pulled out my phone, snapped a picture of the usual disaster — papers stacked in the corner, two coffee mugs (one current, one aspirational), cables going nowhere in particular, a notepad with a to-do list from three weeks ago that still has unchecked boxes on it.

Then I uploaded it to for the LLM (I happened to use Copilot on my Windows machine) and typed: “Look at this workspace through the lens of Lean. What waste do you see, and what would you change?”

What came back wasn’t a generic “clean your desk” lecture. It was a point-by-point breakdown of waste called out specifically from my photo — waiting, motion, inventory, non-utilized space. It spotted things I’d stopped seeing because I’d stopped looking.

That was the moment I realized we now have a Lean consultant in our pocket. Most of us just haven’t figured out what to do with it yet.

The Problem With Lean Eyes

One of the hardest things about implementing Lean is that you stop seeing your own space. The pile of stuff in the corner isn’t a waste problem anymore, it’s just the corner. The three-step process you do every morning isn’t inefficient, it’s just how you do it.

This is why manufacturing companies bring in outside consultants to do Gemba walks. Fresh eyes. Someone who walks in and immediately asks “why is that there?” about the thing you haven’t questioned in four years.

AI vision gives you that same outside perspective on demand. And it doesn’t charge by the day.

How It Actually Works

The workflow couldn’t be simpler. Take a photo of whatever you want evaluated — your workspace, a storage area, a section of the shop floor, a process board. Upload it to Claude, ChatGPT, or any AI with vision capability. Then give it a focused prompt.

Not just “what do you see?” — but something with a Lean lens. Here’s one you can use right now:

📋 Prompt Template

“Analyze this photo using Lean principles. Identify which of the eight wastes are visible — Defects, Overproduction, Waiting, Non-Utilized Talent, Transportation, Inventory, Motion, and Extra Processing. For each waste you identify, describe specifically what you see and suggest one concrete improvement. Then give me a prioritized top three actions to take first.”

Swap in “5S analysis” or “point-of-use storage” instead of the eight wastes if you want a different angle. The specificity of the prompt directly determines the quality of what comes back.

What It Actually Catches

When I ran my desk photo through, it flagged things I genuinely hadn’t thought about.

The old coffee mug was inventory — stuff sitting there not serving a purpose, adding visual noise that increases cognitive load every time I sit down. The cable pile was a motion problem — every time I need a specific cable, I search. That search time is invisible waste until you add it up across days and weeks. The abandoned to-do list was a defect — a broken signal that something hadn’t been processed and was abandoned in place rather than closed out or re-entered into a live system.

Three items. One photo. Five minutes.

The Catch (There’s Always One)

AI sees what’s in the frame. It doesn’t see what happens between the frames — the walk across the office, the four-email chain before someone makes a decision, the meeting that exists because two people don’t talk directly to each other. By the way, if you take a video, it takes several frames of the video.

Process waste baked into how things flow rather than where things sit doesn’t photograph well. For that you still need a value stream map, a process walk, or a conversation with the people actually doing the work.

So use the photo analysis as your opener, not your closer. It builds your list of things worth investigating. What you do with that list is still on you.

The Bottom Line

We’ve spent decades saying that identifying Lean waste requires training, experience, and a consultant with a clipboard and a day rate. That’s still true for deep operational work.

But “take a photo and ask” now gets you 60% of the way there in a few minutes.

So take the photo. Point it at your desk, your stockroom, your team’s shared wall. Ask the question. You might not like everything it tells you.

That’s kind of the point.

Don’t start your next process improvement effort with a meeting about it. Start with a walk and a camera. You’ll have more to work with before anyone’s even found a conference room.

The question isn’t whether AI belongs in manufacturing. It’s where it’s showing up and what it’s actually doing.

The Porsche Problem Worth Solving

Porsche’s Leipzig plant builds three powertrain types — combustion, hybrid, and full electric — on a single assembly line. Every vehicle is different. Theoretically infinite combinations of model, drive type, color, and equipment. Over 4,000 work steps per vehicle. 5,000 parts assembled during pre- and final assembly.

That’s not a production line. That’s a logistics nightmare with a finish line.

Their answer is what they call the “pearl necklace” — precise sequencing of vehicles so every step of the process is coordinated with the next. Suppliers plan ten days out. Parts arrive when needed, presorted, ready to install. No hunting. No sorting. No waiting.

AI makes this level of coordination manageable. It’s planning at a scale and speed no spreadsheet or scheduler handles well. Sequence changes ripple upstream automatically. The line keeps moving.

This is Lean’s just-in-time principle — but now it’s operating with real-time data, predictive logic, and the complexity of three entirely different powertrains running side by side.

When the Machine Tells You It’s About to Break

The traditional maintenance model is reactive. Something fails. You fix it. In the meantime, the line stops, schedules slip, and everyone scrambles.

Predictive maintenance flips that. Sensors monitor equipment continuously — vibration, temperature, pressure, cycle counts. AI models learn what normal looks like. When something deviates, it flags it before failure. Maintenance gets scheduled in a planned window, not an emergency.

At Porsche, this connects directly to their goal of zero unplanned downtime. The camera system that scans EV battery surfaces for foreign objects — loose washers, mislaid nuts — is the same principle applied to quality. Catch the problem before it becomes a defect. Before it reaches the customer. Before it costs ten times more to fix.

The difference between reactive and predictive isn’t just efficiency. It’s a fundamentally different relationship with your process. You’re no longer chasing problems. You’re ahead of them.

What AI Is Exposing

Here’s the honest part. AI is also a mirror.

Companies that thought they had their operations under control are finding out they didn’t. The data isn’t clean. The processes aren’t standardized. The variation they ignored for years is now visible — and significant.

That’s not a technology problem. It’s a process maturity problem. AI just surfaces it faster.

The organizations getting the most out of AI in manufacturing are the ones who already had a culture of continuous improvement. The Lean discipline. The data hygiene. People already asking where does this process break down?

AI gave them better answers, faster. For everyone else, it’s a wake-up call.

The Takeaway

AI doesn’t replace the thinking. It extends it.

It sees more than we can. It catches variation we miss. It plans farther ahead than a scheduler allows. It learns from patterns across thousands of cycles.

But it still needs humans to define what good looks like, to act on what it surfaces, and to improve the process when the data points to a problem.

Lean gave us the framework. AI gives us the horsepower.

Same goal. Better tools.

Where are you seeing AI make a real difference on the floor — or fall flat? Drop it in the comments.

Sources

• Porsche Newsroom — “How do you produce three drive types on a single assembly line?” (2024): https://newsroom.porsche.com/en/2024/company/porsche-leipzig-production-three-drive-types-single-assembly-line-37453.html

• Porsche Leipzig — “Production in Detail” (2025): https://newsroom.porsche.com/en/company/leipzig/production-in-detail.html

• Manufacturing Digital — “Marrying Autonomy & Innovation at the Porsche Plant Leipzig” (2024): https://manufacturingdigital.com/articles/marrying-autonomy-innovation-at-the-porsche-plant-leipzig

• DigitalDefynd — “5 Ways Porsche is Using AI” (2024): https://digitaldefynd.com/IQ/ways-porsche-using-ai/

Here’s the honest answer — they’re all the same conversation. Different eras, different industries, different vocabulary. Same question underneath:

Where does value get created, and where does it get stuck?

The lineage is worth knowing. Each generation built on the last.

Taylor (1911) — Scientific Management. Time the work. Standardize what works. Radical idea at the time: work can be observed and improved. You don’t just accept it.

Shewhart & Deming (1920s–40s) — Statistical Process Control. Use data to catch problems before they become defects. Deming took it to Japan after WWII. Toyota ran with it.

Management Accounting (1920s) — Standard costing, variance analysis. Accountants were asking “where did we deviate from plan?” long before any of these frameworks had a name. Process visibility with a ledger.

Toyota Production System / Lean (1950s–70s) — Eliminate waste. Pull, don’t push. Stop and fix when something’s wrong. Don’t maximize output and sort the mess later. Elegant then. Still elegant now.

Kaizen — Not a methodology. A mindset. Everyone, every day, looking for small improvements. It lives inside Lean but works anywhere.

TQM — Total Quality Management (1970s–80s) — Quality isn’t just the production floor’s job anymore. It’s everyone’s. The whole organization aligns around the customer’s definition of quality.

Six Sigma (1986) — Motorola, then GE. Where Lean asks where’s the waste, Six Sigma asks where’s the variation. More statistical rigor. DMAIC. Fishbone diagrams. Eventually married Lean to become Lean Six Sigma — stronger together.

Theory of Constraints (1984) — Goldratt’s insight: stop trying to improve everything at once. Find the one bottleneck choking your throughput. Fix that first. The Goal is still worth reading.

BPR — Business Process Reengineering (1993) — Hammer & Champy said sometimes the process isn’t just inefficient, it’s fundamentally broken. Start over. Got misused as cover for downsizing, but the underlying challenge was real.

Operational Excellence (1990s–present) — The synthesis. Not a single methodology but a way of operating where all these tools serve a coherent strategy. Sustained improvement, not just achieved improvement.

Agile / Scrum (2001) — Software developers got fed up with 18-month waterfall projects delivering things nobody wanted. Smaller batches. Faster feedback. Working software over documentation. Borrows heavily from Lean whether it knows it or not.

DevOps (late 2000s) — Agile built software faster but it piled up waiting for IT operations. DevOps broke down that wall. Automate the pipeline. Make releasing a non-event. Keep value flowing to the customer.

Strip it all back and here’s what remains:

• Make the work visible

• Make it flow

• Learn from what breaks

• Repeat

The domain changes. The vocabulary changes. The cadence changes. The goal doesn’t.

The pragmatic takeaway: the frameworks are useful. The thinking behind them is more useful.

The people who move the needle don’t plant a flag in one methodology. They read the problem first, then reach for the right tool:

• Waste on the floor? Think Lean.

• Variation causing defects? Reach for Six Sigma.

• One bottleneck strangling everything? Theory of Constraints.

• Iterative work with changing requirements? Run Scrum.

• Delivery pipeline is the drag? Think DevOps.

Same river. Different boats. The water’s been getting clearer for over a hundred years — and the conversation isn’t done.

Which framework has made the biggest difference in your world? Drop it in the comments.