AI Intake and Review Process Design

An AI intake process turns an idea, newly discovered tool or proposed change into an owned review case. It should tell the requester what information is needed, tell reviewers which decision they are making and keep unresolved work visible. A form that sends an email to several departments is only the front door; the process also needs states, routing rules, evidence handling and an accountable queue owner.

This guide helps governance leads and operations managers design that process for a Saudi organisation. The practical goal is predictable handling: simple uses receive proportionate review, consequential uses reach the appropriate specialists, and incomplete requests cannot acquire an implied approval by waiting long enough. It forms the intake layer of AI governance setup.

Choose an intake unit that reviewers can actually decide

Use a defined business use case and intended operating boundary as the primary unit. “Introduce AI to finance” is not reviewable. “Produce a draft explanation of travel-expense exceptions for a finance officer, using approved fields, without updating claims” gives reviewers a purpose, user, input and output to examine. One purchased product may support several use cases with different consequences.

Give the case a stable identifier and associate it with the product, business process, data sources and proposed deployment. Avoid making the supplier name the unique key. The same supplier can supply a harmless drafting feature and a consequential decision feature. An identifier should survive changes in project name, ownership and commercial packaging.

Provide entry routes for new ideas, procurement requests, embedded features discovered after purchase and changes to existing uses. They can share a record structure while asking different initial questions. Discovery of an unregistered use should record what is already happening, not force staff to pretend that it is merely a future proposal.

Keep the first form short and make uncertainty answerable

The first submission should establish enough context to route the case. It should not require a completed impact assessment before a requester knows which assessment is appropriate. Ask for the business purpose, intended users, affected people, proposed inputs, output use, supplier or technology if known, current stage, accountable sponsor and requested next step.

For each question, allow an explicit unknown with an owner and a discovery action. An unselected checkbox must not be interpreted as absence of personal data or absence of automated actions. Use clear language: “Can this system change a record, send a message or execute a transaction?” is more accessible than asking a nontechnical requester to classify agentic autonomy.

Initial intake questions that influence routing

Question	Useful answer	Routing implication
What changes for the user?	Draft, recommendation, ranking or executed action	Identify consequence and authority review
Whose information enters?	Named categories and source owner	Identify privacy and access review
Who may be affected?	Staff, customers, applicants or other groups	Identify impact and challenge needs
Where is the proposal now?	Idea, purchase, pilot, operation or change	Separate prospective review from existing exposure
What decision is requested?	Discovery, pilot, deployment or scope change	Select evidence appropriate to the stage

The UK's Algorithmic Transparency Recording Standard guidance illustrates recording a tool's purpose and operating context. It is a UK public-sector instrument, not a Saudi intake requirement. The form proposed here is an original internal design that should be adapted to the organisation's obligations and decision structure.

Define states with entry and exit evidence

States should describe what is happening, not merely how optimistic the requester feels. Received means a record exists. Triage means someone is checking scope and routing. Awaiting information means specific questions have been assigned. In review means the required specialists are examining an agreed submission version. Ready for decision means the necessary opinions and evidence are available to the decision-maker.

Decision outcomes need their own distinctions: permitted within a boundary, permitted subject to preconditions, deferred, declined or withdrawn. Do not merge “review completed” with “approved”. A review can end by identifying that the request cannot proceed as described. Similarly, a withdrawn request is not evidence that the underlying deployed tool has been removed.

For every transition, identify who may perform it and what must be recorded. For example, a queue coordinator may mark a case ready for specialist review after completeness checks, but may not change a specialist's conclusion. The approval-route design determines who authorises a business step; the intake record carries that decision faithfully.

Route parallel reviews without losing their dependencies

Some questions can proceed in parallel. Security can examine the proposed connection while the business owner clarifies the intended user group. Other questions depend on a resolved fact: privacy cannot assess an undefined set of inputs, and a transaction owner cannot approve an unspecified action. Represent those dependencies explicitly rather than sending the same incomplete pack to everyone at once.

Use a routing table based on consequence, data handling, affected groups, supplier involvement and requested capability. The use case classification framework can suggest review depth, but it should not be the only signal. A supposedly low-impact use can still have an unresolved access boundary requiring specialist attention.

Require reviewers to distinguish observations, required corrections, conditional opinions and matters outside their competence. “Security reviewed” does not tell the approver whether security found a blocking issue. Ask each review to identify its scope, evidence version, conclusion and remaining dependencies. A consolidated decision pack should preserve disagreements rather than smoothing them into one green status.

