Advice to “get your data in order” before doing anything with AI can sound responsible and still leave a firm with an indefinite programme detached from a real use. At the other extreme, adopting a tool because peers appear to be moving creates risk without a business decision.

Distinction treats AI readiness as specific to a use case. A firm can be ready to test a contained internal task and unready to automate a client-facing judgement. The useful question is whether the people, information, technology and controls are sufficient for a defined application and consequence.

This is a profile, not a single maturity score.

Begin with the work

Identify a recognisable problem before assessing tools. Which task, decision or service is slow, inconsistent, difficult to scale or insufficiently supported? Who experiences the problem and what evidence shows it matters?

Map the current process, including judgement, exceptions, review and failure. Some apparently repetitive work contains professional reasoning that should remain with a person. Some delays come from policy or ownership and will survive automation.

Define the desired outcome and guardrails. A drafting assistant might aim to reduce first-draft effort while maintaining factual accuracy, confidentiality, professional review and accessibility. These conditions determine what “ready” means.

Use a portfolio view to compare opportunities by value, feasibility, learning and consequence. Early work often benefits from a bounded internal use where every output can be reviewed before it affects a client. This is a risk-led starting principle, not a claim that internal tools are automatically safe.

Examine information fitness

The data question concerns the information required for the selected task. Assess:

  • availability and lawful access;
  • accuracy, completeness and currency;
  • structure, metadata and retrieval;
  • provenance and permission;
  • representation and relevant bias;
  • retention, confidentiality and residency;
  • ability to correct, remove and audit material.

Perfect organisation-wide data is unrealistic. Define an acceptable threshold for the use and test it. A contained knowledge-search application may need a well-governed document collection; it does not automatically justify cleansing every record in the CRM.

Data quality also includes the source process. If colleagues store final and draft advice together, a one-off cleanup will decay. Readiness work should address creation, ownership and lifecycle as well as the initial dataset.

Do not upload sensitive client or employee material to a service until contractual, privacy, security and professional-duty questions have been reviewed by accountable specialists.

Examine technology and supplier fit

Determine how the proposed capability will access information, authenticate users, enforce permissions, log activity and fit existing workflows. A technically impressive model may fail because colleagues must copy material between systems or cannot see the source behind an answer.

Review architecture and supplier terms for:

  • model and service boundaries;
  • data use, training and retention;
  • hosting and transfer arrangements;
  • identity and role-based access;
  • integration and export options;
  • version change and evaluation;
  • monitoring, incident and support routes;
  • portability, termination and dependency;
  • total operating cost.

Capabilities and terms change. Verify current product documentation and the actual contract at the point of decision. Avoid designing strategy around a feature promised for a future release.

Examine people and operating confidence

Enthusiasm and readiness are different. People need to understand the task the system can support, recognise common failure modes, check outputs and know when to escalate or stop.

Assess the likely users, supervisors and affected colleagues. Explore workload, professional incentives, accessibility, training, confidence and the consequence of increased review. A tool that saves drafting time while adding hidden verification effort may not improve the service.

Involve practitioners in scenario design and evaluation. Their knowledge is essential for difficult examples and quality judgement. Do not place responsibility for an unsafe system on an individual user through a generic instruction to “check the output”. The service must make review practicable and retain organisational accountability.

Change evidence should include more than adoption. Examine appropriate use, correction, override, exception handling, skill development and whether people understand the limits.

Examine governance by consequence

Name an accountable owner for the use case and identify specialist responsibilities for technology, data, security, privacy, risk, legal and professional practice. A mid-sized firm may not need a new executive title, though it does need sufficient authority and capacity.

Governance should cover:

  • permitted and prohibited use;
  • approval and risk classification;
  • documented purpose and responsible owner;
  • evaluation before and during service;
  • human review and decision boundaries;
  • transparency to affected people where required;
  • incident, complaint and correction handling;
  • supplier and model change;
  • records, audit and retirement.

Requirements depend on jurisdiction, sector and the role of the system. Current legal and regulatory advice is essential for material use. A policy copied from another firm cannot determine local duties.

Test readiness through scenarios

Interviews reveal perceptions. Combine them with evidence: sample data, system documentation, policies, contracts, incidents and realistic tasks.

Build a small set of scenarios including ordinary work, incomplete information, conflicting sources, malicious or irrelevant input, access boundaries and a case where the right action is referral to a person. Define success and unacceptable failure before testing.

Measure output quality, groundedness, consistency, user effort, review burden, security and operational behaviour. Generic model benchmarks cannot replace evaluation in the firm’s context.

Record uncertainty rather than compressing the result into a red-amber-green score. One dimension may be strong for a research assistant and weak for automated advice.

Make three kinds of recommendation

A useful readiness assessment should lead to decisions, not a shelf document.

“Start” recommendations identify bounded uses where evidence and controls support a pilot. They state the hypothesis, participants, data, evaluation, guardrails and stop conditions.

“Prepare” recommendations identify a specific missing foundation tied to a plausible use. This could be permission cleanup in one document collection, a review policy, an integration path or role-based training. Give it an owner and evidence of completion.

“Do not pursue yet” recommendations explain why consequence or uncertainty is unacceptable and what, if anything, could change the judgement. This prevents attractive ideas from circulating without their constraints.

Partial readiness can enable partial adoption when the application is deliberately bounded. It does not justify using a low-risk success as proof that the firm is ready for a substantially different client-facing or regulated task.

What Distinction’s assessment should produce

Our approach examines the intended work across information, technology, people and governance. It should produce an evidence-backed readiness profile, prioritised use cases, immediate controls, specific preparation and a recommendation about the next decision. It is not a promise of an AI strategy, fixed timeline or guaranteed return.

We will recommend stopping or narrowing an idea when the problem, evidence or safeguards do not support it. Distinction may benefit commercially from later work, so the assumptions and reasons should remain visible and open to challenge.

The downloadable self-assessment checklist can help a team structure an initial view before commissioning anything. It is a prompt for evidence, not a compliance certification. If a direct discussion would be more useful, book a readiness conversation. The appropriate outcome may be a pilot, foundation work, further specialist review or a decision that AI is currently the wrong intervention.