AI Intake and Approval: The Gate Between a Request and a Deployment

Every AI governance programme builds an intake process, and most of them are judged on the wrong thing. The question asked in design reviews is whether the process is thorough: does it capture the risk, the data, the vendor, the legal basis, the oversight design. The question that actually determines whether it works is different and much less comfortable.

Is the approved route faster than going around it?

Because if it is not, people will go around it. Not out of recklessness, and usually not out of disagreement with the policy. They will go around it because they have a deadline, the sanctioned path costs three weeks, and the unsanctioned one costs a corporate card. Everything in the design of a gate follows from that single comparison, and a process optimised for completeness almost always loses it.

This guide covers what the law actually specifies about the system around the gate, the shape of a gate that holds up, the difference between questions that route and questions that assess, the standing decisions that empty most of the queue, and the second gate that almost nobody builds. It sits inside our guide to the AI governance operating model, which owns the structures this process runs through.

The only metric that matters

A governance gate is in competition with the alternative, and the alternative is always available. For AI specifically the alternative is unusually cheap: a subscription, a personal key, a free tier, a feature already bundled into software the team has. Our guides on shadow AI and endpoint governance describe what the result looks like once it has accumulated.

So the design objective is not to make the gate comprehensive. It is to make the gate cheaper than the workaround for the overwhelming majority of requests, while remaining genuinely demanding for the small minority where the consequence justifies it. Those two goals look contradictory and are not, because the request distribution is heavily skewed. Most of what arrives is low consequence, and treating it at the same depth as the few high consequence cases is what makes the median experience slow.

What the law specifies, and what it does not

There is a useful asymmetry in how the obligations are written, and it changes what you can expect to be told.

Article 17 requires providers of high risk systems to operate a documented quality management system, and lists thirteen elements it must include. They cover a strategy for regulatory compliance including "procedures for the management of modifications"; methods for design including "design control and design verification"; development methods including "quality control and quality assurance"; "examination, test and validation procedures" with their frequency; technical specifications and standards; "systems and procedures for data management"; the Article 9 risk management system; the Article 72 post-market monitoring system; "procedures related to the reporting of a serious incident"; handling of communication with authorities and other parties; "systems and procedures for record-keeping"; "resource management"; and "an accountability framework setting out the responsibilities" of management and staff.

Read the list again and notice what is missing. Article 17 never uses the word approval. It describes design control, verification, validation, record-keeping and an accountability framework, and leaves entirely open how a particular organisation decides that a particular system may proceed.

That is not an oversight, and for a governance team it is good news badly disguised. Nobody is going to hand you a template for the gate. What the obligations do is tell you what has to exist by the time something is deployed, and several of those things are explicitly time-bound to before deployment: technical documentation "drawn up before that system is placed on the market or put into service", and, where a provider concludes an Annex III system is not high risk, a duty to "document its assessment before that system is placed on the market or put into service". A negative classification is a documented decision with a deadline, which is a strong argument for the gate existing at all.

The design implication is to work backwards. The gate is whatever reliably produces, by the time a system is live, the artefacts somebody will later be asked for. Our guide to audit ready evidence covers what those artefacts are.

The shape of a gate that works

Three structural choices account for most of the difference between a gate people use and one they route around.

One front door, whatever the request looks like. Organisations commonly end up with several: a procurement path for buying, an architecture path for building, a privacy path for data, and an AI path that overlaps all three. A requester who has to work out which one applies will pick wrong or pick none. One entry point that routes internally is slower to build and dramatically cheaper to use.

Triage first, depth afterwards. The most common structural error is a single form long enough to serve the hardest case. Everyone pays the cost of the hardest case, including the person registering a meeting-notes summariser. Split it: a short triage that classifies, then a depth of assessment set by the tier. Our guide to risk tiering covers the classification that routes it.

A committed answer time per tier, published. Not a target, a commitment, with a stated default when it is missed. The value is partly operational and mostly behavioural: a known five day answer for low tier requests is something a requester can plan around, and an unknown duration is the thing that drives people to the workaround even when the actual answer would have been quick.

The last row contains the most common avoidable delay in the whole process. Where a committee meets monthly and the assessment is done in the meeting, the real cycle time is dominated by calendar arithmetic rather than by work. Doing the assessment beforehand and using the meeting to decide converts a month into a week without reducing scrutiny at all.

The intake form that fits on one screen

Triage questions and assessment questions get mixed together constantly, and separating them is most of the work of making intake usable. A triage question is one whose answer changes the route. An assessment question is one whose answer changes the decision. Only the first belongs at the front.

1. What will it decide or influence, and for whom
   One sentence, no technology in it. This single answer does more routing than everything else combined, and a requester who cannot write it has revealed something useful before any assessment starts.
