AI readiness audit: what exactly we check and what you get at the end

An AI readiness audit is a paid diagnosis, usually lasting 2–4 weeks, of processes, data, live or planned systems, and accountability. It should lead to decisions: what to test, what to repair first, and what to reject. It does not produce a certificate or promise a return. The organisation receives a system register, risk matrix, project list, architecture recommendation, and a roadmap with owners and decision gates. This guide shows the complete flow from scoping to artefact handoff.

For the commercial scope, start with the audit offer on the services page. You can also use this guide as a question set when assessing another supplier. It is not legal advice or a formal conformity assessment of a particular system.

Table of contents

• What an AI readiness audit covers
• Before the audit: scope and people
• Interviews and data: how we collect evidence
• Decisions: what happens to the findings
• Handoff: who takes ownership of the artefacts
• What an audit is not
• FAQ: AI readiness audit
• What next

What an AI readiness audit covers

A practical AI audit for a company has five phases. First, the team agrees boundaries and identifies the people who can confirm facts. It then collects evidence about processes, data and tools, including shadow AI. The third phase structures systems, roles, risks, architecture and cost. In the fourth phase, candidates pass through decision gates. Finally, each artefact is handed to a named owner with a review date.

The audit should not begin with a model shortlist. It begins with decisions and consequences: who uses the output, what happens when it is wrong, what data enters the process, and whether a person can stop or correct the action. The same chatbot may be a low-impact writing aid in one team and a component of a consequential workflow in another. We therefore assess the use case, the organisation’s role and its context, not just the tool’s brand.

In practice, we examine six areas:

• Processes. We map repetitive work, waiting points, manual transcription, information retrieval and decisions that cannot be delegated without control. Each candidate receives a description of the current workflow, a baseline measure and a business owner.
• Data. We check the source of truth, quality, freshness, permissions, lawful use, retention and deletion. For RAG, the separate data-readiness checklist provides a deeper review.
• Shadow AI. We register public chatbots, private accounts, plugins and automations used outside the approved process. The open AI system register gives teams a common working format.
• Roles and risk under the AI Act. We establish whether the organisation acts as a provider, deployer or in another role, and identify questions that need further legal validation. The reference is the official text of Regulation (EU) 2024/1689, read together with later amendments. The AI Act page structures the deadlines and technical work. The audit and register do not provide an automated legal classification.
• Architecture and costs. We recommend an AWS option and estimate delivery and running costs. The Region and inference mode determine where processing may occur. Application and logging configuration determine where additional copies are created. KMS controls encryption and keys, while network design controls the transport path. The shared responsibility model identifies which settings and evidence remain the customer’s responsibility. Our guide to AI architecture on AWS for GDPR and AI Act requirements sets out the checks required before deployment. We separately explain what drives the cost of a RAG system or an agent.
• Funding. We check whether the technical scope fits a programme, but do not promise an award. Semitora can prepare the technical contribution; the client or a grants adviser owns the formal application.

Before the audit: scope and people

Phase 1 starts before the first workshop. The sponsor names the business problem, and a coordinator prepares the initial list of teams, systems and documents. We do not ask for “all company data”. The useful scope is the minimum needed to confirm the selected processes and dependencies. Starting too broadly blurs accountability; starting too narrowly may hide tools used outside IT.

A short intake should capture:

• the audit objective and the decision expected at its conclusion;
• organisational units, processes, locations and systems in scope;
• sponsors, process owners, IT, security, compliance and a legal contact;
• known AI tools, suppliers, integrations and shadow-AI cases;
• available process measures, costs, volume and common failure consequences;
• access constraints for data and documentation.

The opening meeting also agrees the evidence rules. A claim that “the system does not process personal data” needs support from the data flow or configuration, not the owner’s assurance. “IT approved it” should point to a decision, date and scope. We do not copy secrets, keys or whole databases into a report. We record the source, owner and verification result in a form the organisation can maintain after the audit.

The 2–4-week timeline is a planning range, not a guarantee. Two weeks may be enough for one process and a small set of well-documented tools. Four weeks may not be enough if owners are unavailable, system access requires new approvals, or interviews uncover a second shadow-AI portfolio. The first decision is then to change scope or timing, not to skip evidence.

Interviews and data: how we collect evidence

Phase 2 covers process interviews. A board conversation gives priorities but does not describe daily work. We also speak with the person doing the work, the process owner, IT and risk functions. We ask about inputs, steps, exceptions, escalations and outputs. The goal is to locate where AI could help and where a person must regain control.

We do not rate an idea from an attractive demo alone. For example, an assistant that answers from procedures may shorten search time, but its value depends on source freshness, access control and correct refusal. An automation writing into an ERP needs a separate assessment of permissions, failure impact, action limits and approval. Both use AI, yet require different evidence.

Phase 3 is the evidence review for data, systems and controls. We select the samples and configurations needed to test each claim. For knowledge sources, we inspect versioning, ownership, update dates and permissions. For a SaaS tool, we inspect the contract, account settings, logging and data flow. For an internal PoC, we inspect the scope, repository, environment, access and existing tests. This is not a full security or legal audit; gaps that require such work enter the backlog with an owner.

Each finding has one of four states: confirmed, partly confirmed, unconfirmed, or out of scope. This is less decorative than a green score, but more useful. It shows where a decision rests on evidence and where it rests on an assumption. Uncertainty does not disappear after a workshop; it gets a name, owner and verification date.

This phase also creates the automation candidate list. We assess impact and feasibility, but estimated ROI remains a hypothesis to test. Without a baseline, actual handling cost and failure data, a return percentage would be false precision. First, the team records what to measure. A bounded PoC can then produce evidence for one process.

