An AI governance framework is not a policy; it is a set of records that show who decided to use a system, on what evidence, and who is watching it now.
A supervisor who asks about a firm’s use of artificial intelligence is unlikely to ask for the framework as such. In our reading, the request will come as a list of documents: the policy, the inventory, the risk assessments, the testing, the vendor files, the minutes. A firm that can produce those records in a day is likely to be treated as a firm with a working framework. A firm that needs a month is likely to be treated as a firm that has started building one. This guide sets out the ten documents, what each must show, and the order in which to build them.
What an AI governance framework is
A governance framework is the set of controls through which a firm decides whether to use an AI system, how to use it, and how to know when it is going wrong. The documents are the evidence that those controls exist and operate. A policy alone proves that someone wrote a policy. A risk assessment dated before deployment, signed by a named owner, with testing results attached and a monitoring log that follows, proves that the firm made a decision and lived with it.
The most widely used reference point is the NIST AI Risk Management Framework. NIST released version 1.0 of its AI Risk Management Framework on January 26, 2023. NIST states that the framework is intended for voluntary use. NIST describes its purpose as improving the ability to incorporate trustworthiness considerations into “the design, development, use, and evaluation of AI products, services, and systems”. NIST frames the framework as a way to better manage risks to individuals, organizations and society.
The framework is voluntary, and that matters. A regulated firm cannot point to it as a safe harbor, and a supervisor is unlikely to require it by name. What the framework offers is a shared vocabulary. When a firm’s documents are organized in a way that a reader familiar with NIST can follow, the review is likely to go faster and the questions are likely to be narrower.
Why NIST is the reference point
The framework was developed through a process that included a Request for Information, several draft versions for public comment and multiple workshops. NIST says the framework is intended to build on, align with and support AI risk management efforts by others. That design choice is why it travels well across sectors: it does not replace sectoral rules, it sits under them.
NIST has also built out the material around the core document. NIST published a companion Playbook alongside the framework, together with a Roadmap, a Crosswalk and a set of Perspectives. On March 30, 2023, NIST launched the Trustworthy and Responsible AI Resource Center to support implementation of the framework and international alignment with it. The Resource Center’s Use Case page collects examples of how other organizations are building on and using the framework. NIST has also published translations of the framework in Arabic and Japanese.
Two later additions matter for financial firms. On July 26, 2024, NIST released NIST-AI-600-1, the Generative Artificial Intelligence Profile of the framework. NIST says the profile can help organizations identify the unique risks posed by generative AI and proposes actions for managing them. On April 7, 2026, NIST released a concept note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure. That profile is intended to guide critical infrastructure operators toward specific risk management practices to consider when they use AI-enabled capabilities.
The core document is not fixed. NIST states that AI RMF 1.0 is being revised as part of the White House AI Action Plan. A firm that crosswalks its documents to the framework should therefore record which version it mapped to, and plan to repeat the mapping when the revision is published.
The ten documents
The table below lists the ten documents, what each one must show, and who should own it. The owner column is our view of where accountability usually sits; a firm’s own structure may put it elsewhere, and that is fine as long as the name is written down.
| # | Document | What it must show | Usual owner |
|---|---|---|---|
| 1 | AI policy | Scope, prohibited uses, approval thresholds, board sign-off | Board and compliance |
| 2 | AI inventory | Every system and use case, its purpose, data, vendor and risk tier | Compliance or technology risk |
| 3 | Accountability map | Named owners for each system, committee charter, escalation path | Chief compliance officer |
| 4 | Risk assessment methodology | How the firm tiers risk, what triggers deeper review, who signs | Risk function |
| 5 | Use-case risk assessments | One per system, dated before deployment, signed by the owner | System owner |
| 6 | Data governance record | Provenance, permissions, retention and quality checks for training and input data | Data owner |
| 7 | Testing and validation evidence | Pre-deployment tests, performance thresholds, bias and robustness results, re-test schedule | Model risk or technology |
| 8 | Vendor and model due diligence file | Contract terms, model cards, security review, exit plan | Procurement and compliance |
| 9 | Monitoring, incident and change log | Live performance, drift, incidents, overrides, every material change | System owner and operations |
| 10 | Board and committee reporting | Minutes, management information, decisions taken, follow-up actions closed | Company secretary and compliance |
Documents one to three: the frame
The policy sets the boundary. It should say what the firm will not do with AI, what it will do only with committee approval, and what staff may do without asking. It should be short enough that the board has read it. The inventory is the document most firms cannot produce on request, because nobody owns it and tools arrive through browser extensions and vendor upgrades. Build it first and keep it as a living register. The accountability map turns the inventory into names. Every system has an owner, every owner has a backup, and the path from a frontline concern to the committee is written down.
Documents four to six: the decision
The methodology is one document and the assessments are many. The methodology says how the firm decides what is high risk: customer-facing decisions, use of personal data, irreversibility, regulatory reporting. Each assessment applies the methodology to one use case and records the answer. The data record sits beside the assessment. It answers where the data came from, whether the firm had the right to use it, and how it is checked.
Documents seven to nine: the evidence
Testing evidence is the difference between believing a system works and having checked. It should name the thresholds the system had to meet and show the results against them. The vendor file matters because most firms buy AI rather than build it, and a supervisor is likely to ask what the firm knew about the model when it signed. The monitoring log is the document that shows the framework is operating rather than archived. Gaps in the log are, in our reading, the most common finding in any review of a control.
Document ten: the record of oversight
Minutes and management information close the loop. They show that the board or committee saw the inventory, the high-risk assessments and the incidents, asked questions, and that someone answered them. A framework with nine strong documents and no minutes is likely to read as a technology project rather than a governed one.
A governance framework is the set of documents that show who decided, on what evidence, and who is watching now.
How a supervisor is likely to read them
We expect a reviewer to follow the chain rather than read the documents in isolation. A question about a customer-facing chatbot is likely to run: is it in the inventory, who owns it, what tier is it, where is the assessment, what did testing show, what does the contract say, what has monitoring recorded, and when did the committee last see it. Each link in that chain is one of the ten documents. If a link is missing, the reviewer is likely to assume the control did not operate, whatever the policy says.
Dates matter as much as content. An assessment dated after deployment suggests the firm deployed first and documented later. A framework assembled in a fortnight is likely to read, to an examiner, as one the firm built in response to the request rather than one it has been running. The defense against that reading is a monitoring log and a set of minutes that go back further than the request.
Building the framework: implementation steps
The order below is our suggested sequence. It front-loads the documents that other documents depend on.
- Appoint a single owner for the inventory and give them authority to ask every function what tools are in use.
- Build the inventory before the policy, so the policy addresses the systems the firm actually has.
- Draft the policy and the risk methodology together, so the tiers in the policy match the tests in the methodology.
- Take the policy to the board with the inventory attached, and minute the discussion.
- Complete a risk assessment for each high-tier system already in use, and record the date and the owner honestly.
- Pull the vendor contracts for every bought system and record what they say about model changes, data use and exit.
- Set testing thresholds for each high-tier system and run the tests, keeping the results.
- Start the monitoring log on the day the assessment is signed, and define what counts as an incident.
- Map every document to the NIST framework and record the version mapped to.
- Put AI on the committee agenda at a fixed cadence and keep the minutes.
The sequence can be run inside a quarter for a firm with a small number of systems. Larger inventories take longer, and the honest approach is to tier the backlog and document the plan for working through it. A written plan with dates is itself evidence of governance.
Questions people ask
Do we need a separate AI committee? Not necessarily. Many firms route AI decisions through an existing risk or operational committee. What matters is that the charter names AI as in scope and that the minutes show it was discussed.
What counts as AI for the inventory? In our view, draw the line wide. Include any system that makes or recommends a decision, generates content, or classifies people or transactions, whether built, bought or embedded in another product. It is easier to tier a system down than to explain why it was left out.
How often should assessments be refreshed? The methodology should set the cadence by tier and should also list the triggers that force an early refresh: a model change by the vendor, a change in the population the system is used on, an incident, or a change in the applicable rules.
Does the NIST framework replace sector rules? No. NIST says the framework is intended to build on and support AI risk management efforts by others, and it is voluntary. Sector obligations on recordkeeping, suitability, fair treatment and model risk continue to apply to any process the firm automates, and where a question of legal interpretation arises the firm should take legal advice.
Which NIST documents should we read first? The core framework, then the Playbook, then the Generative AI Profile if the firm uses large language models. The Crosswalk is useful for mapping existing controls, and the Resource Center’s use cases show how other organizations have approached the work.
Will the revision of the framework change the ten documents? We do not expect the list to change, because the ten documents answer questions any reviewer asks about any control: who decided, on what basis, and who is watching. What may change is the vocabulary used to map them, which is why the firm should record the version it mapped to.
Where Taft helps
Taft helps firms build the ten documents in this guide, from the inventory and policy through to testing evidence, monitoring logs and board reporting, through its AI and Automation Studio. The work produces records a firm can hand over on request, mapped to the NIST framework and to the firm’s own sector obligations. Where a question needs a legal opinion, Taft will say so and work alongside the firm’s counsel; the AI and Automation Studio is a compliance service, not a law practice.
Questions
Is the NIST AI Risk Management Framework mandatory for financial firms?
No. NIST states that the framework is intended for voluntary use. It is a reference that many firms use to structure their own governance, not a rule that binds them.
Does a firm need all ten documents before it deploys its first AI tool?
In our reading, a firm needs the policy, the inventory, the accountability map and a risk assessment for that first use case before deployment. The remaining records are built as the use case moves through testing, vendor review and monitoring.
What has NIST published beyond the core framework?
NIST released version 1.0 on January 26, 2023, with a companion Playbook, Roadmap, Crosswalk and Perspectives. It launched the Trustworthy and Responsible AI Resource Center on March 30, 2023, released the Generative AI Profile (NIST-AI-600-1) on July 26, 2024, and released a concept note for a Critical Infrastructure profile on April 7, 2026.
Is the framework changing?
Yes. NIST states that AI RMF 1.0 is being revised as part of the White House AI Action Plan, so firms should keep their crosswalk to the framework under review rather than treating it as fixed.
Sources
Taft does not provide legal advice. Content is for informational purposes only and subject to regulatory guidance.