CUP FIELD TOOLS · AI Act use-case review

Before deploying AI, can you explain the use and its obligations?

Review one AI system in one intended use. Establish the organisation’s role and the applicable pathway, then assemble the evidence needed for a controlled deployment decision.

12 chapters · 36 detailed verifications · Initial and detailed review modes · No account required

Start the evidence review →

WHY USE IT?Start with the actual use, then examine the evidence.

A model name or vendor risk label does not describe the deployed workflow. Record what the system does, who may be affected and who is responsible, then identify the classification, evaluation and oversight questions still to resolve.

YOUR REVIEW PATH

Scope → Evidence → Action

A focused review with an accountable outcome.

Intended use & roleDefine the reviewed scope

Review ↗

Classification & safeguardsChallenge the supporting records

Review ↗

Deployment decisionAssign the unresolved actions

Review ↗

Your exportable action plan

Missing records · Owners · Next steps

Illustrative review flow. Select a checkpoint to explore it.

How to use this review

Bring the right people: system owner, provider or deployer, technical reviewer, affected-function and legal/privacy roles. Record roles and non-sensitive references.

Define one decision. Record the baseline, applicable basis and accountable owner. Identify uncertain applicability before treating requirements as settled.
Challenge the evidence. Work through twelve questions. Reference existing records, explain what they demonstrate and leave unsupported conclusions open.
Take an action plan to the review. Export a report or CSV, assign owners and dates, and save a review file to update later.

The first pass identifies missing work. It does not complete the underlying assessment, tests or regulatory review. Use “Not applicable” only with a recorded rationale.

SCOPE AND REFERENCE BASIS · REVIEWED 1 NOVEMBER 2026

Agree the basis before relying on the result.

Review the current legal text, including amendments, application dates and transitional treatment. The Commission’s official Explorer identifies the 27 July 2026 consolidated text and the Digital Omnibus amendment. Requirements depend on role and use; not every checkpoint is a mandatory duty for every system. Record a reason for non-applicability. GPAI-model providers need a separate obligation review; this worksheet focuses on a system/use-case decision and does not automatically classify it.

CUP’s questions are original engineering review prompts, not a reproduction of standard clauses, a complete legal checklist, a certification or legal advice. Record the applicable text, edition, jurisdiction and review date; seek qualified interpretation where needed.

BEFORE YOU START · YOUR DATA

Use references, keep sensitive information in your own systems.

This worksheet runs in your browser. Answer the checkpoints, reference your existing records and export the resulting action plan when you need it.

Saved in this browser · No upload of worksheet entries to CUP · Use non-sensitive references only. Downloaded files contain your entries; check them before sharing.

Read how saving, deletion and exports work

What to enter: fictional or non-sensitive review references, job roles and short action descriptions. For example, “Review record R-042” and “Accountable review owner”.
What to leave out: passwords, keys, tokens, personal data, IP addresses, network diagrams, unpublished vulnerability details, incident details and confidential system, product or supplier information. Keep the evidence itself in your organisation’s approved systems.
Where entries are saved: automatically in this browser profile on this device, when local storage is available. Worksheet entries and imported review files are not uploaded to CUP. There is no account-based backup or synchronisation. Other people using the same profile, and software with access to it, may be able to read them. This is not an encrypted vault.
How to remove them: choose “Clear saved review” in the workspace. Clearing this site’s browser data also removes the local review. Download a copy first if you need to keep it. Browser data can be lost or cleared.
Exports and sharing: downloaded reports, CSV and review files contain your entries and are not encrypted by this tool. Printing or saving a PDF creates another copy. Check every copy before sharing and store it according to your organisation’s rules. Clearing the worksheet does not delete downloads, backups or copies you have shared.

The worksheet supports an evidence review. Your authorised team remains responsible for verifying evidence and deciding the appropriate next decision. See the site privacy notice for information about visiting CUP.

Before design or procurement

Agree the scope, responsibilities and evidence to request before accepting a supplier or solution claim.

Before release or deployment

Check the current baseline and unresolved conditions with the authorised decision owner.

After a material change

Reopen the review when the use, configuration, evidence, legal basis or supporting assumptions change.

Build your action plan →

Twelve evidence checkpoints

Read or print this table without JavaScript. Guided saving and exports require JavaScript. Keep sensitive evidence in approved systems; use non-sensitive references here.

