AI Approval Routes and Decision Rights

AI approval routes define who may authorise a particular step, which other decisions must exist first and what evidence makes that authority usable. They prevent a familiar failure: several departments say they have reviewed a project, but nobody can identify who permitted its actual operating behaviour.

For a Saudi organisation, an approval route should connect AI use to existing business authority. A system that books a carrier, changes an employee record or communicates a contractual position is exercising a capability that already belongs somewhere in the organisation. Adding AI does not transfer that authority to the technical team or to a vendor's default configuration.

This guide is for governance leads, IT directors and process owners designing the decision mechanics within AI governance setup. It provides an original route design, a delegation record and a warehouse-booking example. It separates expert review, operational release and acceptance of remaining risk so each can be understood and tested.

Start with the action being authorised

Write the permission as a verb with a bounded object. “Run a draft carrier comparison for these warehouse users” differs from “book an approved carrier for eligible shipments”. Both differ from “change customs declaration information”. A project title such as logistics AI cannot carry these distinctions on its own.

Identify the stage as well: discovery, limited test, pilot, production operation, expansion or retirement. Approval to inspect synthetic examples is not approval to process live shipment records. Approval to operate within one site does not automatically extend to another site with different contractual or data-handling conditions.

The decision record should name the system configuration and relevant use-case version. If the same permission is reused for an updated deployment, the organisation should be able to explain why the change falls within the original boundary. Use the AI change-trigger process when it does not.

Distinguish expertise, authority and execution

A reviewer supplies a conclusion within their competence. A decision-maker authorises a business step within their delegation. An operator implements that authorised step. The same person may hold more than one role in a small organisation, but the responsibilities should still be distinguishable and conflicts addressed.

A security reviewer can conclude that a specified connection meets the assessed controls without approving the commercial consequences of a booking. A business sponsor can accept an operational tradeoff without declaring a privacy question resolved. A release engineer can verify that preconditions are present without acquiring power to waive them.

The NIST governance playbook discusses delegated authority and accountability. This route design applies those general concerns to specific organisational permissions; it does not prescribe a universal Saudi approval hierarchy. Record the actual delegation instrument and its owner rather than relying on job seniority alone.

Build a dependency map for the decision

List the decisions that must precede the requested step. For a carrier-booking assistant, these may include permitted data use, authorised supplier scope, spending or commitment authority, tool permissions and operational release conditions. Some can be assessed in parallel, but the final permission depends on their compatible boundaries.

Illustrative approval dependencies for a booking capability

Decision	What it establishes	What it does not establish
Data-use determination	Permitted shipment fields and recipients	Authority to place a booking
Commercial delegation	Eligible carriers and commitment limits	Technical enforcement of those limits
Technical control review	Identity, permissions and failure handling assessed	Acceptance of every business consequence
Operational acceptance	Owner, support and fallback ready for the defined use	Permission for unrelated workflow changes
Release authorisation	Required decisions and preconditions satisfied	A waiver of future change review

Check that the boundaries intersect. If data-use approval covers site A while the commercial approval covers sites A and B, the combined operating permission is not automatically A and B. A route that simply counts green approvals misses this incompatibility. The final record should state the common permitted scope and any exclusions.

Write delegation rules that survive absence and escalation

A delegation record should specify the role, decision types, operating limits, prerequisites, duration and escalation route. Identify whether subdelegation is permitted and how temporary cover is appointed. A deputy should not inherit broader authority merely because the usual approver is unavailable.

Define what happens when no authorised approver is available. The route may wait, use a valid alternate or escalate to the owner of the delegation. “Ask the most senior person online” is not a stable rule. Urgent containment may have a separate predefined authority, but it should not be confused with permission to introduce a new capability.

Keep the delegation reference connected to the responsibility map. The map says who performs and owns work; the delegation says which decisions that role may make. One does not substitute for the other. When the organisation changes, review both and preserve historical authority for earlier decisions.

Use conditional decisions without hiding the release gate

Conditional approval should be written so an operator knows whether work may start. A precondition blocks the specified step until verified. An ongoing condition limits operation after it begins. A follow-up recommendation is neither unless the decision explicitly makes it binding. Avoid prose that mixes all three under “actions”.

