A useful EU AI Act robotics requirements checklist starts with the particular AI function, intended use and responsible entity, then records the source of each applicable obligation and the evidence needed to address it. Begin with classification and duty allocation before turning general AI Act themes into product requirements. A robot label, a learned model or a product-law reference cannot supply that assessment by itself.
This guide is for robotics systems leads, product assurance managers and engineering process owners preparing an EU product or deployment review. Its practical output is a classification decision worksheet linked to a dated obligation, owner and evidence register. The workflow helps the team explain which rules it has assessed, why they apply and what remains unresolved.
Use current source status and application dates
Source freshness matters because entry into force, application and a proposed amendment are different states. The Commission’s AI Omnibus news page, reviewed on 26 October 2026, reports that the Omnibus entered into force on 27 July 2026. Its summary reports 2 December 2027 for high-risk AI systems in Annex III and 2 August 2028 for high-risk AI embedded in regulated physical products covered by Annex I.
The current Commission AI Act timeline reflects those amendments. It also lists earlier milestones: general provisions, AI literacy and prohibitions from 2 February 2025, rules for general-purpose AI model providers from 2 August 2025 and transparency rules from 2 August 2026. Applicability to a particular entity and function still needs assessment.
These are guidance-level statements in this guide. The amended operative legal text was not reviewed, so the guide does not assert operative article wording or assign article-level duties. Its date statements are explicitly attributed to the Commission guidance.
For a product review, obtain the current operative text, amendments and relevant sectoral sources, then retain the versions that support the decision. Keep a proposal as a proposal, a guidance interpretation as guidance and an enacted source as an enacted source. An old proposal should not remain the authority for a duty after an amendment, and a new summary should not silently replace a legal reference.
Classify the function and use before assigning obligations
Define the AI system or function being assessed, its inputs, outputs, intended use, configuration and the decisions influenced by its output. A robot may combine perception, planning, an operator interface and a separate analytics function. Those features can have different purposes and responsible organisations. Avoid treating a whole product name as the only unit of assessment.
Record the relevant economic operators and legal entities. Identify who supplies the AI system, who uses it and what each organisation changes or provides. If a general-purpose model is involved, assess the model-provider question separately from the robot-system question. Using a model does not by itself explain which model-provider obligations belong to the robotics organisation.
Assess product and use routes separately. For a physical product, identify the applicable sectoral legislation, relevant Annex entry and section, classification conditions and provisions invoked by the current text. For a use that may fall within Annex III, make a separate use-based assessment. Neither route should be assumed solely from a marketing description.
The Commission’s AI Act policy page describes a risk-based approach for specific uses and notes that the interplay with machinery product law has been clarified. Its broad summary cannot establish uniform high-risk duties for every machinery AI function. Obtain an authorised sector-specific decision before allocating duties or conformity work.
Build a classification decision worksheet
The worksheet below is an editorial preparation method. It is not a legal classification tool and does not reproduce amended clauses. Complete its answers with the responsible engineering, product and legal reviewers, using the actual operative sources.
| Decision gate | Record | Unresolved outcome |
|---|---|---|
| System and intended use | Function ID, purpose, inputs, outputs, users and approved configuration | Hold assessment if the use is too broad or changing |
| Responsible entity and role | Legal entity, assessed operator role, supplied work and modification responsibilities | Identify who must obtain the role decision |
| Product-law route | Sectoral source, relevant Annex entry and section, conditions and invoked provisions | Retain an explicit sector-interplay question |
| Use-based route | Potential Annex III use, factual basis and assessed conditions or exclusions | Seek a separate determination for that use |
| Other applicable themes | Assessed prohibitions, literacy, transparency or model-provider questions and their sources | A future high-risk date cannot close current-duty questions |
| Source version and status | Operative text, amendment, guidance or proposal, with retrieval and effectivity dates | Mark inaccessible or superseded text as a source gap |
| Decision authority | Reviewer, scope, rationale, uncertainty and approved assessment | A checklist author cannot supply missing legal authority |
| Change trigger | New use, changed output, modified system, entity change or source amendment | Reopen affected decisions when the basis changes |
Keep classifications and obligation decisions related but distinct. A reviewer may complete the entity assessment while the sectoral route remains open. Another may confirm an applicable theme but require an operative-source check before approving its exact duty wording. Represent that uncertainty rather than compressing it into “AI Act complete”.
Turn assessed duties into evidence work
Once the responsible reviewers establish a duty, retain its exact source and scope. Give the obligation an accountable owner, a deliverable or requirement, acceptance criteria and evidence references. Some duties concern product behaviour. Others concern documentation, organisational processes or operator arrangements. Keep those record types distinguishable.
The Commission policy summary names risk assessment, data quality, logging, documentation, information to deployers, human oversight, robustness, cybersecurity and accuracy among high-risk themes. They are candidate review themes here, not a blanket allocation to every robot. The assessed route and current text determine which duties apply and to whom.
For a product requirement, define the behaviour and how it will be verified in the relevant configuration. For a governance duty, define the process evidence and decision authority. For a supplier dependency, identify what information is needed, who provides it and how the receiving team assesses it. A procedure attached to a record does not demonstrate that it was followed or that its scope is adequate.
| Obligation-register element | What it establishes | Evidence-review question |
|---|---|---|
| Versioned source | Exact legal or authorised contractual reference, source status and assessed wording | Has the operative source been read for this duty? |
| Scope and entity | Assessed function, use, configuration and accountable legal entity | Why does this duty belong to this entity and system? |
| Application and review dates | Effective obligation timing, milestones and next source review | Is this current work or preparation for a future duty? |
| Owner and implementation | Responsible person, product requirement, process work or supplier deliverable | Can the owner identify the work that closes the obligation? |
| Evidence and limits | Artifact, configuration, exercised scope, result and remaining assumptions | Does the evidence address the assessed duty and criteria? |
| Disposition | Reviewer, rationale, open action, accepted scope and change triggers | Who accepted what, and what reopens the decision? |
The obligation register differs from the machinery transition register by retaining the AI function’s classification, entity role and sector or use route as prerequisites. Keep machinery requirements and AI obligations connected where their assessed scope overlaps. Do not duplicate a rule merely because two summaries describe similar themes.
Worked example: two functions in one fictional product
The following example is entirely fictional and unexecuted. Project PEREGRINE-5 proposes configuration PG-B4 for a robotic inspection station. Function AIF-11 would classify surface defects. A separate proposed function AIF-12 would suggest worker allocation based on station data. No legal classification, conformity route or evidence result is established by this example.
| Decision record | Factual scope | Review work and disposition |
|---|---|---|
| CL-11: inspection function | AIF-11’s output informs the product-quality decision. Its relationship to any safety function needs factual assessment. | Reviewer must establish the product-law route, Annex entry and section and resulting obligations. A robot label cannot close classification. |
| CL-12: worker-allocation proposal | AIF-12 would influence how work is allocated. Its purpose differs from surface inspection. | A separate use-based review must assess the relevant Annex III question. No conclusion is inferred from the station’s product route. |
| ENT-4: operator roles | Supplier and customer would define who provides, modifies and uses each function. | Duty allocation stays open until the responsible legal entities and assessed roles are recorded. |
| SRC-8: amended-source review | Commission guidance provides current milestones, while the operative amendment text must be obtained. | The date note can cite guidance. Exact duty wording remains a source gap. |
| EV-15: proposed evidence work | Requirements and process evidence would follow the reviewed obligation decisions. | No run or governance artifact exists. Planned work cannot be marked as demonstrated evidence. |
The worksheet prevents two shortcuts. AIF-11’s product route cannot automatically classify AIF-12’s employment-related use, and the future high-risk milestones cannot remove the need to assess currently applicable themes. Each function needs its own factual and source basis.
A useful next decision would approve the factual use and entity scope, resolve the operative-source gap and identify the applicable duties. Only then should the team allocate evidence work and its acceptance criteria. The example demonstrates record logic and unresolved states, not legal advice or a compliant product.
Control changes to use, system and sources
Reopen the assessment when intended use, operator role, output decisions, model or system modifications, deployment conditions or the governing source changes. A new analytics feature can change a use-based question even if the robot hardware is identical. A legal amendment can change duty allocation without changing the product.
Compare the proposed scope and sources with the approved assessment. Identify affected obligations, requirements, supplier commitments and evidence. Preserve historical source versions and review decisions, then record whether evidence remains applicable or needs additional work. The robotics change-impact guide provides the wider dependency review.
Keep safety-risk derivation with the hazard-to-requirement guide. The AI Act worksheet governs the source and scope of duties. It does not replace the application’s safety assessment.
Manage the register in Arc
Arc’s public programme model supports typed records, ownership, lifecycle states and relationships. A team can configure classification, obligation and source records, then link assessed duties to requirements and evidence. The customer defines the record structure and maintains the source and applicability decisions.
Traceability and impact views help inspect connected work. Attributable reviews preserve who decided what against the reviewed context. Controlled changes preserve source or use revisions and baseline decisions. Arc organises the engineering record. It does not supply a legal classification or certify compliance.
Evaluate one assessed obligation chain
Bring one assessed AI function, its approved source and role decision, one obligation and representative evidence to an Arc demo. Connect the chain, make a proposed use or source change and ask a reviewer to explain which requirements and evidence need reassessment. Include one unresolved interpretation so the team can test how a source gap remains visible.
Use synthetic or agreed evaluation material and settle data handling before introducing programme information. The exercise is useful when another reviewer can reconstruct the duty’s scope, owner, evidence and decision basis from the records.
Sources and method
Arc prepared this educational guide and sells requirements management and systems engineering software.
Prepared on 26 October 2026 from the Commission’s AI Omnibus news, AI Act timeline and policy summary retrieved that day and Arc’s canonical capability-page source. The amended operative legal text was not reviewed. Current dates are attributed to guidance, and no article-level or uniform machinery-AI duty is assigned. The worksheets are editorial methods and the example is fictional and unexecuted. Product-specific interpretation requires current operative sources and authorised specialist review. Arc capability records retain their 4 September 2026 public review date.
Frequently asked questions
Is every robotics AI system high-risk under the AI Act?
Do not infer classification from the word robot or the presence of a learned model. Assess the specific system, intended use, economic operator, product legislation and relevant Annex route against the current operative text. Different functions and uses can require separate decisions.
What application dates does current Commission guidance report?
The Commission guidance reviewed on 26 October 2026 reports 2 December 2027 for high-risk systems in Annex III and 2 August 2028 for high-risk AI embedded in regulated products covered by Annex I. Earlier milestones already apply to some other provisions. These dates do not decide the duties of a particular robotics function.
Can an Annex I product reference determine all applicable AI duties?
No. Record the exact sectoral entry and section, classification conditions, entity role and provisions invoked by the current text. An Annex I product description is not a complete obligation assessment, particularly where amendments change the interaction with sectoral product law.
What should an AI Act evidence checklist retain?
Retain the specific use and configuration, classification decision, responsible legal entity, exact versioned obligation source, application date, accountable owner, evidence criteria, linked artifacts and review disposition. Keep unresolved legal interpretations and planned evidence visible.
Does the checklist establish compliance or replace legal review?
No. It organises the engineering and governance work needed for an authorised assessment. This guide uses current Commission guidance and has not reviewed the amended operative legal text. It does not assign article-level duties or establish a product-specific compliance conclusion.