AI Act use-case review · original CUP review prompts
Checkpoint	Evidence to assemble	Decision to resolve	Review notes
01 · System and intended use	System purpose, users, affected people, deployment context, model/system boundary and version. Detailed verifications (3) Suggested review roles: System owner; affected-function representative. Lifecycle: Intended-use and deployment definition. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Intended purpose concrete Evidence to request: Use-case definition. Document only when: The actual workflow and decision are described. People and context considered Evidence to request: Deployment-context assessment. Document only when: Affected groups and operating conditions are identified without personal data here. Version and boundaries fixed Evidence to request: System baseline reference. Document only when: Model, system and external dependencies are distinguished.	What exact AI use and decision are being assessed?	Evidence assembled
02 · Organisation’s role	Provider, deployer, importer, distributor or other relevant role and contractual responsibilities. Detailed verifications (3) Suggested review roles: Relevant provider/deployer; qualified legal reviewer. Lifecycle: Value-chain role assessment. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Actual activity examined Evidence to request: Role assessment. Document only when: The organisation’s responsibilities follow its activity. Upstream and downstream duties separated Evidence to request: Responsibility agreement. Document only when: Provider and deployer contributions are not conflated. Role-changing modifications considered Evidence to request: Change-of-role review. Document only when: Rebranding or changed intended purpose can trigger reassessment.	Which role does this organisation perform for this use?	Evidence assembled
03 · Current legal basis and application dates	Current consolidated text, amendments, relevant guidance, application dates and transitional analysis. Detailed verifications (3) Suggested review roles: Qualified legal/regulatory reviewer; system owner. Lifecycle: Current legal basis and timing. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Current binding text recorded Evidence to request: Dated legal-basis register. Document only when: Amendments and authentic text are identifiable. Guidance status distinguished Evidence to request: Interpretation record. Document only when: Guidance and proposals are not treated as enacted duties. Dates and transition reviewed Evidence to request: Application-date assessment. Document only when: The relevant role and use have a reviewed timing basis.	Which provisions and dates apply to the reviewed use?	Evidence assembled
04 · Prohibited-practice screening	Intended functionality, affected groups, use restrictions and reasoned screening against current prohibitions. Detailed verifications (3) Suggested review roles: Qualified prohibited-practice reviewer; use-case owner. Lifecycle: Screening before reliance on a go-ahead. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Real functionality screened Evidence to request: Prohibited-practice assessment. Document only when: Screening addresses the deployed workflow. Uncertainty escalated Evidence to request: Qualified review reference. Document only when: A potentially prohibited use is not cleared by a generic vendor description. Internal go-ahead bounded Evidence to request: Deployment decision record. Document only when: Unresolved prohibition questions are explicitly escalated before reliance.	Could this use fall within a prohibited practice?	Evidence assembled
05 · Classification and rationale	Article 6 and applicable annex analysis, intended use, exclusions or exceptions and review ownership. Detailed verifications (3) Suggested review roles: Classification reviewer; system owner. Lifecycle: Role/use-specific pathway determination. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Use-specific pathway analysed Evidence to request: Classification rationale. Document only when: The applicable use and role determine the reviewed pathway. Exceptions substantiated Evidence to request: Exception assessment. Document only when: Any relied-on exception has recorded grounds. Vendor label challenged Evidence to request: Independent classification review. Document only when: The conclusion is not based solely on a supplier risk label.	What supports the chosen risk and obligation pathway?	Evidence assembled
06 · Information and transparency	Applicable disclosure analysis, user notices, content marking arrangements and communication responsibilities. Detailed verifications (3) Suggested review roles: UX/communications owner; relevant provider/deployer. Lifecycle: Information and transparency delivery. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Applicable information identified Evidence to request: Transparency applicability review. Document only when: The role and actual interaction inform the required information. Interface delivery checked Evidence to request: User-journey verification. Document only when: Relevant notices or markings reach their intended audience. Supply-chain disclosures preserved Evidence to request: Integration review. Document only when: Upstream information is not silently removed or obscured.	Will the right people receive the information required for this use?	Evidence assembled
07 · Human oversight and competence	Assigned oversight roles, instructions, training or competence arrangements and intervention authority. Detailed verifications (3) Suggested review roles: Oversight owner; training/competence lead. Lifecycle: Human oversight preparation and exercise. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Oversight responsibility assigned Evidence to request: Oversight role record. Document only when: The responsible role has authority and capacity. Intervention practical Evidence to request: Oversight exercise. Document only when: The role can recognise limits and intervene where needed. Competence needs addressed Evidence to request: Role-specific competence plan. Document only when: Instructions and skills match the actual task and current basis.	Can responsible people understand the limits and intervene where needed?	Evidence assembled
08 · Data and evaluation evidence	Data provenance and suitability, evaluation scope, relevant performance and bias checks, limitations and applicable privacy review. Detailed verifications (3) Suggested review roles: Data/evaluation owner; privacy/rights reviewer. Lifecycle: Data suitability and evaluation. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Data suitability examined Evidence to request: Data provenance and suitability review. Document only when: The evaluation reflects the intended population and context. Relevant failure patterns assessed Evidence to request: Evaluation results. Document only when: Aggregate measures do not conceal consequential subgroup failures. Related rights obligations reviewed Evidence to request: Qualified data/privacy assessment. Document only when: Applicable data and rights questions have an owned resolution.	Do the evidence and tests represent the people and conditions of intended use?	Evidence assembled
09 · Security, reliability and dependencies	Abuse cases, accuracy/robustness targets where applicable, dependency risks and verification results. Detailed verifications (3) Suggested review roles: Security/reliability owner; dependency owner. Lifecycle: Version-bound validation and change control. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Expected performance bounded Evidence to request: Version-bound performance review. Document only when: Targets and limitations match intended conditions. Abuse and dependency risks tested Evidence to request: Approved robustness/security results. Document only when: Relevant misuse and dependencies are assessed. Changes controlled Evidence to request: Model/tool change record. Document only when: A changed dependency can invalidate earlier evaluation.	What supports reliable operation under the expected conditions and foreseeable misuse?	Evidence assembled
10 · Rights and deployment safeguards	Assessment of whether a fundamental-rights impact assessment or other deployment assessment is required, resulting actions and accountable owner. Detailed verifications (3) Suggested review roles: Applicable assessment owner; affected-function/legal reviewer. Lifecycle: Impact-assessment applicability and safeguards. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Assessment applicability decided Evidence to request: Impact-assessment applicability record. Document only when: Role and use determine which assessment is required. Relevant assessment completed Evidence to request: Assessment reference where applicable. Document only when: The applicable assessment exists before the relevant decision. Safeguards implemented Evidence to request: Safeguard follow-up record. Document only when: Required actions have implementation evidence or an explicit unresolved status.	Which impact assessments and safeguards apply before this deployment?	Evidence assembled
11 · Evidence and conformity pathway	Applicable technical documentation, instructions, logging, registration and conformity-assessment responsibilities. Detailed verifications (3) Suggested review roles: Dossier/formal-process owner; provider/deployer reviewer. Lifecycle: Role-specific records and formal pathway. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Role-specific dossier indexed Evidence to request: Documentation index. Document only when: Required records can be found for the relevant role. Formal pathway reviewed Evidence to request: Conformity/registration applicability record. Document only when: Applicable formal steps are identified without assuming all systems share them. Model and system duties separated Evidence to request: GPAI boundary review. Document only when: Model-provider duties are routed to the appropriate specialist review.	Which records and formal steps are required for this role and pathway?	Evidence assembled
12 · Monitoring, incidents and changes	Monitoring ownership, feedback, incident escalation, suspension criteria and reassessment triggers. Detailed verifications (3) Suggested review roles: Operational owner; incident/change lead. Lifecycle: Monitoring, intervention and reassessment. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Operation observed Evidence to request: Monitoring plan. Document only when: Feedback and relevant failures can reach an owner. Intervention and escalation actionable Evidence to request: Incident/intervention procedure. Document only when: Someone can suspend, correct or escalate when limits are exceeded. Changes trigger reassessment Evidence to request: Reassessment register. Document only when: Use, model, context and legal-basis changes are covered.	What event causes the team to stop, correct or reassess the use?	Evidence assembled

PRIMARY REFERENCES · REVIEWED 1 NOVEMBER 2026

Check the source and its applicability.

Public catalogue and guidance links support orientation. Licensed standards and legally authentic texts govern their respective requirements. This worksheet does not establish equivalence between standards and regulations.

AI Act — current consolidated legal text

Use the official source to check the relevant scope, current text and applicable conditions.

Open official reference →

Commission — official AI Act Explorer

Use the official source to check the relevant scope, current text and applicable conditions.

Open official reference →

Commission — AI Act implementation resources

Use the official source to check the relevant scope, current text and applicable conditions.

Open official reference →

All six worksheets →Comparative evidence map →