AI Act Classification for Hotel Service Robots

Hotel service robots are not automatically high-risk AI systems. Classification attaches to the relevant AI system and its intended purpose, not simply to a machine being called a robot or operating near guests. The binding AI Act, Regulation (EU) 2024/1689, Article 6, establishes two routes: specified product-safety circumstances under Article 6(1), and listed uses under Article 6(2) and Annex III.

For AI Act hotel service robots, the practical test is therefore sequential: identify whether the component is an AI system; examine whether it is an AI safety component, or itself a product, covered by Annex I legislation requiring third-party conformity assessment; then check whether its intended use appears in Annex III. Navigation and obstacle avoidance on a delivery robot do not automatically make it Annex III high-risk, but the Article 6(1) safety route still needs analysis. The Commission’s draft classification guidelines explain these two routes without replacing the Regulation.

1. Classify the functions of hotel service robots

A single robot deployment may combine navigation software, a conversational interface, remote fleet management and analytics about employees. These functions need not share one classification. Procurement should identify the boundaries of each AI system, including cloud services and optional features, before accepting a supplier’s overall label.

Begin with the intended purpose stated in instructions, technical documentation, sales materials and contractual specifications. Article 3 defines intended purpose by reference to the use intended by the provider, including its context and conditions. The Commission’s AI Act FAQ also explains that classification depends on intended purpose and use modalities. A hotel’s actual configuration matters, not just the product brochure.

Record a concrete use statement: for example, transporting sealed room-service orders through mapped corridors, without evaluating staff or identifying guests. Then record exclusions and access controls that keep those exclusions real. A disabled employee-scoring feature should not silently become part of the deployment through a later dashboard update.

Keep the source hierarchy visible. The Commission guidelines were published on 19 May 2026 and updated on 23 July 2026, but remain draft and non-binding; their examples are non-exhaustive. The FAQ, updated on 7 August 2026, is explanatory guidance. Neither displaces the binding AI Act.

2. Step one: identify the relevant AI system

Ask the supplier which components meet the Article 3(1) definition: a machine-based system operating with varying autonomy that infers, from inputs, how to generate outputs such as predictions, content, recommendations or decisions influencing physical or virtual environments. Adaptiveness after deployment is possible, not a mandatory characteristic of every AI system. Use the definition and recital 12, rather than the presence of an “AI-powered” marketing label.

Request a component map distinguishing learned perception, route planning, language generation, fixed rules and conventional safety controls. Ordinary software is not automatically AI, while a fixed model can still fall within the definition. The supplier should explain the inference mechanism sufficiently to support the classification, without the hotel needing source-code access.

The output should be a system inventory tied to product versions and enabled services. Where one model supports several functions, identify each intended purpose and its interfaces. This prevents a defensible navigation assessment from being reused without examination for a newly introduced personnel-management feature.

3. Step two: test the product-safety route

Article 6(1) requires both conditions. First, the AI must be intended as a safety component of a product, or itself constitute a product, covered by Annex I harmonisation legislation. Second, that product must require third-party conformity assessment under that legislation. Being a machine, or containing AI, is insufficient by itself. See Article 6(1) and Annex I.

For a mobile hotel robot, examine what actually prevents hazardous collisions or uncontrolled movement. Is AI perception credited with a safety function? Could its failure or malfunction endanger people or property? Or does an independently justified safety architecture provide the protective function while AI handles non-safety navigation? These questions follow the Act’s Article 3(14) safety-component definition; module names alone cannot answer them.

The Machinery Regulation, Articles 3 and 25 and Annex I, matters because safety components can be digital, including software. Annex I, Part A specifically addresses safety components with fully or partially self-evolving behaviour using machine-learning approaches that ensure safety functions, and machinery embedding such systems in the circumstances specified there. These categories require third-party involvement through the applicable conformity-assessment procedures.

Do not convert that specific provision into a rule that every machine-learning robot needs a notified body. Request the manufacturer’s product category, safety allocation and chosen conformity route, including why third-party assessment is or is not required. The Machinery Regulation generally applies from 20 January 2027; the AI Act’s Article 6(1) and corresponding obligations apply from 2 August 2027 under Article 113. Distinguish present obligations from future supply and modification plans.

For the procurement implications, see Ergasa’s service robot notified-body analysis and Machinery Regulation briefing for Greek hotels.

4. Step three: check Annex III and prohibited uses

Next, compare each intended use with Annex III. Hotel operations can intersect with employment and worker management, biometric identification, biometric categorisation and emotion recognition. The Commission’s Annex III explorer is a useful navigation aid, but the precise wording in the Regulation controls. Assess each feature separately:

Hotel function	Classification question	Evidence to request
Room-service delivery	Transport and navigation are not automatically listed in Annex III; assess Article 6(1) safety functions.	System boundary, collision-protection architecture and conformity route.
Cleaning	Cleaning is not automatically an Annex III use; AI-linked protective functions need the product-safety test.	Safety-function allocation, operating limits and human-access assumptions.
Reception chatbot or concierge	Ordinary guest assistance is not automatically high-risk; Article 50 interaction transparency may apply.	Guest disclosure, permitted tasks and escalation controls.
Staff scheduling or performance	Annex III can cover individual behaviour-based task allocation and monitoring or evaluation of workers.	Decision criteria, employee inputs and consequences of outputs.
Emotion recognition	Annex III addresses permitted emotion recognition; workplace use is generally prohibited, subject to specified exceptions.	Biometric inputs, inferred states, affected people and claimed exception.
Biometric identification or access	Remote biometric identification can be listed; verification solely confirming a claimed identity is excluded from that entry.	Identification versus verification design, enrolment and matching process.