For an objective precondition, an authorised verifier can inspect evidence and record closure. For a condition requiring judgement, specify who must make that judgement. A screenshot showing a limit setting is not necessarily evidence that the limit is enforced during retries, concurrent requests or exceptional paths.

Record the release gate separately from the earlier conditional decision. This can be a lightweight entry confirming which preconditions closed, who verified them and which configuration is being released. The final gate should not reopen every settled issue, but it must detect incompatible or expired approvals.

Worked example: a warehouse carrier-booking assistant

Consider a fictional warehouse introducing an assistant that recommends and books carriers. Its proposed initial boundary covers approved domestic carriers and an existing shipment category. It may use specified shipment fields, while the warehouse team retains responsibility for dispatch. The example does not assume any special regulatory permission or an existing Open for AI customer.

The logistics manager holds authority to approve a bounded pilot within an established commercial limit. The data owner confirms permitted fields and recipient purposes. The technical owner demonstrates that the booking tool accepts only eligible carrier identifiers and that a timeout does not lead to a duplicate booking. Operations confirms who reconciles uncertain booking outcomes.

The manager can approve the pilot within that combined boundary. During preparation, a requester asks the assistant to alter customs declaration details to match a carrier's requirements. That action was not part of the reviewed workflow and belongs to a separate accountable process. The pilot delegation does not authorise it, even if the tool could technically edit the fields.

Decision rights in the illustrative warehouse case

Proposed action	Route	Required disposition
Compare eligible domestic carriers	Existing bounded review route	Confirm source and recommendation limits
Book within the defined pilot scope	Delegated logistics authority after preconditions	Record compatible approvals and release evidence
Change customs declaration information	Separate process and authority review	Keep outside the pilot permission
Retry an uncertain booking	Approved reconciliation procedure	Establish prior outcome before another commitment

If a booking's outcome is unknown, the operator should not infer failure and repeat the action automatically unless the approved design handles that case. The authority to book an eligible shipment does not include creating duplicate commitments. The decision route therefore connects business permission with demonstrable control of the action's result.

Define the effect of disagreement and vetoes

A required reviewer should be able to identify a blocking issue within their remit. Define how that issue is escalated and what evidence would resolve it. Avoid informal vetoes that have no explanation, owner or review route. Equally, do not allow an unrelated majority vote to erase an unresolved legal or specialist requirement.

Distinguish a factual disagreement from a choice about tolerable residual risk. If reviewers disagree about whether a tool can write to a restricted system, obtain evidence. If they agree on the remaining exposure but disagree about whether to proceed, use the delegated risk decision route. The risk acceptance record should name the exposure, limits and authority.

Record dissent and the final reason without overstating agreement. A decision may proceed with a documented minority concern where the authority and applicable requirements permit it. It should not claim unanimous specialist endorsement when the evidence shows otherwise.

Align technical permissions with the approved boundary

Approval is meaningful only if the released system can stay inside it. Translate the decision into permitted users, tools, records, recipients and transaction conditions. Ask the technical owner to show both allowed and denied paths. A broad service account can defeat a narrow written approval if the application does not enforce the intended boundary.

Include indirect routes. A model may not write directly but may produce commands that another component executes. A draft may be emailed automatically by a workflow outside the assistant. The approval map should follow the actual chain of actions rather than stop at the model endpoint.

When a condition cannot be enforced technically, examine whether an operational control is credible and observable. Do not assume that a policy sentence compensates for an unrestricted tool. The outcome may be a narrower use, stronger control or a decision not to enable the capability yet.

Keep evidence of decisions separate from mutable workflow status

A dashboard status can change as conditions close or expire. The underlying decision should retain its author, timestamp, scope, evidence version and reasoning. Avoid overwriting an earlier permission with a new one without preserving the sequence. Investigators and operating owners may need to know which boundary applied when an action occurred.

Use explicit invalidation rules. A decision may cease to support operation because its expiry is reached, a precondition fails, the supplier configuration changes or the use moves outside scope. The process should tell operators what to do when that happens: pause the affected action, use an approved fallback or obtain renewed authority.

