What belongs in an AI model inventory record?

At minimum, record the system ID, business and technical owners, vendor, model and version, use case, data categories, jurisdictions, risk tier, contract and DPA status, approval date, review date, monitoring owner, and lifecycle decision. Attach evidence rather than relying on unverified vendor claims.

When should an AI model or vendor be re-reviewed?

Re-review at the scheduled review date and whenever a material model, vendor, data, use-case, contract, jurisdiction, performance, incident, or regulatory change occurs. A material change should pause adoption or trigger an explicit re-approval decision before continued use.

Template Reusable Inventory + vendor risk

AI Model Inventory & Vendor Risk Policy Template

Q: Does this template replace legal, security, or privacy review?

No. It is a governance starting artifact. Legal, security, privacy, procurement, or other specialist review may be required before adoption, depending on the use case, data, jurisdiction, contract, and risk tier.

A practical, copy-paste-ready policy and record structure for knowing which AI models your organization uses, who owns them, what evidence supports the vendor relationship, what approval the risk requires, and when to renew, remediate, suspend, replace, or offboard the system.

Create a workspace → Guided intake → See the Engagement Offer → Email Me a Downloadable Copy

Generic reusable template · Replace bracketed fields · Route material decisions for required specialist review

TL;DR — Make the record do the work

Inventory is an ownership system: A row without a named business owner, technical owner, monitoring owner, and next review date is not operational evidence.
Vendor claims require evidence: Store the contract, DPA, security materials, model documentation, testing results, and service-change terms that support each material claim.
Approval must match risk: Low-risk internal assistance may use a lightweight review; consequential, sensitive-data, or high-impact use should require documented legal, security, privacy, compliance, or executive sign-off as applicable.
Material changes trigger re-review: A model version, vendor, data category, jurisdiction, use case, contract, performance, or incident change can require re-approval before continued use.

01 · Purpose and scope

Adopt a living inventory, not a one-time spreadsheet

Use this policy to establish the minimum record and decision path for AI models, model-enabled vendors, embedded AI features, and internally developed systems used by [Organization]. Customize the scope and approval authorities to your operating model and jurisdictions.

Copy-paste policy section

Purpose, scope, and policy owner

Policy owner: [Name / role] Effective date: [YYYY-MM-DD] Review cadence: [Quarterly / semiannual / annual] Approving authority: [Committee / executive / board role] Purpose [Organization] maintains an inventory of AI models and AI-enabled services so that each system has an accountable owner, documented use case, known data and jurisdictional scope, evidence-backed vendor and model information, risk-tiered approval, monitoring, and a recorded renewal or offboarding decision. Scope This policy applies to [employees / contractors / business units] and covers [internal tools, customer-facing features, decision-support systems, generative AI tools, APIs, embedded vendor features, and models trained or fine-tuned by Organization]. It applies whether the system is purchased, embedded, open source, self-hosted, or developed internally. Out of scope: [specific exclusions]. Out-of-scope claims must be documented by [role] and revisited when the use case or data changes. No system may be adopted or materially changed without an inventory record and the approval required by its assigned risk tier. Legal, security, privacy, procurement, compliance, or other specialist review may be required before adoption.

Define “material change” in local practice. At minimum, include a new model or version, a changed vendor or subprocessor, a new data category or jurisdiction, a new population or decision use, a material contract or DPA change, a performance or safety signal, or an incident. If the team is unsure whether a change is material, treat it as material until the accountable reviewer decides otherwise.

02 · Required inventory record

Give every model a durable, reviewable identity

Create one record per system or materially different use case. Link related versions and vendors, but do not collapse distinct purposes into one row just to reduce administration.