2. Who is affected, and can they avoid it
   Customers, employees, applicants, the public, or nobody outside the team. Whether exposure is voluntary matters as much as the count.
3. Does a person review each output before it has effect
   Ask it as a factual question about the design, and expect to verify it later. Our guide to risk tiering covers why the override rate, not the design, is the honest answer.
4. What data goes in, and whose is it
   Enough to route to privacy or security, not enough to constitute a data protection assessment. The question is which specialists need to see this, not what their answer will be.
5. Built, bought, or a feature of something we already have
   The third option is the one usually missing from the form, and it is increasingly the most common. It routes to a different conversation: a change to an existing vendor relationship rather than a new system.
6. Who owns it when it is live
   A named person, not a team. Everything downstream, from assessment to monitoring to the eventual retirement decision, needs somebody to be accountable, and the cheapest moment to establish that is before anyone has built anything.

Six questions, answerable in a few minutes by the person requesting, without a specialist. Everything else is an assessment question and belongs after the tier is known, asked only of the requests whose tier requires it.

Standing decisions, which empty the queue

The change that returns the most, in most intake processes, is not making reviews faster. It is removing reviews entirely for cases that have already been decided.

A pre-approved pattern is a combination of tool, data class and use that has been assessed once and recorded as permitted, so that a request matching it needs registration rather than review. "This approved assistant, with internal non-personal data, for drafting and summarisation, with no output reaching a customer unreviewed." A request matching that gets a register entry and proceeds.

Three things make patterns work rather than becoming a loophole.

• Each pattern has an expiry. Tools change, terms change, the tier assumptions change. A pattern that was assessed two years ago and never revisited is an unexamined standing permission, which is the thing patterns are supposed to replace.
• Matching is sampled. Some proportion of pattern-matched registrations get checked against what was actually built. Without sampling, the pattern becomes the route everything claims to take.
• Patterns are published, in the requester's language. A pattern nobody can find does no work. The list belongs wherever people look before they start, next to the usage policy, not inside the governance portal.

The second gate nobody builds

Almost every intake process governs the moment a system arrives, and almost none governs the moment it changes. That is backwards relative to how the risk actually accumulates, and the obligations say so.

Article 17 lists "procedures for the management of modifications" inside its very first element, alongside the strategy for regulatory compliance. Modification management is not an afterthought in the structure; it sits at the top of the list with conformity assessment.

The reason it matters is that the material changes rarely look like new systems. A model version swapped for a newer one. A tool given access to a second data source. A human review step removed because the queue got long and the quality looked fine. An assistant approved for drafting now used for a customer-facing reply. None of those arrives as a request, and every one of them can move a system up a tier.

The workable approach is a short, enumerated list of changes that require a return to the gate, published alongside the patterns, with everything not on the list explicitly not requiring one. A list of four or five specific triggers gets followed. A general instruction to come back when something material changes does not, because materiality is exactly the judgement the requester is not placed to make.

Useful triggers tend to be: a change in what the system decides or influences; a change in who is affected; removal or reduction of a human review step; a new data category; and a change of model or vendor. Several of those surface automatically from other signals, and a step change in consumption often reveals the last one before anybody files anything, which our guide to AI spend as a governance signal covers.

The trade-offs nobody puts on the slide

A fast gate approves things you would have caught. Shallow review at the low tiers will let some things through that a thorough process would have questioned. That is the deliberate trade, and it is the right one if the alternative is those systems never appearing at all. Sampling is what keeps it honest, and the sampling budget is not optional.

Pre-approved patterns drift. They are the mechanism that makes the process usable and the mechanism most likely to decay quietly. Expiry dates and sampling are the cost of having them, and a programme that adds patterns without maintaining them has traded a slow gate for a notional one.

One front door means somebody owns the routing. The single entry point works because a human or a rule set decides where each request goes. That is a real role with real judgement in it, and leaving it unassigned reproduces the original problem inside the process instead of outside it.

The gate cannot catch what never asks. Intake governs requests. It does nothing about systems that arrive without one, which is most of the problem in most organisations. Intake and discovery are complementary, and a programme that builds only the gate will have an immaculate process covering a minority of its estate.

Frequently asked questions

Where this leaves you

The thing that makes intake difficult is that its success condition is invisible. A gate that works produces a register that keeps filling, requests that arrive before systems go live, and an absence of unpleasant discoveries. None of that is an event, and none of it shows up in a quarterly report as clearly as a completed framework does.

What does show up, eventually, is the opposite: a system nobody assessed, found during an audit or after an incident, with a business owner who genuinely did not know the process applied. That outcome is almost never caused by the review being too shallow. It is caused by the route being slower, less findable or less obviously relevant than the alternative. Which is why the uncomfortable question is the right one to design against, and why the answer to it is mostly about the median request rather than the hardest one.