AI Governance for Enterprises

Enterprise AI governance must connect common controls with decisions that remain specific to a business unit, legal entity or use. A shared platform can simplify technical oversight, but it does not make every activity using that platform equivalent. The operating model needs to show which evidence can be inherited, which conditions require local review and who can intervene when a shared component changes.

For Saudi groups with multiple subsidiaries, the difficult work is often at the boundary between central technology, group risk and local operations. Central teams may own the platform while local managers own customer commitments and source information. Governance should make those relationships explicit without sending every routine request to the same overloaded committee.

This guide develops a federated operating design through a fictional three-company group. It focuses on evidence inheritance, shared dependencies, local authority and coordinated changes. The enterprise policy framework addresses policy hierarchy; this page explains how the organisation makes the hierarchy work across actual services and decisions.

Use this federated design to scope enterprise governance setup around shared evidence and local decision authority.

Choose which decisions belong at group and local levels

Start by listing decisions rather than drawing an organisational chart. Shared platform configuration, access architecture and supplier change management may belong to a central service owner. The permitted business purpose, affected customers and commercial authority may belong to a local accountable role. Legal and sector questions need the appropriate specialist assessment for each entity and activity.

Decide where a group minimum is sufficient, where a local rule can be stricter and where a proposed departure requires escalation. A local team should not be able to weaken a shared security boundary simply by approving its own use. Equally, central platform approval should not create local commercial authority that the group service owner does not possess.

The NIST Govern playbook connects AI risk responsibilities with organisational governance. The federation design below is an original operating proposal: it assigns specific decisions and evidence relationships rather than claiming that a standard prescribes one universal enterprise structure.

Document the route for unresolved cross-boundary decisions. If two entities share a source and disagree about permitted access, an automatic majority vote may not resolve the underlying rights. Identify the authority needed and restrict the affected activity until the decision is properly established.

Worked example: one platform, three different uses

Imagine a fictional group with a wholesale company, a property-services company and a repair-services company. All use a shared assistant platform. Wholesale staff prepare account-reply drafts; property staff use an assistant that can update service-case categories; repair staff receive warranty-routing recommendations. Each use has different sources, users and action consequences.

The central platform team provides common identity integration, approved model configuration and a controlled service-change route. These are reusable pieces of evidence. The wholesale owner still defines which account information may enter replies and who approves commitments. The property owner still needs evidence that case updates stay within authorised categories. The repair owner still owns the distinction between routing and a warranty decision.

A central approval can therefore confirm a platform condition without authorising every local use. The local record references the relevant shared evidence and adds its own workflow conditions. The group can see the whole arrangement without requiring each company to repeat the same technical assessment independently.

Now suppose a planned retrieval change introduces suggestions from a common index. The platform team must identify which uses depend on that retrieval path and whether entity separation remains enforced. A successful test in wholesale does not establish appropriate results for property or repair users. The change needs a shared technical decision and the affected local acceptance evidence.

If the separation is uncertain, the authorised service owner can pause the affected shared capability while preserving approved manual or narrower routes. Resumption should not occur merely because the central change ticket closes. Each material condition needs its assigned verifier, and local activities must remain within their valid permission.

Build an inheritance map for common evidence

What can be shared and what remains use-specific

Evidence area	Potential common evidence	Local decision still required
Identity and access design	Shared authentication and role-enforcement configuration	Which people may access each source and act in the workflow
Supplier arrangement	Relevant contract and configured service facts	Whether the actual entity, use and information fall within that arrangement
Model evaluation	Common capability tests under a recorded configuration	Task, language and consequence-specific evaluation
Incident handling	Central detection, service pause and supplier coordination	Local affected parties, business fallback and specialist decisions
Change control	Versioned shared component and technical release evidence	Continued validity of the local permission and conditions

For every inherited item, record the scope, version, evidence owner and conditions under which it remains applicable. A local record should reference the common item rather than contain a stale copied paragraph. When the item changes, the reference makes it possible to find affected uses.

