How to Run an AI Readiness Assessment

Your leadership team has three AI pilots underway. A vendor demo impressed the board, someone has asked whether competitors are moving faster, and the next budget discussion is approaching. Yet nobody can clearly explain who’ll own the systems after launch, what happens when the data changes, or who can stop an automated decision.

An AI readiness assessment should answer those questions before you commit more money. The useful result isn’t a reassuring score. It’s a defensible decision about what can run safely, what needs fixing, and who’ll do the work.

What an AI Readiness Assessment Really Measures

AI readiness is the ability to deploy AI repeatedly, securely and at operational scale. Buying a tool demonstrates access. Running a pilot demonstrates that something can work under selected conditions. Neither proves that your organisation can sustain it.

A pilot team can manually clean inputs, check every answer and call the developer whenever something breaks. Those arrangements may be sensible during discovery. They become hidden operating costs if leadership assumes the production service will look after itself.

Singapore’s adoption figures make the distinction important. According to Singapore’s Infocomm Media Development Authority, enterprise AI adoption increased from 14.7% in 2024 to 23.5% in 2025, while SME adoption rose from 14.5% to 23.4% over the same period. Those figures measure adoption, not whether every adopter has production-ready data, trained supervisors or effective controls.

Assess the organisation behind the pilot

Readiness is specific to the work you want AI to perform. An internal drafting assistant and a system influencing insurance decisions shouldn’t receive the same approval because they share a technical platform.

Organisation size, investment capacity, skills and data infrastructure shape what’s feasible. So does leadership’s willingness to change workflows rather than bolt AI onto an already confusing process. Building agile mindsets for AI-ready organisations matters because teams need permission to test assumptions, expose problems and adapt how they work.

Bring the people who can make those changes into the assessment:

• CEOs and founders set direction and resolve competing investment priorities.

• HR and L&D leaders examine capability, role changes and training needs.

• Operations and product leaders define useful outcomes and workable human handovers.

• Data, technology and risk owners establish whether the proposed service can be supported and controlled.

Don’t delegate the whole exercise to IT. Technical reviewers can assess integration, but they can’t decide which business outcome deserves investment or who accepts the operational risk.

The assessment should leave you with a score across six dimensions, a short list of blocking gaps and a 90-day plan with named owners. Each finding must connect to a delivery decision, not merely a presentation slide.

The Six Dimensions and the Evidence to Score Each

Use this scorecard to make discussions concrete. Ask reviewers to inspect the evidence, record where it lives and distinguish approved plans from capabilities that work.

Readiness dimensions, evidence and strong signals

Read the evidence behind each row

Strategic alignment requires more than an AI ambition statement. Ask the sponsor which business metric should change, what its baseline is and what would justify stopping the initiative. A funded project with no measurable outcome is still poorly defined.

For data quality and access, inspect the actual datasets the use case needs. Check missing values, inconsistent definitions, update frequency and permission records. A useful dataset that takes an unpredictable approval journey to obtain isn’t operationally dependable.

Technology architecture is about fitness for the workload, not owning the newest infrastructure. A managed service may reduce maintenance effort but introduce dependencies around updates, observability and cost. Ask IT to demonstrate deployment, monitoring and recovery rather than accepting an architecture diagram alone.

The framework below keeps these checks connected rather than treating them as separate departmental audits.

Separate capability from confidence

For governance and risk, follow a real approval from submission through testing to sign-off. If nobody can produce the test record, don’t award credit because a policy says testing should happen.

Talent means demonstrated competence and available capacity. Training attendance is useful evidence of participation, but ask people to evaluate a flawed output, explain when to intervene and show how they’d report an incident. Backup cover matters when the person who built the pilot is unavailable.

The operating model connects those capabilities to daily work. Inspect review minutes, service responsibilities and escalation records. A recurring meeting isn’t proof of oversight unless someone records decisions and follows through.

For a complementary checklist, teams can assess AI readiness with SourceX. Keep any supporting template subordinate to your own use-case evidence rather than treating completed fields as proof.

Where uncertainty centres on datasets and access, a focused AI data readiness assessment can help define the investigation.

Practical rule: Give data and controls more influence over the deployment decision than budget or enthusiasm. Spending demonstrates commitment, not operational capability.

How to Run the Assessment in Five Steps

