Share PLM Summit 2026: Why AI in PLM Is a Human Problem

I’m coming to Share PLM Summit 2026, taking place on May 19–20 in Jerez de la Frontera, Spain. It the second one. If you missed the summit last year, it is an opportunity to check my article- What I Learned at the Share PLM Summit: Five Observations That Challenge the Status Quo and Five Principles of Building a Human-Centric PLM in 2025..

The question that has stayed with me most from recent customer conversations is deceptively simple. People ask: how will your AI learn about my problems?

Not “what features does it have.” Not “which models does it use.” Something more personal and more honest than that. They want to know whether the software will eventually understand their specific situation — their parts, their decisions, their team’s way of working, the pressures they are under. As we explored in What We Learned Asking Customers About AI for BOM and PLM, customers are not asking about AI in the abstract. They are asking whether AI will ever actually know them.

That question is the starting point for everything I want to talk about at Share PLM Summit 2026. The summit is built around workshops, conversation, and the human side of transformation, which is exactly the right setting for what I think are four genuinely hard questions.

Will AI Replace Me in Engineering and PLM Workflows?

This is still the first thing many people are thinking, even when they phrase it differently.

In engineering organizations, this fear does not usually come out as a direct statement. It arrives as skepticism, slow adoption, or a reluctance to rely on the output. People have been through enough waves of “transformation” to know that the language of empowerment and the reality of displacement are not always far apart.

This fear deserves a serious answer, not a reassuring one.

What our experience building AI into OpenBOM has shown is that the real risk to relevance is not AI itself. It is whether the AI is actually useful. If it is not grounded in real product context — in your specific parts, revisions, BOMs, changes, sourcing decisions, and engineering history — it produces plausible-sounding output that nobody trusts. And nobody adopts something they do not trust. As I wrote in PLM 2026: Re-examining Engineering and Manufacturing Workflows for AI, the biggest opportunity for AI is not to be smarter, but to make work lighter — reducing friction rather than replacing people.

The answer to “will I be replaced?” is genuinely connected to whether the AI knows enough about your work to be worth trusting. And building that knowledge takes time. It is not installed. It is earned through use.

How Does AI Make Engineers More Effective, Not Less Relevant?

This is the more useful version of the same question, and it leads directly to one of the concepts we have been building around at OpenBOM.

When customers ask how our AI will learn about their problems, what they are really asking is whether the system will eventually understand enough about their work to help them perform better. At OpenBOM, the concept we have built around this is Product Memory. The Product Memory Flywheel describes how this works in practice: the system first captures your product data from the tools where design work happens, then learns from your activity over time — the decisions you make, the changes you push, the patterns in how your team works — and builds an understanding that accumulates. The AI becomes more useful as the memory grows.

But it is a flywheel, not a switch. As I wrote in Why PLM AI Needs Product Memory, PLM has always been good at remembering what happened. What it was never designed to remember is why something happened. AI becomes useful in engineering not when it generates text around disconnected documents, but when it can interpret the connected context of parts, BOMs, changes, supplier decisions, and design intent. That is where real performance improvement lives: not in having smarter outputs, but in building a system that progressively understands your problems better than you can hold in your head at once.

Who Owns the Product Intelligence Created from Your Engineering Data?

This is the question I find most strategically underexplored in most AI conversations, and it is one I increasingly think of as the intelligence lock problem.

The data ownership conversation is familiar by now. People understand file access, database control, and vendor lock-in. But AI adds a layer that the traditional conversation does not cover. The question is not only where your data lives. It is where the intelligence derived from your data lives — and who controls it.

If your engineers, planners, and operations teams interact with AI systems every day, those systems are not simply reading information. They are forming a new understanding of your organization: how you work, what you decide, how you handle exceptions, where your risks tend to cluster. Over time, that becomes something genuinely valuable — not just data, but intelligence about your products and your patterns.

As I explored in PLM Single Source of Truth: Why It Was Never the Final Answer, the deeper problem has always been that PLM systems capture status, not reasoning. 

AI raises the stakes on that gap considerably. If the accumulated understanding of your product decisions disappears into a vendor-controlled black box that you can access through a subscription but never truly own, you have created a new kind of dependency. And in Product Memory — Architecture and the Future, I argue that product intelligence must be governed the same way product data has always needed to be governed — as a durable company asset, not a vendor service. Read more about the vision of Product Memory.

Architecture, in this sense, is not a technical detail. It is a governance question. For companies that intend to still be competitive in ten years, how product intelligence is captured, structured, and controlled will matter more than which AI features they have access to today.

Which Engineering Workflows Should Be Redesigned Now That AI Can Interpret and Automate Parts of the Process?

This is the question I think we are only beginning to ask seriously, and it may be the most consequential one.

Most AI implementations I observe are additive. Take the existing workflow. Insert an AI assistant at one step. Measure improvement. Move on. This treats the workflow as a given when it is often the source of the problem. As I wrote in Why PLM Must Be Re-Architected for AI Agents, dropping an agent into a workflow built for human screen interaction does not make the workflow intelligent. It creates friction and gaps the agent has to work around rather than through.

Many engineering and manufacturing workflows were designed around information scarcity. Files had to be routed manually because context did not travel automatically. Approvals accumulated because the system could not provide enough visibility to allow faster trust. When AI can now assemble context, identify relationships, and automate some of the mechanical transitions between steps, the question should not be “where do I insert AI?” The better question is whether the inherited workflow still deserves to exist in its current form. In OpenBOM and the Direction Ahead: Strategy for 2026, I describe this shift as moving from product data control toward building product knowledge that compounds over time — which requires a fundamentally different view of what workflows are for.

The role of the human in many of these workflows will shift away from collecting, searching, routing, and formatting, toward reviewing, deciding, challenging, and steering. That does not make the human smaller. In most cases, it makes human judgment more visible and more consequential, because the mechanical parts of the process start to recede.

Share PLM Summit AI Workshop 

This is why I am looking forward to facilitating a workshop AI, Identity and Future of Engineering at Share PLM Summit together with Helena Gutierrez and Martin Eigner.

Helena has framed her own contribution to the summit around how humans adapt in the age of AI and how work is changing under the pressure of accelerating technology. That framing is exactly right. Martin brings a long and grounded perspective on PLM architecture and transformation — and I note that some of our shared thinking about product complexity and AI has already surfaced in discussions that reference his work, especially this publication – PLM: Stop Decorating old Silos with AI. It’s Time for ‘Agentic’ Product Memory.

The workshop is not designed to deliver clean answers. It is designed to put the tensions on the table honestly: people want help, but not irrelevance; companies want intelligence, but not loss of control; teams want speed, but not opacity. And all of us are beginning to see that AI should not simply be dropped into existing processes. In many cases, it should force us to ask whether those processes still make sense.

That, to me, is the conversation worth having. Share PLM Summit 2026 is built for exactly that kind of exchange. I am looking forward to being there, to the workshop, and to the conversations that happen when these questions are taken seriously in the right room.

If AI is really changing PLM, then it is not only changing software. It is changing the meaning of work, the design of workflows, and the architecture of knowledge itself.

Are you coming to Jerez de la Frontera, Spain? If yes, I will see you there. If not, there is still time to register – Share PLM Summit 2026. 

Best, Oleg