Assign ownership of the queue and of each unanswered question

The queue owner maintains movement and visibility; they are not automatically the risk owner for every case. Each missing item should have a named role, an answerable question and an expected next action. “Waiting for business” is too broad when the actual gap is confirmation of which expense fields the summariser may receive.

When a case crosses departments, retain one coordination owner. Otherwise every team can believe another team is responsible for the next step. Use reminders and escalation for unowned or aged questions, but distinguish delay caused by workload from delay caused by unresolved authority. The remedy differs: adding a reviewer will not fix a missing data owner.

Give requesters a readable status view. It should show the current state, outstanding questions and what they may do meanwhile. It need not reveal restricted specialist evidence. A clear status can reduce informal side conversations that accidentally become parallel approval channels.

Worked example: an expense summariser becomes a write-back request

Consider an illustrative travel-expense team asking for an assistant that drafts explanations of unusual claims. The first submission identifies finance reviewers and a draft-only output, but lists inputs as “expense documents”. Triage returns a specific question: which fields and attachments are necessary, and which owner confirms their use? The case remains received and awaiting information; it has no pilot permission.

The sponsor supplies a field map that excludes unnecessary attachments and names the source owner. Privacy, security and operational reviewers now receive the same version. The operating reviewer asks how a disputed claim will be distinguished from a missing receipt. The applicant supplies examples and a human-review instruction. This additional evidence belongs to the same case because it clarifies the original drafting purpose.

Before the decision, the sponsor adds automatic updates to the claim status. That is a new action capability. The coordinator records a scope change and returns the affected part to routing. The previous evidence may still support the drafting function, but it does not establish authority, recovery or duplicate handling for write-back. The committee or delegated approver can decide the drafting boundary separately if the operating design makes that separation real.

How the intake record preserves the expense-assistant boundary

Event	Record treatment	What it does not imply
Inputs described too broadly	Specific information request with owner	No automatic low-risk classification
Field map and reviewer examples supplied	Versioned evidence added to original drafting case	No permission for every expense document
Claim-status updates proposed	Material scope-change branch	No inheritance of draft-only permission
Drafting approved within limits	Decision linked to exact version and conditions	No approval for autonomous write-back

The record should show the history without cloning the entire request into disconnected copies. Link the proposed change to the original case and identify which decisions remain valid. If the product cannot disable write-back separately, the apparent separation is not an available operating option and the decision must reflect that constraint.

Design timing measures that expose waiting

Measure elapsed time from a defined event and retain time in each state. A service target for initial triage can start at receipt; a specialist-review target can start when the agreed evidence is complete. Report both. Otherwise a team can appear fast by delaying the moment it labels a request review-ready.

If the process pauses a target clock while awaiting the requester, record the reason and duration. Do not erase that waiting from the user's end-to-end experience. Separate active review, requester waiting, supplier waiting and authority escalation. These categories reveal whether the process needs clearer forms, better supplier evidence or more decision capacity.

Age the open queue as well as reporting completed cases. A median calculated only from completed reviews can look healthy while difficult cases remain unresolved. The governance metrics guide explains how cohort and state definitions change interpretation. Use the measures to improve the route, not to pressure reviewers into favourable conclusions.

Keep evidence versioning and access proportionate

Store controlled references to evidence rather than copying every source record into the intake tool. A reviewer may need a redacted example, synthetic test or supervised demonstration rather than unrestricted access to operational data. Define who can see the initial form, specialist comments, decision and supporting material, and avoid exposing sensitive content through notification emails.

When a material document changes, capture what changed and which reviewers must reconsider their opinion. A new supplier processing arrangement can invalidate an earlier conclusion even if the use-case title is unchanged. The AI change-trigger design should define that re-entry path after approval as well as during intake.

Retain the evidence and decision versions needed to reconstruct why a case progressed. A live document link alone is insufficient if later edits replace the relevant content. Choose retention and deletion rules with the responsible records and privacy functions; the intake system itself can contain confidential information and personal data.

Provide paths for duplicate, abandoned and already-running uses

Duplicate requests should be linked and reconciled, not silently deleted. Two business units may use the same tool with different data and consequences. Merge only when the review boundary is genuinely the same, and preserve each affected owner. A shared platform approval may simplify evidence collection without authorising every use.

For abandoned requests, record whether any purchase, trial account, data upload or integration remains. Closing a governance ticket does not deactivate a system. Assign operational cleanup where necessary and retain evidence of what was actually stopped. The AI inventory should reflect the resulting lifecycle state.