Start with a defined assessment boundary: the business area, the decisions AI may influence and the people affected. Without that boundary, reviewers can spend their time debating enterprise-wide ambition while missing a specific unsafe workflow.

The Singapore findings justify close attention to foundations. In ServiceNow’s Singapore AI maturity country sheet, 68% of surveyed Singapore executives identified inadequate data accuracy and access as their leading AI challenge, 58% cited data privacy and security, and only 28% reported having AI testing, auditing and risk processes.

Run an evidence-led review

1. Inventory AI use cases: List formal projects and informal uses, including staff using public tools for client work, then classify them by business value, regulatory sensitivity and data dependency. Ask about workarounds without turning the interview into a blame exercise; otherwise employees may leave out the uses you most need to understand.

2. Score the six dimensions: Interview the responsible owners and inspect artefacts against the scorecard, recording the evidence date and any limitations. If a team claims monitoring exists but can only produce a proposed dashboard, score the current capability, not the intended one.

3. Identify gaps: Separate inconvenient weaknesses from dependencies that prevent safe deployment, and connect each blocker to an affected use case. For example, a model awaiting a security review that nobody has scheduled needs a decision and an appointment, not another development task.

4. Prioritise actions: Place initiatives on a simple value-and-feasibility grid, then use risk as an approval condition rather than something to average away. An internal knowledge assistant may be a sensible early candidate, while a customer-facing decision system may need data remediation before further build work.

5. Set ownership and timing: Convert the ranked actions into 90-day delivery backlogs with accountable owners, deadlines, review dates and measurable exit criteria. Replace “improve data quality” with a testable outcome such as approved source definitions, resolved critical exceptions and a repeatable quality check.

Use the process map to keep interviews and decisions moving in the same direction.

Plan for the work of producing evidence

Book leadership and owner interviews early. Inventory and scoring can take longer than expected because people need to locate approvals, reconcile conflicting records and explain processes that were never written down.

Send the evidence request before each interview. Ask for existing records first, and mark missing artefacts as findings rather than encouraging teams to create polished documents that disguise the current state.

Keep a decision log alongside the backlog. Record disagreements, who resolves them, and whether an unresolved issue prevents a pilot, production release, or expansion. That distinction allows useful experimentation without approving unrestricted deployment.

For regulated use cases, require documented data lineage, access controls, human-oversight rules, validation thresholds, incident escalation and post-deployment monitoring before granting production-ready status. Treat these as release evidence to inspect, not assurances to collect.

Turning Scores Into a Maturity Level

Use the following as a working assessment rubric, not an industry benchmark or regulatory certification. The average suggests a stage, while mandatory controls determine whether an initiative can progress.

Maturity bands and the next move for each

Apply consistent evidence anchors

For this rubric, score each dimension from 1 to 5: 1 means ad hoc, 2 means documented but incomplete, 3 means implemented, 4 means consistently monitored, and 5 means tested and improved through operating evidence. Average the six dimension scores for the headline result.

Half-points can represent mixed evidence within a dimension, provided the reviewer explains the judgement. Don’t use extra decimal places to imply accuracy the assessment doesn’t possess.

Suppose a mid-sized insurer averages 3.8 across six dimensions, but governance scores 1.5 because nobody owns model risk. This hypothetical organisation belongs in piloting, not repeatable delivery: the average cannot compensate for missing accountability.

Use a weakest-dimension check to prevent that mistake. Under this proposed rubric, an unresolved critical dependency caps the deployment decision at piloting, even when the arithmetic suggests a higher stage.

Adjust scores without hiding the reason

The underlying concern is practical. Singapore Business Review reports that 60% of Singapore organisations in one survey identified centralised data governance as a missing capability, while 49% cited data quality and accuracy as their top data-stack challenge.

Treat those weaknesses as delivery work. When reviewing provisional scores:

• Lower data scores for unresolved lineage gaps or uncertain permitted use.

• Lower governance scores for undocumented employee AI use, absent testing or unclear accountability.

• Award higher maturity only when monitored deployments and successful control tests support the relevant evidence anchor.

Don’t deduct twice for the same failure. Record its primary dimension, explain its wider consequences and reassess after remediation. A promised fix doesn’t earn the same credit as a passed test.

