AI Model Card Template for ERP Use Cases
A model card is a short record of what an AI system is for, what data it uses, how it was tested and where it fails. For ERP-connected agents it also tells auditors and IT managers what the system can see and do. Fill in the fields and export one card per model.
Fill in
AI Model Card Template for ERP Use Cases
Model Card: Purchasing Assistant v1
Version date: 2026-10-20 Business owner: Procurement Manager Technical owner: ERP Platform Lead Base model: Open-weight 70B instruct model, quantized, served on-prem Risk tier: Low: read-only, internal
Intended purpose
Answer buyer questions about open purchase orders, supplier delivery performance and item cost history using read-only ERP queries.
Out of scope uses
Creating or changing purchase orders, negotiating prices, answering HR or payroll questions, legal advice.
Data sources
Purchase order, receipt and vendor tables via a read-only reporting view; supplier scorecard export refreshed nightly.
Evaluation
120 question test set written by buyers, answers checked against ERP reports. Pass mark agreed with the business owner before go-live.
Known limitations
May misread ambiguous vendor names. Does not see documents outside the ERP. Answers reflect data as of last nightly refresh.
Operating controls
| Control | In place | Notes |
|---|---|---|
| Access follows ERP roles | ||
| Queries or sources shown to user | ||
| Interaction logging and retention | ||
| Human approval for write-back | ||
| Re-evaluation after model or data change |
Change history
| Date | Change | Approved by |
|---|---|---|
| 2026-10-20 | Initial release | |
Approvals
Keep one card per model or agent and update it whenever the base model, data sources or permissions change. Store cards where internal audit can find them.
Get a model card reviewed
Optional: an expert comments on your card, focusing on ERP permissions and evaluation.
Optional. The tool and every export work without this. No spam.
How to use this template
Complete the card before go-live, not after. The business owner writes the purpose and out-of-scope sections, because they know which questions users really ask. The technical owner fills in the model, data sources and controls. Agree the evaluation method and pass mark together. Export a copy to your AI register and attach it to the change ticket that releases the system.
Why cards help in an ERP context
ERP assistants are easy to expand quietly. A read-only reporting helper gains a write tool, or a new data source is added, and nobody updates the documentation. A card forces a conscious change record and gives audit a stable reference.
- States the purpose so scope creep is visible
- Lists the data sources, which drive access and retention reviews
- Records the evaluation, so changes can be re-tested the same way
- Names owners, so incidents have a first call
- Separates read-only from write-capable systems by risk tier
Choosing the risk tier
A simple three-tier scheme is enough to start. Low risk means read-only answers used inside the company. Medium means read-only but the answers may reach customers, suppliers or regulators. High means the system can create, change or trigger something, such as releasing a work order or posting a journal. Higher tiers should require stronger evaluation, human approval steps and more frequent review. Frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001 take a similar approach to documenting and managing AI systems.
Common mistakes
Cards fail when they are written once and filed away. Put a review trigger in your change process: new base model, new data source, new permission, or a pattern of wrong answers. Avoid vague limitations such as may be inaccurate. Name the actual weak spots, like ambiguous vendor names or stale nightly data.
Frequently Asked Questions
Do we need a model card for every chatbot?
Yes for anything that touches company data or influences decisions. Even a simple read-only helper benefits from a short card. Tools that only use public information and no company data can usually be covered by your general policy instead.
Who should own the card?
Two owners work best: a business owner who is accountable for how the system is used, and a technical owner who maintains it. Use roles rather than names so the card survives staff changes.
How often should we review a card?
At least yearly, and immediately when the base model, data sources, permissions or prompts change materially. Tie the review to your change management process so it happens without a reminder.
Does a model card replace a risk assessment?
No. The card documents the system. A risk assessment evaluates what could go wrong and what controls are needed. The card links naturally to your risk register and gives the risk review its facts.
If you are documenting agents on top of NetSuite, SyteLine, M3, LN or another ERP and want a second pair of eyes on scope and controls, Netray can review a draft card with you.
Related Tools
AI Risk Register Worksheet for ERP Projects
An editable risk register with likelihood x impact scores, owners and mitigations, pre-filled with typical ERP AI risks.
Compliance & ContractsAI Acceptable Use Policy Template for ERP Users
A fill-in acceptable use policy that tells ERP users what they may and may not paste into AI tools, and who approves exceptions.
AI Agents & AutomationAI Agent Runbook Template
A runbook for the person on call when an ERP-connected AI agent misbehaves: how to check it, pause it and roll back.
AI Agents & AutomationERP AI Data Source Inventory Worksheet
An editable inventory of ERP tables, file shares and document stores with classification and an AI-allowed decision per source.
More AI Agents & Automation tools
See all- Business Process Automation ROI Calculator
- AI Agent Use Case Prioritizer
- Document Processing Automation Savings Calculator
- AP Invoice Automation ROI Calculator
- Order Entry Automation Savings Calculator
- Quote-to-Cash Cycle Time Calculator
- Manufacturing AI Readiness Assessment
- RPA vs AI Agent Selector
- ERP AI Maturity Assessment