AI Use Case Classification Framework

An AI use case classification framework decides how much scrutiny a proposed use needs and which approval route applies. It should classify the activity in context: what the system does, whose interests it affects, the information it uses and how much authority it exercises. Labelling every chatbot low risk and every agent high risk is too crude to support those decisions.

For Saudi governance teams, the useful output is an explainable internal routing category with supporting facts, unresolved assumptions and review obligations. That category must remain distinct from any applicable legal or regulatory classification. An organisation can create a proportionate internal framework without presenting its own labels as official Saudi risk classes.

This guide provides an original operating framework for AI governance setup, illustrated by three versions of a shift-roster assistant. It is designed for reviewers who need consistent decisions across business units while preserving the specific consequences of each use.

Classify the use and deployment, not the model name

The same model can explain a published staff roster, recommend changes or automatically assign overtime. The model family may be unchanged while authority and consequences change substantially. Conversely, a simpler predictive model can influence a consequential decision. Begin with the task, people affected, output consumer and permitted actions before considering technical complexity.

Record whether the output is information, a draft, a recommendation, a ranking, a decision input or an executed action. Then ask what happens next in the actual workflow. A nominally advisory ranking may determine which cases receive attention if staff rarely inspect the full list. Human involvement should be described as observed work with time, information and authority, not a checkbox labelled “human in the loop”.

The OECD framework for classifying AI systems examines several dimensions, including people, context, data and outputs. The internal routes proposed below are our practical design; they are not a reproduction of an official scoring instrument or a statement of Saudi law.

Use consequence dimensions before assigning a tier

Describe potential consequences for people, operations, finances and information. Consider severity, reach, duration and reversibility separately. A small number of affected people does not make serious individual harm negligible. A reversible technical transaction can still produce an irreversible disclosure or a missed opportunity.

Dimensions for an internal AI use case classification record

Dimension	Review question	Evidence to request
Decision consequence	What changes if the output is wrong or ignored?	Workflow and affected decision
People and access	Who benefits, who bears error and who can challenge?	User and affected-person map
Information exposure	What inputs, outputs and derivatives may be disclosed?	Data-flow and permission boundary
Action authority	Can the system commit, communicate or change records?	Tool permissions and approval points
Scale and reversibility	How far and how quickly can an error propagate?	Volume, distribution and recovery design
Uncertainty	Which claims remain untested or supplier-controlled?	Evidence gaps and their owners

Keep the narrative explanation alongside any score. A value of “3” is not enough to tell a reviewer whether the concern is harmful allocation, confidential disclosure or operational interruption. The explanation should identify the event and affected party so later controls can be tested against the actual concern.

Separate inherent exposure from proposed controls

Describe the consequence of the use before relying on mitigating controls, then document what the proposed controls change. Otherwise a team can classify a consequential use as routine because it promises that every output will be checked, without establishing whether reviewers can perform that check reliably.

For example, manual approval may reduce the chance of an erroneous overtime assignment being executed. It does not remove the effect of a biased recommendation on the supervisor's attention. Access filtering may reduce disclosure risk, but it needs evidence for the actual identity and derived copies. Record the control, its implementation status and what residual exposure remains.

Use the AI impact assessment for a deeper examination where consequences warrant it. Classification selects the review route; it should not pretend to replace all the assessment work that route requires. A concise classification with a clear escalation can be more useful than a long scorecard built on unverified assumptions.

Define routes through review obligations

Labels become useful when they change work. An illustrative routine route can require a known owner, permitted inputs, a bounded purpose and standard controls. An enhanced route can add specialist review, representative evaluation and evidence of human oversight. A reserved route can require designated senior authority, impact analysis and explicit operating limits. A hold state can preserve material uncertainty or an unresolved prohibition.

Illustrative internal routes, to adapt to the organisation

Route	Typical decision need	Required outcome
Routine controlled use	Confirm a narrow use inside established conditions	Named owner and recorded boundary
Enhanced review	Resolve meaningful consequence or control questions	Specialist conclusions and evaluation evidence
Reserved authority	Consider consequential use outside ordinary delegation	Explicit authorised judgement and conditions
Hold for resolution	Clarify material unknowns or a potential restriction	Evidence or determination before progression

