AI Readiness Audit for Saudi Businesses: What Evidence to Collect

Choose a start event and an observable end state. For a supplier-onboarding workflow, record who receives the request, checks mandatory information, authorizes a supplier and creates the record. For each handoff, identify the input, system, owner, waiting condition and exception path. Distinguish time spent working from time waiting for another team.

If staff describe different processes, keep both versions and inspect approved example records to resolve the difference. Do not average incompatible workflows into a single readiness score. The audit output should expose uncertainty rather than hide it behind a traffic-light dashboard.

Define the measurement window and which requests count. Record completed, rejected, duplicate and still-open requests separately. Measure elapsed completion time and staff touch time separately; a reduction in waiting time is not automatically a reduction in salary expense. Record the sample size and missing timestamps alongside any average.

When reliable logs do not exist, make instrumentation the first deliverable. A proposed savings estimate belongs in an assumption-based worksheet, not in the observed baseline. Do not fill missing historical timings with numbers generated by a language model.

Prepare a small authorized sample, a field dictionary, a record of known errors and the source of truth for each field. Ask who can approve access, correct a record and authorize a write. Confirm whether a safe test environment exists. A spreadsheet export proves data can be read; it does not prove that production integration is permitted or reliable.

Document where data would travel, who receives it and which contractual or sector-specific questions remain open. NIST describes its AI Risk Management Framework as voluntary guidance for design, development, use and evaluation. It is a useful risk-management reference here, not a Saudi legal requirement or a compliance certificate.

Assume fictional request SUP-DEMO-7 is delayed because a mandatory identifier is absent and the team has no named owner for requesting it. No AI accuracy problem has been demonstrated. Proposed decision: add required-field validation and assign the exception owner before testing extraction or classification. Expected next evidence: a request cannot silently proceed without that identifier.

If the identifier is present but staff repeatedly misclassify approved request descriptions, a classification experiment is a separate candidate. First define allowed classes and independently checked examples. If no one can agree on the correct class, defer the model comparison and clarify the policy. These are proposed branches, not findings from a client engagement.

For an AI candidate, specify the input, expected output, unacceptable error and comparison baseline. OpenAI's evaluation guide recommends defining an objective, collecting a dataset and continuing evaluation as the application changes. Use that process as a reference; it does not establish a universal pass rate or require an OpenAI implementation.

Keep the audit separate from the validation sprint. The audit identifies the question and prerequisites; the sprint generates test evidence. A production implementation adds operating ownership and integration controls. Do not mark all three complete because a demonstration answered a few sample questions.

For each candidate, record: workflow boundary, evidence references, unresolved dependency, decision, owner and next acceptance check. Use explicit decisions: process fix, bounded AI experiment or defer. Include the reason a candidate was not selected. A prioritized list without owners or failure criteria is not an executable handoff.

If you commission an audit, ask to see the expected document structure and how findings will be traced to evidence. Use the audit service link for scope, the validation link for testing a candidate, and the budget worksheet for your own financial assumptions. None of these documents alone demonstrates return on investment.