AI Use-Case Intake Form Template (EU AI Act)
An AI use-case intake form template to feed your AI inventory and trigger EU AI Act classification (Article 6), role assignment (Article 26) and literacy.
An AI use-case intake form is the first gate every new or existing AI use in your organisation passes through. It is the structured questionnaire that turns "someone wants to use an AI tool" into a registered, classified, role-assigned entry in your AI inventory. The form itself is not a statutory requirement — you will not find "intake form" in Regulation (EU) 2024/1689. But it is the practical instrument that lets you do what the Act expects: know what AI you operate, classify each use under Article 6, assign the right role under Article 16 or Article 26, and route each use to the obligations that follow. Skip the intake step and you are guessing; run it well and classification becomes a checklist, not a crisis.
This page gives you the fields to capture and shows how each one feeds a downstream duty. Use it as the front door to your AI register.
Why intake comes first
The Act's duties all presuppose one thing: that you know what AI you have. Article 26 deployer obligations, the Article 6 classification analysis, the Article 50 transparency triggers, and the Article 4 literacy duty are all impossible to discharge against a use you have never recorded. Shadow AI — tools adopted by a team without compliance's knowledge — is the single biggest source of unrecorded exposure, and an intake form is how you surface it before it bites.
So intake does three jobs in sequence: it registers the use (feeding the inventory), it classifies it (the Article 5 prohibition screen, then the Annex III / Article 6 high-risk test, then the Article 50 transparency check), and it assigns the role (provider or deployer) that determines whose duties apply. Everything else hangs off those three outputs.
The classification flow the form drives
A good intake form is built so that the answers route automatically to a first-pass classification. The order is not arbitrary — work top-down:
| Step | The question the form asks | Where it routes |
|---|---|---|
| 1. Prohibition screen | Does the use involve social scoring, manipulative techniques, untargeted scraping of facial images, workplace/education emotion recognition, generating non-consensual intimate deepfakes or child sexual abuse material (banned from 2 December 2026), or similar? | Article 5 — if yes, stop: the practice is prohibited (€35M/7%) |
| 2. High-risk test | Does the use fall in an Annex III area (biometrics, employment, creditworthiness, essential services, etc.) or act as a safety component of an Annex I product? | Article 6 / Annex III — if yes, high-risk obligations and the Art 6(3) exemption check |
| 3. Transparency test | Is it a chatbot, does it generate synthetic media, or run emotion recognition / biometric categorisation? | Article 50 — disclosure / marking duties |
| 4. Role assignment | Do you build/place it on the market under your name, or use a third party's system? | Article 16 (provider) vs Article 26 (deployer) |
The form captures the inputs; a person (or a rule-based check) reads them and produces the first-pass finding. The point is that no use reaches production unclassified.
The fields to capture
1. Requester and business owner — name, team, and the accountable owner for the use. Compliance needs a human to come back to.
2. Plain-language description of the use — what the AI does, what decision or output it produces, and who or what it affects. This is the single most important field: classification turns on use, not on the tool's brand.
3. The AI system / tool and its provider — the named product (e.g. a CV-screening tool, a support chatbot), its vendor, and the model or service underneath where known. Links the entry to vendor documentation.
4. Affected persons — employees, customers, applicants, the public; whether the use profiles natural persons (a profiling use is always high-risk if it falls in Annex III).
5. Decision influence — does the output decide, recommend, or merely inform? Is there a human in the loop? This feeds both the Article 6(3) exemption analysis and the Article 14 oversight design.
6. Data used — categories of input/training data, any special-category (GDPR Article 9) or personal data. Feeds the Article 10 data-governance and bias questions and the GDPR overlap.
7. Provider-or-deployer indicator — do you place this on the market or put it into service under your own name (provider), or are you using a third party's system in your own activity (deployer)? Determines the obligation set.
8. First-pass risk category — the classifier's output: prohibited / high-risk / limited-risk (transparency) / minimal. Recorded with the reason and the Article/Annex cited.
9. Transparency triggers — chatbot, synthetic content, emotion recognition, deepfake — each mapped to its Article 50 sub-duty.
10. AI-literacy note — who operates and oversees this use, and whether they have the competence the role requires (the link to Article 4).
How the form supports Article 26 deployer diligence
Most small and mid-sized EU companies are deployers, not providers — they use AI built by someone else. Article 26 is the deployer's obligation set, and an intake form is how a deployer meets it in practice. Article 26 expects a deployer to use a high-risk system in accordance with the provider's Article 13 instructions for use, to assign competent human oversight, to monitor operation, and to keep the automatically generated logs the system produces. None of that is doable for a use you have not recorded.
The intake form operationalises Article 26 by forcing the deployer to capture, at adoption time, the provider's instructions reference, the named human overseer, the data the deployer feeds the system, and the use's classification — so that when an obligation is triggered, the record already exists. It also surfaces the cases where a deployer becomes a provider: under Article 25, a deployer who puts a high-risk system on the market under its own name, or makes a substantial modification, inherits provider duties. The "do you brand or modify this?" field on the form is exactly where that flip gets caught early, not in an audit.
How it supports Article 4 AI literacy
Article 4 — applying since 2 February 2025, and covering all AI, not just high-risk — requires providers and deployers to take measures to support the development of AI literacy among the staff who operate and use their AI systems. Since Regulation (EU) 2026/1744 (the Digital Omnibus on AI) took effect on 27 July 2026, the text no longer requires you to guarantee a specific level for each individual, but the duty to act still sits with you. The intake form's "who operates and oversees this" field is the connection: it identifies the people whose competence Article 4 covers for each use, and lets you check that operators and overseers actually have the understanding the use demands. A use-by-use literacy note turns Article 4 from an abstract policy into a per-system record of who needs to know what.
Worked example: a logistics firm registering a new tool
Nordwerk Logistik GmbH, a German freight-and-warehousing company with about 240 employees and roughly €52M turnover, runs the intake form when its HR team asks to adopt a CV-screening assistant. The requester describes the use plainly: the tool ranks job applicants for warehouse roles and surfaces a shortlist to recruiters.
The form routes the analysis. The prohibition screen is clear — no Article 5 issue. But the high-risk test lands squarely: applicant screening for employment is Annex III point 4, so the use is high-risk under Article 6, and because it profiles natural persons the Article 6(3) exemption is not available. The role field shows Nordwerk uses the vendor's tool without rebranding it, so Nordwerk is a deployer under Article 26, not a provider. The form captures the vendor's Article 13 instructions reference, names the recruiter responsible for Article 14 human oversight, and flags that the recruiters operating the tool fall within Article 4 literacy. The whole chain — register, classify, assign role, route to duties — runs from a single ten-field intake, and the high-risk finding reaches compliance before the tool touches a real applicant. (Note: stand-alone Annex III high-risk obligations apply from 2 December 2027 under Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force since 27 July 2026; product-embedded Annex I systems follow on 2 August 2028.)
How Confir helps
Confir's intake and registration step captures exactly these fields and runs the rule-based classifier across them: the same answers always produce the same first-pass finding — prohibited, high-risk, limited-risk, or minimal — with the Article or Annex that fired shown in plain language. From there it assigns the provider or deployer role, opens the Article 26 deployer checklist where relevant, and flags the operators who fall under Article 4 literacy. The intake form becomes the front door to an inventory an auditor can read, not a spreadsheet that drifts.
Frequently Asked Questions
Is an AI use-case intake form required by the EU AI Act?
Not by name. The Act does not mention intake forms. But it requires you to classify each AI use under Article 6, assign the correct role under Article 16 or 26, meet transparency duties under Article 50, and take AI-literacy measures under Article 4 — none of which is possible for a use you have not recorded. An intake form is the practical instrument that makes those statutory duties achievable; it supports compliance rather than being a legal requirement itself.
What is the difference between an intake form and an AI inventory?
The intake form is the process — the structured questionnaire each new or existing AI use passes through. The AI inventory (or register) is the result — the maintained list of all your AI uses with their classification, role, and owner. The form feeds the inventory: every completed intake becomes a registered entry. Run the form consistently and the inventory stays current; skip it and the inventory goes stale.
Does the intake form replace a full high-risk classification?
No. The form produces a first-pass classification — enough to route a use correctly and catch prohibited or high-risk cases early. A use that screens as high-risk under Annex III still needs the full Article 6 analysis, the Article 6(3) exemption assessment, and the downstream Article 9–15 work. The form is the trigger and the triage, not the complete assessment.
Who should fill in the intake form — the requester or compliance?
The requester or business owner completes the descriptive fields — what the use does, who it affects, what data it uses — because they know the use best. Compliance (or a rule-based check) reads those answers and produces the classification and role assignment. Splitting it this way keeps the form usable for non-experts while keeping the legal judgement with the people accountable for it.
How does intake help with Article 4 AI literacy?
Article 4, applying since 2 February 2025 to all AI, requires providers and deployers to take measures to support the AI literacy of staff who operate and use AI systems; since 27 July 2026 it no longer demands a guaranteed level for each individual. The intake form's "who operates and oversees this use" field identifies, per system, exactly the people those measures must reach — turning a general literacy duty into a concrete, use-by-use record of who needs which understanding.
We are a deployer, not a provider — do we still need intake?
Yes, and arguably more so. Deployers carry Article 26 duties — using high-risk systems per the provider's instructions, assigning human oversight, monitoring, keeping logs — all of which depend on having recorded the use. Intake also catches the Article 25 flip, where a deployer who rebrands or substantially modifies a system becomes a provider with the heavier duties. The form surfaces that early, before an audit does.
Related guides
- AI system register template — the inventory the intake form feeds
- How to classify your AI system — the full Article 6 analysis the form triggers
- Risk classification decision tree — the prohibited → high-risk → limited flow, step by step
- Provider vs deployer — the role distinction the form assigns
- Deployer obligations (Article 26) — what an intake entry routes a deployer toward
- AI literacy — the Article 4 duty the operator field supports
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →