AI Governance for Purchased and Embedded AI

Purchased AI still needs an accountable operating owner. Embedded AI needs a visible feature boundary. When a supplier adds an assistant to an existing business platform, the organisation must decide what the feature may read, recommend and change, rather than assuming that the original platform approval covers every new capability.

This guide is for application owners, procurement teams and business leaders who govern AI inside software they buy rather than models they build. It addresses the period after supplier selection: feature discovery, activation, ownership, user instructions, change handling and withdrawal. The central question is whether the organisation can explain the actual use and exercise control over it.

The UK's AI procurement guidance explicitly recognises that AI can be built into wider technology products. That international reference supports looking beyond an “AI” purchase label; it does not set Saudi procurement obligations. The operating approach below is an original design for connecting existing application governance with AI governance setup.

Govern the feature and its use inside the platform

A platform record identifies the supplier and service, but an AI feature record should identify the function, users, inputs, outputs and authority. One expense system might classify receipts, explain policy and prepare payment instructions. Those functions share a vendor but have different consequences and review needs.

Link the feature to the parent application rather than creating disconnected inventories. Record which underlying services or models are relevant where the supplier provides that information, and preserve uncertainty where it does not. The buyer does not need to pretend it owns every technical component to maintain an accountable use record.

Use a stable identifier for the governed use. A marketing name can change while the underlying function remains, or the same name can acquire new capabilities. The AI inventory design should allow the owner to connect the current feature to earlier approvals, changes, incidents and supplier evidence.

Separate supplier responsibility from buyer authority

The supplier controls aspects of product design and delivery. The buyer controls its intended use, user groups, information selection and business decisions, subject to the actual service arrangement. Governance needs both sides. A supplier can document a capability without deciding whether the buyer should use it for a particular employment, customer or financial purpose.

Define who owns the business process, application administration, information sources and supplier relationship. The roles may be combined in a small organisation, but the decisions remain distinct. A platform administrator may be able to enable a feature technically without authority to approve the consequences of using it.

Document the handover between procurement and operations. The application owner should receive the approved scope, conditions, evidence references and change-notification route. A signed purchase record with no operational handover leaves the people running the service unable to explain what was actually authorised.

Create an activation record before users see the feature

The activation record should name the feature, environment, permitted user group, data sources, settings, output audience and excluded actions. State who verified each condition and what remains unresolved. Include a way to disable or restrict the feature and identify the business fallback.

Ask whether the supplier enables the feature by default, by administrator choice or through individual user action. The control design depends on that answer. If the buyer cannot prevent activation at the feature level, it may need a different contractual, access or platform decision. Do not write a policy that assumes a switch exists when the product does not expose one.

Activation record for purchased or embedded AI

Field	Practical content	Owner
Approved use	Task, audience and decisions the output supports	Business process owner
Information boundary	Sources, fields, attachments and derived copies	Information owner with relevant specialists
Configuration	Enabled functions, identities and integrations	Application administrator
Supplier conditions	Terms, evidence limitations and change obligations	Procurement or supplier manager
Operating response	Review, correction, pause and fallback	Service owner
Decision	Authority, conditions, date and review triggers	Designated approver

Keep the record close to the application's change process. Users should receive a concise explanation of what they may do, while administrators retain the detailed evidence. The approval-route design should prevent activation from becoming an unrecorded consequence of an ordinary software update.

Worked example: three AI features in an expense platform

Consider a fictional organisation whose purchased expense platform offers three AI functions. Receipt classification suggests a category. Policy explanation drafts an answer about an internal expense rule. Payment preparation suggests a payment instruction. The organisation must assess each use even though the functions appear in the same interface.

Illustrative boundaries for three expense-platform features

Feature	Proposed permission	Boundary that remains separate
Receipt classification	Suggest a category for an authorised reviewer	Final accounting treatment and approval remain with the normal owner
Policy explanation	Draft an answer from approved current policy material	Exceptions and disputed entitlement require the designated decision route
Payment preparation	Remain disabled pending a separate action review	Creating or releasing payment instructions is outside the initial approval

The buyer tests whether classification and explanation can operate without enabling payment preparation. It also checks whether the explanatory feature retrieves employee-specific claims or only the approved policy source. A service description that says “uses your expense data” is not specific enough to settle that information boundary.

In the proposed initial rollout, reviewers can correct categories and see the original receipt. Policy answers identify their source and preserve exceptions. The feature cannot approve an expense or create a payment. These are illustrative design conditions; the actual product must demonstrate support for them before the buyer relies on the boundary.