For an already-running use discovered through intake, distinguish immediate containment questions from the retrospective review. Record what is known, what continues, who owns the decision and whether a restricted interim boundary is authorised. Avoid punishing disclosure through unnecessarily confusing forms; staff need a credible route to make existing exposure visible.

Test routing with cases that disagree at the edges

Before launch, ask different coordinators to route the same small set of realistic cases. Include a purchased feature, a low-consequence drafting use with personal data, a high-consequence recommendation without personal data, a supplier update and an unregistered live use. Compare the rationale, required reviewers and unresolved questions, not just the final colour or tier.

Where coordinators disagree, improve the question or decision rule. Do not simply instruct them to remember the preferred answer. Record examples that distinguish adjacent routes and use them in role-specific training. Revisit the examples when new technologies or business processes expose a missing boundary.

Acceptance should demonstrate that a requester can submit, receive specific feedback, supply evidence, reach the proper authority and understand the outcome. Test a declined and a withdrawn case as well as a successful one. The process must handle the whole lifecycle of requests, not only an ideal proposal with a supportive sponsor.

Use conditional questions without hiding the full request

A branching form can reduce effort by asking detailed questions only when a relevant capability appears. If the requester selects that the system sends messages, reveal questions about recipients, confirmation and correction. If it only drafts material, ask how that draft reaches a reviewer. Keep the initial question broad enough to capture indirect automation through another workflow.

Retain the answers that led to the route. If a requester later changes “draft only” to “updates records”, the system should reveal new questions and flag the earlier routing for reconsideration. It should not silently keep the original low-effort path because the first submission was already assigned. The reviewer needs to see the changed answer and its date.

Test an “unknown” branch separately from “no”. Unknown supplier retention, unknown input categories or an unclear action boundary should create an assigned discovery question. The process can permit harmless fact-finding within its authority while preventing premature use of information whose handling has not been established.

Provide examples beside difficult questions, but avoid examples that imply the only relevant cases. A question about affected people should cover staff and suppliers as well as customers. Ask intended requesters to explain their answers aloud during a usability test. Their interpretation often reveals ambiguity that a specialist reading the form would miss.

Specify notifications, resubmission and closure receipts

Each important state change should produce a concise message tailored to the recipient. The requester needs the state, reason, required response and permitted interim activity. A specialist needs the scope and evidence version. The decision-maker needs a stable question and unresolved issues. Sending every participant the same full notification increases noise and may disclose material unnecessarily.

Illustrative intake messages for the expense-assistant request

Event	Message must make clear
Input boundary incomplete	Identify required expense fields and the source owner; no pilot permission is implied
Evidence resubmitted	Which questions are answered and which document version changed
Write-back capability added	The affected scope is rerouted; earlier drafting evidence remains bounded
Decision issued	Permitted function, exclusions, preconditions and the authoritative record

Make resubmission additive to the case history. Preserve the original received date and record a new evidence-ready event where appropriate. Resetting the whole case on every clarification can make performance appear better while obscuring how long the requester has actually waited. The queue should show both the current work and the accumulated journey.

A closure receipt should distinguish declined, withdrawn and approved outcomes. For withdrawal, ask whether any actual use or account remains and identify cleanup separately. For approval, direct the operator to conditions and release requirements rather than using an unqualified “completed” message. A clear receipt is part of implementing the decision.

Assign an owner for delivery failures. If a notification goes to a departed employee or an unmonitored mailbox, the process should not assume the required action was understood. Use acknowledgement where the consequence warrants it, and test the fallback for missing responses. A reliable workflow depends on the receiving role, not only on a message being successfully generated.

Hand over an operable intake service

The setup handover should include the field dictionary, state definitions, routing table, roles, notification rules, evidence-access arrangements, timing measures and tested cases. Name the person who maintains the route when a department reorganises or a new AI capability appears. Software configuration should be documented well enough that another authorised operator can administer it.

Start with a controlled scope and learn from real requests. Where the form repeatedly asks for information that never affects routing or decisions, challenge the field. Where reviewers repeatedly request the same missing evidence, improve the guidance. The process should become clearer without accumulating unrelated questions from every stakeholder.

Discuss AI intake and review process design with Open for AI using a sample of actual proposals, current approval responsibilities and the systems available for tracking work. The useful deliverable is a tested route from request to owned decision, with its waiting states and unresolved conditions visible.