These are internal workflow names, not legal categories. Map them to the approval routes and actual delegated authorities. A classification officer should not create new power for a business owner simply by assigning a lower label. Where law or sector rules impose a separate requirement, record that requirement independently.

Use escalation rules that cannot be averaged away

Weighted scores can help organise discussion, but averaging can conceal a decisive condition. A high score for convenience, mature infrastructure or good documentation should not cancel an unresolved authority to make a consequential decision. Define specific escalation triggers whose presence requires a designated route regardless of the overall numerical result.

Candidate triggers include direct execution of material transactions, effects on access to important services, safety-related operation, broad disclosure potential or inability to identify an accountable owner. Their exact definition depends on the organisation and applicable requirements. Give reviewers examples at the boundary and a process for asking for interpretation.

Unknowns should not automatically receive the lowest score. Mark the affected dimension unresolved and explain which decision it blocks. Some unknowns can be resolved during an authorised discovery stage; others prevent even a proposed pilot using real data. The distinction should follow the exposure created by the next step, not the team's desired timeline.

Worked example: three shift-roster assistant versions

Consider a fictional employer evaluating a roster assistant. Version A explains a published roster to an authenticated employee, limited to information they may already view. Version B recommends swaps and overtime allocations to a supervisor. Version C executes allocations and updates staff records automatically. These are three proposed uses, not successive approvals earned simply by improving the model.

For Version A, reviewers examine access, source currency and whether explanations can misstate obligations. A routine route may be appropriate if established conditions demonstrably cover those questions. If employees can obtain another person's restricted details, that unresolved access issue changes the route even though the function only answers questions.

Version B introduces allocation consequences. Reviewers need to understand who may receive less desirable shifts, how constraints are represented and whether supervisors have enough information to challenge recommendations. The internal framework sends it to enhanced review in this example. That is an operating choice based on the described task, not a universal legal conclusion about scheduling software.

Version C adds action authority and faster propagation. It needs evidence of permitted transaction scope, exceptional cases, recovery and the authority to approve automated allocation. The example reserves this decision to a higher delegated level. A high-quality explanation benchmark from Version A does not establish these conditions.

How the same assistant family produces different review needs

Version	New consequence	Evidence that changes the decision
A: explain a published roster	Misleading explanation or disclosure	Source validity and permitted employee view
B: recommend allocations	Influence on distribution of work	Constraints, affected-person analysis and supervisor challenge
C: execute allocations	Committed changes at operating speed	Action authority, bounded permissions and recovery

Keep separate records for the approved use and the proposed expansion. If Version B is permitted, Version C remains outside that boundary until its own conditions are met. The change-trigger process should detect the addition of execution even if the supplier describes it as a minor feature release.

Capture human oversight as a testable design

Ask who reviews, what they see, when they can intervene and whether they can reject the recommendation without unreasonable effort. A supervisor who receives only a final score may not be able to judge whether the roster constraints were respected. A reviewer given hundreds of proposals moments before execution may have nominal authority but inadequate time.

Specify the decision evidence available to the reviewer: relevant source facts, uncertainty, alternative options and the reason an exception was flagged. Observe a representative exercise to determine whether the review actually catches the failure types that matter. Do not transfer a claim of effective oversight from a demonstration with ideal examples to the full workload.

Classification can change when the oversight design changes. Removing a review step, changing reviewer incentives or concealing supporting information can increase exposure without changing the model. Link these changes to the responsible owner and require reassessment of the affected dimension.

Calibrate reviewers with contrasting cases

Give reviewers pairs of similar cases with one meaningful difference. Compare an internal summary with a customer-facing explanation, a recommendation with an executed transaction, and a small restricted group with unrestricted distribution. Ask them to state which fact changes the route and which facts remain irrelevant.

Track disagreements by dimension rather than forcing an immediate consensus tier. One reviewer may interpret “approval” as checking every input while another assumes a quick glance. Resolve that factual mismatch before changing the score. Maintain a short decision guide containing the interpretation and evidence that distinguish adjacent cases.

Periodically review whether assigned routes match observed incidents, overrides and implementation difficulty. An absence of reported problems is not proof that the classification was correct if reporting itself is weak. Use feedback to improve the rules while preserving the original classification and the reason for any revision.

