Audit & readiness
How to Prepare for an AI Project: Start With One Workflow
What to prepare before anyone picks a model: one mapped workflow, a measured baseline, a check of data and permissions, and a decision register with owners.
In this guide6 sections
- Which workflow should you prepare first, and how does it really run?
- Baseline the workflow with a defined denominator
- Can your data, permissions and destination system support it?
- What does a prepared finding look like? A fictional supplier-onboarding case
- Write the test before you choose a tool or vendor
- Finish with a decision register, not a generic roadmap
- Sources
- Frequently asked
Preparing for an AI project starts with one workflow, not a model shortlist or a vendor demo. Map how that workflow really runs, measure it with a defined denominator, check the data, permissions and destination system it depends on, and write down the decision: fix the process without AI, test a bounded AI task, or defer until a blocking dependency is resolved. This is the evidence a company brings to an AI Transformational Audit or an AI Readiness Assessment, and it is useful on its own when an input turns out to be missing. It is not a financial audit, a certification or a legal assessment.
Which workflow should you prepare first, and how does it really run?
Pick one workflow that already costs you time and choose a start event and an observable end state. For supplier onboarding, record who receives the request, who checks the mandatory information, who authorizes the supplier and who creates the record. For each handoff, write down the input, the system, the owner, what the work waits for and where exceptions go. Separate the time someone spends working from the time the request sits waiting for another team.
If two teams describe the process differently, keep both versions and settle the difference against approved example records. Do not average incompatible versions into one readiness score. Your preparation file should show the uncertainty instead of hiding it behind a traffic-light dashboard.
Baseline the workflow with a defined denominator
Fix the measurement window and decide which requests count. Record completed, rejected, duplicate and still-open requests separately, so the denominator behind every average is visible. Measure elapsed completion time and staff touch time separately; less waiting is not automatically less salary expense. Publish the sample size and the number of missing timestamps next to any average.
When reliable logs do not exist, the first preparation step is to start recording them. A proposed savings estimate belongs in an assumption-based worksheet, not in the observed baseline. Never fill missing historical timings with numbers generated by a language model.
Can your data, permissions and destination system support it?
Prepare a small authorized sample, a field dictionary, a list of known errors and the source of truth for each field. Find out who can approve access, who can correct a record and who can authorize a write into the ERP or CRM. Confirm whether a safe test environment exists. A spreadsheet export proves the data can be read; it does not prove that a production integration is permitted or reliable.
Write down where the data would travel, who would receive it and which contractual or sector-specific questions are still open. Saudi Arabia's Personal Data Protection Law applies to processing of personal data in the Kingdom, including processing by a party outside the Kingdom of data about people residing in it (Article 2).1 NIST describes its AI Risk Management Framework as voluntary guidance for design, development, use and evaluation.2 It is a useful risk-management reference here, not a Saudi legal requirement or a compliance certificate.
What does a prepared finding look like? A fictional supplier-onboarding case
Assume fictional request SUP-DEMO-7 is delayed because a mandatory identifier is absent and nobody is named to chase it. No AI accuracy problem has been shown. Proposed decision: add required-field validation and assign an exception owner before testing extraction or classification. Expected next evidence: a request can no longer move on silently without that identifier.
If the identifier is present but staff keep misclassifying approved request descriptions, a classification test is a separate candidate. Define the allowed classes and a set of independently checked examples first. If nobody can agree on the correct class, defer the model comparison and clarify the policy. These are proposed branches, not findings from a client engagement.
Write the test before you choose a tool or vendor
For each AI candidate, write the input, the expected output, the error you cannot accept and the baseline you will compare against. OpenAI's evaluation guide recommends defining an objective, collecting a dataset and continuing evaluation as the application changes.3 Use that process as a reference; it does not establish a universal pass rate or require an OpenAI implementation.
Keep preparation separate from the bounded test that follows it. Preparation identifies the question and its prerequisites; the test generates evidence against written cases; a production implementation adds operating ownership and integration controls. Do not mark all three complete because a demonstration answered a few sample questions.
Finish with a decision register, not a generic roadmap
For each candidate, record the workflow boundary, the evidence references, the unresolved dependency, the decision, the owner and the next acceptance check. Use explicit decisions: process fix, bounded AI experiment or defer, and write down why a candidate was not selected. A ranked list without owners or failure criteria is not something a team can act on. For governance references, SDAIA's AI Ethics Principles (2025) include accountability and responsibility among their seven principles, and ISO/IEC 42001 specifies requirements for an organization's AI management system; neither turns this register into a certification.45
This register is what you bring to an AI Readiness Assessment or an AI Transformational Audit, and when you commission either, ask to see the expected document structure and how each finding is traced to evidence. The Readiness Assessment marks each dimension In place, Partial or Missing and ends with ready to build, or not yet; the Audit ranks what to build first across workflows and writes down every assumption behind an expected return. Neither document alone demonstrates return on investment.
ExhibitWhat to build first, ranked
Which candidate goes first? Each one is rated for impact and ease, gets a decision and an owner, and names the evidence that would settle it.
What to build first, rankedRasikh Holding · p. 9
| Candidate | Impact | Ease | Decision | Owner | Next evidence | |
|---|---|---|---|---|---|---|
| Required-field check at supplier intake | High | High | Process fix | Procurement lead | No request moves on without the supplier identifier | Pursue |
| Classify supplier request descriptions | Medium | Medium | Bounded AI test | Procurement and IT | Allowed classes and independently checked examples agreed | Explore |
| Predict onboarding delays | Medium | Low | Wait for the data | Procurement lead | One full month of complete timestamps | Defer |
Illustrative exampleRasikh Holding is fictional
The decisionFix the process before testing a model: the delay comes from a missing field with no owner, not from an AI problem.
Practical decision tool
Decision register fields to copy
- Boundary: start event, end state and excluded work.
- Evidence: source records, measurement window and known gaps.
- Decision: process fix, bounded AI experiment or defer, with reasons.
- Acceptance: next observable check, responsible owner and unresolved dependency.
SUP-DEMO-7 is fictional. This rubric is a proposed operational aid, not a measured result, financial audit or legal assessment.
Sources
Evidence review ·
Primary sources: regulators, standards and official documentation
- Personal Data Protection Law (amended, English text)SDAIARetrieved: November 6, 2026Official Saudi government source
- AI Risk Management Framework: voluntary use and scopeNISTRetrieved: November 6, 2026
- Evaluation best practices: objectives, datasets and continuous evaluationOpenAIRetrieved: November 6, 2026
- AI Ethics Principles — 2025 editionSDAIARetrieved: November 6, 2026Official Saudi government source
- ISO/IEC 42001:2023 — AI management systemsISORetrieved: November 6, 2026
Frequently asked
What should a company prepare before an AI project?
One workflow with a clear boundary, an evidence-backed baseline, a check of the data, permissions and destination system, and a decision register with owners and acceptance checks—not only a score or a slide deck.
Do we need to choose an AI model or vendor first?
No. Start with the operational problem and approved records. A process fix or a fixed business rule may be the right next step, and the model choice comes after the test cases are written.
What if we have no historical timing data for the workflow?
Record the gap as a finding and collect a baseline before claiming any improvement. Keep estimates visibly separate from observations.
Does this preparation establish Saudi compliance?
No. Legal and sector-specific applicability needs a qualified assessment of the actual data and workflow. The cited NIST framework is voluntary guidance.2
Related guidance
Reviewed on November 7, 2026
