Twenty checks before any AI touches your ERP.
Your ERP holds contracts, prices, payroll and the ledger. Before an AI assistant gets anywhere near it (ours included), these are the questions a careful buyer puts to the vendor, in writing. The full checklist is on this page; the printable PDF and the editable sheet are yours for an email.
Where the data goes
The first five checks decide whether the conversation continues at all.
Is customer data used to train models?
Get the answer in the contract, not the FAQ. The acceptable answer is no.
Exactly which fields leave your instance per request?
Ask for the egress list. A vendor who cannot produce one does not know.
Is sensitive data stripped before it reaches a model?
Redaction at egress: before the model, not after the breach.
Where are prompts and responses stored, and for how long?
Region, retention window, deletion path. All three, in writing.
Can the whole thing run inside your walls if you need it to?
If on-prem matters to you, ask what ships today versus what is planned, and get dates.
Who can do what
An assistant must never become a new superuser role.
Does the AI act under each user's own permissions?
If the assistant sees more than the person asking, every chat is a privilege-escalation path.
What happens when someone asks for a record they cannot open?
The right answer: it refuses, and the refusal is logged like everything else.
Are credentials scoped and short-lived?
No long-lived, all-powerful token sitting on a server. Ask how sessions are minted and when they expire.
Can you scope different assistants to different jobs?
The public-facing bot should not share keys with the one that reads your ledger.
Who can change the permission model itself, and is that logged?
Governance that can be quietly reconfigured is not governance.
What happens on a write
Reading is a privacy question. Writing is a survival question.
Can the AI change records without a human approving?
Confirm the product enforces human approval for writes, with gates you configure per model and per action. Not as a promise; as a setting.
Is there a dry-run? Can you see the exact change before it lands?
The diff on screen before the write, every time.
Are there value caps and rate limits?
A reminder over a threshold waits for a person; a runaway loop hits a ceiling. Both should be settings, not promises.
What is the blast radius of a wrong approval?
Ask the vendor to walk the worst case with you, and how you would find every affected record afterwards.
Can a category of writes be turned off entirely?
"Read-only until we trust it" is a legitimate rollout plan. The product should support it.
The record it leaves
If it is not written down, it did not happen. Or worse, it did.
Does every decision write a record, including refusals?
Allowed, blocked and approved, side by side. Sampling is not an audit trail.
Is each action tied to the person who asked?
Not to a service account. To a person.
Can your auditor read the trail without the vendor's help?
Exportable, filterable, understandable by someone who was not in the demo.
How is the trail protected from tampering?
Ask what "tamper-resistant" means concretely. Accept precise answers only.
When the vendor's own AI makes a mistake, what do they show you?
A vendor with a real audit trail can show you exactly what happened. Ask for that story before you need it.
Take the checklist into your next vendor call.
The pack is the checklist as a printable PDF plus an editable sheet with a scoring column and notes per check, ready for your evaluation file. We send the pack once. No marketing emails unless you opt in later.
Prototype form; when enabled, we store your details in our Odoo CRM to send the pack and respond if you reply. No marketing emails unless you opt in; see our privacy policy.