How to run AI use case intake and approval

AI use case intake gives every proposal for new AI one front door. A short request form sorts each proposal by risk, a named reviewer approves it quickly or sends it for a full assessment, and the decision is recorded. Most organisations meet AI governance through a request. Someone wants to use a new tool, a team wants to automate a decision, a vendor wants to switch on an AI feature in a product you already pay for. How you handle that moment sets the tone for everything after it. A good intake process gives people a clear way in, gives reviewers the facts they need, and leaves a record that later work can build on.

Why intake matters

An inventory built after the fact is always behind. Discovery tools and surveys find AI already in use, which is necessary, but it means governance starts from a position of catching up. Intake moves the first look to before the system goes live, when changing course is cheap.

The frameworks point the same way. ISO/IEC 42001 asks an organisation to define the intended use of each AI system and to assess its impacts before deployment. The NIST AI Risk Management Framework places context-setting in its Map function, and its Govern function calls for mechanisms to inventory AI systems. Australia’s Guidance for AI Adoption opens with deciding who is accountable and understanding impacts. None of them prescribes a request form, but each assumes a moment where someone looks at a proposed use and decides.

Step 1: Decide what counts as a request

Write down what must come through intake. A workable rule covers three things.

• A new AI system or agent, whether built, bought or switched on inside an existing product.
• A new use of an approved tool, where the purpose, the affected people or the data changes.
• A material change to a system already on the register, such as a new model, a new data source or a move from advising to acting.

Be explicit about what does not need a request. General productivity features used within an approved acceptable use policy may sit outside intake. Saying so stops the process from collecting noise.

Step 2: Build a short request form

The form has two jobs. It captures why the requester wants the AI, and it captures the facts about the system that every later step needs. Ask about the request itself first.

• Why, and for what. The business problem in plain words.
• Intended use. What the system would do day to day.
• How outputs are used. Whether a person reads them, whether they feed another system, whether they decide something.
• Who is affected. Customers, staff, applicants, the public.
• Urgency and the date it is needed by, with the requester’s manager.

Then ask about the system. Ask who provides it and which model it runs on, whether it processes personal information, and what data it would use for training, as reference material or as input. Ask what it produces, from content to scores to autonomous actions, and what level of human oversight it would have. Finally, ask whether people interact with it directly and whether they would know it is AI.

Keep every question answerable by a requester without a specialist at their elbow. Questions only a lawyer could answer belong in the assessment, not the form.

Step 3: Triage into lanes

The answers should sort the request before a reviewer reads it. Three lanes cover most organisations.

• Fast lane. No personal information, no decisions about people, a person reviews every output. Approve against standard conditions within days.
• Standard lane. Personal information or customer-facing use, but no consequential decision. A reviewer checks the facts and sets conditions.
• Assessment lane. Decisions that significantly affect people, autonomous action, special-category data, training on your own data, or use in a setting a law treats as high risk. A risk assessment, and often an impact assessment, comes before the decision.

Derive the lane from signals in the answers rather than asking the requester to choose it. “Named data assets carry personal information” or “the system takes autonomous decisions” are facts the form already holds. People asked to rate their own risk rate it low.

Step 4: Route to a named decision-maker

Name the approver for each business unit, the committee an escalation goes to and how long a decision should take. A default route covers everyone else. Without routes, requests pile up in a shared inbox and the process gains a reputation for being slow.

Give the reviewer three options short of a final answer. They can ask the requester a question, send the request back for clarification, or escalate it to a committee. When a committee decides, its outcome should write back to the request, so the requester sees one answer in one place.

Step 5: Record the decision and its conditions

A decision record holds who decided, when, the outcome and the reasons. Approvals usually carry conditions, such as no customer data until the vendor contract is signed, human review of every output for the first quarter, or a guardrail on personal information before go-live. Write the conditions down where the system owner will see them, not in an email thread.

Keep the discussion with the request. The questions asked, the answers given and the documents attached are part of why the decision was reasonable. Keep declined and withdrawn requests too. A record of what was refused, and why, is some of the best evidence that the process does real work.

Step 6: Turn the approval into the register record

The single most useful design choice is to make the approved request become the system’s record in the register. The answers the requester gave are the system’s first profile. The risk assessment starts from them. When the system later changes, a change request raises the next version of the same record.

Keep approval and going live separate. Approval says the use may proceed under its conditions. Going live is a later act, once the conditions are met. Holding them apart stops an approval from being read as a launch.

Making intake work in practice

Intake fails in predictable ways. It gets too long, so people avoid it. It gets too slow, so people buy tools on a credit card. It asks requesters to make legal judgements, so the answers are guesses. It sits apart from the register, so the two drift.

A few habits keep it working. Publish the decision times and report against them. Review the form every few months and remove questions nobody uses. Use discovery to find tools that went around intake, and treat each one as a prompt to ask why rather than a disciplinary matter. If the same kind of request keeps arriving, pre-approve it with standard conditions and move it to the fast lane.

Where Aicura fits

On Aicura’s Pro tier, AI use requests sit on the AI Register’s Requests tab, so Step 6 happens by design. Raising a request writes a proposed version of the system’s record in the register, and the request form is the register’s own sections plus the reasons for the request. Signals derived from the answers, such as named data assets carrying personal information or training on the organisation’s data, are shown to the reviewer as labels. Routes name the approvers and the escalation committee for each business unit, with a default decision time.

Reviewers can ask questions, send a request back for clarification or escalate to a committee, whose outcome writes back to the request. Approval does not make the system live, which is a separate status change once the conditions are met. Settings decide whether requests are not used, optional or required, and when they are required every new system arrives through one. The decision stays with your reviewers.