What is an AI readiness audit?
An AI readiness audit is a review that happens before any build. It answers three questions: which use cases are worth automating, whether your data can support them, and what your security and compliance rules require before go live. We read your systems and data, and we interview the people who do the work. The audit is vendor neutral, and the output is a ranked list with a build, buy or wait call on each item.
The workshop
The audit starts with a half day or full day workshop, on site or remote. Six to twelve people attend: the decision maker, the budget owner, a technical lead and at least two people who do the work.
We map where the hours go first. That means the tasks that take the most time each week and the handoffs that cause rework. It also means the steps a person repeats without a clear reason. Every idea goes on the list. Each one then gets a score on value, effort, data readiness and the cost of a wrong output. We score live, and the disagreements get settled in the room. The top items leave with an owner, the effort and the payback.
Data readiness
Most stalled AI projects stall on the data rather than the model. For each top item we find where the data lives: the ERP, the core system, a document store, a shared drive or a mailbox. We profile its quality, which covers missing fields, duplicates, values that conflict between systems, and records that exist only as scanned PDFs. We also record who can access each source today, and through which API or export. When the data is not ready, the fix goes on the roadmap ahead of the model. Data engineering covers that work.
Architecture and security
We review the systems that each use case touches: the APIs they expose, where they run, how staff sign in and where the logs go. With your security team we agree where a model can run. The options are a hosted model in an Australian region under your own cloud account, or an open-weight model on your own servers. We record the data residency rules, the access controls and the third party risk rules that apply. For entities that APRA regulates, those include CPS 234 and CPS 230. Private AI covers the hosting options.
Use case ranking
Every candidate gets a score on four axes: the value at stake, the effort to build, the readiness of the data and the cost of an error. The cost of an error decides where a person must review the output, and that changes the payback. A wrong tag on an internal file costs little. A payment to the wrong supplier account can cost the full amount. Lower items stay on a written list with the reason for their rank.
Build, buy or wait
Buy means a product you already pay for, or can license, does the job, and we name the product. Build means the work depends on your own data or systems in a way that no product covers. Wait means the data, the process or the models are not ready. We write down the reasoning for each call and the capability assumptions behind it, with the date. When the models change, your team can check those assumptions without a new audit.
Governance
The governance policy is short and written for the people who must follow it. It says what data can go to which model and who approves a workflow that touches customers or money. It also sets what gets logged, how long the logs are kept, who reviews the output each month and who can switch a workflow off.
The roadmap
The roadmap puts the items in order. Early items are small and contained, and each one replaces work that people do every day. They build the review habits and the evaluation sets that later items depend on. Larger items come later, after the team learns to check and correct these systems. Each item has an owner, its dependencies, the effort and the expected payback, and the top three come with a one page business case. Your own team can then build from it, or we build it with you through AI agents and workflow automation and the other services.