AI Procurement Policy

An AI procurement policy determines how the organisation identifies, reviews, contracts for and activates AI capabilities obtained from suppliers. It must work when the purchase is called “AI”, when AI is embedded in ordinary software and when a supplier starts using AI to deliver an existing service. The commercial label should not decide whether a material capability receives review.

The policy's central job is to connect purchasing authority with operational permission. Signing an order, approving a supplier and activating a feature are related but different decisions. A company may have a legitimate reason to renew a business platform while keeping an optional AI function disabled until its information handling and operating conditions are resolved.

This guide helps Saudi procurement leaders, legal teams, technology owners and AI governance leads write that rule system. It provides proposed policy provisions and a worked renewal case. The provisions require adaptation to applicable procurement rules, contracts and sector obligations; they are not a claim that one universal approval process is legally required for every Saudi buyer.

Set the policy trigger around capability and consequence

Require the requester to identify whether AI contributes to the proposed service, which function it performs and what information or decisions it touches. Include new purchases, renewals, contract variations, free trials, bundled features and supplier-led changes. A feature with no additional licence price can still introduce a new processing route or authority boundary.

Distinguish a supplier using AI to prepare its bid from AI used in delivering the service. The UK's PPN 017 procurement guidance makes that disclosure distinction through optional information questions for its own public-sector context. Saudi organisations can use the distinction as a design insight while applying their own procurement requirements; the UK questions are not a Saudi legal mandate.

Define a practical escalation threshold. A minor administrative use within a supplier's existing approved arrangements may be treated differently from processing the buyer's confidential records or making decisions affecting customers. The requester should provide enough information for triage, and uncertainty should trigger clarification rather than a confident “no AI” response.

Write the purchasing rule before the questionnaire

A questionnaire collects facts; a procurement policy decides what happens with them. State which approvals are needed before a trial receives real data, before a contract commits the organisation and before a feature is activated. Identify the owner who can confirm each condition and the evidence that must accompany the decision.

A proposed core clause is: “Procurement must identify material AI capabilities in the proposed service and route them through the approved review before authorising the relevant commitment or activation. Conditional commercial approval must state any restriction on data use, feature enablement or production operation.” This clause needs a real workflow and delegated authorities behind it.

Do not assume procurement alone can approve every issue. The business sponsor owns the need and intended outcome; technical owners assess integration and operation; privacy and security owners address their domains; legal owners review contractual and applicable legal questions. The AI approval routes should show where those judgements converge and who can accept any remaining risk within their authority.

Use a policy schedule that survives different purchase routes

Proposed AI procurement policy provisions

Provision	Required operating behaviour	Record
Capability declaration	Identify AI functions, including optional and embedded features	Service and feature boundary
Controlled evaluation	Approve trial inputs, users and permitted actions before access	Evaluation permission and expiry
Evidence review	Assess relevant supplier claims and unresolved conditions	Evidence-linked review outcome
Conditional commitment	Make any commercial approval conditions explicit	Contract or order decision with restrictions
Activation authority	Enable the approved feature only when its conditions are met	Configuration and activation approval
Change and renewal	Reassess material changes and confirm continuing obligations	Updated scope and decision history
Exit and continuity	Plan records, access, data handling and replacement arrangements	Service-specific exit responsibilities

Apply the schedule to marketplace purchases and departmental subscriptions as well as large tenders. The level of evidence can be proportionate, but the decision should not disappear because the amount is small. If the buying system cannot record a conditional approval, use a linked controlled record and make the activation restriction visible to the administrator.

Keep the schedule aligned with existing financial authority. An AI review does not grant budget authority, and a budget approval does not establish that a data-processing activity is acceptable. Recording both decisions prevents staff from using one approval as a substitute for the other.

Worked example: renewing fleet software with an optional assistant

Consider a fictional company renewing an existing fleet-management platform. The renewal includes an optional assistant that drafts depot messages to drivers using scheduling information. The commercial team wants to preserve the established platform service. The AI review has not yet confirmed the assistant's input scope, support access or whether messages can be sent automatically.

