Why Most AI Pilots Never Touch the ERP

Most AI pilots we see are technically successful and organizationally irrelevant. They summarize emails, draft first pass copy, or answer questions about a document nobody was going to read anyway. Meanwhile the ERP, the system holding the actual operational truth of the company, sits completely untouched.

This is not an accident. It is the path of least resistance, and it quietly guarantees the pilot never produces a result leadership actually notices.

AI pilots default to the easiest system to touch, not the most valuable one.

Email, documents, and chat interfaces are easy to connect AI to. They are low risk, well understood by AI vendors, and do not require anyone to understand the internal structure of a company's core operational systems. That is exactly why so many pilots start and stay there.

The ERP is the opposite. It holds messy, years old data, custom fields nobody remembers the purpose of, and workflows specific to how this particular company actually runs. Touching it requires real understanding, real access, and real risk if something goes wrong, so most vendors quietly steer the pilot away from it.

The ERP is where the actual leverage lives, which is exactly why it gets avoided.

Inventory levels, production schedules, financial close, order fulfillment, vendor payments. This is where a mid market company's real operational complexity concentrates, and it is also where an AI capability that actually works would save the most time and prevent the most costly mistakes.

We ask leadership teams a blunt question when we hear about a pilot: if this succeeded completely, would anyone outside the pilot team notice. If the honest answer is no, the pilot was aimed at the wrong system from the start.

ERP data is harder to work with because it accumulates years of decisions nobody remembers making.

A CRM is relatively young in most companies and gets cleaned up periodically because sales teams complain loudly when it is wrong. An ERP is often older, touched by more departments, and shaped by years of workarounds nobody documented, because the system technically still functioned even with the workaround layered on top.

That messiness is not a reason to avoid the ERP. It is the actual reason forward deployed AI work exists: someone has to understand that mess well enough to build something that works with it instead of assuming it away.

A pilot that never touches the ERP cannot produce evidence that AI will work where it matters.

Leadership approves further AI investment based on pilot results, reasonably. If the pilot only ever touched low stakes systems, the results tell leadership almost nothing about whether AI can be trusted with the systems that actually run the business, which means the next investment decision gets made on incomplete evidence.

This is how companies end up stuck for years in a pattern of small, safe AI experiments that never graduate into anything that changes how the company actually operates.

We have watched leadership teams proudly report a dozen completed AI pilots over two years, none of which touched a system that actually runs the business, and then wonder why AI still feels like a side project rather than a real capability. The pilot count was never the problem. The target was.

Starting with the ERP does not mean starting with the riskiest part of the ERP.

The fix is not recklessness. It is choosing a genuinely bounded, well understood problem inside the ERP rather than avoiding the system entirely. Matching purchase orders to invoices, flagging inventory discrepancies before they become a production problem, or catching duplicate vendor entries before a payment goes out twice are all specific enough to build carefully and verify against a known right answer.

None of these require handing an AI system broad authority over financial close on day one. They require picking a narrow, real, valuable problem inside the system that actually matters, instead of retreating to email because it is easier.

The IT team's caution about the ERP is usually reasonable, which means the answer is inclusion, not workaround.

Whoever owns the ERP internally has good reason to be protective of it, because it is genuinely load bearing infrastructure and a mistake there has real consequences. AI vendors sometimes treat that caution as an obstacle to route around rather than a signal to take seriously, which is exactly backwards.

The right approach brings the ERP owner in early, scopes the first use case narrowly enough that they can verify it themselves, and earns broader access over time as trust builds. Trying to bypass that caution to move faster almost always costs more time later, once something breaks and the whole initiative loses credibility internally.

Sequencing this correctly means fixing the process before automating it, the same rule as everywhere else.

We would not build an AI layer on top of an ERP process that was never clearly defined in the first place, for the same reason we would not automate an undefined sales sequence. The AI just executes the existing confusion with more speed and more apparent authority, which makes the underlying problem harder to catch, not easier.

What CEOs ask us about this

Isn't it safer to start with something low risk like email?
It feels safer, but it also produces results that tell you nothing about whether AI can handle the systems that actually run your business, which just delays the real decision.

What is a reasonable first ERP use case?
Something narrow and verifiable, like flagging inventory discrepancies or catching duplicate vendor payments, where the output can be checked against a clear right answer before scope expands.

Do we need to clean up our ERP data before starting?
Not entirely, and waiting for perfect data is usually a stall tactic in disguise. Part of the work is understanding what is usable now versus what genuinely needs fixing first.

How do we know if our AI vendor is capable of this kind of work?
Ask them directly whether they have implemented anything inside a real ERP, not just against sample data or a demo environment, and ask for specifics about what broke and how they handled it.