Decisions: what happens to the findings

Phase 4 turns observations into decisions. Not every gap blocks a project, and not every idea should enter a PoC. For each candidate, the audit records a decision, rationale, owner and review condition. Typical paths are: prepare the data, narrow the scope, request further legal or security qualification, run a bounded PoC, defer, or close the candidate.

Three gates keep that decision explicit:

1. Scope gate: do we know the process, user, data, owner and failure consequence? The minimum evidence is a use-case card and a register entry. The decision is to complete the scope or continue.
2. PoC-readiness gate: may we use the data slice, and do we have a measure and threshold? Data-owner approval, a sample and test criteria support a PoC, preparation work or no-go decision.
3. Further-investment gate: do the PoC result, cost and risk justify the next stage? Evaluation results, unit cost and open risks lead to delivery, a changed scope or no-go.

A threshold is not a universal benchmark. It depends on the process and the consequence of failure. A tool suggesting words in an internal note can use different criteria from a system supporting a customer-facing decision. The process owner approves thresholds with the functions accountable for risk. A consultant proposes a method and reports the result but should not take over the business decision.

An organisation that wants to assess its starting point before commissioning an audit can complete the free AI Readiness Scorecard. Its 24 questions separate missing foundations from readiness for a bounded PoC. The result is not an automatic conformity assessment and does not select a project for the board.

Handoff: who takes ownership of the artefacts

Phase 5 ends only when artefacts have owners. Sending a report is not a handoff. The audit needs a decision meeting where the sponsor approves priorities, owners accept actions, and legal, security and data questions move to the proper functions. Every roadmap item has a date, dependencies and a closure condition.

The final report records decisions in five working artefacts. We adapt ownership to the organisation; the matrix below shows the accountability that must be assigned before the audit closes.

Artefact	Owner	Decision / next step
AI-system and shadow-AI register	AI portfolio owner or nominated coordinator	confirm scope, missing systems and the next review date
Risk matrix	risk / compliance owner with legal input	identify cases that require further qualification and controls
Project list scored for impact and feasibility	business sponsor	select a PoC and defer or reject the remaining candidates
Architecture recommendation	technical owner	approve data, security, integration and cost constraints
Roadmap	sponsor and action owners	agree sequence, dependencies, dates and go/no-go gates

The open AI Governance RACI template can maintain accountability after the audit. It asks for exactly one Accountable role per stage, required input, evidence and escalation. The Evidence Pack structures the system card, risk classification, golden set, evaluations, logs, handoff, rollback and go/no-go decision. Neither template is a certificate. Their value is that a decision has a version, source and owner.

A useful roadmap separates three horizons. The first contains blockers, such as confirming rights to data or stopping a risky shadow-AI flow. The second prepares one case for a PoC. The third describes the conditions for potential delivery and ongoing operation. Dates are agreed after dependencies are reviewed; the audit itself does not guarantee a production date.

What an audit is not

An audit is not a sales pitch disguised as a free consultation ending in an invented price. It is also not a complete cybersecurity audit, legal advice, a formal conformity assessment or a certificate. It can identify that such work is required and prepare technical evidence for the specialists who perform it.

It does not guarantee AI Act compliance, a financial return, funding or production delivery. Cost and impact estimates help compare candidates; ROI must be tested with process evidence. An AWS recommendation does not mean data automatically remains in one location. Region, service, inference mode, logs, integrations, copies and customer configuration determine the actual flow. Those conditions must be verified for the specific architecture.

The mojApteczka production GenAI healthcare system shows how versioned sources, citations and measurement work in one Semitora system. It is evidence from that system, not a forecast for a client’s audit and not a promise that its metrics will transfer to another process.

FAQ: AI readiness audit

What does an AI readiness audit cover?

It covers scope and owners, the process map, data and permissions, the AI-system and shadow-AI register, initial AI Act role and risk qualification, architecture, cost, the candidate list and a roadmap. The exact scope depends on the number of processes, systems and locations. We agree it before starting and change it explicitly when new dependencies appear.

How long does an AI readiness audit take?

Usually 2–4 weeks, but that is a planning range rather than a guaranteed SLA. Timing depends on scope, owner availability, documentation, approvals and system access. One process can take less time than a portfolio across several companies. If evidence is missing, we do not shorten the review by guessing; we agree another step or record the gap.

What data and materials should we prepare?

Start with the process and system list, owners, known AI tools, integration descriptions, access policies, supplier terms, data-flow diagrams, sample documents and available baseline measures. Do not send passwords, keys or entire databases. Samples and access are selected after the objective is agreed, keeping the data scope to the minimum needed.

What does the company receive after the audit?

It receives working artefacts: the AI-system and shadow-AI register, risk matrix, project list scored for impact and feasibility, architecture recommendation and roadmap. Each entry has an owner, evidence or an explicit assumption, a decision and a review point. An optional PoC has a separate scope and should end with test results and a go/no-go decision.

Does an audit provide certification or guarantee compliance and delivery?

No. An audit does not issue a certificate or replace legal advice or a formal conformity assessment. It does not guarantee ROI, funding, timing or implementation results. It provides structured facts, questions, technical evidence and a plan that allows the proper owners to decide and commission further validation.

What next

There are two sensible routes. To assess the starting point yourself, open the AI Readiness Scorecard and then complete the AI system register. If you need workshops, evidence review and an owned roadmap, see the full audit scope on the services page and book an audit conversation. The first conversation scopes the work; it does not replace the audit.