A later supplier update adds a button that turns a suggested category into a submitted expense. That is not merely a nicer interface. It changes the action available to users and may require a new decision about authority, confirmation and records. The original receipt-classification approval should not be stretched to cover it silently.

Inspect information paths hidden by a familiar interface

An embedded feature may send information to services different from those used by the core application. Ask about inputs, retrieval, model processing, output storage, telemetry and support. The familiar platform login does not prove that every stage shares the same handling arrangement.

Identify optional features separately, including feedback, conversation history, file upload and connected knowledge sources. A buyer may be able to narrow the information path through configuration, but only if that capability is documented and demonstrated. Record which settings are controlled by the supplier, administrator or individual user.

Derived information deserves attention too. A generated policy explanation can contain claim details, and a category suggestion can become part of a financial record. Determine where those outputs are stored and who receives them. The PDPL and AI governance guide addresses the relevant privacy decision process; a vendor's general assurance should not replace a feature-specific assessment.

Evaluate the buyer's use, not only the supplier's model

A product benchmark may be useful background, but the operating decision needs evidence for the buyer's task, source conditions and review process. For receipt classification, test ambiguous documents, incomplete scans and categories that look similar but carry different treatment. Include the cases where the system should decline to suggest a category or ask for review.

For policy explanation, test current and superseded rules, exceptions, conflicting sources and questions that require a human decision. The assistant should not turn an ambiguous policy into a definitive entitlement simply because a fluent answer is easier to produce. Record what the reviewer must inspect before relying on the answer.

For any action-capable feature, evaluate authority and outcome handling separately from text quality. A well-written payment instruction is not evidence that the service should create or release it. Use the agentic AI governance approach when tool use or autonomous execution becomes part of the purchased capability.

Make correction and challenge part of the workflow

Users need a way to correct an AI suggestion without losing the original record or creating an unexplained overwrite. Define which corrections are local to a transaction, which update a shared knowledge source and which are sent to the supplier as feedback. Those are different processing activities with different owners.

In the expense example, a reviewer may correct a category for one receipt. That does not automatically establish a new organisation-wide classification rule. A disputed policy explanation should reach the policy owner, who can determine whether the source is unclear or the model misread it. The feedback loop should preserve that distinction.

Explain how affected people can raise a concern where the output influences their work or treatment. A simple “report an issue” button may be useful, but the organisation needs a response owner and a route for decisions outside the supplier's authority. The supplier should not become the final judge of an internal expense exception merely because its software generated the explanation.

Govern supplier updates and automatic feature changes

Record how the buyer learns about updates: release notes, administrator notifications, contract notices or direct account communication. Assign someone to assess material changes, not merely archive the message. The change owner should compare the new capability with the approved task, information and action boundary.

Ask which changes can be deferred, configured or disabled. Some services allow version choice; others update centrally. Governance should reflect the actual options. If a material change cannot be deferred, the buyer may need to pause a particular use, narrow access or activate a fallback while evaluating the new conditions.

The change-trigger design should include changes in supplier processing, providers, source connections, audience and authority. A model name remaining constant does not prove that the feature behaves identically, while a new model version does not automatically make every earlier control irrelevant. Assess the consequences of the actual change.

Monitor use without collecting everything

Choose operating signals that support a decision. Useful examples include unreviewed outputs reaching a final state, corrections to material categories, repeated unsupported policy answers, unauthorised feature activation and unresolved supplier notices. Define who reviews each signal and what response it can trigger.

Avoid collecting complete employee prompts or receipt content by default when less intrusive records can answer the governance question. Determine the appropriate access and retention for activity records and investigation evidence. The monitoring design should protect the information it uses to protect the service.

Interpret metrics with context. A rise in reported corrections may reflect better user engagement rather than a deteriorating model. A low incident count may reflect an inaccessible reporting route. Compare signals with the workflow and evidence before presenting a simple green dashboard to management.

Prepare for suspension and supplier exit

Identify the narrowest useful pause. Can the AI feature be disabled while the core platform remains available? Can users return to manual category selection or the authoritative policy document? Test the fallback before relying on it. A governance policy that says “switch off AI” is incomplete if doing so unexpectedly interrupts essential non-AI operations.

Plan how to preserve required records when the feature is withdrawn. Export accepted decisions, source references, corrections and approval history in a usable form where needed. Do not assume generated outputs remain accessible after a licence or feature is removed. Clarify what the supplier retains and what the buyer must keep.