Connect the decision to the AI inventory and the intake case. This allows a newly proposed change to locate the controlling permission instead of starting a disconnected review. It also helps retiring a system identify open obligations that survive shutdown.

Test the route with denied and unavailable paths

Rehearse a missing approver, conflicting scopes, an expired condition and a request beyond delegation. Have the actual roles process the case. A route that succeeds only when every person is present and every answer is favourable is not ready for routine operation.

Check that the requester understands the outcome. Ask them to describe which actions may proceed and which remain excluded. If they interpret a conditional decision as complete launch approval, improve the wording and implementation notice. Governance should not depend on the requester guessing the committee's intent.

For electronic workflows, test who can alter approval fields and whether administrative access can bypass required decisions. A workflow tool's flexibility is useful, but changes to authority rules should themselves have an owner and review record. Preserve a tested export or specification so the organisation can understand the route outside the tool.

Translate a permission into an executable grant record

After a decision, create a concise grant record that the implementation and operating teams can use. It identifies the principal or user group, permitted action, eligible objects, applicable conditions, effective period and controlling decision. This is a translation of authority into an operating boundary, not a new approval issued by the technical team.

For the warehouse pilot, the record could authorise the booking service identity to create bookings only for the specified domestic shipment category and approved carrier set. It would exclude customs-data changes and require the approved outcome-reconciliation procedure. The exact enforcement mechanism depends on the architecture; the record should state where each restriction is applied and how it is tested.

Decision-to-grant mapping for the illustrative booking pilot

Decision condition	Operating representation	Verification question
Approved carriers only	Controlled eligible-carrier reference	Is an unlisted carrier rejected through every action path?
Specified shipment category	Eligibility rule before tool execution	Can a changed or incomplete shipment bypass it?
No customs-data editing	Excluded action permission and interface	Can any indirect tool still perform the edit?
Reconcile uncertain outcomes	Pending state with assigned operator	Does a timeout trigger another commitment without checking?

Give the business owner an understandable description of the implemented limits. They need not inspect every configuration field, but they should be able to confirm that the technical interpretation matches the decision. Retain that mapping so a later permission change can identify which controls and owners it affects.

Define revocation for queued and in-flight actions

Revoking a permission is more complex than removing a button. A task may already be queued, an external call may be in progress or a completed action may await confirmation. Define what happens in each state and who reconciles the result. The business effect of a request can outlast the interface through which it was initiated.

For queued bookings that have not been committed, the approved design may cancel or hold them when the relevant permission is withdrawn. For a call already submitted to a carrier, the operator may first need to establish whether a booking exists. That reconciliation is different from authorising a new booking. The route should permit necessary containment and fact-finding without leaving the old capability broadly enabled.

Record effective time and scope of revocation, notify the affected operating roles and preserve evidence of enforcement. If the withdrawal concerns only one carrier, do not silently disable unrelated authorised work unless the containment decision requires it. If the boundary cannot be isolated reliably, the authority may choose a wider temporary pause with a documented reason.

Test a permission withdrawn while a request is waiting and while its outcome is uncertain. Ask the operator to distinguish cancellation, confirmation and a new commitment. This exercise reveals whether the approval route extends to real operating states or only to the moment of initial release.

Include revocation in handover responsibilities. An authorisation owner may change the decision, but a technical owner must implement it and an operational owner must manage outstanding work. A record saying “access removed” is incomplete if it does not address queued actions and externally committed results relevant to the withdrawn permission.

Deliver a route that people can operate

A complete handover includes the decision catalogue, dependency map, delegation records, condition types, evidence standards, escalation rules and rehearsal results. It should name the owner who maintains the route and the operating team that receives decisions. Keep the design aligned with existing procurement, change and risk processes so teams do not face contradictory instructions.

Review the route when new actions, business units or delivery models appear. The key question is whether existing authority and evidence still cover the proposed step. Adding more signatures is not always the answer; clarifying a missing decision or removing a redundant one can make the process both stronger and faster.

Discuss AI approval routes and decision rights with Open for AI using a concrete action your organisation wants an AI system to perform. The setup should make its authority, dependencies, implementation limits and escalation path explicit before that action becomes part of daily operations.