AI readiness and opportunity audit

What this audit is — and what it isn't

"AI audit" is currently the name of several different services. This one is about where AI can create value in your business and what needs to change before you invest — we don't start from a preferred tool, we start from how work actually gets done today: its volumes, delays, exceptions, costs and the consequences when something goes wrong.

This is not an AI Act compliance audit — that's a separate page, the AI Act technical compliance sprint, and it implements the duties your lawyer has identified. It is also not a brand-visibility audit for ChatGPT or Gemini — that's SEO-adjacent work we don't do. The full distinction between these three services, with examples, is in an AI audit in a company: what it covers, how long it takes and what you get.

This audit is the first phase of AI implementation for business — you can order it on its own, or as the starting point of a full project.

What we assess

Eight dimensions, any one of which can stop a project on its own:

• Processes and actual tasks. Steps, handoffs, volumes, exceptions, rework and the consequences of a wrong decision. Automating an unstable process accelerates mistakes rather than removing them.
• Information and data. Availability, quality, provenance, permitted use, freshness, formats, ownership and access. A promising use case can be blocked by fragmented records or unsuitable permissions.
• Existing software. Internal applications, SaaS, APIs, exports, licences and built-in AI capabilities. A capability you already pay for can beat a new platform or a custom build.
• Integration and architecture. Identity, API limits, connectivity, environments, hosting constraints, logging, deployment and support. A demonstration is not evidence that an integration will hold up in production.
• Endpoints and servers. Supported operating systems, patching, device management, browser compatibility — and server capacity where a workload actually needs it. Mixed operating systems or older devices are not automatic blockers for SaaS-based AI.
• People and operating readiness. Role-specific skills, verification habits, sponsorship, ownership, capacity for change and support arrangements.
• Risk constraints. Sensitive data, high-impact decisions, confidentiality, procurement, human oversight and initial regulatory screening. Detailed legal classification is your lawyer's call; the AI Act technical compliance sprint then implements the duties they identify.
• Economics. Baseline cost, realistic adoption, implementation, licences, inference cost, human review and ongoing maintenance. Capacity released is not automatically cash saved.

How we do it

1. Define objectives and boundaries. Agree the target outcome, participating departments, constraints and evidence access.
2. Observe and baseline the work. Interview the people who do and own the work, sample process records, and check the gap between how a process is supposed to run and how it actually runs.
3. Inspect the foundations. Review architecture, data samples, identity and integrations. Where access allows, run targeted feasibility checks — we don't infer compatibility from a product logo.
4. Build opportunity cards. For each candidate, record the problem, the user, the inputs, the proposed intervention, alternatives, risks, owner, dependencies and success measure.
5. Compare options. Assess value, feasibility, risk and change effort. Prohibited or unacceptable uses are ruled out before ranking — regardless of how attractive the economics look.
6. Produce a staged roadmap. Separate no-regret improvements, bounded pilots and longer-term bets. Define stop/go criteria and the evidence needed to proceed at each stage.

What you get

• An executive summary — where to invest, and where not to.
• A readiness profile across the eight dimensions, with evidence coverage and a confidence level for each.
• A use-case portfolio with buy, integrate, build, plain-automation or no-change options.
• Prioritised blockers and quick wins, with owners and dependencies.
• Indicative business cases — with ranges, assumptions and sensitivity to adoption rate and review cost. We don't publish hypothetical savings without evidence.
• Pilot briefs: scope, test data, success thresholds, human oversight, rollback and decision gates.
• A sequenced implementation roadmap and a handover workshop.

Illustrative example

A hypothetical example, not a client description or a determination of any company's actual KSeF tax obligations. A Polish distributor wants an autonomous invoice-processing agent. Discovery starts by checking whether authorised KSeF/ERP access already supplies the required structured fields. Where it does, XML parsing and deterministic reconciliation can remove the need for AI extraction. For the remaining unstructured documents, an extraction pilot is justified. Missing purchase-order references and a limited ERP write interface still require safe validation and human exception handling — not unrestricted agent access. Before scaling up, we measure accepted records, correction time and duplicate prevention. More on KSeF itself in accounting automation after KSeF.

Scope, exclusions and what follows

Indicative planning envelope: one business unit and up to five workflows, one to two weeks once evidence becomes available — the same range as the AI audit article and the implementation methodology. This is an internal estimate to validate through pilots, not an advertised SLA. Enterprise-wide discovery, detailed penetration testing, legal opinions and production implementation require a separate scope.

This is typically followed by data remediation, a pilot, team enablement, or a specialist audit (regulatory or security). The report has standalone value — you can implement with your own team or another supplier. The conditions under which we advise against a project at all are on what we don’t do, and the full four-phase methodology is on the implementation methodology page.

This is not a guarantee of return on investment, nor a technical security clearance — in-depth security testing and legal classification are separately scoped work.

Frequently asked questions

Do we need clean data across the whole company to start?

No. We assess the information needed for the chosen use case, rather than making perfect enterprise-wide data a prerequisite. Fragmented data in one area can still be enough for a sensible pilot elsewhere.

Will the audit recommend cutting staff?

The audit assesses work and its outcomes, not roles. We separate capacity released, service quality and actual cash savings — three different things that are easy to conflate. Workforce decisions stay with leadership and need their own consultation.

Can we do this without an in-house AI team?

Yes, provided process owners and the people responsible for your systems can supply evidence: case examples, data-export access, integration descriptions. The plan we propose reflects the team and support capacity you actually have — it does not assume specialists you do not employ.

How does this differ from the blog post?

It's the same audit — this page covers scope, deliverables and how to commission it; the blog post walks through the method step by step, including the process scoring card and a worked example. Worth reading both if you're considering ordering it.