HOTELLEX → EU AI Act
What the EU AI Act requires of a hotel
The Act's main obligations became applicable on 2 August 2026. These are the 13 duties that reach a hotel, by article, with who actually owes each one.
A fixed worked example — not your property. Computed for a hotel
in Amsterdam that uses AI for hiring, rostering, a guest chatbot and facial check-in, so
every duty is visible at once. Run a lookup for yours — most hotels
will owe fewer.
The facial check-in in that example is not a recommendation.
It is in there to make the biometric duties visible, and it is the clearest case in this
register of one regulation answering permissively while another does not. Under the
AI Act it is neither prohibited nor high-risk — Annex III 1(a) expressly
carves out biometric verification whose sole purpose is confirming a person is who
they claim to be. Under GDPR Article 9(1) it is prohibited by default:
face-matching a guest is biometric data processed to uniquely identify a person. It becomes
lawful only on explicit consent under Article 9(2)(a) — which must be freely given, so
a guest who declines needs an equally quick alternative — and only after a DPIA.
Read the AI Act on its own and you get the wrong answer.
At a glance
| Article | What it requires | Who owes it | Applies from |
|---|---|---|---|
Art. 3(3) | Commission a bespoke AI system and run it as your own, and your vendor's duties become yours | You, as deployer | 2026-08-02 |
Art. 4 | Ensure staff who operate or use your AI systems have sufficient AI literacy | You, as deployer | 2025-02-02 |
Art. 5(1)(f) | PROHIBITED: inferring staff emotions in the workplace with AI | Nobody — it is banned | 2025-02-02 |
Art. 26(1) | Running a high-risk system: oversight, monitoring, and six months of logs | You, as deployer | 2027-12-02 |
Art. 26(7) | Tell your staff before you put a high-risk AI system to work on them | You, as deployer | 2027-12-02 |
Art. 50(1) | Guests must be told when they are talking to an AI, not a person | Provider — verify your vendor | 2026-08-02 |
Art. 50(2) | Machine-readable marking of AI-generated content — your vendor's duty, and what to demand | You, as deployer | 2026-08-02 |
Art. 50(3) | Tell people when a system is reading their face or inferring emotion | You, as deployer | 2026-08-02 |
Art. 50(4) | Publish AI-generated or materially altered imagery of your property, and you must disclose it | You, as deployer | 2026-08-02 |
Art. 50(5) | The disclosures must land at first interaction, and be accessible | You, as deployer | 2026-08-02 |
Art. 86(1) | A rejected candidate can demand to know what the AI did in the decision | You, as deployer | 2027-12-02 |
Annex III, 4(a) | AI used to hire or sift staff is HIGH-RISK — deployer duties apply to you | You, as deployer | 2027-12-02 |
Annex III, 4(b) | AI that allocates shifts, monitors or rates staff is HIGH-RISK too | You, as deployer | 2027-12-02 |
Two that catch people out. Article 50(1) is addressed to
providers, so if you bought your chatbot the design duty is your vendor's and
yours is to verify it. And Annex III 4(b) — rostering and performance
monitoring — catches far more hotels than 4(a) CV screening does.
Art. 3(3)
Commission a bespoke AI system and run it as your own, and your vendor's duties become yours
A "provider" is anyone who develops an AI system — OR HAS ONE DEVELOPED — and puts it into service under their own name or trademark. Buy an off-the-shelf chatbot and use it, and you are a deployer. Commission one, or have a vendor build a bespoke assistant you run as your own, and you are the PROVIDER of that system. Every duty this register describes as "your vendor's" then belongs to you: the Art. 50(1) disclosure design, the Art. 50(2) marking of generated content, and, if the system is ever high-risk, the whole Chapter III conformity apparatus.
What you need in placeEstablish which role you hold in writing, because it decides which duties are yours. Put your own name on a system and the provider duties follow it.
Applies when: uses_ai :: Settle this before reading anything else in the AI Act chapter. It changes who owes almost every other duty.
THE TEST IS "HAD IT DEVELOPED", NOT "PAID FOR IT". Licensing a product other customers also use does not make you its provider, even white-labelled. Commissioning a build specific to you, which you put into service as yours, is the case the definition names. Between those sits a real grey zone — a heavily configured deployment of a shared product — and this register does not pretend to resolve it. Where the answer changes what you owe, get it in writing from counsel and keep the reasoning.
Article 25, which turns a deployer into a provider by branding or substantial modification, is limited to HIGH-RISK systems and does not reach a chatbot. The route that reaches a chatbot is the Art. 3(3) definition itself.
This is the most commercially consequential question in the chapter and the one most often answered by assumption. Hotels commission bespoke booking assistants routinely, then read "the duty is the provider's" as meaning it is somebody else's.
What the text actually says
that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademarkArt. 3(3)
using an AI system under its authority except where the AI system is used in the course of a personal non-professional activityArt. 3(4)
the supply of an AI system for first use directly to the deployer or for own use in the Union for its intended purposeArt. 3(11)
Art. 4
Ensure staff who operate or use your AI systems have sufficient AI literacy
If the property operates any AI system — a booking chatbot, dynamic pricing, a CV screener, guest sentiment analytics — it must take measures to ensure a sufficient level of AI literacy among staff and others dealing with the system on its behalf, taking into account their technical knowledge, experience and training, and the context the system is used in. This is a duty on DEPLOYERS, not only on the company that built the tool.
What you need in placeHave a record of AI-literacy measures for staff who use or are affected by these systems: who was trained, on what, and when.
Applies when: uses_ai :: Any AI system operated by or on behalf of the property. Buying the tool from a vendor does not move this duty to the vendor.
Most operators do not think of themselves as AI companies and so never look for this. It is the cheapest AI Act duty to discharge and the easiest to be caught without.
What the text actually says
Providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staffArt. 4
Ask your vendor
Provide the training material, model limitations and failure modes we need to make our staff competent on this system. commercial leverage — not a legal duty
If they will not: Art. 4 binds YOU, not them — staff competence is not a duty a vendor can discharge on your behalf, and no article obliges them to help. But they hold what you would train anyone on, and a vendor who will not describe the system's limitations is telling you something about how it will behave when it fails.
Art. 5(1)(f)
PROHIBITED: inferring staff emotions in the workplace with AI
Placing on the market, putting into service or using AI systems to infer the emotions of a natural person in the workplace is PROHIBITED, save where the system is intended for medical or safety reasons. This is a prohibition, not a requirement to manage — there is no compliance path that makes it permissible for staff-monitoring or performance purposes.
What you need in placeDo not deploy it. This is a prohibition, not a duty you can discharge with documentation — if such a system is running in a workplace or training context, withdraw it.
Applies when: uses_ai :: Applies to the workplace. Note the carve-out is narrow — medical or safety reasons only.
QUOTE CORRECTED 2026-08-26. The span read "intended to be installed or put into the market"; the source reads "intended to be put in place or into the market". A paraphrase inside quotation marks is the exact failure the span rule exists to catch, and it survived because the live citation test needs --run-network and is skipped by default.
Guest-facing emotion analytics is a different question from staff monitoring and is not covered by this prohibition limb — but may engage GDPR Art. 9 and the transparency duties. This register does not resolve that; take advice.
What the text actually says
the placing on the market, the putting into service for this specific purpose, or the use of AI systems to infer emotions of a natural person in the areas of workplace and education institutions, except where the use of the AI system is intended to be put in place or into the market for medical or safety reasonsArt. 5(1)(f)
Art. 26(1)
Running a high-risk system: oversight, monitoring, and six months of logs
A deployer of a high-risk AI system must use it in accordance with the instructions for use; assign human oversight to named people with the competence, training, authority and support to exercise it; ensure input data it controls is relevant and sufficiently representative; monitor operation and suspend use and inform the provider where the system presents a risk; and keep the logs the system generates automatically for at least six months. Where a decision affects a person, that person must be told a high-risk system is being used on them.
What you need in placeHave logs retained for at least six months, human oversight assigned to a competent person, and input data relevant to the intended purpose.
Applies when: ai_recruitment or ai_workforce :: The Annex III limbs a hotel realistically hits are 4(a) recruitment and selection and 4(b) task allocation, monitoring and evaluation. A guest-facing chatbot is high-risk on neither.
Minimum retention of automatically generated logs: 6 months — quoted: “keep the logs automatically generated by that high-risk AI system to the extent such logs ”
THE LOGS ARE ONLY YOURS IF YOU CAN GET THEM. Art. 26(6) binds you to retain logs "to the extent such logs are under their control", and a SaaS deployment routinely leaves them under the vendor's. Retention you cannot perform is not an excuse; it is a procurement failure you can still fix. See the vendor asks below.
DATE. Annex III high-risk obligations were postponed to 2 December 2027 by the Digital Omnibus (in force 27 July 2026). Article 50 transparency was not postponed. Do not let the delay of one become an assumption about the other.
Art. 26(9) does not create a new assessment — it requires you to USE the Art. 13 information to perform the GDPR Art. 35 DPIA you already owe. If your DPIA for an AI recruitment tool does not draw on the vendor's instructions for use, it was written without the inputs the Regulation assumes.
What the text actually says
take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systemsArt. 26(1)
assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary supportArt. 26(2)
keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six monthsArt. 26(6)
inform the natural persons that they are subject to the use of the high-risk AI systemArt. 26(11)
Ask your vendor
Supply the instructions for use for this system, complete to Article 13(3). owed under Art. 13
A compliant answer contains
- 13(3)(a) — provider identity and contact details, and those of any authorised representative
- 13(3)(b) — intended purpose; accuracy level WITH THE METRICS IT WAS TESTED AGAINST, robustness and cybersecurity per Art. 15; circumstances that degrade them; known risks; performance for the specific groups the system is used on; input data specification
- 13(3)(c) — pre-determined changes to the system and its performance fixed at conformity assessment
- 13(3)(d) — the human oversight measures under Art. 14, including the technical measures that help us interpret output
- 13(3)(e) — computational and hardware requirements, expected lifetime, and required maintenance and software updates
- 13(3)(f) — the mechanisms for collecting, storing and interpreting the logs
If they will not: A high-risk system is not lawfully on the market without these. A vendor who cannot produce them either does not have a conformity assessment, or does not accept the system is high-risk — and you need to know which, because if they are wrong you are operating a non-conforming system on your own staff.
Give us access to the automatically generated logs, and confirm retention meets six months. owed under Art. 26(6)
A compliant answer contains
- How we export or retain the logs ourselves, not merely view them in your console
- Your retention period, and what happens to logs if we terminate the contract
- Confirmation the logs cover the events Art. 12 requires the system to record
- The format, so the logs are readable without your product
If they will not: Art. 26(6) binds US to keep these for at least six months. If the logs sit only in your product and you delete them at 30 days, we cannot comply, and the breach is recorded against us rather than you.
Commit to a serious-incident notification path and the timescales you work to. owed under Art. 73
A compliant answer contains
- A named contact and channel for notifying us, not a general support queue
- Your reporting deadlines to market surveillance authorities: 15 days ordinarily, 2 days for widespread infringement or serious disruption of critical infrastructure, 10 days where a death is involved
- That you will notify US on becoming aware, since our monitoring duty under Art. 26(5) depends on it
- What you treat as a serious incident under Art. 3(49)
If they will not: Art. 73 puts the reporting duty on the provider, but the clock can start when the DEPLOYER becomes aware. Without a notification path in both directions the deadline can expire while each of you assumes the other is handling it.
Provide the EU declaration of conformity and CE marking evidence for this system. owed under Art. 47
A compliant answer contains
- The declaration identifying this system and the version we are running
- Which conformity assessment route was used
- The harmonised standards or common specifications applied
If they will not: For an Annex III high-risk system this is the document that says it may lawfully be placed on the market at all. Its absence is not a paperwork gap.
Art. 26(7)
Tell your staff before you put a high-risk AI system to work on them
Before putting a high-risk AI system into service or use at the workplace, a deployer that is an employer must inform workers' representatives and the affected workers that they will be subject to its use. This is a duty owed to staff, and it sits alongside — not instead of — any information duty owed to candidates or guests.
What you need in placeHave a documented notice to affected workers and their representatives, issued BEFORE the system goes live — not on the day.
Applies when: ai_recruitment or ai_workforce :: Triggered by deploying ANY high-risk system at the workplace, not only a hiring tool.
What the text actually says
Before putting into service or using a high-risk AI system at the workplace, deployers who are employers shall inform workers' representatives and the affected workers that they will be subject to the use of the high-risk AI system.Art. 26(7)
Art. 50(1)
Guests must be told when they are talking to an AI, not a person
An AI system intended to interact directly with people must be designed so those people are informed they are interacting with an AI — unless it is obvious to a reasonably well-informed, observant and circumspect person in the context. For a booking chatbot or concierge assistant, assume it is not obvious and disclose.
What you need in placeHave the disclosure visible at the point the guest starts interacting — first message on the chatbot, not buried in the privacy policy.
Applies when: ai_customer_facing :: Any AI that converses with guests directly — booking chatbot, concierge assistant, voice agent. The "unless it is obvious" exemption is narrower than it sounds and should not be relied on for a chatbot that answers in fluent prose.
READ THE DUTY-HOLDER. Article 50(1) is addressed to PROVIDERS, not deployers. If you bought the chatbot off the shelf, the design duty is your vendor's and your job is to verify they have met it. If you built it, or put your own name or trademark on it, you are the provider and it is yours. This register cannot tell which of those you are.
What the text actually says
AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspectArt. 50(1)
Ask your vendor
Confirm in writing how the system informs users they are talking to an AI, and where that disclosure appears. owed under Art. 50(1)
A compliant answer contains
- The exact wording shown to the user, and at what point in the conversation
- That it appears at or before the FIRST interaction, which is what Art. 50(5) requires
- Whether it is served in the page markup or injected later by script — a disclosure that only exists after hydration is not reliably present
- How it behaves on the surfaces we actually run: web widget, WhatsApp, voice, in-app
- Whether we can alter or remove it in configuration, and what happens to your compliance position if we do
If they will not: Art. 50(1) is a DESIGN duty on the provider, so a vendor who cannot describe the mechanism has not built one. If the answer is that we control it in configuration, the duty has effectively been handed to us without being said out loud, and our configuration is now a compliance artefact.
Tell us whether you consider us the provider of this system, and why. commercial leverage — not a legal duty
If they will not: Not a legal duty on them, but the single most useful question you can ask. If the deployment is bespoke and runs under your name, Art. 3(3) may make YOU the provider — see eu.aiact.provider-status-if-commissioned — and every "your vendor owes this" in this register inverts. Ask early; the answer is cheap now and expensive later.
Art. 50(2)
Machine-readable marking of AI-generated content — your vendor's duty, and what to demand
Providers of AI systems generating synthetic audio, image, video or text must ensure the output is marked in a machine-readable format and detectable as artificially generated or manipulated. This duty is the PROVIDER's. Use a third-party tool to produce marketing copy or imagery and the marking duty is that tool vendor's, not yours. What is yours is the consequence of publishing unmarked synthetic content, and the Art. 50(4) disclosure duty where that content is a deep fake. The action here is procurement, not engineering.
What you need in placeHave your vendor's written confirmation that outputs are marked machine-readable, and a way to check it. The marking duty is theirs; verifying it is your procurement.
Applies when: uses_ai :: Any generative tool used to produce published copy, imagery, audio or video — including general-purpose assistants used by the marketing team.
DO NOT READ THE ABSENCE OF A MARK AS PROOF OF ANYTHING. An image carrying no C2PA manifest is an image carrying no manifest. That is not evidence the image is synthetic, and not evidence it is authentic. Any finding built the other way round collapses on contact with the vendor.
Systems already on the market before 2 August 2026 have until 2 DECEMBER 2026 to comply with this paragraph. That grace period belongs to the PROVIDER. It is not a deadline a hotel can miss, and it is routinely mis-sold as one.
There is a carve-out where the AI performs an assistive function for standard editing or does not substantially alter the input data. Ordinary retouching sits inside it. That carve-out does more work than most summaries admit.
What the text actually says
Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulatedArt. 50(2)
Ask your vendor
State how your system marks generated output, and give us a way to verify a mark on a file we supply. owed under Art. 50(2)
A compliant answer contains
- Which technique is used — C2PA / Content Credentials manifest, a SynthID-style watermark, a cryptographic signature, or metadata only
- Whether the mark survives what we actually do to files: re-encoding, resizing, CDN transformation, screenshotting
- A named tool or endpoint we can run against an output file to confirm the mark is present and valid
- Which output types are marked and which are not — text is frequently unmarked even where images are
- For systems on the market before 2 August 2026, the date they will meet Art. 50(2), which cannot be later than 2 December 2026
If they will not: Cannot name a technique: there is no mark. Names one but cannot give a verification path: you have no way to evidence compliance and neither have they. Metadata-only marking that your own CDN strips on upload is marking that does not survive your publishing pipeline.
Warrant in the contract that outputs supplied to us are marked, and that you will notify us if that changes. commercial leverage — not a legal duty
If they will not: Commercial leverage, not a legal duty — Art. 50(2) obliges them to mark, not to indemnify you. Worth having anyway, because the Art. 50(4) and reputational exposure of publishing unmarked synthetic content lands on you, not them.
Art. 50(3)
Tell people when a system is reading their face or inferring emotion
A deployer of an emotion recognition system or a biometric categorisation system must inform the people exposed to it that it is operating, and must process the personal data in accordance with the GDPR. Unlike Art. 50(1), this duty sits with the DEPLOYER — it is yours, not your vendor's.
What you need in placeHave the notice delivered to the people exposed to the system before they are exposed, plus the GDPR lawful basis that permits the processing at all.
Applies when: ai_biometric :: Emotion recognition or biometric categorisation.
CITATION CORRECTED 2026-08-26. This was carried as Art. 50(4) and is Art. 50(3). 50(4) is a different duty entirely — deep fakes and public-interest text — and is registered separately as eu.aiact.transparency-deepfake-imagery. The paragraphs bind different things, so the wrong number sends an operator to the wrong duty.
Facial check-in is probably NOT high-risk. Annex III 1(a) expressly excludes biometric VERIFICATION whose sole purpose is confirming a person is who they claim to be — which is exactly what matching a guest to their own booking does. Identifying people who have not presented themselves is a different thing. Emotion inference on STAFF is separately PROHIBITED outright — see eu.aiact.prohibited-emotion-recognition-workplace.
What the text actually says
Deployers of an emotion recognition system or a biometric categorisation system shall inform the natural persons exposed thereto of the operation of the system, and shall process the personal data in accordance with Regulations (EU) 2016/679Art. 50(3)
Art. 50(4)
Publish AI-generated or materially altered imagery of your property, and you must disclose it
A deployer who generates or manipulates image, audio or video content constituting a deep fake must disclose that the content has been artificially generated or manipulated. A deep fake is content resembling existing persons, objects, places, entities or events that would falsely appear to a person to be authentic. A fully generated room, or a composite showing a view the room does not have, is squarely within it. Unlike Art. 50(1) and 50(2), this duty is the DEPLOYER's — it is yours, and it does not move to the tool vendor.
What you need in placeHave a disclosure on published imagery that is AI-generated or materially manipulated, and an inventory of which published assets that covers.
Applies when: uses_ai :: Any AI-generated or AI-composited imagery of the property, its rooms, its views or its surroundings used in marketing, OTA listings or the booking flow.
WHERE THE LINE ACTUALLY FALLS. Fully generated room imagery and composites showing a view the property does not have are the mischief the paragraph names. Sky replacement, object removal and colour grading are far more arguable and your vendor's counsel will call them assistive editing. This register does not claim the line is crisp; it claims you need an inventory to sit on either side of it.
THIS CANNOT BE ANSWERED BY SCANNING YOUR WEBSITE. Whether an image is generated, composited or merely retouched is not observable from the published file — absence of a provenance mark proves nothing either way. The only reliable source is your own production process: who made the asset, with what tool, and how much of it is real. That makes this an inventory question, not an audit finding.
The same paragraph separately covers AI-generated TEXT published to inform the public on matters of public interest. Hotel marketing copy is not that. Do not stretch it: a duty asserted where it does not apply discredits the ones that do.
Consumer law bites here independently and often harder. Imagery that materially misleads a guest about what they are booking is an unfair commercial practice under the UCPD whatever the AI Act says — see eu.ucpd.misleading-claims.
What the text actually says
Deployers of an AI system that generates or manipulates image, audio or video content constituting a deep fake, shall disclose that the content has been artificially generated or manipulatedArt. 50(4)
Art. 50(5)
The disclosures must land at first interaction, and be accessible
Every disclosure required by Art. 50(1), 50(3) and 50(4) must be given to the person concerned clearly and distinguishably, at the latest at the time of the first interaction or exposure, and must meet the applicable accessibility requirements. A disclosure buried in a privacy policy, or shown after the guest has already typed a message to the chatbot, does not discharge the duty.
What you need in placeHave each disclosure given at the FIRST interaction and in an accessible form — late or unreadable is not disclosed.
Applies when: ai_customer_facing or ai_biometric :: Applies to whichever of the Art. 50 disclosures you owe. It governs their delivery, not whether you owe them.
THIS IS THE PARAGRAPH A WEBSITE SCAN CAN ACTUALLY EVIDENCE. Whether a disclosure is present in served markup before the first interaction is directly observable from outside. Whether an image was generated, or whether staff received literacy training, is not. Weight findings accordingly.
"Accessible" carries the Union accessibility requirements, so a disclosure that is visual-only, or that a screen reader does not reach, is incomplete even when it is present and timely.
What the text actually says
The information referred to in paragraphs 1 to 4 shall be provided to the natural persons concerned in a clear and distinguishable manner at the latest at the time of the first interaction or exposureArt. 50(5)
Art. 86(1)
A rejected candidate can demand to know what the AI did in the decision
Where you take a decision on the basis of output from an Annex III high-risk system, and that decision produces legal effects or similarly significantly affects the person adversely in their health, safety or fundamental rights, that person has the right to obtain from YOU — the deployer, not the vendor — clear and meaningful explanations of the role the AI system played in the decision procedure and the main elements of the decision taken. A rejected job applicant, or an employee refused a promotion where a scoring tool contributed, is exactly this person.
What you need in placeHave a route by which an affected person can get a meaningful explanation of a decision — and confirm your vendor can supply what that route needs.
Applies when: ai_recruitment or ai_workforce :: Annex III point 2 (critical infrastructure) is excluded from this right; the employment limbs at point 4 are not.
YOU CANNOT ANSWER THIS WITHOUT THE VENDOR, BUT YOU OWE IT ANYWAY. The explanation is due from you. If the system is a black box you licensed and the vendor will not describe how output is produced, you will be unable to discharge a duty that is nonetheless yours. That is a procurement problem to solve BEFORE deployment, which is why Art. 13(3)(b) requires the provider to describe the technical capability to explain output. Ask for it while you still have commercial leverage.
This sits alongside, not instead of, GDPR Art. 22 on automated decision-making and Art. 15(1)(h) on meaningful information about the logic involved. Where personal data is processed, expect both to be invoked in the same letter.
What the text actually says
shall have the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision takenArt. 86(1)
Ask your vendor
Describe the technical capability of the system to explain its output, in terms we can put in front of an affected person. owed under Art. 13(3)(b)
A compliant answer contains
- The technical capabilities of the system to provide information relevant to explaining its output
- Which features or inputs drove an individual decision, retrievable for a named case after the fact
- How long that per-decision explanation data is retained and how we export it
- Any documented limits on explainability, stated plainly rather than implied
If they will not: Art. 86 makes the explanation OUR duty and Art. 13(3)(b) obliges the provider to describe this capability for a high-risk system. A vendor who cannot describe it is selling a system we cannot lawfully use for decisions about people.
Annex III, 4(a)
AI used to hire or sift staff is HIGH-RISK — deployer duties apply to you
AI systems intended to be used for the recruitment or selection of natural persons — placing targeted job adverts, analysing and filtering applications, or evaluating candidates — are high-risk under Annex III. A property using such a system is a DEPLOYER and must, among other duties, use it in accordance with the provider's instructions, assign human oversight to people with the competence, training and authority to exercise it, monitor operation, and keep the automatically generated logs it controls.
What you need in placeHave the provider's Article 13 instructions for use, an assigned competent human overseer, and retained logs before the system screens a single applicant.
Applies when: ai_recruitment or ai_workforce :: Art. 26 binds the deployer of ANY high-risk system, so this covers both Annex III limbs: 4(a) recruitment and selection, and 4(b) allocating tasks, monitoring or evaluating staff, and decisions on promotion or termination. A guest-facing chatbot is not high-risk on either limb.
DATE CORRECTED 2026-08-26. This was carried as 2026-08-02. The Digital Omnibus on AI (in force 27 July 2026) postponed the Annex III high-risk obligations to 2 December 2027; Annex I moves to 2 August 2028. Article 50 transparency was NOT postponed and still applies from 2 August 2026 — the two are routinely confused, and the confusion runs both ways.
High-risk obligations under Art. 6(2) and Annex III have applied since 2 August 2026. The separate Art. 6(1) route — AI as a safety component of a regulated product — does not apply until 2 August 2027 and is unlikely to be relevant to accommodation.
What the text actually says
AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidatesAnnex III, 4(a)
Deployers of high-risk AI systems shall take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systemsArt. 26(1)
Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.Art. 26(2)
Annex III, 4(b)
AI that allocates shifts, monitors or rates staff is HIGH-RISK too
Annex III is not limited to hiring. An AI system used to allocate tasks based on individual behaviour or personal traits, to monitor or evaluate the performance and behaviour of staff, or to inform decisions on promotion or termination, is high-risk in its own right. Rota optimisation that scores individuals, and performance dashboards that rank them, are squarely within this limb — and it catches far more hotels than CV screening does.
What you need in placeHave the provider's instructions, a named human overseer with authority to override, and log retention running before rotas or evaluations depend on it.
Applies when: ai_workforce :: Task allocation, monitoring, performance evaluation, promotion or termination. Scheduling that merely fills shifts without scoring individuals is outside this limb.
DATE CORRECTED 2026-08-26. This was carried as 2026-08-02. The Digital Omnibus on AI (in force 27 July 2026) postponed the Annex III high-risk obligations to 2 December 2027; Annex I moves to 2 August 2028. Article 50 transparency was NOT postponed and still applies from 2 August 2026 — the two are routinely confused, and the confusion runs both ways.
This was missing from an earlier version of this register, which gated all high-risk duties on recruitment alone. An operator who does not screen CVs but does run performance analytics would have been told no high-risk obligations applied. They do.
What the text actually says
to make decisions affecting terms of work-related relationships, the promotion or termination of work-related contractual relationships, to allocate tasks based on individual behaviour or personal traits or characteristics or to monitor and evaluate the performance and behaviour of persons in such relationshipsAnnex III, 4(b)
GDPR and ePrivacy alongside
An AI system that touches guest or staff data engages these at the same time. Four further instruments — the DSA, Data Act, NIS2 and the 2024 Product Liability Directive — can also bear on how a hotel governs AI; they are flagged with sources on the home page rather than curated here, because naming them honestly is useful and analysing them shallowly is not.
Get consent before setting non-essential cookies or trackers on the booking site
Storing information on, or reading information from, a visitor's device is allowed only with that visitor's prior consent, given after clear and comprehensive information about the purposes. Strictly necessary storage — the session that carries a booking through checkout — is exempt. Analytics, advertising, remarketing pixels, chat widgets and A/B testing are not.
Applies when: always
The CONSOLIDATED text is cited on purpose. The original 2002 wording required only a right to refuse; the consent requirement was introduced in 2009. Citing CELEX 32002L0058 for this duty would link an operator to a source that does not state it.
The quality of consent — freely given, specific, informed, unambiguous, and as easy to withdraw as to give — is set by the GDPR, not by this Directive.
This is an EU Directive. It binds Member States, and the duty an operator can actually be prosecuted under is the national law transposing it — wording, thresholds and penalties vary by Member State. The national layer is where that lands; where this register has no national layer for your country, treat this as the duty category, not the rule text.
What the text actually says
Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consentArt. 5(3), as amended by Dir. 2009/136/EC
CCTV, door locks and guest data need a lawful basis and a privacy notice
Personal data collected from guests — booking records, identity documents, CCTV footage, electronic door-lock logs, Wi-Fi and captive-portal data, loyalty profiles — must be processed lawfully, fairly and transparently, limited to what is necessary, and the guest must be told at the point of collection who is processing it, why, on what basis, for how long and what rights they have. CCTV needs signage at the point of entry to the monitored area, and cameras must not cover rooms, bathrooms or changing areas.
What you need in placeHave signage at the point of capture and a privacy notice covering the footage: purpose, lawful basis, retention, and who to contact.
Applies when: always
A statutory guest-registration duty is a lawful basis for the registration data it requires and for nothing beyond it. Retaining a scanned passport image because it is convenient is a separate processing operation needing its own basis, and several Member States restrict or prohibit copying identity documents outright.
What the text actually says
processed lawfully, fairly and in a transparent manner in relation to the data subjectArt. 5(1)(a)
adequate, relevant and limited to what is necessary in relation to the purposes for which they are processedArt. 5(1)(c)
Delete guest data when the purpose it was collected for has ended
Personal data may be kept in identifiable form only for as long as is necessary for the purpose it was collected for. Set and actually apply a retention period per category — booking records, CCTV, door-lock logs, marketing consents — and delete or anonymise on schedule. Where a guest asks for erasure and no other basis to keep the data applies, erase it. "We keep everything" is not a retention policy.
What you need in placeHave a documented retention schedule per data category, and a deletion mechanism that actually runs rather than a policy that describes one.
Applies when: always
Retention period for guest records: cannot be determined — The GDPR sets no period. The retention floor for any given category is fixed by OTHER law — tax and invoicing rules, the national guest-registration statute, employment law — and those periods are national. This register will not invent a number that the source does not contain.
Retention periods collide. The tax rule says keep the invoice; the guest-register rule says keep the form; the GDPR says do not keep either longer than necessary. Resolving that collision is national-layer work and, for the register mechanics, sometimes municipal.
What the text actually says
kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processedArt. 5(1)(e)
Facial check-in is prohibited processing unless you have explicit consent and a real alternative
Matching a guest's face to their booking is the processing of biometric data for the purpose of uniquely identifying a natural person. Article 9(1) GDPR PROHIBITS that outright, and it becomes lawful only if one of the Article 9(2) exceptions applies. For a hotel the only realistic one is 9(2)(a) explicit consent. Consent is valid only if it is freely given, which means a guest who declines must be able to check in another way, just as quickly and without disadvantage. If facial check-in is the only route, or the alternative is a longer queue, the consent is not freely given and the processing has no lawful basis at all.
What you need in placeHave explicit consent captured and logged per guest, an equally quick non-biometric alternative, and a completed DPIA — all BEFORE go-live, not after.
Applies when: ai_biometric :: Any face-matching at check-in, in-room access or payment. Applies whether or not the system is "AI" — GDPR does not care how the match is computed.
THE AI ACT IS THE PERMISSIVE ONE HERE, AND THAT IS THE TRAP. Facial check-in is not a prohibited practice under Article 5, and Annex III 1(a) expressly carves biometric VERIFICATION out of the high-risk list where the sole purpose is confirming a person is who they claim to be. Read the AI Act alone and facial check-in looks permitted. GDPR Article 9(1) prohibits it by default. Both are true; the second is the one that stops the project.
DO NOT REACH FOR LEGITIMATE INTERESTS. Article 6 lawful bases do not unlock Article 9 special-category data — you need a 9(2) gateway as well as a 6(1) basis, and legitimate interests is not one of the gateways. "Necessary for the contract" is also not a 9(2) gateway, and a guest can plainly be checked in without their face.
A DPIA is required before you start. Article 35 requires one where processing is likely to result in high risk, and new-technology biometric identification of guests is the paradigm case. Doing the DPIA after go-live does not cure the defect — the obligation is prior.
The AI Act duty still applies on top: Article 50(3) requires you to inform people exposed to an emotion recognition or biometric categorisation system. Verification against a booking is arguably neither of those, but if you infer anything about the person beyond "is this the guest", you are into 50(3) and possibly Annex III 1(b) or 1(c) as well.
Employees are a harder case than guests, not an easier one. Consent from staff is rarely accepted as freely given because of the imbalance of power, so biometric time-and-attendance sits on much weaker ground than guest check-in does.
What the text actually says
the processing of genetic data, biometric data for the purpose of uniquely identifying a natural personArt. 9(1)
the data subject has given explicit consent to the processing of those personal data for one or more specified purposesArt. 9(2)(a)
Every article of the Act, and what we did with it
Article text and numbering cross-checked against artificialintelligenceact.eu, the independent AI Act explorer. Operative quotes are taken from EUR-Lex.
Thirteen duties out of a 113-article Regulation invites a fair question: did you read the rest? This is a verdict for every article — including the ones that never reach a hotel, and the one we assessed and excluded. A build test asserts these tile Articles 1 to 113 exactly, with no gaps and no article counted twice, so this stays true rather than merely having been true once.
6 in this register11 your vendor's — ask for it1 assessed, excluded35 context, no duty on you60 never reaches a hotel
| Articles | Verdict | Why |
|---|---|---|
| Art. 1–2 Ch. I | Context, no duty on you | Subject matter and scope. Article 2 is where the Act reaches a non-EU operator: output used in the Union brings you in even with no EU establishment. It creates no standalone duty, but it decides whether any of the rest applies to you at all. |
| Art. 3 Ch. I | In this register → eu.aiact.provider-status-if-commissioned | Definitions. 3(3) provider, 3(4) deployer and 3(11) putting into service decide who owes almost everything else, which is why they are modelled as an obligation rather than left as a glossary. |
| Art. 4 Ch. I | In this register → eu.aiact.ai-literacy | AI literacy. Binds deployers directly and has applied since 2 February 2025. |
| Art. 5 Ch. II | In this register → eu.aiact.prohibited-emotion-recognition-workplace | Prohibited practices. 5(1)(f) — emotion inference in the workplace — is the limb a hotel realistically reaches, via wellbeing or engagement analytics sold for staff management. The other limbs were assessed: subliminal manipulation, exploitation of vulnerability, social scoring, predictive policing, untargeted face scraping and real-time remote biometric identification in public for law enforcement are not configurations of a hotel system we can construct. 5(1)(g), biometric categorisation inferring protected characteristics, is the nearest miss and is noted on the obligation. Two further prohibitions were added by the Digital Omnibus and apply from 2 December 2026 (AI nudification tools, and systems capable of generating child sexual abuse material); neither is reachable by hotel operations. |
| Art. 6–7 Ch. III | Context, no duty on you | High-risk classification. 6(1), the product-safety route via Annex I, does not reach hotel systems. 6(2) plus Annex III does, at point 4 — employment. Article 7 is the Commission's power to amend Annex III, so it is a watch item rather than a duty: the list this register filters on can grow. |
| Art. 8–11 Ch. III | Your vendor's — ask for it | Requirements for high-risk systems: compliance, risk management, data governance and technical documentation. Every one binds the PROVIDER. An operator cannot perform them and is not asked to — but they are what the Article 13 instructions for use attest to, so they are the substance behind that ask. |
| Art. 12 Ch. III | Your vendor's — ask for it | Automatic record-keeping. The provider must build logging in; Article 26(6) then obliges YOU to retain those logs for at least six months. That pairing is the reason log access is a contract term and not an afterthought — see the vendor ask on eu.aiact.high-risk-deployer-operating-duties. |
| Art. 13 Ch. III | Your vendor's — ask for it | Transparency to deployers, and the single most useful thing an operator can demand. 13(3)(a)-(f) is an itemised list of what instructions for use must contain, which converts "are you compliant?" into a checklist a vendor either satisfies or does not. |
| Art. 14–15 Ch. III | Your vendor's — ask for it | Human oversight, and accuracy, robustness and cybersecurity. Provider duties, but both surface in what you can demand: 14 defines the oversight measures Article 26(2) then requires you to staff, and 15 is why the accuracy METRICS belong in the instructions rather than a marketing claim. |
| Art. 16–24 Ch. III | Never reaches a hotel | Obligations of providers, authorised representatives, importers and distributors. A hotel occupies none of those roles when it buys and runs a system. If Article 3(3) makes you the provider of a commissioned system, Article 16 is where your duties begin — which is the whole point of settling that question first. |
| Art. 25 Ch. III | Context, no duty on you | Responsibilities along the value chain. Frequently cited as the route by which branding a chatbot makes you its provider; it is not. Article 25 is limited to HIGH-RISK systems. The route that reaches a chatbot is the Article 3(3) definition. |
| Art. 26 Ch. III | In this register → eu.aiact.high-risk-deployer-operating-duties | Deployer obligations for high-risk systems. The core operating duties: instructions, human oversight, input data, monitoring, six months of logs, worker notification, DPIA input, and telling people a high-risk system is being used on them. |
| Art. 27 Ch. III | Assessed, excluded | Fundamental rights impact assessment. Assessed and excluded: Article 27 binds deployers that are bodies governed by public law, private entities providing public services, and deployers of the Annex III 5(b) and 5(c) systems — creditworthiness and life or health insurance pricing. A hotel is none of those. It would reach a hotel only through a public-service contract, which is outside this register's subject. Named here rather than omitted, because "no FRIA" should be a finding you can point at, not an absence. |
| Art. 28–39 Ch. III | Never reaches a hotel | Notifying authorities and notified bodies — how conformity assessors are designated and supervised. Structural machinery of the regime; no operator duty in any configuration. |
| Art. 40–46 Ch. III | Never reaches a hotel | Harmonised standards, common specifications, conformity assessment procedures and derogations. These bind providers and assessment bodies. They matter to an operator only as the thing an Article 47 declaration attests to. |
| Art. 47 Ch. III | Your vendor's — ask for it | EU declaration of conformity. For an Annex III high-risk system this is the document saying it may lawfully be on the market at all. Asking for it is the cheapest possible check, and its absence is not a paperwork gap. |
| Art. 48–49 Ch. III | Never reaches a hotel | CE marking and registration in the EU database. Provider duties. Note the asymmetry: Article 49(3) requires DEPLOYERS who are public authorities to register their use — a private hotel has no such duty, which is why Article 71 is also not-operator. |
| Art. 50 Ch. IV | In this register → eu.aiact.transparency-guest-facing-ai | Transparency. Fully modelled: 50(1) provider disclosure for direct interaction, 50(2) provider marking of synthetic output, 50(3) deployer notice for emotion recognition and biometric categorisation, 50(4) deployer disclosure of deep fakes and public-interest text, 50(5) timing and accessibility. 50(6) is a savings clause preserving Chapter III and other Union transparency law and creates no separate duty. This is the chapter that applies from 2 August 2026 and was NOT postponed. |
| Art. 51–56 Ch. V | Never reaches a hotel | General-purpose AI models. These bind model providers — the firms training the models, not those building on them. Commissioning a bespoke assistant can make you the provider of an AI SYSTEM under Article 3(3); it does not make you the provider of a MODEL. The one place this touches an operator is Article 53(1)(b) and Annex XII, the information a model provider must give downstream providers: if you become a provider, that is the documentation you inherit the right to. |
| Art. 57–63 Ch. VI | Never reaches a hotel | Regulatory sandboxes and real-world testing, including the SME provisions. An opportunity available to providers, not a duty owed by a deployer. |
| Art. 64–70 Ch. VII | Never reaches a hotel | Governance: the AI Office, the AI Board, the scientific panel, the advisory forum and national competent authorities. Article 70 is worth knowing operationally — it names who you would actually hear from — but imposes nothing on you. |
| Art. 71 Ch. VIII | Never reaches a hotel | EU database for high-risk systems. Registration falls on providers, and on deployers who are public authorities. A private hotel registers nothing. |
| Art. 72 Ch. IX | Your vendor's — ask for it | Post-market monitoring by providers. Not your duty, but it is the mechanism that is supposed to surface a degrading system, and Article 26(5) requires you to feed it by informing the provider when use presents a risk. Worth confirming the vendor actually operates one. |
| Art. 73 Ch. IX | Your vendor's — ask for it | Serious incident reporting. The duty to report to market surveillance authorities is the provider's, but the clock can start when the DEPLOYER becomes aware — 15 days ordinarily, 2 for widespread infringement or serious disruption of critical infrastructure, 10 where a death is involved. Without an agreed notification path in both directions the deadline expires while each party assumes the other has it. |
| Art. 74–84 Ch. IX | Context, no duty on you | Market surveillance, enforcement, mutual assistance and Union safeguard procedures. These describe what happens TO you rather than anything required OF you: powers of entry, information requests, and orders to withdraw. Article 74 read alongside Article 26(5) is why suspending use and telling the provider is the correct first move when something looks wrong. |
| Art. 85 Ch. IX | Context, no duty on you | Right to lodge a complaint with a market surveillance authority. A right held by others against you, not a duty of yours — and the realistic route by which a guest or a rejected candidate initiates contact. |
| Art. 86 Ch. IX | In this register → eu.aiact.right-to-explanation | Right to explanation of individual decision-making. Owed by the DEPLOYER to the affected person for Annex III high-risk decisions, excluding Annex III point 2. |
| Art. 87 Ch. IX | Context, no duty on you | Reporting of infringements and protection of reporting persons — the whistleblower route under Directive (EU) 2019/1937. Relevant to how an internal concern is likely to leave the building, rather than a duty under this Act. |
| Art. 88–94 Ch. IX | Never reaches a hotel | Supervision and enforcement in respect of general-purpose AI model providers, including the Commission's powers to request documentation and conduct evaluations. Directed at model providers. |
| Art. 95–96 Ch. X | Context, no duty on you | Codes of conduct for voluntary application, and Commission guidelines. Voluntary by construction. Worth tracking: guidelines under Article 96 are where the Commission settles questions this register currently marks as contested, including where assistive editing ends and a deep fake begins. |
| Art. 97–98 Ch. XI | Never reaches a hotel | Delegation of power and committee procedure. Institutional mechanics. |
| Art. 99–101 Ch. XII | Context, no duty on you | Penalties. Article 99(4) carries the €15 000 000 or 3% of total worldwide annual turnover, whichever is higher, that attaches to breaches of Article 50 and the deployer obligations. Article 99(3) is the €35 000 000 or 7% band reserved for the Article 5 prohibitions. Article 101 concerns fines for model providers. |
| Art. 102–113 Ch. XIII | Context, no duty on you | Final provisions, including the amendments to existing Union legislation. Two matter operationally: Article 111 on systems already on the market before the application dates, and Article 113 on the staggered application dates themselves — which the Digital Omnibus then amended, moving Annex III high-risk to 2 December 2027 and Annex I to 2 August 2028 while leaving Article 50 on 2 August 2026. |
What the deliverables actually look like
This register tells you a DPIA is required, or that you can demand Article 13 instructions from a vendor. Reasonable next question: what does one of those look like when it is done? These are real outputs from C2MD, the compliance agent in this framework — published as samples, watermarked DEMO DATA.
Two of these are hospitality; two are not. The DPIA and the FRIA
counter-example are generated for hotel and public-service systems respectively. The risk
assessment and governance bundle below are built for Northwind Bank and a
credit-decision agent — the worked example the suite ships. Their structure transfers to a
hotel; their risks, data categories and Annex III classification do not.
GDPR Article 35 DPIA — for a hotel
See a completed hotel DPIA →
A guest agent doing bookings,
dynamic pricing and biometric check-in. Processing activities, risk table, measures,
sign-off. This is the document facial check-in requires before go-live.
Article 27 FRIA — and why you don't owe one
See the counter-example →
A public-service system that
genuinely triggers Art. 27, shown so the exclusion in the scope table above is something
you can check rather than take on trust.
EU AI Act governance dossier
See a conformance summary →
Systems inventory and risk
classification, per-system records, Art. 9–17 alignment, obligations checklist — the
provider-side map your vendor asks are asking for.
Agent risk assessment
See a risk classification →
Risk category, provider-vs-deployer
role, lawful basis, special-category flags, required deliverables.
Governance bundle
See AGENTS.md / SOP.md →
The governance files an agent
is actually operated against, in plain Markdown.
Not sure how your systems classify?
C2MD — the compliance agent in this framework — classifies an AI system against the Act and GDPR and tells you which assessments it triggers. It is the definitive authority here; this register points at the duties, C2MD rules on the system. Run a lookup and it will offer the assessment.