Separate service exit from historical investigation. Disabling the feature does not settle earlier disputed decisions or erase data-handling obligations. Assign those tasks explicitly, with appropriate specialist review. The incident response plan can coordinate investigation while the application owner maintains business continuity.

Translate the activation record into user instructions

Give employees a short buyer-owned summary of the activation record: what became available, to whom and under which conditions. Identify the feature, account or tenant, permitted functions, information scope and support owner in language they recognise. Keep that summary connected to the controlled decision without making employees read the entire procurement pack.

In the expense-platform example, the user summary could state that receipt classification is advisory, policy answers require a source check and payment preparation remains disabled. Those are three separate operating statements. A platform-level “AI enabled” flag would not tell an expense reviewer which suggestion they may accept or an administrator which action must remain unavailable.

Have the business owner and administrator reconcile the summary with the interface before announcing availability. Check what an ordinary user actually sees, which buttons are present and which sources the feature can reach. If the interface exposes a broader capability than the approved record, resolve the mismatch rather than relying on a general email asking staff not to use it.

Make the summary discoverable from the employee's approved-tool guidance. Include a named contact and a clear example of when to stop. When the scope changes, update the summary and tell the affected users what changed in their work. A release note about improved AI may not explain that a button now submits a transaction.

Keep corrections separate from supplier learning

Define how users correct a wrong classification or explanation. The business record should preserve the accepted result and, where needed, the reason for override. Separately establish whether a correction or feedback button sends information to the supplier, affects a shared model or remains within the buyer's environment. Ask the supplier to explain the actual feature rather than assuming the word “feedback” has one meaning.

For the expense use, a reviewer may correct an advisory category while leaving the original receipt intact. The correction should not silently create a new payment authority or change an approved expense policy. If users repeatedly correct the same category, route that pattern to the feature owner to investigate the source, configuration or suitability of the task.

Do not instruct reviewers to accept suggestions merely to improve an adoption target. Track whether the feature helps produce accurate, reviewable work and whether correction burden is manageable. A low acceptance rate may identify a poor fit, an unclear task or cautious users; the number alone does not distinguish those causes.

Test suspension while preserving essential platform work

Before relying on a purchased feature, ask how it can be suspended without disrupting unrelated operations. Test the supported configuration in a controlled environment and identify dependencies. Do not assume an AI toggle affects every related component or that disabling a visible assistant removes an underlying connection.

In the illustrative platform, the business may need ordinary expense submission to continue while the new AI submission button is reviewed. The application owner should establish whether that separation is technically and contractually supported. If not, the continuity plan must address the wider consequence; governance should not promise an isolation capability the supplier does not provide.

Document what happens to unfinished work. A suggested category, a draft explanation and a prepared payment record have different states. Name the owner who checks whether any pending item became a live transaction and who tells users how to proceed. A feature being unavailable is a service condition; an uncertain financial action needs reconciliation through the established financial process.

After suspension, confirm which sources and credentials remain connected and which records must be retained. Keep the evidence needed for investigation and business continuity under the applicable rules. A request to erase all AI-related material may be inappropriate if it destroys the record of a decision that still needs review.

Include affected users in the continuing review

Ask users where the feature's boundary is hard to understand. Can they distinguish a suggestion from a submission? Do Arabic labels preserve the same action meaning as English labels? Can a person find the policy source behind an explanation? These questions reveal operating problems that a supplier capability checklist may miss.

Use a small sample of completed and corrected tasks to improve instructions and configuration. Explain the sample's scope and keep personal information limited. The purpose is to learn whether the approved use still works as intended, not to create a hidden performance score for every employee who declines an AI suggestion.

Review the whole ownership arrangement periodically

Check whether the named owners still exist, whether the feature is used for the approved task and whether supplier conditions remain satisfied. Changes in staffing or process ownership can weaken governance even when the software does not change. Reassign responsibilities before records become orphaned.

Review a sample from activation through output correction and final business decision. Can the organisation explain which source and feature version supported the result, who reviewed it and what authority allowed the final action? The level of detail should match the consequence, but the path should be reconstructable.

Bring an application inventory, recent supplier updates and a few disputed feature boundaries to a governance setup discussion about purchased AI. A practical governance arrangement will connect the product contract, activation settings, employee instructions and operating ownership. That is how a purchased capability becomes an accountable part of the business.