ERP data has become part of the fuel that gives AI agents and assistants the business context to do their jobs.
But what happens when ERP data is no longer just system-of-record data? What happens when it must become more exposed?
That creates a new governance problem. In the past, valuable ERP data could be protected partly because ERP systems were hard to reach, difficult to change and often closed off from the rest of the software stack. But if organizations want to take advantage of AI, some of that data must become more accessible to partners, data platforms, agents, business users and other enterprise systems.
The challenge is doing that while still protecting governance, process context, security and control.
AI puts new pressure on ERP data
SAP is dealing with that tension directly. At its annual Sapphire conference in May, the company introduced products and updates meant to give customers the data infrastructure to use AI successfully -- and, SAP would argue, safely -- within its ERP platforms.
But the larger problem goes beyond SAP. AI needs access to data inside and outside SAP systems. SAP needs its own data to remain valuable, but it also needs that data to work in a broader AI and data ecosystem.
SAP's approach also shows why this is not just a data-access problem. The company is using knowledge graphs to help AI navigate ERP data, relationships and business objects, which points to the larger need for structure around the data AI is asked to use.
That is the core tension: Open the data enough to make AI useful, but govern it tightly enough so the business does not lose control over what the data means.
Enterprise leaders need to ask the unglamorous questions before they let ERP data flow into AI tools, partners or orchestration layers: Which data is safe to expose? Which system remains the source of truth? Does the data still carry the process context that made it useful in the first place? Who can use it, who can change it and who is responsible if an AI tool acts on the data in the wrong way?
Otherwise, the risk is not just that sensitive data gets exposed. It is that ERP data gets separated from the rules, process context and controls that made it reliable enough to use in the first place.
ERP data connects core business functions, which makes it valuable fuel for AI -- and a new control problem for enterprises.
Raw data access is not context
AI tools can have access to all the data they want. But without the context for how that data is used, the results can become unreliable, useless or even dangerous.
That risk grows when agents, LLMs and other AI tools cross ERP, CRM, HR, customer service and collaboration system boundaries. One system's version of the truth might not match another's. One system might have the record. Another might have a policy constraint. A third might have the current status of the customer, supplier, employee or order.
In other words, AI can act on one system's version of the truth while missing a more important business constraint somewhere else.
So, ERP data exposure is not only a governance, security and compliance issue. It is also a context issue. AI needs data from across systems, but it also needs to understand how that data is used in every system it touches.
Where ERP data can lose context
ERP data becomes risky only when it is stolen, copied or exposed to the wrong person. It can also become risky when it is used without the business context that made it reliable.
That can happen in several ways.
A customer might look ready for renewal in CRM, while ERP shows a compliance hold or unresolved billing issue. A supplier might be approved in one procurement workflow but restricted in another region, category or contract. Inventory might look available in one system but already be reserved, quality-blocked or stuck in transit. A worker might appear as a candidate in one system and an employee in another.
Those are not just data-quality problems. They are context problems.
AI agents and assistants need to know more than what the record says. They need to know where the record came from, which system is authoritative, which policy applies and whether the data still means the same thing once it leaves the system where it was created.
The goal is not to keep ERP data locked away forever. It is to make sure that when the data moves, enough meaning moves with it.
That adds another layer of complication. Vendors and enterprises are starting to work on parts of this problem through context engineering that gives AI more business meaning around the data, not just access to the records. Metadata structures, integration rules, identity mapping, access policies and data-governance models also matter. But the hard part is not just technical. It is deciding who owns the meaning of the data once AI starts using it across the business.
The problem is not hard to picture. Say a CRM agent spots what appears to be a perfectly good renewal opportunity. That might be true inside CRM. But if ERP shows the same customer is on a compliance hold or has an unresolved billing issue, then the agent is working with only part of the truth. Same thing with a supplier that looks approved in one procurement process but is restricted in another region or contract. Or inventory that appears available in one system but is already reserved, quality-blocked or in transit.
That is where the danger comes in. The AI is not necessarily making up data. It might be using real data from a real system. The problem is that the record does not always carry all the business meaning around it. Once that meaning gets lost, the answer can look reasonable and still be wrong.
Those are not just data-access problems; they are business-context problems.
When ERP data gets separated from the business definitions, policies and systems of record that made it useful, AI output becomes untrustworthy at best and dangerous to the business at worst.
Citizen developers pull data closer to the work
Modern citizen developer programs take long-available low-code and no-code tools and add generative AI to make it easier for nontechnical employees to build small AI agents and automations.
Why would enterprises go that route? The answer is pretty simple. Demand for AI tools is already outstripping what many IT, data science and AI teams can build on their own.
At Ducker Carlisle, the company started a citizen developer program after its data science and AI specialists were overwhelmed with requests for AI applications. The goal was not to turn business users into full enterprise software developers. It was to help them build useful-enough agents that could automate specific tasks, support the human workforce and reduce costs.
That sounds good -- pretty great, actually. But the ERP data-control problem does not go away just because the AI work starts closer to the business. If anything, the issue becomes more complicated.
Open the data enough to make AI useful, but govern it tightly enough so the business does not lose control over what the data means.
Citizen developers can sit in research, sales, HR, finance and other departments. That means their AI tools can quickly move near ERP, CRM, HR, finance, customer and operational data. The risk is not that business users build AI tools. More power to them. The risk is that useful local AI tools start touching important data and workflows without enough ownership.
The same issue occurs on the citizen-developer side. Business users building small AI tools is not the problem. In many cases, that is exactly where the useful ideas will come from.
The problem starts when those local tools get close to important data or start changing how real work gets done. Then someone must decide what data is fair game, what should stay off-limits and when IT, security or compliance needs to take a look. And at some point, a useful little team tool might stop being a local experiment and become software the enterprise has to own.
These should read less polished, less list-driven and more like your natural argument.
Too many restrictions and the citizen-developer promise gets smothered. Too little and the business creates a new layer of shadow AI sitting close to sensitive data and important workflows.
ERP data is being pulled in two directions
AI is pulling ERP and related enterprise data in two directions at once.
Vendor platforms, partner ecosystems and AI agents are pulling it upward into broader AI and data environments. Citizen developers and business users are pulling it outward toward the people closest to the work.
Both directions have value. One can make enterprise systems smarter and more connected. The other can help employees automate real work that centralized IT teams might never have time to reach.
But both also make the same control problem harder: Who gets access to the data, what context travels with it and who owns the result when AI acts on it?
ERP data used to be valuable because it was structured, governed and close to business processes, making it meaningful. AI does not make that less important. It makes the control around that data matter more.
The next ERP data problem is not just opening access. It is doing so without losing the context, ownership and control that made the data worth using in the first place.
James Alan Miller is a veteran technology editor and writer who leads Informa TechTarget's Enterprise Software group. He oversees coverage of ERP & Supply Chain, HR Software, Customer Experience, Communications & Collaboration and End-User Computing topics.
