AI agent governance for ERP — the working playbook
ⓘ About this article & how it was made
The frameworks — NIST AI RMF, ISO 42001, the EU AI Act — all ask for the same three things: know what the system can do, keep a human in charge of what matters, write everything down. For an ERP agent that translates to five concrete moves: a named owner, a written write-policy, a one-page inventory, a test set you refuse to soften, and runtime controls — approval gates, value caps, rate limits, dry-runs, one audit trail — that exist as settings, not sentences.
The common governance baselines in 2026: NIST's AI Risk Management Framework, ISO/IEC 42001:2023, and the EU AI Act's obligations. What none of them will do is tell you, concretely, what to configure before an AI agent touches your ERP on Monday. This playbook is that translation — the frameworks' actual demands, mapped to the controls that matter when the system in question holds your ledger. I run engineering on a product whose whole reason to exist is this problem, so read the last section knowing where I stand; the playbook itself is written to be useful whatever you deploy.
#What the frameworks actually ask for
NIST AI RMF 1.0 is a voluntary framework widely used as the operational starting point. It organizes the work into four functions: Govern (roles, policies, risk appetite, incident paths), Map (know your AI systems, their data and their context), Measure (test and monitor against risk criteria), and Manage (controls, mitigation, response). It is voluntary, free, and practical enough that enterprises use it to structure real risk registers rather than shelf documents (NIST AI RMF).
ISO/IEC 42001:2023 is a certifiable AI management system standard — the ISO-27001 pattern applied to AI: scope, policies, impact assessments, internal and external audit. Implementation guides commonly recommend mapping operational controls (NIST-style) into it, using 42001 for the certificate (ISO/IEC 42001).
The EU AI Act adds legal weight for anyone in its scope; for high-risk systems it includes requirements around human oversight and operation logging on the deployer side (Regulation (EU) 2024/1689 on EUR-Lex) — instructive even where the Act does not bind you. Notice the shape — oversight, logs, accountability. The law is asking for the same three things your own skeptics ask for.
The pattern across all three is not subtle: know what the system can do, keep a human in charge of what matters, and write everything down. The rest is translation.
#The translation: four functions, one ERP agent
Govern, concretely. One named owner for the agent — a person, not a committee — plus the single most important policy decision you will make: the write policy. Which models may the agent touch, which actions run freely, which need a human, which are forbidden. Write it before you evaluate vendors, and evaluate them against it. Wire AI incidents into the same incident path you already have; a wrong posting is an incident whether a person or an agent made it.
Map, concretely. A one-page inventory: what the agent is for, which modules it reaches, which data leaves your instance per request, which model providers sit behind it, who uses it. If your vendor cannot help you fill in that page, that is itself the finding.
Measure, concretely. A test set of real tasks from your own workflows — quotes it should draft, questions it should answer, requests it must refuse — run before go-live and after every significant change. Thresholds that trigger review rather than debate. In our own engineering practice this is where we are strictest: the write-gate ships with a holdout test suite that nobody on the team is allowed to edit — when a holdout fails, we fix the code, never the test. I recommend the same discipline to anyone building evaluation sets: the tests you can quietly adjust are the tests you will quietly adjust.
Manage, concretely. The runtime controls, which deserve their own section — because this is where governance stops being a document.
#The runtime controls that make it real
Least privilege first: the agent acts under each requesting user's own permissions, never a service account with broad reach. Then the write path — every proposed change matched against the policy from Govern: allow, deny, or hold for confirmation, with value caps so amounts above a threshold always wait for a person, rate limits so nothing loops into two hundred wrong invoices, and a dry-run that shows the exact change before it lands. Refusals must be first-class outcomes: a request the user is not cleared for gets stopped and recorded, not silently dropped. And all of it — allowed, blocked, approved — writes one audit record tied to the person who asked, because the EU's logging duty, your auditor's sampling request, and your own Tuesday-morning "what happened here" all read from the same trail.
This is also the honest test of any vendor, ours included: ask to see these controls as settings, not sentences. A write policy you can configure per model and per action. A cap you can set. A dry-run you can demand. An export your auditor can read without the vendor on the call. In Odient this set is the product's spine — the security page enumerates the gates and the write-gate controls — but the point of this playbook is that the list is vendor-neutral. Whoever you deploy, these are the switches that must exist.
#You do not need a certification to be governed
A mid-size company deploying one ERP agent does not need ISO 42001 on day one. It needs the owner, the write policy, the one-page inventory, the test set, and the runtime controls above — most of which is a week of decisions, not a quarter of consulting. Certification is what you add when customers start asking for proof; governance is what keeps Monday safe. Start with governance. The 20-check version of this playbook is free, printable, and written to be used against any vendor in your next evaluation call — including us.
#Frequently asked questions
Which framework should a mid-size ERP team start with?
NIST AI RMF, used as a checklist rather than a certification project: name the owner (Govern), write the one-page inventory (Map), build the test set (Measure), and demand the runtime controls (Manage). Add ISO 42001 later if customers need the certificate.
Does the EU AI Act apply to a company just using an AI agent in its ERP?
Deployer obligations depend on your jurisdiction, sector and the system's classification — that determination needs your counsel, not a blog. The useful part regardless: its demands — human oversight, operation logging, clear accountability — are the same controls this playbook already requires.
What is the single most important control?
The write policy enforced as an approval gate. Everything else limits damage; the gate is what prevents it. If you adopt one thing from this piece, decide today which actions an agent may never take without a person — and verify your product can enforce that decision as configuration.
Prasad leads Odient's engineering — the write-gate, the prompt firewall and the audit trail are his team's work. He reads the Odoo source so customers don't have to.