# AI Model Card Template for ERP Use Cases

> Source: https://netray.co/tools/ai-model-card-template-for-erp-use-cases
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

A one-page model card for each AI model or agent in your ERP landscape, covering intended use, data, limits, evaluation and ownership.

## Category

ai-automation

## Audience

- CIO
- IT manager
- AI lead
- Internal audit

## Tool

**Kind:** template

**Output:** document

**Fields:**

#### Model or agent name

**Key:** model_name

**Type:** text

**Default:** Purchasing Assistant v1

#### Business owner (role)

**Key:** owner

**Type:** text

**Default:** Procurement Manager

#### Technical owner (role)

**Key:** tech_owner

**Type:** text

**Default:** ERP Platform Lead

#### Version date

**Key:** version_date

**Type:** date

**Default:** 2026-10-20

#### Base model and version

**Key:** base_model

**Type:** text

**Default:** Open-weight 70B instruct model, quantized, served on-prem

#### Intended purpose

**Key:** purpose

**Type:** textarea

**Default:** Answer buyer questions about open purchase orders, supplier delivery performance and item cost history using read-only ERP queries.

#### Out of scope uses

**Key:** out_of_scope

**Type:** textarea

**Default:** Creating or changing purchase orders, negotiating prices, answering HR or payroll questions, legal advice.

#### Data sources

**Key:** data_sources

**Type:** textarea

**Default:** Purchase order, receipt and vendor tables via a read-only reporting view; supplier scorecard export refreshed nightly.

#### Evaluation method

**Key:** eval

**Type:** textarea

**Default:** 120 question test set written by buyers, answers checked against ERP reports. Pass mark agreed with the business owner before go-live.

#### Known limitations

**Key:** limits

**Type:** textarea

**Default:** May misread ambiguous vendor names. Does not see documents outside the ERP. Answers reflect data as of last nightly refresh.

#### Risk tier

**Key:** risk_tier

**Type:** select

**Options:**

- Low: read-only, internal
- Medium: read-only, external impact
- High: can write or trigger actions

**Default:** Low: read-only, internal

**Blocks:**

#### Model Card: {{model_name}}

**Body:** Version date: {{version_date}}
Business owner: {{owner}}
Technical owner: {{tech_owner}}
Base model: {{base_model}}
Risk tier: {{risk_tier}}

#### Intended purpose

**Body:** {{purpose}}

#### Out of scope uses

**Body:** {{out_of_scope}}

#### Data sources

**Body:** {{data_sources}}

#### Evaluation

**Body:** {{eval}}

#### Known limitations

**Body:** {{limits}}

#### Operating controls

**Table:**

**Columns:**

- Control
- In place
- Notes

**Rows:**

**0:** Access follows ERP roles

**0:** Queries or sources shown to user

**0:** Interaction logging and retention

**0:** Human approval for write-back

**0:** Re-evaluation after model or data change

#### Change history

**Table:**

**Columns:**

- Date
- Change
- Approved by

**Rows:**

**0:** {{version_date}}

**1:** Initial release

#### Approvals

**Signatures:**

- Business owner
- Technical owner
- Information security

**Notes:** 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.

## Content

**Intro:** 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.

**Sections:**

#### How to use this template

**Body:** 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

**Body:** 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.

**Bullets:**

- 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

**Body:** 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

**Body:** 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.

**Cta:** 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.

**Faq:**

#### Do we need a model card for every chatbot?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

ai model card template, model documentation template, llm model card example, ai system inventory template, ai use case documentation, model risk documentation erp, ai register entry template

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json