Turn an AI Policy Into a Working Approval Process

Turn your AI policy into a process with a clear request, a named decision owner, and evidence for each approval. Assess the actual use and data, attach conditions to a bounded pilot, and check those conditions before release. Keep the decision current through monitoring, change review, and an incident route staff can use.

Give staff a clear route for a new AI use

Start with a request people can submit through an existing service desk or work-management system. Give it a named receiving owner and a visible status. Staff need to know what information to supply and where to ask when they aren't sure whether a proposed use fits an existing approval.

The National AI Centre's AI-policy guidance asks organisations to define permitted uses, data rules, oversight, approval responsibility, issue reporting, and review. Use those decisions to design the request route and the actions it triggers. Adapt the wording to roles and processes your staff already recognise.

Ask the requester to describe the work, intended users, and output. Record the information the system will use, its proposed destinations, and any action it can take. Include the business owner and the improvement they want to test. A product name alone doesn't define the use.

Allow unknowns to become assigned questions. A team leader may know the workflow but not whether a supplier stores prompts or permits further training. The intake owner can route that question to procurement or the technical reviewer without asking the requester to invent an answer.

A recent CIO discussion about an AI governance committee asks how to stop meetings becoming a queue for repeated purchasing questions. Treat that as a process-design question, rather than evidence about all committees. Gather routine supplier and use information before the relevant decision meeting.

Include AI already embedded in licensed software. A new summarisation function or connected agent can change how staff use an existing product. Give those uses the same route into the register, even when nobody is buying another licence.

Choose the review path from the actual consequences

Define a small set of review paths that your organisation can operate. An approved pattern can cover a recurring use when its purpose, data, audience, and actions stay within documented conditions. A new use or an exception needs the relevant assessment before it proceeds.

Make someone accountable for confirming that a request fits the approved pattern. Don't let a tool's position on an approved list automatically authorise every input or action. Drafting public material and analysing private customer records can require different decisions within the same tool.

The National AI Centre's implementation guidance distinguishes organisation-wide governance from assessment of specific uses and calls for records of decisions, testing, incidents, and monitoring. That supports reviewing how the system operates in context instead of assigning a blanket decision to the product.

Assess who can be affected, what happens when the output is wrong, and whether staff can detect and reverse the consequence. Consider the sensitivity of the information, the reach of the output, and the authority the system has. Record why those factors lead to the chosen review path.

Keep prohibited uses and unresolved requirements visible. A request can need a different design, more evidence, specialist review, or a decision not to proceed. Give the requester the reason and the next available route rather than leaving it indefinitely pending.

Separate the review path from purchasing approval. Procurement may assess the supplier and commercial arrangements while the business owner assesses the proposed workflow. Link those records so both decisions can use the same evidence without making either approval stand in for the other.

Name the decision owner and specialist reviewers

For each use, name the business owner who accepts the operating purpose and proposed outcome. Name the technical owner who can implement, release, and stop the service. Confirm that both have the time and authority to do the work.

Use specialist reviewers for the questions within their remit. Privacy reviews the proposed handling of personal information. Security examines access and exposure. Other relevant advisers assess contractual, professional, or regulatory questions. Record their findings and any unresolved issue for the authorised decision maker.

The OAIC's commercial-AI guidance recommends checking suitability for the intended use, testing, human oversight, privacy and security risks, and access to personal information. It also describes privacy impact assessment and ongoing review. Bring the relevant privacy owner into the assessment early enough to change the design.

Write down who can accept the remaining risk and under what authority. A specialist's completed review doesn't remove a business owner's responsibility for how staff use the system. Equally, a sponsor's enthusiasm doesn't resolve a specialist question that the process requires them to address.

In a small company, the same person may hold several roles. Keep the decisions explicit and obtain outside expertise when the question exceeds the team's competence. In a larger company, identify when escalation needs an executive or committee and which decisions a delegated owner can make.

Give staff an owner during absences and a next decision date. Track where the request waits and what information would unblock it. A proportionate process needs review capacity as well as a written requirement for review.

Turn approval conditions into operating controls

Write conditions that the delivery team can implement and demonstrate. If approval permits an internal draft from a defined source collection, specify that collection, the users who can access it, the reviewer, and the allowed destination of the draft.

Keep access enforcement outside the model's discretion. The application should supply only permitted records and expose only approved operations. A prompt telling the assistant to respect policy can't substitute for a source connection that grants broader access.

Translate human oversight into an actual task. Show the reviewer the evidence and proposed output, give them authority to reject it, and provide a route to correct a failed case. Define what happens when the reviewer is unavailable or the queue exceeds its capacity.

Set the pilot population and operating boundary. Name the staff group, supported tasks, permitted data, and duration or review condition. Prevent a limited trial from expanding into general use while its acceptance questions remain open.

