At a glance
- A generic AI readiness checklist covers data, use cases and skills; a regulated financial operation also needs model-risk ownership, audit evidence, data lineage, human decision authority, vendor-access review and change control.
- The checklist below turns those six dimensions into a question to ask, what “ready” looks like, and the evidence to collect, for one workflow at a time.
- Model risk needs a single named accountable owner before launch, not an assignment made after an incident.
- How long an assessment takes depends on how many workflows are in scope and how much evidence already exists, not a fixed number of weeks.
- A readiness score is a prioritization tool: it says which workflow to fix first, not whether the finished system will succeed.
Why generic readiness checklists fall short in financial services
A generic readiness checklist asks: is the data clean, is the use case well-defined, does the team have the skills to build or buy. Those questions matter, and none of them are wrong. In a bank, lender, or insurer, we recommend adding two questions before any of those. Who owns this once it's live, and what could we show a reviewer if asked?
AI systems also carry risks a generic software checklist wasn't built to catch. NIST's AI Risk Management Framework names “underdeveloped software testing standards and inability to document AI-based practices to the standard expected of traditionally engineered software for all but the simplest of cases” [1]. This is a risk distinct from ordinary software. A readiness check that only covers data and use-case fit misses that gap entirely.
- Who owns the model or workflow after launch, and what happens if that person changes roles.
- Whether an auditor could reconstruct why the system produced a given output, months later.
- What a vendor's model or staff can see or change inside your own systems.
- Who has to sign off before the system acts, and at which exact step in the workflow.
The readiness checklist for regulated operations
NIST's AI Risk Management Framework describes the discipline this checklist operationalizes. Its Govern function “outlines processes, documents, and organizational schemes that anticipate, identify, and manage the risks a system can pose, including to users and others across society – and procedures to achieve those outcomes” [1]. The six dimensions below turn that into questions you can ask about one workflow at a time.
| Dimension | Question to ask | What “ready” looks like | Evidence to collect |
|---|---|---|---|
| Model-risk ownership | Who signs off before this model or workflow goes live, and who owns it after? | A named owner and accountable executive, documented before launch, not assigned after an incident. | An ownership record naming the accountable owner, a sign-off tied to the launch decision, and what happens if that owner changes roles. |
| Audit evidence | Could an auditor reconstruct why the system produced any one output, six months later? | The input, model version, and reviewer decision behind a sampled output can be pulled up on demand, without asking the vendor. | A retained record per decision: input snapshot, model or version identifier, reviewer name and decision, and the date. |
| Data lineage | Where did the data feeding this model come from, and has it changed since testing? | Every input field traces to a named source system, and a change to that source triggers a review, not a surprise. | A data-source map for each input field, plus a log of when the model was last tested against current data. |
| Human decision authority | At which step does a named person decide, rather than just review after the fact? | The decision step is named, the person who holds it is named, and the system cannot act past that point without them. | A written decision point in the workflow diagram naming the role and what authority it holds. |
| Vendor-access review | What can the vendor, or its model, see, touch, or change in our systems, and who approved that? | Access is scoped to what the workflow needs, reviewed on a schedule, and revocable without the vendor's cooperation. | An access-grant list by vendor and system, the approver of each grant, and the date of the last access review. |
| Change control | What happens when the model, prompt, or underlying data changes? | A change to the model, its configuration, or its data pipeline goes through the same approval path as any other production change. | A change log linking each production change to an approval, a tester, and a rollback plan. |
Score one workflow at a time, not the whole organization at once. A system that's ready in one business line may not be ready in another with a different owner, vendor, or data source.
Ownership and human decision authority
Model risk needs one named owner, not a committee everyone assumes is handling it. NIST's Govern function lists as an outcome that “Accountability structures are in place so that the appropriate teams and individuals are empowered, responsible, and trained for mapping, measuring, and managing AI risks” [1]. It also lists as an outcome that “Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment” [1].
NIST describes the RMF itself as voluntary — “The Framework is intended to be voluntary” [1] — so what follows is recommended practice, not a NIST requirement. NIST's framework assigns governance and oversight tasks to AI actors with “management, fiduciary, and legal authority and responsibility for the organization” [1], naming “organizational management, senior leadership, and the Board of Directors” [1] as typically accountable. We recommend separating the reviewer of individual outputs from the owner of the decision to run the workflow.
- The accountable owner: signs off that the workflow may run, owns its risk profile, and answers for the workflow if it's questioned.
- The decision authority: the named role that approves, or can override, an individual output before it takes effect — see the checklist's human-decision-authority row above.
Evidence and lineage
An assessment isn't complete until you know what you could show, not just what you believe. NIST's framework asks for documentation at more than one stage: its Measure function lists as an outcome that “Test sets, metrics, and details about the tools used during TEVV are documented” [1]. Its Manage function also lists as an outcome post-deployment plans that include “mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management” [1].
Data lineage is part of that same evidence base. The framework ties it directly to accountability: “Maintaining the provenance of training data and supporting attribution of the AI system's decisions to subsets of training data can assist with both transparency and accountability” [1]. In practice, that means every input field the workflow relies on traces to a named source system. A change to that source triggers a review rather than a surprise months later.
- A decision log: input, model or ruleset version, reviewer, and outcome, retained long enough to answer a question asked months later.
- A data-source map naming where each input field comes from and when it was last checked against the model's test conditions.
- A change log linking every production change — model, prompt, configuration, or pipeline — to an approval and a rollback plan.
- A vendor-access record: what each third party's system or staff can see or touch, and who approved it.
Scoring the result and choosing a first workflow
How long an assessment takes isn't a fixed number of weeks. It depends on how many AI workflows are in scope and how distributed model ownership already is across business lines. It also depends on whether the evidence above already exists somewhere or has to be built from scratch, and how many third parties touch the workflow.
NIST's own framework leaves implementation flexible: it “does not prescribe profile templates, allowing for flexibility in implementation” [1]. We recommend treating that flexibility as permission to scale the depth of review to the system's own context, not to a template someone else set. The companion guidance NIST publishes alongside the framework describes the Playbook itself as “neither a checklist nor set of steps to be followed in its entirety” [2].
- Score each dimension separately
Rate model-risk ownership, audit evidence, data lineage, human decision authority, vendor-access review and change control one at a time — ready, partial, or not ready — rather than a single composite score.
- Treat any “not ready” row as a blocker, not a deduction
A workflow with most dimensions ready and one missing owner is not ready to launch until that gap is closed; the missing dimension doesn't average out against the ones that are fine.
- Use the score to prioritize, not to promise
A score tells you which workflow to fix first. It says nothing about whether the finished system will work well, and it isn't a stand-in for testing the system itself.
- Re-score after any material change
A new vendor, a new data source, or a model update resets the dimensions that change; it doesn't require redoing the whole assessment.
Choosing the first workflow follows the same logic NIST uses to frame an initial go/no-go decision. Its Map function is meant to leave an organization with “sufficient contextual knowledge about AI system impacts to inform an initial go/no-go decision about whether to proceed to design, develop, or deploy an AI system” [1].
In practice, that favors a workflow that already has a named owner and makes a narrow and reversible decision rather than a final credit, claims, or account action. It also has a clean evidence trail to build on — not necessarily the workflow with the largest potential payoff.
When a lighter check is enough
Not every AI use in a bank, lender, or insurer needs this full checklist. Internal, non-customer-facing tools with no credit, claims, or account impact can usually be assessed with a general AI readiness check instead. A drafting aid for internal memos is one example.
- The workflow never touches a customer decision, a regulated filing, or funds movement.
- An existing IT change-control process already owns approvals for the tool.
- No third-party vendor has access to production data or systems through it.
Our general AI readiness assessment covers the broader data, process, and sponsorship questions that apply whether or not the workflow is regulated.
Frequently asked questions
What does an AI readiness assessment cover for a bank?
For a bank, an AI readiness assessment covers six dimensions: who owns model risk, what evidence an auditor could review, where the data comes from, and who holds final decision authority. It also covers how vendor access is scoped and how changes to the model or its data are controlled and approved.
How is AI readiness different in a regulated industry?
A generic readiness check asks about data quality, use-case fit, and team skills. A regulated financial operation adds questions a general checklist skips: who is accountable for the model, what an auditor could reconstruct later, and how vendor access is controlled. It also asks who has final decision authority before the system acts.
Who should own model risk for an AI workflow?
Name a single accountable owner for model risk, separate from whoever reviews outputs day to day. We recommend a manager or executive over the business line the workflow serves. NIST's AI Risk Management Framework assigns that kind of accountability to organizational leadership with management, fiduciary, and legal authority.
What evidence should an assessment collect?
At minimum, collect a decision log with input, model version, reviewer, and outcome, plus a data-source map naming where each input field originates. Also collect a change log linking every production change to an approval and rollback plan. It also includes a vendor-access record showing what each third party can see or touch and who approved it.
How long does an AI readiness assessment take?
There's no fixed length. It depends on how many workflows are in scope, how distributed model ownership already is across business lines, and whether the evidence above already exists or must be built from scratch. It also depends on how many third-party vendors touch the workflow. Scope those factors before estimating time.
What should the first AI workflow be in financial services?
Favor a workflow that already has a named owner and makes a narrow and reversible decision rather than a final credit, claims, or account action. It should also have a clean evidence trail to build on, not necessarily the workflow with the largest potential payoff. That combination is easier to assess and to fix if something's missing.
Related reading
- Our 12-question AI readiness check covers the broader data, process, and sponsorship questions that apply to any AI workflow, regulated or not.
- Once a workflow has a named decision authority, human-in-the-loop AI governance covers how to design and staff that review checkpoint.
- If a workflow fails one of the six dimensions above and you're not sure it belongs in an agent at all, when not to use an AI agent covers the disqualifying conditions.
- The 360° AI Blueprint ranks candidate workflows by ROI, cost, and time-to-value once this checklist has scoped them.
More in AI strategy
AI Agents vs. RPA for Hotel Back-Office Operations: When Bots Break and What Replaces Them
AI agents vs RPA for hotel back-office operations: a decision table for OTA statement matching, folio audit and multi-property AP, plus how to phase bots.
Hotel Management CompaniesWhat a 360 AI Blueprint Costs for a Food & Beverage Manufacturing Back Office
What drives food and beverage manufacturing AI cost in the back office: a table of plants, co-packers, deductions and traceability scope, plus how to budget.
Food and Beverage ManufacturersAI Implementation Cost for Multi-Rooftop Dealer Groups: What Changes When You Add a Store
AI implementation cost for multi-rooftop dealer groups: a driver table showing how DMS count, OEM portals, build type and upkeep move cost per added store.
Auto Dealerships