Field	Required entry	Evidence or note
System ID	[AI-###]	Stable identifier used in tickets, contracts, and monitoring.
Business owner	[Name / role / business unit]	Accountable for purpose, outcomes, budget, and lifecycle decision.
Technical owner	[Name / role / team]	Accountable for integration, access, configuration, and change control.
Vendor / model / version	[Vendor] · [Model] · [Version or release date]	Attach model card, release notes, contract terms, or internal build record.
Use case	[What the system does and where it is used]	State whether it informs, recommends, generates, ranks, or decides.
Data categories	[Public / internal / confidential / personal / sensitive]	List inputs, outputs, retention, training use, and access restrictions.
Jurisdictions	[Countries / states / regulated markets]	Include where people, data, customers, and decisions are located.
Risk tier	[Low / moderate / high / prohibited]	Record rationale and the approval path completed.
Contract / DPA status	[Executed / pending / not applicable]	Link contract, DPA, subprocessors, security addendum, and renewal date.
Approval date	[YYYY-MM-DD]	Record approvers, conditions, exceptions, and expiry if any.
Review date	[YYYY-MM-DD]	Next scheduled review; bring forward on a material change.
Monitoring owner	[Name / role]	Owns metric cadence, issue log, escalation, and evidence retention.
Lifecycle decision	[Pilot / approved / renew / remediate / suspend / replace / offboard]	Record decision date, rationale, conditions, and decision maker.

Recommended attachments: data-flow diagram, access list, model or feature documentation, testing results, incident history, vendor evidence, contract and DPA, approval record, monitoring snapshots, and the latest renewal or offboarding decision. If an item does not apply, write [N/A — rationale]; do not leave material fields blank.

03 · Ownership and lifecycle

Make accountability explicit at each handoff

The business owner owns why the system exists; the technical owner owns how it operates; reviewers confirm whether the proposed use is acceptable; and the monitoring owner makes sure approval remains true over time.

Role	Before adoption	During use	At review or exit
Business owner	Defines purpose, population, benefit, and success criteria.	Confirms use stays within approved purpose and budget.	Recommends renew, remediate, suspend, replace, or offboard.
Technical owner	Documents architecture, access, data flow, and safeguards.	Controls changes, permissions, integrations, and rollback.	Exports records, removes access, and confirms deletion or migration.
Risk / compliance reviewer	Confirms risk tier, required evidence, and conditions.	Tracks exceptions, incidents, and regulatory or policy triggers.	Confirms residual risk and whether conditions remain satisfied.
Security / privacy / legal	Reviews as required by data, contract, threat, jurisdiction, and use case.	Advises on incidents, material changes, and control gaps.	Confirms obligations for retention, notice, deletion, and transition.
Monitoring owner	Defines metrics, thresholds, cadence, and evidence location.	Publishes snapshots and escalates threshold breaches.	Brings evidence to the renewal or offboarding decision.

For small teams, one person may hold multiple roles, but do not erase the distinct decisions. Record the role performed, the person approving, and any conflict or independence safeguard required by [Organization].

04 · Vendor assessment

Ask for evidence, then record what the evidence actually supports

A vendor questionnaire is not a substitute for diligence. Send the questions below, request source materials, note limitations, and avoid converting a marketing claim into an approved control without corroboration.

Copy-paste questionnaire

Vendor and model assessment

Vendor: [Vendor legal name] Product / model / version: [Name and version] Assessment owner: [Name / role] Assessment date: [YYYY-MM-DD] 1. What model, version, hosting region, subprocessors, and fallback systems support the service? 2. Are customer inputs, outputs, prompts, files, or telemetry used to train or improve a shared model? State the default and the contractual control. 3. What retention, deletion, export, access, and tenant-isolation controls apply? 4. What security assurance, penetration testing, incident response, vulnerability management, and business continuity evidence is available? 5. How are model changes, deprecations, outages, safety events, and material service changes communicated? 6. What testing or documentation addresses accuracy, limitations, bias, privacy, security, explainability, and human oversight for this use case? 7. What restrictions apply to our data, jurisdictions, users, prohibited uses, and downstream decisions? 8. What audit, notice, indemnity, liability, service-level, and termination assistance rights are included? 9. What support exists for data export, deletion confirmation, migration, and end-of-service transition? 10. Which answers are claims, and which are supported by attached evidence? Identify every gap. Assessment conclusion: [Approved / approved with conditions / remediation required / not approved] Open issues and owner: [Issue] — [Owner] — [Due date] Required re-review trigger: [Describe the change that reopens this assessment]

Evidence checklist	Status	Evidence reference / gap
Contract, DPA, subprocessors, and data-use terms	[Attached / pending / gap]	[Link or explain limitation]
Security report, certification, or completed review	[Attached / pending / gap]	[SOC 2 / ISO / questionnaire / other]
Model documentation, release notes, and service-change notice	[Attached / pending / gap]	[Version and date]
Testing, performance, safety, privacy, and bias evidence	[Attached / pending / gap]	[Test scope, population, and limitations]
Retention, deletion, export, and transition evidence	[Attached / pending / gap]	[Terms, procedure, or support ticket]
Incident history and notification commitments	[Attached / pending / gap]	[Timeframes and escalation contact]

05 · Approval thresholds

Scale review to the consequences of the use

Set local thresholds with legal and compliance input. The example below is a governance starting point, not a universal risk taxonomy. A higher tier always overrides a lighter path when facts are uncertain.

Risk tier	Typical characteristics	Minimum approval and conditions
Low	Internal productivity support; no sensitive inputs; no customer or employee decision impact; human checks output.	Business owner + technical owner; inventory record; basic vendor and data-use review; monitoring owner assigned.
Moderate	Confidential or personal data; external-facing content; material workflow influence; meaningful vendor dependency.	Business + technical owner; security/privacy or legal review as applicable; documented testing; contract/DPA status; time-bound approval and periodic monitoring.
High	Consequential recommendations or decisions; sensitive populations; regulated activity; material rights, access, safety, or financial impact.	Formal risk assessment; documented legal, privacy, security, compliance, and executive or committee review as applicable; human oversight; launch conditions; enhanced monitoring and incident plan.
Prohibited / no-go	Use violates law, contract, policy, vendor terms, data restrictions, or approved purpose; evidence is materially missing; safeguards cannot control residual risk.	Do not adopt or continue. Escalate to [role], document the rationale, and identify a safer alternative or remediation plan.

Decision record

Approval outcome for [System ID]

Risk tier: [Low / moderate / high / prohibited] Decision: [Approved / approved with conditions / pilot only / not approved] Approvers: [Names / roles] Conditions before use: [Condition] — [Owner] — [Due date] Residual risk accepted by: [Name / role] Approval date: [YYYY-MM-DD] Approval expiry or next review: [YYYY-MM-DD] Re-review triggers: [List material changes and thresholds]

06 · Monitoring and escalation

Define what changes the decision

Monitoring should answer whether the system still operates within the approved purpose, data boundary, performance range, vendor commitment, and risk tolerance. Keep snapshots and issue records where reviewers can retrieve them.

Signal	Example metric or check	Cadence / owner	Escalation trigger
Usage and scope	Approved users, use cases, data categories, jurisdictions, access exceptions	[Monthly / quarterly] · [Owner]	Use outside approved purpose or population.
Quality and reliability	Accuracy, completion, rejection, latency, outage, fallback, or human override rate	[Weekly / monthly] · [Owner]	Metric crosses [threshold] or trend worsens for [period].
Safety, privacy, and bias	Incidents, complaints, harmful output, privacy events, disparate outcomes, red-team findings	[Continuous / quarterly] · [Owner]	Any material incident or threshold breach.
Vendor and contract	Version change, subprocessor change, DPA status, SLA, security notice, data-use change	[At notice / quarterly] · [Owner]	Material vendor or contract change without re-review.
Inventory integrity	Required fields complete, review date current, evidence links live, exceptions closed	[Monthly / quarterly] · [Owner]	Record is stale, owner missing, or evidence cannot be produced.

Change triggers: new model or version, vendor or subprocessor change, data or retention change, new jurisdiction, new decision population, changed automation level, material contract or DPA change, performance drift, security or privacy event, credible complaint, regulatory change, or an unresolved control exception.

Escalation record

Monitoring exception for [System ID]

Detected: [YYYY-MM-DD / time zone] Signal: [Metric, incident, change, or complaint] Impact / affected population: [Description] Immediate control: [Pause / restrict / human review / rollback / notice] Escalated to: [Names / roles] Decision: [Continue with conditions / remediate / suspend / replace / offboard] Corrective action owner and due date: [Owner] — [YYYY-MM-DD] Re-review completed: [YYYY-MM-DD / approver]

07 · Renewal and offboarding

Make the end-of-life decision as deliberate as the launch

Complete this record before a contract renews, a model version becomes unsupported, a control gap remains open, or the business no longer needs the system. “Renew” is one option, not the default.

Decision	Use when	Required record and action
Renew	Purpose, evidence, controls, performance, and vendor terms remain acceptable.	New approval date, review date, contract status, monitoring evidence, and any conditions.
Remediate	Gap is controllable and the owner can close it within an approved time window.	Gap, risk owner, due date, interim control, and escalation if overdue.
Suspend	Continued use creates unacceptable uncertainty or a threshold, incident, or contract breach.	Disable or restrict access, notify users, preserve evidence, and define restart criteria.
Replace	Another system better meets the purpose, risk tolerance, data boundary, or vendor requirements.	Compare options, approve the replacement, migrate safely, and close the old record.
Data export	Records, prompts, outputs, configurations, or audit evidence must move to another system.	Export scope, format, owner, validation, transfer safeguards, and retention decision.
Deletion / offboard	Service is no longer needed, approved, supportable, or acceptable.	Revoke access, terminate integrations, request deletion, obtain confirmation, retain required evidence, and update inventory.

Lifecycle decision record

Decision for [System ID] on [YYYY-MM-DD]

Current vendor / model / version: [Details] Decision: [Renew / remediate / suspend / replace / data export / delete and offboard] Decision owner: [Name / role] Reason and evidence reviewed: [Summary with links] Contract / DPA action: [Renew / amend / terminate / confirm status] Data export completed: [Yes / no / N/A] — Validation: [Details] Access and integration shutdown: [Owner / date] Deletion request and vendor confirmation: [Reference / date] Records retained under: [Retention rule / location] Replacement or remediation owner: [Name / role / due date] Final approval: [Name / role / date]

08 · Implementation guide

Roll this out in 30, 60, and 90 days

Start with visibility and ownership, then add evidence and tiered review. Keep the first version usable; improve the controls as the inventory reveals where the real risk sits.

Window	Priority	Checklist
Days 0–30	Find and name	Appoint policy owner; publish definitions; collect known AI tools and embedded features; assign system IDs, business owners, technical owners, and monitoring owners; freeze unrecorded high-risk adoption.
Days 31–60	Evidence and tier	Complete required metadata; classify data and jurisdictions; gather contracts, DPAs, security and model evidence; apply risk tiers; route moderate and high-risk records to required reviewers; record gaps and interim controls.
Days 61–90	Operate and decide	Set metrics and thresholds; run the first monitoring review; test a change-trigger workflow; schedule review dates; complete one renewal or offboarding tabletop; report stale records, exceptions, and no-go decisions to [governance forum].

After day 90, make the inventory part of procurement, architecture review, security review, privacy review, change management, incident response, and annual planning. A record that is not connected to those workflows will drift.

FAQ

Questions teams ask before adopting the template

Do we need a separate inventory record for every model version?

Record versions separately when the change could affect behavior, data handling, performance, risk, contract terms, or approval conditions. Otherwise, link the version history to the system record and document why the change was not material.

Can vendor self-attestations satisfy the assessment?

They can be one input, but vendor claims require evidence proportionate to the risk. Attach source documents, test results, contract language, or an explicit limitation and owner for closing the gap. Do not mark a control complete only because a sales or questionnaire response says it exists.

What if we cannot get every vendor document?

Record the missing evidence, the consequence of the uncertainty, the interim safeguard, the responsible owner, and a due date. For a high-risk or no-go use, missing material evidence may mean the system cannot be adopted or continued until the gap is resolved.

Does this replace legal, security, privacy, or procurement review?

No. It organizes the facts and decision record those reviewers need. Legal, security, privacy, procurement, compliance, or executive review may be required before adoption, renewal, or a material change.

How do we get a downloadable copy?

Email hello@governiq.com with the subject “GovernIQ model inventory template download.” We can send a clean copy for adaptation; replace the bracketed fields and run it through your organization’s review process before adoption.