Strategy
What an AI Readiness Audit Should Actually Examine
A readiness audit should look at data access, system connections, review capacity, and ownership, then end with a scoped pilot. Here is what to expect.
For: Operations leader and IT lead · 1 min read ·
An audit should end in a decision
A useful readiness audit is not a maturity score or a slide about transformation. It ends with one of three answers for a specific process: pilot it, prepare it, or leave it alone.
1. Data access
- Where the inputs live today: inboxes, SharePoint or Google Drive folders, the ERP, the CRM.
- Whether your Salesforce edition, HubSpot tier, or Microsoft 365 tenant allows API access for this use.
- Who grants that access, and how long that usually takes in your organization.
2. System connections
- Which system is the record of truth for each field.
- Whether writes back to the ERP or CRM are allowed, or only reads at first.
- Rate limits, sandbox environments, and how test data is kept separate.
3. Review capacity
Every workflow we build has a person reviewing outputs before they reach a customer or a ledger. The audit has to confirm that person exists, has time, and knows what a wrong answer looks like. If nobody can review, the process is not ready, however good the model is.
4. Ownership and success criteria
- A named owner for the process after go-live.
- Ten to fifty real examples, including awkward ones, to test against.
- A written definition of success, such as time per item or share of items needing correction.
What you should receive
A short written report: the processes reviewed, what blocks each one, and a scoped pilot proposal for the best candidate with its success criteria, review points, and the systems it will touch.