"Read-only co-pilot good, write access hard no" — what ERP buyers get right about AI

Spend an evening reading what ERP administrators actually say about AI — on r/ERP, r/CRM, r/sysadmin, r/Dynamics365 — and a pattern emerges that vendor marketing rarely engages with directly: the objections are not fear of the unfamiliar. They are precise, they are correct, and taken together they read like a requirements document. This piece quotes the objections as written, agrees with most of them, and shows what an architecture that takes them seriously looks like.

#The objections, in the buyers' own words

On write access. A commenter on the r/ERP thread "AI in ERP software. Worth going that route?" put the whole debate in one line: "Read-only AI for suggestions? Fine. Write access to production ERP? Hard no." And the question that follows from it — who owns the mess when an agent posts a batch of wrong invoices or changes a pricing table — comes up wherever practitioners compare notes on agentic ERP.

On permissions. The recurring sysadmin framing: giving today's AI assistants broad ERP access feels like handing a junior developer root on production — an assistant must not become a new superuser role.

On data. The same threads return again and again to visibility: an ERP holds contracts, pricing and payroll — everything a breach would ruin — and admins are unwilling to pipe it into a co-pilot when nobody can say where the prompts and logs are stored. The fear behind the fear, stated repeatedly: nobody wants their ERP becoming someone's training dataset.

On trust in the numbers. On hallucination, the pattern across ERP threads: demos look great until a question goes slightly off-script and the model confidently invents a number — and no one is letting that near inventory or the general ledger without a human in the loop.

On price and hype. And on pricing, the blunt version buyers share: too many vendors put a chatbot on top and raised the price — show a concrete business case, not another keynote.

#They are right

Here is the uncomfortable part for anyone selling AI into ERP: every one of those objections is well-founded. An assistant with blanket write access is a liability. A model wired straight to the database does turn every chat into a potential privilege escalation. Prompts do go somewhere, and if the vendor cannot say where, the correct assumption is the bad one. A system that invents one forecast number has forfeited its place near the ledger. And buyers who report chatbots bolted on at a premium are describing purchases they actually made.

The mistake is treating these objections as resistance to overcome. They are the specification. Our own demo reflects this: the script ends on the audit trail rather than a feature reel — a deliberate choice, because the trail is what the skeptics in the room need to see before the drafting matters. An AI worth letting near a production ERP is one designed as if the skeptics were in the room — because when the purchase decision comes, they are.

#The objections, read as a design spec

"Write access hard no" → writes wait for a person. The workable answer is not "trust the model" but a gate: every proposed change matched against a rule — allow, deny, or confirm — with anything above policy held for human approval. Value caps for amounts, rate limits so nothing loops, and a dry-run that shows the exact change before it lands. Then "read-only until we trust it" stops being a compromise and becomes a rollout setting. Odient's write-gate is built and tested this way — the controls are enumerated on the security page.

"Not a new superuser role" → the AI acts as the asker. The assistant should hold no permissions of its own. Ask about a record you cannot open, and it refuses — and the refusal is logged like everything else. One engine can still serve many jobs safely if each assistant is scoped to its role: the public-facing one reads Helpdesk and the knowledge base and nothing else.

"Where do the prompts go" → an answerable question, in writing. Which fields leave the instance per request, what gets stripped before a model sees it, where responses are stored and for how long, and — in the contract, not the FAQ — whether customer data trains models. For Odient the training answer is no; whatever vendor you evaluate, the answer belongs in writing.

"Confidently invents numbers" → every answer carries its source. An assistant reading live records can attach the record to the number — this order, that invoice, this stock move — so checking takes one click instead of an act of faith. Answers without receipts are the thing the r/ERP commenter was right to keep away from the GL.

"Who owns the mess" → one audit record per decision. Allowed, blocked and approved, side by side, tied to the person who asked — nothing sampled. When something goes wrong, the trail answers what ran, who approved it, and what was refused. That is also, not incidentally, what your auditor will ask for.

"Show me a business case" → prove it on your own data. The honest response to pricing skepticism is a pilot on the buyer's own instance, where the drafts, the chases and the traces either save real hours or they do not. Odient's beta is free for early Odoo teams for exactly this reason.

#A detail from the source, since we read it

One example of why "scoped access" claims deserve suspicion rather than nods. When we built Odient's session handling, we read Odoo's authentication path instead of its documentation — and found two things worth knowing. In Odoo 17 and 18, the RPC dispatch path re-checks an API key's scope on each call (odoo/service/model.py — dispatch runs security.check; checked against the 17.0 and 18.0 branches), and for API-key credentials that check is pinned to scope='rpc' — so a custom-scoped key cannot serve a remote XML-RPC client directly. Meanwhile, API keys generated through Odoo's settings UI are stored with a NULL scope, and the credential check in res.users.apikeys._check_credentials (odoo/addons/base/models/res_users.py) accepts NULL against any requested scope — which means "we use scoped keys" can be technically true and protectively empty at the same time. Odient's design answer — built and tested, described on the security page — is a short-lived session exchange: a narrow per-user key is traded for a native-scope key bounded by that person's own permissions, which then expires. The point is not our cleverness; it is that this level of detail is where ERP-AI security actually lives, and a vendor should be able to talk at this level about their own stack.

#The one-line test

If you are evaluating any AI for your ERP — ours included — compress this whole piece into a single question for the vendor: "Show me what happens when the AI is told no." A system with real governance produces a refusal, logged, tied to a person, sitting in the same trail as the work that went through. A system without it produces an excuse. The twenty-question version of that test is our free AI Governance Checklist, written to be used against any vendor.

#Frequently asked questions