For broader organisational context, Doczen’s maturity assessment guidance for enterprise leaders offers a complementary perspective. Keep your AI deployment decisions tied to the specific workload rather than a company-wide label.

Finish with an auditable decision record linking every use case to its data owner, risk tier, approval authority, monitoring KPIs and rollback trigger. Record whether it may proceed, proceed with restrictions or remain on hold.

A score is only as credible as the evidence behind the lowest dimension.

Governance Gaps That Surface After Launch

Say an AI workflow passes its pre-launch review, then sends an incorrect instruction into an operational system. The team can see the output, but nobody knows which permissions the agent used or who can suspend it.

The review tested whether the system could start. It didn’t establish whether people could supervise it once live.

In SAP’s Singapore research, only 10% of businesses considered their AI governance processes and frameworks fully ready, and only 12% considered their governance skills fully ready. Those findings make operational supervision a separate assessment task, not an assumption attached to technical approval.

Test controls through realistic scenarios

Ask owners to demonstrate these controls, ideally through a simulated failure:

1. Agent identity: Can you list every system acting on your behalf and identify its owner?

2. Delegated authority: What can each agent read, change or send without human approval?

3. Escalation paths: Who receives a suspicious-output alert, and what response time has the team agreed?

4. Audit logs: Can you reconstruct an earlier decision from inputs, permissions, model version and approvals?

5. Model-change approvals: Who assesses a vendor update before accepting changed behaviour?

6. Business accountability: Which named person answers for the outcome and authorises recovery?

These are operational questions for responsible AI practice, not policy wording. A documented intervention process is weak evidence if the designated person cannot interrupt the workflow.

For regulated firms, add a named executive with authority to approve or stop use cases, written escalation routes and regular board reporting on AI risk. Test that authority during an exercise rather than discovering organisational ambiguity during an incident.

Make post-launch problems measurable

Track post-release defects and incident counts, with severity, affected workflow and resolution status. In a Malaysian banking case study, we coached teams on measuring performance using agile metrics, particularly post-release defect counts.

Apply the same discipline here: count failures, inspect causes and record corrective decisions. Read incident counts alongside usage and reporting quality, because fewer reported incidents don’t automatically mean safer operation.

A system can be technically ready and still be operationally unsafe. The constraint is often supervision, not access to a model.

Confirm Your Next Step Before You Commit Budget

A completed scorecard doesn’t justify an open-ended implementation budget. It should support a narrower decision: which work deserves funding now, which conditions must be met, and what evidence leadership expects at the next review.

Don’t finish the assessment by circulating a report and waiting for volunteers. Close it in a leadership session where people can make resource and ownership decisions.

Make the commitment explicit

1. Agree on the top two gaps: Share the scorecard and maturity band, then choose the weaknesses that most directly prevent useful delivery. Keep secondary improvements visible without allowing them to crowd out the blockers.

2. Name owners within a week: Give each owner authority to coordinate decisions across data, risk and business functions. An owner who must repeatedly seek permission to convene the right people cannot reliably remove the dependency.

3. Choose the first 90-day cycle: Set exit criteria for each selected use case and put the progress review in leadership calendars. Include the conditions under which the team should pause or stop, not just the milestones it hopes to reach.

4. Decide what needs outside help: Separate work your people can own from specialist gaps or temporary capacity needs. Keep internal accountability even when an external team performs the work.

Match support to the actual gap

Data remediation and lineage work need people who can trace sources and repair pipelines. Governance design for regulated use cases needs risk and business participation, while use-case prioritisation needs honest decisions about value. Delivery support should address the specific integration or operating capability preventing production.

We offer AI Strategy & Advisory for ground-level execution planning, leadership alignment and governance frameworks that turn strategic plans into 90-day cycles, alongside an AI Use-Case Discovery Workshop to identify and prioritise where AI is worth pursuing.

Most of our engagements begin with a scoping conversation, followed by a short plan mapped to the client’s goals. The assessment should make that conversation concrete: bring the evidence, the unresolved decisions and the outcome your team needs to achieve.

Take this question back to your leadership team: Which initiative can we keep running responsibly after launch, and what must we fix before funding it?

At Ekipa, we help leadership teams connect AI readiness findings to execution planning, governance and practical delivery priorities. Bring your current use cases and the gaps you can’t yet resolve, and start a scoping conversation about a plan your teams can act on.