NIST AI RMF Implementation: The Minimum Artifact Set for a Team That Cannot Build 200 Controls

TL;DR

• The NIST AI RMF has 72 subcategories. The Treasury’s FS AI RMF has 230 control objectives. A two-person risk team cannot build all of them before the next bank partner review.
• The goal is not full coverage on day one. It is a defensible minimum — one artifact per major area — that traces each AI deployment decision to its evidence.
• Twelve artifacts, organized across GOVERN, MAP, MEASURE, and MANAGE, are enough to answer an examiner’s opening questions and demonstrate a functioning program.

The most common question after a bank partner sends an AI governance questionnaire is: “what are we actually supposed to have built?”

Not in theory — not what the framework says — but what do you actually need to produce, in a team of two or three, before the next review cycle. The NIST AI RMF points to 72 subcategories and over 100 suggested actions. The Treasury’s Financial Services AI RMF adds 230 control objectives. No small team is implementing all of that in year one.

What they can do is identify the minimum artifact set — the specific documents, registers, and records that demonstrate a functioning program — and build those first. This post names them.

Why artifacts, not controls

A lot of AI governance effort goes into writing policies. Policy documents matter, but policy alone is not evidence. What an examiner or bank partner is actually trying to establish is whether your organization can trace an AI deployment decision to a specific approval, by a specific authority, based on specific evidence, with defined ongoing monitoring. That trace lives in artifacts, not policy text.

The NIST AI RMF Core organizes work across four functions: GOVERN, MAP, MEASURE, and MANAGE. Each function demands different artifacts. The common mistake is treating GOVERN as the starting point — writing an AI governance policy before you know what AI your organization is actually running. In practice, the MAP function should come first, because governance written without a current inventory governs imaginary systems.

Here is the minimum set that holds up to a review, organized in implementation order.

Start with MAP: know what you’re governing

Artifact 1: AI Use Case Inventory

This is the foundational document. Before writing policy, run an internal discovery exercise — survey engineering, product, operations, and support to surface every AI or ML tool in use, in development, or in pilot. The inventory should capture, for each use case:

• Name and brief description
• Risk tier (High / Medium / Low), using defined criteria
• In-house or third-party vendor
• Data categories processed (PII, financial data, protected characteristics)
• Regulatory applicability (CFPB Reg B, ECOA, BSA/AML, state AI laws)
• Owner
• Deployment status and date
• Pre-deployment checklist reference (for deployed use cases)

A first draft in a spreadsheet is fine. What matters is that you have a complete picture before you start writing governance documents that reference it.

Risk tier criteria that actually work: four factors — consumer impact (does the output directly affect credit, fraud decisions, or customer communications?), decisioning role (is the model the primary decision or a human-reviewed input?), PII involvement, and regulatory touchpoint. High means two or more factors present. Low means none.

Artifact 2: Third-Party AI Vendor Register

Most fintechs are not building their own AI models. They are using third-party tools — fraud scoring from a vendor, chatbot platforms, document processing, credit underwriting support. Each of these is an AI use case that requires governance, and the relevant artifact is a separate register tracking:

• Vendor name and service
• AI-specific function performed
• Data shared with the vendor
• Due diligence performed (questionnaire sent and received, date)
• Contract provisions covering AI transparency and model explainability
• Monitoring frequency

The 2023 interagency third-party risk guidance from OCC, FDIC, and the Federal Reserve treats AI vendor relationships as a category of third-party relationship subject to the full lifecycle: due diligence, contracting, ongoing monitoring, and termination. The FS AI RMF adds a dedicated domain for third-party AI risk. Your vendor register is the intake record for that work.

GOVERN: write policy against what you found

With the inventory complete, governance policy becomes specific rather than abstract.

Artifact 3: AI Acceptable Use Policy

One to two pages. It should answer four questions:

1. What AI uses are permitted without a formal risk review? (Low-risk, no consumer impact)
2. What AI uses require a pre-deployment risk assessment? (High and Medium tier)
3. What AI uses are prohibited? (Real-time biometric profiling, automated adverse decisions without human review where prohibited, use cases that violate fair lending obligations)
4. What must any AI-powered vendor disclose before onboarding?

Keep it short enough to be enforceable. A 20-page AI policy that nobody reads is not a control. A two-page policy with defined triggers that compliance can actually enforce is.

Artifact 4: AI Risk Appetite Statement

The risk appetite statement connects AI governance to your broader enterprise risk framework. It does not need to be a long document — one page of defined thresholds works:

• What level of bias risk is acceptable, and how is it measured?
• What consumer harm outcomes trigger mandatory review or suspension of an AI use case?
• What is the maximum time a conditional AI approval can remain open before it expires or returns for review?

The NIST AI RMF GOVERN function (GOVERN 1.4 and 1.7) requires that risk tolerances are explicit and connected to organizational decision-making. Without this document, “risk-based” decisions are opinion, not policy.

Artifact 5: AI Governance Charter

This can be a section of an existing risk committee charter or a standalone document. It should name:

• Who holds AI approval authority for each tier (High-risk: risk committee; Medium: compliance + risk; Low: business owner sign-off)
• Quorum for AI risk decisions
• Escalation path when a pre-deployment assessment flags a High-tier issue
• Review cycle for the use case inventory

Without a charter, AI governance exists informally. Informal governance creates a discovery problem: when an examiner asks who approved a model, the answer is often “we discussed it” rather than “here is the signed record.”

MEASURE: evidence before go-live

The MEASURE function is where most small programs fall short. MAP built the inventory; GOVERN wrote the policy. MEASURE produces the evidence that specific AI deployments were actually evaluated before they went live.

Artifact 6: Pre-Deployment Risk Assessment Checklist

