An AI readiness assessment checks whether a business can use AI for a defined purpose with appropriate data, oversight and operating support. It should end with a practical decision: proceed with a bounded pilot, fix specific gaps first, or choose a simpler solution.
A company does not need to be ready for every form of AI. It needs to be ready for the proposed use case. Drafting an internal meeting summary, finding information in approved documents and taking actions in a customer system create different requirements.
Begin with one workflow and one accountable owner
Write down who performs the work, what enters the process, what a useful result looks like and who is affected when it goes wrong. Avoid starting with a broad ambition such as “transform the business with AI.” It is too large to assess and too vague to test.
For example, an illustrative service company might explore an assistant that drafts answers from its approved service documentation. That is a more assessable proposal than an unrestricted agent that handles all customer communication. The narrower scope makes it possible to examine source quality, review effort and response accuracy.
The NIST AI Risk Management Framework provides a voluntary reference for managing AI risks across an organisation. The following checklist is a practical planning aid for a business project, not a certification or a substitute for requirements specific to the organisation.
1. Is the business problem worth solving?
Observe the current workflow before estimating benefits. How frequently does the task occur? Where does the time go? Which errors matter? Who checks the output? Include exceptional cases instead of measuring only the easiest work.
Then identify the desired change. Reduced preparation time, better information retrieval and fewer incomplete handovers are different outcomes. If the process is already simple and governed by stable rules, conventional workflow automation may be sufficient.
Evidence to collect: a short workflow description, a baseline from representative work and an owner who can approve the acceptance conditions.
2. Can the system access suitable information?
List the information the proposed solution needs, where it lives and who maintains it. Check whether documents are current, whether important terms are consistent and whether the intended users are allowed to see the material.
More data is not automatically better. A small set of approved documents may be more useful than a large collection containing contradictory policies and obsolete instructions. Decide which source wins when two documents disagree and how changes reach the AI application.
Evidence to collect: a source register with owners, update dates, access rules and known quality gaps. Use approved sample or synthetic information while assessing the workflow; do not copy sensitive material into an unreviewed tool.
3. Are access and action boundaries clear?
Distinguish reading information, drafting a recommendation and making a change. A system that can suggest a customer response has a different risk profile from one that can send it, alter a record or approve a transaction.
Specify which data and tools the solution can use, which actions need human approval and how activity is recorded. Review the provider's handling of submitted information, retention options and administrative controls against the company's needs. Relevant requirements depend on the data, sector and contractual context.
Evidence to collect: an approved access scope, an action approval policy and a named person responsible for exceptions. CREDIUM's cybersecurity consulting and services can support this assessment alongside the application design.
4. Can you tell a good result from a plausible one?
Build a test set from representative tasks before celebrating a demonstration. Include straightforward questions, incomplete requests, conflicting information and cases where the correct response is to ask for help or decline to answer.
For the service-document assistant, a useful test would check whether the answer is supported by the approved source and whether the employee can verify it quickly. A fluent paragraph that cites an irrelevant document should not count as success.
Measure the work after review, including corrections and exceptions. Evaluate important failure categories separately so an average score does not hide a serious weakness. The NIST AI RMF Playbook offers further suggested actions for governing, mapping, measuring and managing AI risks.
Evidence to collect: an evaluation set, acceptance criteria, a record of failures and a procedure for retesting when the system changes.
5. Will people know how to use and challenge it?
Identify who reviews output and whether they have enough context to notice mistakes. “A human is in the loop” is weak protection if that person has no time, no relevant knowledge or no practical way to correct the result.
Provide role-specific guidance with examples of acceptable use, escalation and prohibited actions. Ask pilot users to record where the tool helps and where it creates additional work. Make feedback part of the project schedule instead of hoping it appears informally.
Evidence to collect: a review owner, a short operating guide and time allocated for feedback and training.
6. Can the business operate the solution after the pilot?
Decide who owns the application, supplier relationship, integrations and ongoing evaluation. Estimate the cost of usage, administration, monitoring and human review. Agree what happens if a model, data source or connected system changes.
A practical pilot has a stop condition and a fallback process. If the assistant becomes unavailable or fails its checks, employees should know how to continue the underlying work. See our AI governance article for additional ownership and approval questions.
Use readiness gates instead of a misleading average
Mark each area as evidenced, incomplete or blocked. A strong training plan should not cancel out an unresolved access problem. Record the missing evidence, assign an owner and decide what must be resolved before testing with real users or information.
- Proceed: the bounded use case has suitable data, controls, evaluation and ownership.
- Prepare first: the opportunity is plausible, but named gaps need work.
- Change approach: a process improvement or deterministic automation better fits the task.
This assessment should produce a small, usable decision brief. Include the pilot scope, allowed actions, evaluation criteria, costs to investigate and the date of the next decision.
From AI assessment to implementation
CREDIUM combines business consulting with AI solutions, software development and system integration. We can help assess a workflow, prepare the requirements and deliver a controlled implementation. Talk to CREDIUM about an AI readiness assessment focused on the work your organisation actually needs to improve.