The review separates the current platform from the proposed new feature. It asks the supplier and administrator to demonstrate whether the assistant can remain disabled while the existing service continues. Legal and procurement owners determine whether the renewal terms actually preserve that separation. A feature toggle alone cannot override a contract that introduces broader processing conditions.

Illustrative renewal decisions

Decision	Possible outcome in this example	Evidence or condition
Renew the existing platform	Proceed only if the authorised commercial review supports it	Terms and service boundary remain acceptable
Evaluate message drafting	Allow a separate controlled trial with approved sample information	Named users, no automatic sending and agreed inputs
Activate live-data assistance	Hold pending the relevant information and operating review	Feature-specific data path and access evidence
Enable automatic driver messages	Require a distinct action-authority decision	Sending rules, recipients, escalation and rollback arrangements

This is not a recommendation to renew every platform with an unresolved AI feature. It illustrates how to make the choices explicit. If the supplier cannot separate the feature or changes the baseline data handling, the renewal decision must consider that broader scope. The policy should preserve the unresolved condition instead of allowing the purchasing deadline to erase it.

After the decision, the application owner records the feature's disabled or limited state, the procurement owner records the contractual conditions and the sponsor receives a clear route for further review. The company has one coherent decision history rather than a contract marked approved and an administrator left to infer what that means.

Require evidence that answers the buyer's actual questions

The policy should identify evidence categories without turning every purchase into an identical document demand. Relevant topics may include service architecture, data handling, access, evaluation, change notification, incident cooperation and exit. The depth depends on the intended use and its consequences. A read-only drafting feature and an autonomous transaction service need different proof.

Ask for the evidence that supports the exact service edition and configuration being purchased. A supplier's company-wide certificate, generic model benchmark or demonstration from another environment may be useful background but leave the important question unresolved. The supplier evidence requirements should define how reviewers accept, qualify or reject an artefact.

Where a supplier cannot disclose certain detail, record what alternative assurance is available and what remains uncertain. Procurement should not quietly replace an unmet requirement with a marketing claim. The responsible decision owner can narrow the scope, seek additional assurance or decide that the purchase cannot proceed on the available basis.

Make commercial commitments match operational controls

Translate review outcomes into obligations that the parties can understand. If approval depends on a feature staying disabled, identify who controls activation and how a change will be communicated. If the service requires a specific data-use arrangement, ensure the relevant terms cover the actual feature rather than relying on a sales email about another product.

Distinguish an obligation from a technical capability. A supplier may contractually agree to notify material changes while the buyer still needs an owner to receive and assess the notice. A deletion clause may require a practical process for identifying data and confirming completion. The policy should assign those buyer responsibilities rather than treating contract signature as the end of governance.

Use legal review for the actual wording and remedies. This guide does not provide a universal indemnity, warranty or liability allocation. The governance contribution is to make the required behaviour and evidence clear enough for legal and commercial owners to negotiate a meaningful agreement.

Control trials and demonstrations before they become production

Require a trial record that names the question being tested, permitted inputs, users, duration, output audience and prohibited actions. Use synthetic or appropriately prepared material where it can answer the question. Real information should enter only through the applicable approval route, not because a supplier calls the environment a sandbox.

Define how a trial ends. The owner should account for access, connected sources, retained records and any decision to continue. A successful demonstration does not automatically authorise a wider user population or new sources. If the trial becomes part of daily operations, the production decision and operating owner must be explicit.

Watch for procurement bypass through free features. A department may activate a no-cost assistant inside an existing platform without an invoice. Give application owners a clear change-review duty and a route to procurement where terms or supplier obligations change. The purchased and embedded AI guide explains why feature governance must continue after onboarding.

Build renewal around changes, not repeated paperwork

Before renewal, compare the current service with the scope last approved. Review changes to features, model providers, data handling, support arrangements, users and action capabilities. Ask the business owner whether the service is being used as intended and whether outstanding conditions have been resolved. A fresh copy of an old questionnaire is not the same as a change assessment.

Prioritise material changes and deteriorating evidence. If an evaluation no longer represents the current feature, identify what needs rechecking. If the supplier's support route changes, route that issue to the relevant owner. The AI change-trigger design should define which changes require notification, review or a pause in a specific activity.