For each High-tier and Medium-tier AI use case, a completed checklist documenting:

The checklist is not a substitute for independent model validation at scale. For a fintech with a handful of use cases, it is the practical mechanism for ensuring that someone asked the right questions before the model went live.

Artifact 7: Evaluation Results Record

For High-tier use cases, preserve the evaluation that supported deployment: the eval inputs, the model outputs, and the interpretation of those outputs. This does not need to be a formal model card (though model cards are useful). It needs to be a retrievable record that shows what testing was done, what the results were, and that the results were reviewed by someone with authority to approve deployment.

If your vendor runs a pre-trained model, the equivalent artifact is the vendor’s bias and fairness documentation — their model card, testing results, or written attestation — plus your review of it.

The FS AI RMF dedicates a full domain to model development and monitoring, including requirements for test results to be documented and retained. The evidence should live somewhere findable when the bank partner asks.

MANAGE: what happens after deployment

Most AI governance programs have decent pre-deployment documentation and no post-deployment process. The MANAGE function is about what you do after a model is live: monitoring, incident response, and orderly retirement.

Artifact 8: AI Incident Response Procedure

A short addendum to your existing incident response plan covering AI-specific scenarios:

• Model output produces a discriminatory decision at scale (what triggers a halt, who decides)
• Model produces demonstrably incorrect outputs that affected customers (notification, remediation)
• AI vendor discloses a data breach or model failure (your obligations, escalation path)
• Regulatory inquiry specifically about an AI deployment (who responds, what documents to pull)

AI incidents are often slower-moving than cybersecurity incidents — they show up in complaints, audit samples, and exam findings rather than as acute outages. Your incident response procedure should account for that.

Artifact 9: Ongoing Monitoring Plan

For each High-tier use case, define:

• What metrics are being monitored (accuracy, fairness ratios, false positive/negative rates, complaint volumes)
• How often they are reviewed (monthly minimum for customer-impacting models)
• Who reviews them and what they do with the results
• What threshold triggers escalation back to the governance committee

For vendor AI, monitoring means tracking performance at the application layer — complaint volumes, output sampling, deviation from baseline — since you often cannot access the underlying model directly.

Artifact 10: Decommission Protocol

Define what “retired” means for an AI use case:

• How is the model removed from production?
• How long are the deployment records retained?
• Are there customer notifications required when an AI-assisted decision process changes?
• How is the use case removed from the inventory?

This sounds procedural because it is. But the absence of a decommission protocol creates a governance gap: a model that has been “stopped” may still affect production systems, and the inventory may retain stale records that confuse the next examiner review.

The supporting artifacts: don’t skip these

Two more artifacts round out the minimum set and are frequently the first things a bank partner asks for.

Artifact 11: AI Governance Decision Log

For each High-tier deployment, a single record connecting the use case to its approval authority, the evidence reviewed, any conditions attached to the approval, and the expiry date. We covered the AI governance decision log in detail in a prior post — it is the artifact that turns a committee discussion into an enforceable record.

Artifact 12: AI Vendor Questionnaire (Completed, Per Vendor)

For each AI vendor on the third-party register, a completed due diligence questionnaire covering: training data sourcing and bias controls, explainability capabilities, drift monitoring, incident notification obligations, regulatory certifications, and data handling under applicable law. This questionnaire is the TPRM evidence for AI vendor relationships — and it is increasingly the artifact that separates a fintech that has a TPRM program from one that relies on the vendor’s marketing materials.

What to build in sequence

The temptation is to start with GOVERN — write the policy, then figure out what it covers. The more effective sequence:

1. Week 1: Run the AI discovery exercise. Complete the use case inventory and vendor register. You cannot write meaningful governance without knowing what you are governing.
2. Week 2: Write the Acceptable Use Policy and Risk Appetite Statement directly against what inventory found. High-tier use cases become specific policy obligations, not hypotheticals.
3. Week 3: Complete pre-deployment checklists for any High-tier use case that lacks one. For deployed models, run the evaluation review retroactively — document what was known at deployment and what monitoring is now in place.
4. Week 4: Draft the AI Incident Response Procedure, Ongoing Monitoring Plan, and Governance Charter. Stand up the governance decision log.

By week four, you have a functioning program — not a complete one, but one that can answer the bank partner questionnaire, respond to an initial examiner inquiry, and demonstrate that AI deployments are tracked, reviewed, and monitored.

The FS AI RMF adoption stage question

Before building the full 230-control matrix, use the FS AI RMF Adoption Stage Questionnaire. It classifies your institution’s AI adoption stage and filters the control objectives to what actually applies. A fintech primarily using vendor-supplied AI tools at early adoption stage faces a materially different control set than a bank running bespoke credit models in production at scale.

This filters before you build, not after. Time spent building controls that don’t apply to your stage is time not spent operationalizing the ones that do.

So what?

The minimum artifact set is not about compliance theater. It is about having a defensible answer when someone asks: “show me how that AI deployment was approved.” If you have the inventory, the pre-deployment checklist, the evaluation record, the signed approval, and the monitoring plan — you have the answer. If you have only a policy document and a verbal recollection that the committee approved it at some point, you do not.

Build the inventory first. Everything else follows from knowing what you’re governing.

If you need pre-built templates for the use case inventory, pre-deployment checklist, and vendor questionnaire, the AI Risk Assessment Template & Guide includes all of them — mapped to the 2026 regulatory landscape — along with eight worked examples for calibration.

Related reading

• AI Governance Decision Log: The Missing Artifact Between Committee Meetings and Production Approval
• NIST AI RMF MEASURE Function: TEVV, Bias Testing, and Metrics That Actually Matter
• Model Risk Management Effective Challenge: What Reviewers Must Document When They Disagree