Inheritance is a reasoned relationship, not an automatic checkbox. A test performed with one identity or data boundary may not apply to another. State why the evidence supports the local claim and what supplementary check is needed. The documentation guide helps make these dependencies visible.

Use the inventory as a dependency map

The enterprise AI inventory should connect products, features, use cases, deployments, sources and accountable entities. This permits a question such as “which active uses depend on this model service and this retrieval configuration?” A flat list of vendor names cannot answer it reliably.

Give shared components and local uses stable identifiers. Record lifecycle state and the evidence relationship without forcing every component to become a separate business approval. The level of detail should allow impact analysis and accountability; excessive fragmentation can create an inventory that nobody can maintain.

Capture dependencies that are easy to overlook: a shared evaluation dataset, a common prompt component, a centrally managed connector or a supplier feature enabled through a group subscription. A change can affect several uses even if the local application code stays unchanged.

Define how the inventory learns about new uses and retirements. Connect procurement, service configuration and local owner attestations to the record. No single discovery tool should be assumed to find every business purpose or decision authority. Technical detection and local ownership evidence need to complement each other.

Delegate review while preserving escalation boundaries

Give local reviewers authority over defined categories of familiar activity, with evidence requirements and escalation triggers. The delegation should name what they may decide and what remains reserved. A local approval cannot substitute for a specialist conclusion that the reviewer lacks competence or authority to make.

Use intake design to route a proposal according to its actual characteristics. Standard uses can follow a proportionate path; cross-entity information, consequential actions or unresolved supplier evidence can trigger additional review. Avoid making the central team read every form merely to confirm that it belongs somewhere else.

Provide a service expectation for the central functions too. Local accountability is difficult when a unit cannot obtain a security answer or an authoritative contract interpretation. Record the handoff, requested decision and elapsed wait so capacity problems are visible rather than attributed to a supposedly resistant business unit.

Test a disagreement. If the local sponsor wants to proceed but a shared control owner cannot demonstrate a required boundary, the route should identify who can resolve the issue and what remains blocked. The decision-rights guide supports this design; a senior title alone should not be mistaken for unlimited authority.

Coordinate shared changes without losing local meaning

A central change notice should describe the capability changed, affected dependencies, evidence collected, remaining limitations and actions required from local owners. A version number and a general assurance that the update is safe are insufficient when the change affects source access or action behaviour.

Use the change-trigger design to distinguish a technical update with unchanged conditions from a material shift in purpose, information, users or autonomy. The decision should follow the effect, not the supplier's marketing label. A feature called a minor enhancement can introduce a new processing path.

Agree the order of approval and activation. Local review after the shared release may be too late if the feature is enabled by default. Where possible, preserve controlled opt-in or a bounded release and ensure that the affected units can maintain their approved state until their conditions are satisfied.

After activation, confirm that the intended configuration reached the intended units and that restricted units remained restricted. A central release record does not prove successful local enforcement. Retain rollback or pause authority appropriate to the shared service and reconcile pending work if the change is withdrawn.

Handle cross-entity incidents with one coordinated account

Assign central coordination for shared technical facts and local responsibility for affected workflows, information and counterparties. Maintain a common incident identifier with entity-specific implications where needed. This avoids several contradictory descriptions of the same underlying event without assuming that every entity has identical consequences or obligations.

The incident response plan should specify who can pause a shared component, how local teams receive instructions and how specialist communication decisions are reached. Local managers need to know whether they can continue a narrower activity; the central team needs timely evidence of local effects.

Protect access to the incident record. A group-wide summary can identify an affected boundary without giving every subsidiary unrestricted access to another entity's customer or employee information. The evidence model should support authorised review and a coherent management account at the same time.

Recovery should reconcile the shared repair with local permission. A platform fix may restore a technical condition while a local business still needs to check pending cases or complete a customer response. Keep these tasks separate and visible so the group does not declare all consequences resolved when only the common component has been repaired.