Make classification durable through the lifecycle

Store the use-case identifier, deployment boundary, classification version, reviewer, evidence date and unresolved assumptions. Link the outcome to the AI inventory so procurement, operations and change management can find it. A classification in a slide deck that cannot be tied to the deployed feature is difficult to enforce.

Define reassessment triggers for changed purpose, users, data, model behaviour, tools, geography or scale where they affect the risk reasoning. Review supplier-controlled changes when notification arrives, and establish a way to discover changes that are not clearly announced. A calendar review can complement these triggers but should not be the only mechanism.

When retiring a use, record whether outputs, derived data or downstream decisions continue to matter. Decommissioning the model does not automatically eliminate the effects of earlier allocation decisions. Classification and inventory histories should support investigation and correction where needed.

Complete a classification decision note, not only a score

A short decision note can make the framework usable at intake. Record the proposed function, the most consequential plausible failure, the affected party, the decisive dimension and the route selected. Add the evidence reference, unresolved assumptions and the facts that would change the route. This note is the bridge between a questionnaire and the review obligations that follow.

For the roster recommendation use, the note might state that the assistant influences allocation of work, that supervisors receive explanations and alternatives, and that oversight capacity remains to be demonstrated. The enhanced route follows from the consequence and the unverified oversight assumption. It does not follow merely from the word AI or the presence of employee data.

Example classification note for roster recommendations

Field	Illustrative entry
Function	Propose swaps and overtime allocations for a supervisor
Consequence	Recommendations may affect how desirable and undesirable work is distributed
Decisive question	Can the supervisor recognise and reject unsuitable recommendations?
Current evidence	Workflow description available; realistic oversight exercise still required
Route	Enhanced review under this internal design
Reclassification trigger	Automatic execution, changed affected population or weakened review

The note should remain understandable without opening every supporting file. At the same time, each material statement should be traceable to its source. If the reviewer later learns that recommendations are automatically accepted after a timeout, the note makes clear why the authority and oversight dimensions must be reconsidered.

Resolve classification disputes without shopping for a lower tier

Allow a sponsor to challenge a classification by supplying corrected facts, new evidence or a reason that a rule was applied incorrectly. Identify the reviewer or forum authorised to resolve the challenge. The process should be transparent enough that a team does not need informal access to a senior executive to obtain a fair interpretation.

Preserve the original classification while the challenge is considered and state what activity remains permitted. A disagreement about whether the recommendation is consequential should not automatically authorise deployment. Equally, an unnecessarily broad classification should be correctable without forcing a project to complete reviews irrelevant to its actual use.

Record the resolution as an interpretation that can improve future consistency. If two departments use the same roster tool differently, the outcome may legitimately differ. One supervisor may make a documented independent choice, while another process may treat the recommendation as the default allocation. The framework should recognise that factual distinction rather than force identical tiers for identical software.

Check for incentives that distort the information supplied. If a lower tier is associated with faster access to funding, teams may describe actions as advice or omit affected groups. Counter this by reviewing the actual workflow and making proportionate routes workable. A classification process that rewards accurate disclosure is more reliable than one that treats a higher route as a project failure.

At periodic calibration, examine a small set of challenged decisions and their outcomes. Look for unclear definitions, inconsistent evidence expectations and rules that add review without changing protection. Improve the framework through controlled revisions and preserve the versions used for earlier decisions, so consistency grows from learning rather than from silently rewriting history.

Avoid turning the framework into a scoring contest

Do not reward teams for obtaining the lowest category. Reward clear facts, early identification of consequential changes and completion of the review appropriate to the use. A higher route can be the correct result for a valuable project; it is not necessarily a failure or a reason to hide the proposal.

Keep the framework compact enough for consistent use but supported by specialist escalation. Too many overlapping dimensions encourage arbitrary scoring; too few hide important distinctions. Test whether a reviewer can explain the route in a short paragraph tied to evidence, and whether the assigned obligations actually address that explanation.

The handover should include the classification questions, internal route definitions, non-averaging escalation rules, calibrated examples, authority mapping and change process. Discuss an AI use case classification framework with Open for AI using contrasting uses from your organisation. The useful result is repeatable review depth grounded in consequences, with legal applicability and internal judgement kept explicit.