These distinctions come from Annex III points 1 and 4, Articles 5 and 50. A biometric access feature is not cleared simply because the supplier calls it verification: establish whether it only confirms a claimed identity or searches for an identity among people. Data-protection questions also remain separate from high-risk classification.

Screen prohibitions before treating a feature as a permissible high-risk use. Article 5 generally prohibits AI used to infer emotions in workplaces, except where intended for medical or safety reasons. A hotel should not treat employee “mood monitoring” as something routine compliance paperwork can authorise. Guest-facing emotion recognition requires its own assessment of scope, permitted use and transparency under Articles 3, 5 and 50 and Annex III.

For Annex III systems, Article 6(3) provides a limited exception where the system poses no significant risk, including by not materially influencing decision outcomes, and meets the specified conditions. Profiling natural persons remains high-risk for systems referred to in Annex III. A provider relying on the exception must document the assessment and comply with the relevant registration requirement under Articles 6(3), 6(4) and 49(2). This exception does not remove Article 6(1) classification.

5. Establish provider and deployer responsibilities

A hotel using a vendor’s system under its authority will commonly be a deployer, while the entity developing or having the system developed and marketing or putting it into service under its own name is the provider. These are functional definitions, not labels a purchase order can freely assign. Check Article 3(3) and 3(4) against the actual supply chain.

For high-risk systems, Article 25 can shift provider obligations to a distributor, importer, deployer or other third party that applies its own name or trademark, subject to the provision’s contractual qualification, or substantially modifies a system that remains high-risk. Changing the intended purpose of a previously non-high-risk system so that it becomes high-risk can also trigger provider status. Read Article 25 alongside the Article 3(23) substantial-modification definition.

A hotel-branded chassis is therefore a prompt for investigation, not proof that every hospitality operator has become an AI provider. More consequential changes might include repurposing delivery telemetry to evaluate employees or altering the safety-related control stack. Require change review before deployment. Ergasa’s service robot manufacturer analysis addresses the related product-law role questions; manufacturer and AI-provider status should not be assumed identical.

6. Build the procurement evidence file

Ask for an evidence pack before acceptance, not an unsupported declaration that the robot is “AI Act compliant”. The following is a recommended procurement checklist, not a claim that every listed document is universally mandatory:

• System inventory: hardware, software, model and cloud-service versions, with enabled and excluded functions.
• Intended-purpose statement: users, environments, tasks, decision consequences and prohibited configurations.
• AI-definition assessment: which components qualify and the technical basis for that conclusion.
• Product-safety analysis: applicable Annex I legislation, safety functions, failure consequences and conformity-assessment route.
• Annex III mapping: each relevant entry, reasons for inclusion or exclusion, and any Article 6(3) assessment.
• Prohibition and transparency screening: employee monitoring, emotion inference, biometrics and guest interaction.
• Role allocation: provider, deployer, importer and integrator identities, plus responsibility for updates and incidents.
• Change controls: notification triggers for new models, purposes, integrations, safety changes and branding arrangements.

The classification memo should identify evidence gaps, assumptions and the exact configuration approved for purchase. As a governance recommendation, the supplier’s authorised compliance representative should sign its classification position. The hotel’s accountable procurement or deployment owner should sign the acceptance decision, with documented review from machinery-safety engineering and legal or compliance specialists. Add HR and the data-protection officer where personnel or biometric functions warrant their involvement.

This is a recommended sign-off structure, not an AI Act-prescribed classification-memo signature form. It does not replace the provider and deployer obligations set out in Articles 16, 25 and 26.

7. Make the classification a purchasing decision

A useful conclusion is specific: identified navigation and delivery functions are not listed Annex III uses; the product-safety route is supported by named evidence or remains unresolved; personnel and biometric features are excluded or separately assessed. Avoid a blanket “low-risk robot” statement that hides unanswered questions.

If evidence is missing, make its delivery an acceptance condition rather than guessing the outcome. Reopen the assessment when functions, intended purpose or safety architecture change. The practical objective is traceability: a hotel should know what it is buying, which organisation carries each responsibility and what would invalidate the recorded conclusion.

8. Frequently asked questions

Is a room-service robot automatically high-risk?

No. Delivery and navigation are not automatically Annex III uses. Assess the separate product-safety route under Article 6(1).

Does obstacle avoidance make the AI a safety component?

Not by its name alone. Examine its intended safety function and failure consequences using Article 3(14), then test both Article 6(1) conditions.

Is every reception chatbot high-risk?

No. Ordinary guest assistance is not automatically listed. Direct AI interaction can nevertheless trigger disclosure requirements under Article 50.

Can a hotel use AI to assess staff emotions?

Workplace emotion inference is generally prohibited, with medical or safety exceptions specified in Article 5(1)(f). Performance management is not itself such an exception.

Can modifying a robot make the hotel a provider?

Yes, in the circumstances specified by Article 25, including qualifying substantial modifications or a changed intended purpose that makes a system high-risk.

Are the Commission’s classification examples binding?

No. The draft guidelines are non-binding and their examples non-exhaustive. The Regulation governs the assessment.