Report group exposure without averaging away a local blocker

Group reporting should show portfolio scope, dependency concentration, unresolved material conditions and the decisions required. The executive reporting guide explains the evidence path. A high overall completion rate should not conceal one local use operating beyond its authorised action boundary.

Show where a common dependency creates concentrated exposure. Several locally reviewed uses may rely on one unverified shared claim. Counting each use as separately controlled can create false confidence if every record inherits the same unresolved evidence. Conversely, one well-established shared control can reduce duplicate work when its scope genuinely applies.

Separate local implementation delay from central evidence delay and strategic disagreement. Management needs to decide whether to allocate reviewers, change the platform design or resolve an authority question. A single list of overdue units can encourage the wrong intervention and conceal the actual bottleneck.

State the evidence boundary for the report. Newly acquired companies, outsourced operations and supplier-enabled features may require discovery work. Treat their absence as a known limitation with an owner, rather than assuming the current register represents every AI activity in the group.

Onboard a new entity without inheriting an unsupported permission

When another subsidiary joins the shared platform, begin with an onboarding decision that identifies the local use and the common evidence it proposes to rely on. A shared security review may be relevant, but its applicability depends on the environment, configuration and responsibilities covered. Record the match and any differences before copying the central conclusion into the local file.

For the group example, imagine a newly acquired service entity wants to use the common assistant for warranty correspondence. Its source records contain different commercial terms and its local team has a different approval delegation. The platform evidence can still support appropriate shared technical claims. It cannot establish the correctness of those local terms or the authority to make a warranty commitment.

An entity-onboarding decision worksheet

Question	Central contribution	Local contribution
Which shared configuration is used?	Versioned platform evidence and change history	Confirmation of the actual local configuration and interfaces
Which sources and purposes apply?	Common source-handling requirements	Approved local collections, permitted purpose and business interpretation
Who may commit the entity?	Group delegation principles where applicable	Valid entity-specific authority and its limits
Who maintains the permission?	Shared-change notifications and platform responsibilities	Operating conditions, local evidence and response ownership

Test the handoff with a central change that has a different local consequence. A revised retrieval component may affect all entities, while the new subsidiary's warranty source makes one particular failure more consequential there. The local owner should receive enough information to assess that effect and a route for raising a blocking condition without needing to stop unrelated uses automatically.

Plan the reverse event as well. When an entity leaves the shared service, identify which permissions, access rights and evidence references cease to apply. Preserve the records needed for legitimate historical purposes under the relevant retention arrangements. The group should know who answers questions about a past decision after the operating relationship changes.

For acquisitions or reorganisations, avoid treating migration completion as governance acceptance. A successfully moved dataset or active account does not show that the receiving owner has accepted the purpose, delegation and conditions. Include a decision checkpoint that reconciles technical completion with local operating authority.

This onboarding and exit discipline turns federation into an explicit relationship between reusable evidence and local accountability. It supports growth while keeping the limits of each inherited conclusion visible to both the shared-service team and the business entity.

Prove the federation through end-to-end rehearsals

Test a local routine request, a cross-entity information request and a shared component change. Include the central owner and the relevant local decision roles. Observe whether evidence is reused correctly, whether authority is clear and whether a blocked condition remains blocked at the point of use.

Introduce an unavailable local approver or disputed inherited claim. The operating model should support an alternate or escalation without silently dropping the condition. Record the correction and repeat the relevant part of the exercise. A federation that works only when every designer attends is not ready for ordinary handover.

Agree who maintains the shared artefacts and who confirms local adoption. Central publication of a policy or workflow does not establish that every entity has adopted it through the appropriate authority. Handover should include current records, open conditions, maintenance ownership and the evidence that selected routes were exercised.

Discuss enterprise AI governance across your shared platforms and business units with Open for AI. Bring the group structure, key shared services and a recent cross-boundary decision. A useful setup should reduce unnecessary duplicate review while making local accountability and shared dependencies easier to see and manage.