Keep a record of unchanged facts too when they matter to the decision. The purpose is not to force a new assessment of every item at every renewal; it is to show why previous evidence remains applicable and where it does not. This makes procurement proportionate while preserving accountability.

Handle urgent requests without losing the decision trail

An urgent business need should reach an authorised decision maker quickly, with the essential facts and alternatives. The policy can provide a fast route for a limited evaluation or temporary arrangement. It should identify which requirements cannot be waived and which conditions can be accepted by a named owner within their delegated authority.

Record the reason, duration, permitted information and stop condition. Do not describe a temporary exception as full supplier approval. The risk acceptance record and exception process can preserve the residual concern without allowing procurement staff to assume authority they do not possess.

Review recurring urgency as a planning problem. If every renewal reaches governance days before expiry, adjust the procurement calendar and supplier-notification obligations. A well-designed policy makes review predictable enough that deadlines do not repeatedly become the reason for incomplete decisions.

Close cancelled evaluations explicitly as well. Record whether access was removed, connected credentials were revoked and required trial records were retained or disposed of through the agreed process. A purchase that did not proceed can still leave an active trial account. Assign that closure to an owner instead of assuming that the absence of an invoice ended the service.

Control the handoff between reseller, supplier and administrator

A purchase may involve a reseller that invoices, a platform provider that operates the feature and an implementation partner that configures it. The policy should identify which party can make each commitment. A reseller's statement that a feature is disabled is not a substitute for configuration evidence from the responsible administrator, and a technical partner may not have authority to vary the provider's data-use terms.

Require the purchase record to name the contracting entities, operational contacts and escalation route. Map each important condition to the party responsible for delivering it and the buyer role that verifies it. If no party accepts responsibility for a condition, leave it unresolved. Do not let a chain of forwarded emails create the appearance of agreement where each participant assumes someone else owns the task.

In the fleet renewal, procurement would distinguish the reseller's renewal quote, the platform provider's feature terms and the application owner's disabled-feature evidence. If the optional assistant is configured by a partner, include that partner's handover responsibility. The buyer should be able to follow one condition from the commercial decision to the actual service state.

Make the purchase record useful at activation

Use a short activation schedule attached to the purchasing decision. It should list each condition, the required evidence, the verifying owner, the allowed interim state and the final disposition. This schedule gives the administrator something actionable instead of a contract folder containing conditions that are difficult to discover.

Suggested activation schedule fields

Field	Example in the fleet case
Condition	Message drafting stays separate from automatic sending
Evidence	Feature configuration and a controlled attempt to send
Verifier	Named application owner with business acceptance
Interim operation	Existing platform continues only within the accepted renewal scope
Reopening trigger	Supplier update changes the feature or activation behaviour

Do not use the schedule to manufacture certainty where the supplier cannot support the required separation. The correct outcome may be a narrower purchase, a revised agreement or a different service. The schedule's value is that it reveals this issue before staff assume the order authorises activation.

At project handover, procurement should confirm that operational owners received the continuing obligations, including notices, evidence refresh and exit support. The implementation team should confirm which conditions were tested and which remain open. Close the purchasing task only in the sense defined by the organisation; preserve unresolved operating conditions in a live system where they will still be seen after the purchase order is archived.

Measure whether the policy changes buying behaviour

Track material AI capabilities identified before commitment, trials that end with a recorded disposition, activation conditions verified and renewals with assessed changes. Report overdue decisions by the reason they are waiting. These measures are more informative than counting completed questionnaires alone.

Sample purchase records to check whether the approval can be followed through to the actual feature configuration. In the fleet example, the reviewer should find the contractual boundary, the limited trial decision and the administrator's activation record. If those disagree, the policy has not yet connected the commercial and operational processes.

Bring representative new purchases, renewals and embedded-feature changes to a governance setup discussion about AI procurement. AI governance setup can turn the policy into a practical set of decision routes, evidence requirements and handover responsibilities. The result should make it clear what the organisation has bought, what it has authorised and what remains conditional.