Most AI governance processes fail at the front door: requests arrive as emails and chat messages, nobody asks the questions that decide how much review is needed, and high-risk projects get the same light touch as a meeting summariser. This template is a ready-to-use intake form for new AI use cases at [Organisation]. A business requester can complete it in about 20 minutes, and its answers route the request to the right review: fast track, standard review, full assessment, or stop. It covers internal builds, AI features in SaaS products, third-party AI tools and AI agents. It is for AI governance leads, security and privacy teams, and anyone running an AI review queue. The scoring logic behind the routing is explained in the AI Use Case Risk Tiering Guide; this page is the form itself.
How to use this template
- Copy sections 3 to 9 into your intake tool (form builder, ticketing system or GRC platform). Keep the question IDs so answers can drive routing rules automatically.
- Replace text in square brackets, such as [Organisation], [AI governance team] and [N working days], with your own values. Bracketed thresholds are NHI Mgmt Group suggestions.
- Questions are written for a business requester, not a specialist. "Don't know" is always an allowed answer, and it routes to the more cautious path.
- Intake is triage, not assessment. The form decides which assessments follow: the AI Impact Assessment Template, the AI Agent Risk Assessment Template, the DPIA Template or the AI Vendor Security Questionnaire Template.
- Every completed form creates or updates an entry in the AI register. See the AI Register and AI Inventory Template.
1. Purpose
This form gives [Organisation] one entry point for every proposed use of AI. It collects the facts needed to decide, within [5 working days], how much review the use case needs, which specialists must be involved, and whether any legal or policy knock-out applies. It supports the NIST AI RMF expectations that intended purpose and deployment context are documented (MAP 1.1), that risk tolerance is applied (MAP 1.5) and that AI systems are inventoried (GOVERN 1.6).
2. When the form is required
- Before any new AI system, model, AI feature or AI agent is procured, built, piloted or switched on for [Organisation] data or users.
- When an existing use case changes purpose, user population, data categories, autonomy or tool access.
- When an AI feature is turned on in an existing SaaS product that processes [Organisation] data.
- Personal experiments with public AI tools using only public data are covered by the AI acceptable use policy instead, unless they move to [Organisation] data.
3. Part A: Requester and summary
| ID | Question | Answer type |
|---|---|---|
| A1 | Requester name, team and business owner (the person accountable for the outcome) | Text |
| A2 | Use case name and one-sentence description of what the AI will do | Text |
| A3 | What problem does it solve, and how is the task done today? | Text |
| A4 | Target go-live date and whether this starts as a pilot | Date, yes or no |
| A5 | How will success be measured? | Text |
4. Part B: Knock-out questions
A "yes" or "don't know" to any question in this part stops fast-track routing and sends the request to [Legal] and the [AI governance team] before anything else happens.
| ID | Question | If yes |
|---|---|---|
| B1 | Could the AI be used to manipulate people's behaviour in harmful ways, exploit vulnerabilities linked to age, disability or social or economic situation, score people socially, predict criminal offending from profiling alone, build facial recognition databases by untargeted scraping, infer emotions in the workplace or education, categorise people by biometrics to infer sensitive traits such as race, religion or sexual orientation, or perform real-time remote biometric identification in public spaces for law enforcement? | Legal review against EU AI Act Article 5 prohibited practices before any work. See the EU AI Act Prohibited Practices Guide. |
| B2 | Will the AI be used in recruitment, worker management, access to education, credit or insurance decisions, access to essential services, or another area listed as high-risk in the EU AI Act? | Full assessment route; classification check. See the EU AI Act High-Risk AI Systems Guide. |
| B3 | Will the AI make or materially influence decisions with legal or similarly significant effects on individuals? | Full assessment; DPIA screening |
| B4 | Is the AI part of a safety function in a product, vehicle, medical device or industrial system? | Full assessment; product safety review |
| B5 | Does the use case conflict with a contract, customer commitment or sector rule you know of? | Legal review |
5. Part C: Source and type of AI
| ID | Question | Answer options |
|---|---|---|
| C1 | How will the AI be obtained? | Built in-house / built on a cloud AI platform / AI feature in an existing SaaS product / new third-party AI product / open source model / don't know |
| C2 | Vendor and product name, if any | Text |
| C3 | What will the AI do? (MAP 2.1) | Generate text or images / summarise / classify or score / recommend / extract data / take actions in other systems / other |
| C4 | Will the vendor or model provider use [Organisation] data to train or improve its models? | Yes / no / don't know |
| C5 | Where will data be processed and stored? | [UK / EU / US / other / don't know] |
6. Part D: Data
| ID | Question | Answer options |
|---|---|---|
| D1 | Highest classification of data the AI will receive | [Public / Internal / Confidential / Restricted] / don't know |
| D2 | Will it process personal data? If so, whose? | No / employees / customers / children / patients / other / don't know |
| D3 | Will it process special category data (health, biometric, ethnicity, religion and similar) or criminal records data? | Yes / no / don't know |
| D4 | Will it receive source code, credentials, secrets or security configuration? | Yes / no / don't know |
| D5 | Will it read content from outside [Organisation], such as inbound email, web pages, uploaded documents or customer messages? | Yes / no / don't know |
D5 matters because content from outsiders can carry hidden instructions. A "yes" combined with any action capability in Part F is a strong signal for full assessment. See the Prompt Injection Guide.
7. Part E: Users and impact
| ID | Question | Answer options |
|---|---|---|
| E1 | Who will use it or see its output? | Small internal team / whole organisation / customers or the public |
| E2 | Will people know they are interacting with AI or seeing AI-generated content? | Yes / no / not applicable |
| E3 | Will a person review every output before it is used or sent? | Always / sometimes / never |
| E4 | What is the worst realistic outcome if the AI is wrong? (MAP 5.1) | Minor inconvenience / rework / financial loss / harm to a person's rights, health or livelihood / don't know |
| E5 | Approximate number of people affected per month | [Under 100 / 100 to 10,000 / over 10,000] |
8. Part F: Autonomy, access and identity
| ID | Question | Answer options |
|---|---|---|
| F1 | Can the AI take actions in other systems (send messages, update records, run code, make payments, call APIs)? | No, it only returns content to a person / yes, after a person approves each action / yes, on its own / don't know |
| F2 | Which systems will it connect to, and with what access (read, write, delete, send)? | List |
| F3 | Whose identity will it use? | Its own service account or agent identity / the signed-in user's access / a shared account / an API key / don't know |
| F4 | Will it connect to third-party plugins, connectors or MCP servers? | Yes (list) / no / don't know |
| F5 | Can it be stopped quickly, and who would do it? | Text |
Answers in this part decide whether the request also needs an agent risk assessment and identity review. Credentials for AI agents should be issued only after that review. See the AI agent registry for how agent identities are registered.
9. Part G: Declaration
The requester confirms that the answers are accurate to the best of their knowledge, that no production data or credentials will be used before approval, and that the [AI governance team] will be told of material changes. The business owner (A1) confirms acceptance of accountability.
10. Triage routing rules
The [AI governance team] applies these rules within [5 working days]. Rules are evaluated top to bottom; the first match sets the route. These are NHI Mgmt Group's suggested defaults.
| Route | Triggered by | Reviews required | Target decision time |
|---|---|---|---|
| Stop and escalate | B1 yes or don't know | Legal decision before any further work | [10 working days] |
| Full assessment | B2 to B4 yes; or E4 harm to rights, health or livelihood; or F1 "on its own" with any write access; or D3 yes | AI impact assessment, DPIA if personal data, agent risk assessment if F1 is not "no", security architecture review, vendor questionnaire if C1 is third-party | [30 working days] |
| Standard review | D1 Confidential or above; or D2 personal data; or D4 yes; or D5 yes; or F1 "after approval"; or E1 customers or public; or C4 yes or don't know | Security and privacy review, vendor questionnaire if third-party, identity review if F3 is not "own identity" | [15 working days] |
| Fast track | None of the above: internal users, Public or Internal data, no actions, a person reviews outputs | Register entry and approved-tool check | [5 working days] |
Any "don't know" moves the request one route up until it is answered. A shared account answer to F3 is never accepted for production; the requester must obtain a dedicated identity.
Implementation guidance
Rolling it out
- Pilot the form with two or three business units for [one quarter] and time how long it takes to complete. If it runs well over 20 minutes, cut questions rather than adding help text.
- Automate the routing rules in your intake tool so requesters get an immediate indication of route and timeline.
- Publish the fast-track criteria. People avoid governance when they cannot predict it; a visible fast lane reduces shadow AI. See the Shadow AI Policy Template.
- Review routing outcomes quarterly: if almost everything lands in full assessment, thresholds are too tight; if incidents involve fast-tracked tools, they are too loose.
Measuring it
- Median time from submission to decision per route.
- Share of requests with any "don't know", as a signal that questions need rewording.
- AI tools discovered outside intake, from SaaS discovery or network logs, per quarter.
- Re-routing rate: requests moved to a higher route after review found missed risk.
Framework mapping
| Form part | NIST AI RMF 1.0 |
|---|---|
| A, C (purpose, context, task) | MAP 1.1, MAP 2.1 |
| B, E (legal knock-outs, impact) | MAP 1.1, MAP 5.1 |
| C, F (third parties, components) | MAP 4.1 |
| Routing rules | MAP 1.5 |
| Register entry | GOVERN 1.6 |
Standards and references
- NIST: AI RMF 1.0 Core (GOVERN and MAP functions)
- EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- OWASP: Top 10 for LLM Applications 2025
Related NHI Mgmt Group resources: AI Governance Guide, AI Ethics Board and AI Review Committee Guide, NIST AI RMF Guide, AI Acceptable Use Policy Template.