Include supplier controls in the implementation record. Identify the service configuration, retention choices, administrative access, and relevant commitments the reviewers relied on. Have the responsible owner verify what the installed service actually does.

The guide to deciding which decisions stay human examines authority in the workflow. The approval process needs to connect that decision to the delivered configuration and the people operating it.

Require evidence before moving beyond the pilot

Agree acceptance cases before running the pilot. Include ordinary work, incomplete inputs, and failures that matter to the affected people. Have the process owner define the expected result and the appropriate refusal or handoff.

Test the conditions attached to approval. If a source is restricted, demonstrate a denied lookup. If staff must review before sending, demonstrate that an unreviewed draft can't reach the customer. If the system must stop on missing evidence, test that gap.

Inspect the whole workflow, including saved records and downstream actions. A correct answer on screen doesn't establish that the application wrote the right record or preserved the required approval. Record the tested configuration and the evidence the reviewer examined.

Separate observations from assumptions. A pilot may show accurate draft preparation on the reviewed cases while leaving a new user group or source untested. Keep those limits in the decision instead of describing the entire product as validated.

Agree which failures block the affected release and who resolves them. Report serious access or decision errors separately from an average quality score. The business owner needs to understand the remaining consequences and the proposed response.

Include operating effort. Measure review time, correction, fallback, and support alongside any reduction in preparation work. An acceptable pilot should support a decision about the workflow's continuing value, not merely show that the model can generate output.

Record the release decision and its limits

Use a maintained decision record linked to the AI register. Record the use, owner, data boundary, permitted actions, and affected users. Link the policy version, relevant supplier assessment, test evidence, approval conditions, and configuration used for release.

Make the status unambiguous. Distinguish permission to investigate, permission to run a bounded pilot, and approval for the stated production use. Record conditions that must be met before the next transition and the person who verifies them.

Keep sensitive source material out of a broadly accessible register. Store restricted evidence in an appropriate location and link it for authorised reviewers. Staff still need a clear view of which uses are approved and the limits they must follow.

Give each production approval a review owner and review condition. Explain when staff must return a use for assessment. The record should let a new manager understand the basis for the decision without reconstructing it from an old meeting invitation.

Connect change and incident handling to the approval

Define material changes in terms of the approved use. A different source collection, new audience, broader action, or changed supplier arrangement can alter the original assessment. Give each change an owner who determines the affected decisions and tests.

Don't make every minor adjustment wait for a full committee review. Establish a delegated route for changes within an approved pattern, with a recorded impact check. Changes outside that boundary need the appropriate assessment before the affected use expands.

Tell staff how to report an error or concern through a route they already use. Collect enough information to identify the use and affected work, with appropriate handling for sensitive evidence. Give the receiving team authority to escalate rather than simply record the complaint.

Name who can pause the affected workflow, withdraw access, or move staff to the fallback. Test that intervention. If the team can't establish the extent of an issue, the incident owner needs a way to contain the broader affected service while investigating.

Assign investigation, impact assessment, and communications to the responsible owners. Have the relevant specialists determine applicable notification and reporting requirements. Preserve the evidence needed for that work without distributing sensitive records across an unrestricted incident thread.

Require a restart decision after corrective work. Link the cause, fix, relevant retests, and any changed operating conditions to the approval record. Feed recurring failures back into the policy or review process when they reveal a wider gap.

Run the process with a real request

Consider an illustrative service company whose team wants an assistant to summarise customer complaints for internal case managers. The request names the source queue, intended users, draft output, and business owner. The assistant won't decide the remedy or send a reply in the first release.

The intake owner identifies that the tool already has approval for a different task using public information. The new use needs a review of customer records and their processing destination. Procurement links the existing supplier evidence, while the privacy and technical owners resolve the questions specific to this workflow.

The pilot conditions restrict the source queue and user group. Case managers review each draft against the original records. The acceptance set includes a missing message, a mistaken inference, a denied cross-team lookup, and a failed source connection.

The release decision records which cases passed and the remaining limits. Staff receive the review instructions and fallback, and the technical owner demonstrates how to disable the connection. A simulated incident checks whether the team can identify affected cases and route the investigation.

Later, the team requests generated customer replies. That changes the output and audience, so the owner sends the proposal through the defined change route. The existing internal-summary approval supplies context and evidence without automatically authorising the new communication.

Measure the process itself as you operate it. Track incomplete requests, waiting time by owner, unresolved conditions, overdue reviews, and the route taken by incidents. Ask staff where they struggle to understand the rules, then repair the relevant form, instruction, or decision boundary.

The AI governance service guide describes how we help implement these processes and their operating handover. Start by taking a pending request through the route and exercising an incident with its proposed owners. Use the gaps you observe to assign the next concrete change.