Ten areas an institution has to have an answer for before an AI system reaches production — what a sound answer looks like in each, and the symptom that gives away an institution about to lose money on a pilot.
In short
- AI readiness is rarely a single missing capability. It is a set of answers an institution either has or does not have when a system is about to touch a real process, and the ones that are missing tend to surface late — after the model works, after the budget is committed, and at the point where someone has to sign.
- AI readiness is having settled answers, before a system touches a real process, across roughly ten areas: ownership and decision rights, a maintained model inventory, data readiness for the specific use case, lawful basis and data handling, the process step where the output lands, independent validation capability, human oversight specified as a mechanism, the production and evidence layer, third-party contract terms, and the internal capability to govern and maintain what has been built.
- Each system needs a named owner in the business function whose decisions it shapes, not in technology, because that is the person who will be asked why a customer was declined or a figure was wrong.
- Ask what the validator would need in order to say no, and whether they have it.
On this page
AI readiness is rarely a single missing capability. It is a set of answers an institution either has or does not have when a system is about to touch a real process, and the ones that are missing tend to surface late — after the model works, after the budget is committed, and at the point where someone has to sign.
The checklist below sets out the ten areas where readiness is most consistently tested, what a sound answer looks like in each, and the symptom that gives away an institution about to spend money on a pilot that will not land.
Ownership and decision rights#
A sound answer names the executive accountable for AI across the institution, the forum that approves systems for production, the tier of decision each level may authorise, and the person who owns each individual system in the business rather than in technology.
The symptom of a weak answer is an AI programme owned by whichever function was most enthusiastic, with approval by a committee that has never declined anything.
Ask who could stop a deployment tomorrow; if nobody can name them, nobody can.
The inventory#
A sound answer produces, on request, a current list of every system whose output materially shapes a decision — including vendor modules inside purchased platforms, scoring rules embedded in workflow tools and departmental models that outlived their builders — each with an owner, a purpose, a risk tier and a review date.
The symptom of a weak answer is a list assembled once for an audit, covering only what the technology function built. Ask when it was last updated and who is obliged to update it.
Data readiness for the specific use case#
A sound answer confirms the institution holds the right data, lawfully usable for this purpose, in sufficient volume, with outcomes or labels that make learning possible, covering the conditions the model will meet in production — and that someone has examined actual records rather than a schema.
The symptom of a weak answer is a data assessment expressed in terms of systems and volumes with no verdict on quality, and no acknowledgement that the outcome history covers only benign conditions. Ask whether the training period contains a downturn, a fraud wave or whatever stress the model will eventually face.
Lawful basis and data handling#
A sound answer states:
- the basis on which each data category may be used for this purpose
- what may not be used
- where the data will physically reside
- who can access it
- what leaves the institution’s perimeter and under what terms
- what customers have been told
The symptom of a weak answer is a project that has assumed data available for one purpose is available for another, and a residency question first raised by the vendor’s architecture diagram. Ask the privacy and legal functions whether they were consulted before or after the use case was selected.
The decision landing point#
A sound answer walks the process as it runs today and identifies the exact step where the output arrives, who occupies it, what they would do differently, what authority they hold, and what changes in their workload.
The symptom of a weak answer is a use case described entirely in terms of the model, with the operating process referred to in the future tense. Ask to be shown the step; if it has to be designed, that design is usually more work than the model and belongs in the plan.
Validation capability#
A sound answer identifies:
- who will validate the system independently of whoever builds or procures it
- against what standard for its risk tier
- with what access to test data
- with the standing to withhold approval or impose restrictions
The symptom of a weak answer is validation assigned to the same team that selected the vendor, or a second line that has never assessed a model of this kind and has not been resourced to learn.
Human oversight as a mechanism#
A sound answer specifies:
- which decisions require review before taking effect
- what the reviewer is shown including the basis for the recommendation and any contrary indicators
- how much time the review realistically allows
- how an override is recorded
- what the expected override rate is
The symptom of a weak answer is oversight described as a principle, with no interface design and no measurement.
Ask what the override rate is in any comparable existing process; a rate at or near zero means the control is decorative there and will be here.
The production and evidence layer#
A sound answer describes what makes this regulated software rather than a script — versioning, access control, input and output logging, the ability to reproduce any past decision on demand, drift and performance monitoring, alerting, and a rollback path — and confirms these are in the build scope rather than a later phase.
The symptom of a weak answer is a plan in which the model is costed and the surrounding engineering is not, which is the arithmetic signature of a pilot that will not reach production. Ask what it would take to explain a specific decision from six months ago.
Third-party terms#
A sound answer shows that documentation of intended use and limitations, evidence of vendor testing, a right to test independently on the institution’s own data, notice before model changes, log access sufficient to reconstruct a decision, and a workable exit were secured in the contract rather than requested afterwards.
The symptom of a weak answer is a signed agreement that covers uptime and price and is silent on all of it. Ask whether the risk function read the contract before signature.
People and the standing capability#
The last area determines whether any of the other nine survive.
A sound answer shows:
- that the board and executives understand enough to ask the right questions
- that risk, compliance and audit have been trained to challenge a model rather than receive it
- that the operating teams have been prepared for the process change
- that someone inside the institution can maintain the system when the vendor or the consultant leaves
The symptom of a weak answer is an AI programme whose entire expertise sits with people who will not be there next year — at which point the institution has bought a system it cannot govern, which is a worse position than not having built it.
Frequently asked
What does AI readiness actually mean for a bank?
AI readiness is having settled answers, before a system touches a real process, across roughly ten areas: ownership and decision rights, a maintained model inventory, data readiness for the specific use case, lawful basis and data handling, the process step where the output lands, independent validation capability, human oversight specified as a mechanism, the production and evidence layer, third-party contract terms, and the internal capability to govern and maintain what has been built. Readiness is rarely a single missing capability — it is the set of answers that surface late, after the model works and the budget is committed, at the point where someone has to sign for the outcome.
Should AI governance be built before or after the first use case?
If models are already running, governance comes first, because ungoverned scoring, monitoring or vendor tools in production are an immediate exposure that no strategy addresses, and the inventory needed to govern them is also the input a credible roadmap requires. Where nothing is live, the two are best built together, with the framework sized to the actual roadmap rather than to a hypothetical estate — a governance framework designed in the abstract is usually too heavy for trivial uses, which means it gets evaded on the serious ones. The practical sequence is a first delivery chosen to prove the framework end to end, rather than a framework written and then applied retrospectively.
Who should be accountable for an AI system inside a bank?
Each system needs a named owner in the business function whose decisions it shapes, not in technology, because that is the person who will be asked why a customer was declined or a figure was wrong. Above them, an executive should be accountable for AI across the institution and a forum should approve systems for production with authority proportionate to the risk tier. The diagnostic question is simple: who could stop a deployment tomorrow? If nobody in the institution can name that person, the decision rights do not exist, whatever the policy document says.
What is the most common reason an AI programme stalls?
The most common cause is that the engineering and governance around the model were never scoped or costed — no integration with the systems that run the process, no decision record, no monitoring, no override interface, no owner with a budget line — so a model that performs well has nowhere to go. Close behind sit two others: a use case with no landing point in the operating process, meaning nobody with authority is positioned to act on the output; and validation assigned to a team that cannot realistically withhold approval. All three are visible before a pilot starts, which is why the refusals and conditions produced by an honest readiness assessment are usually worth more than the approvals.
The programme behind this article
Work through this material with the practitioners who wrote it.
AI Governance & Responsible AI for Financial Institutions
The governance layer your AI adoption now legally needs — model inventories, risk classification, human oversight, validation and vendor control, built for banks and insurers facing hard regulatory deadlines.
View the programme →AI & FinTech Transformation for Banks Masterclass
A practical two-day banking masterclass on AI, FinTech partnerships, digital products, cybersecurity and transformation governance — moving innovation from pilots and disconnected projects to secure, scalable solutions with measurable customer and commercial value.
View the programme →Intelligent Automation: RPA, Process Mining & AI Agents for Operations
Three vendor-neutral days on automating the right work the right way — process mining to find the truth, a clear-eyed choice between RPA, APIs and AI agents, the business case finance believes, and the human-in-the-loop governance that keeps automation safe.
View the programme →