The Hospitality Operator's EU AI Act Compliance Playbook

I spent Saturday on a video call with the operations director of a fourteen-unit casual-dining group in Belgium and the Netherlands. He had a copy of the European Commission’s July 18 Guidelines on GPAI providers open in one tab and a contract with a “menu-intelligence” vendor open in another. His question was the one every multi-unit operator in the EU is asking this week: is my menu assistant going to set me on fire on August 2?

The honest answer is: probably not on August 2 itself — the immediate Article 53 obligations land on the providers of general-purpose AI models, not the restaurants who stitch those models into a recommender. But the honest answer is also a trap, because the Act is a downstream-of-downstream regime. The way a model provider documents its training data on August 2 is the way you, the operator, will have to prove provenance the first time a regulator, a customer’s lawyer, or your own insurer asks. The compliance burden does not stop at OpenAI’s door. It steps from the model provider to your platform vendor, from your platform vendor to your IT director, and from your IT director to the manager on shift in unit four who pressed “approve” on an AI-generated allergen warning that turned out to be wrong.

Here is the contrarian thesis, stated cleanly so we can argue about it for the next 3,500 words: every hospitality operator running a GenAI assistant of any kind needs three documents on the shared drive by August 2 — a model inventory, a vendor questionnaire, and an incident-response plan. Not because the Act compels them in those exact words. Because if you don’t have them, you cannot answer the questions the Act lets other people ask you.

I’ll walk through what changed on July 18, what lands on August 2, the three documents in detail, and what a fourteen-unit operator should do this week. Mark interpretation throughout — there are places where the Guidelines are deliberately vague and I’ll say so.

What actually moved on July 18

The Commission published its Guidelines on the scope of GPAI provider obligations on Friday, July 18. The Guidelines are not law. They are the Commission’s reading of how it will apply Articles 51-55 of the Act, and the implementation timeline maintained by the Future of Life Institute confirms what every operator advisory has been saying since spring: the GPAI chapter applies on August 2, 2025, with a two-year grace period for models placed on the market before that date.

Three things in the Guidelines mattered for operators. First, the Commission clarified what counts as a “general-purpose AI model” using a training-compute threshold and a generality test — the artificialintelligenceact.eu GPAI Guidelines overview does the cleanest summary I’ve read. If a model was trained on more than 10^23 FLOPs and displays significant generality across tasks, it’s a GPAI. Almost every foundation model your vendor is reselling is in scope. Second, the Commission spelled out what “placing on the market” means in a way that closes the loophole some vendors were eyeing — fine-tuning a GPAI does not get you out of the chapter; modifying one above a certain compute threshold makes you the provider of a new GPAI. Third, the Commission published an indicative form for the public summary of training data that providers must publish. The summary is short — a couple of pages — but it includes data categories, large public datasets used, and the provider’s licensing approach.

The summary is the document that will shape how operators verify whether they can use a model in front of a customer. If the public summary says “trained on a mixture of licensed data, publicly available web data, and synthetic data” with no further breakdown, your data protection officer will tell you that’s the floor of what you can put in a privacy notice. If the summary names specific datasets and licenses, your vendor has work to do but you have a defensible answer.

The other piece the Guidelines did was give downstream deployers — that’s most operators — a reading of when they inherit GPAI provider obligations. The threshold is genuine modification: prompt tuning, retrieval-augmented generation, system prompting, even light fine-tuning below the compute cutoff doesn’t make you the provider. Substantial fine-tuning above the threshold does. I haven’t seen a single restaurant group anywhere near that threshold, and I would be very surprised if one shows up before 2027. That should be a relief; treat it as one.

What lands on August 2

The Article 53 obligations on GPAI providers are concrete. They have to maintain technical documentation, make information available to downstream deployers, comply with EU copyright law on training data, and publish the training-data summary. Providers of “GPAI with systemic risk” — the GPT-4-class and above tier — get a heavier set: model evaluations, adversarial testing, incident reporting, and cybersecurity protections. The Nemko summary of the 2025 GPAI rules update breaks the tiers out cleanly for operators who don’t want to read the regulation in raw form.

What lands on operators indirectly is downstream. Article 50 transparency obligations — which apply to deployers of certain AI systems — apply on a different timeline (August 2, 2026 for most). But the chain is connected. The reason transparency works at all in 2026 is because the August 2025 GPAI obligations create the documentation operators will need to inherit. The Commission knows this; the Software Improvement Group’s EU AI Act summary does the best plain-English version of the cascade.

The other thing landing on August 2 is the Code of Practice. Published in July, it is voluntary, signed by most of the major model providers (with a couple of holdouts and the usual asterisks), and it operationalises Article 53. If your vendor’s foundation model provider has signed the Code, you can largely take their compliance posture as evidence — though I’d still get it in writing. If they have not signed, you should ask why and what their alternative is. There is a real chance the answer is interesting.

Now the fines. Article 101 lets the Commission penalise GPAI providers up to €15 million or 3% of global turnover, whichever is higher. That’s the line that gets read out loud in trade press. It applies to providers, not deployers. But the broader fines schedule under Article 99 — applying to other Act violations — runs higher, up to €35 million or 7% for prohibited-practice breaches. The point of the fines, for operators, is not that any specific clause makes you the target. It’s that fines this size mean every model provider you work with is going to flow contract language down to you, and if you sign that language without reading it, you are going to inherit obligations you didn’t price.

The model inventory: what’s in it, how to build it

The first of the three documents. The model inventory answers four questions for every AI system in your stack: what is it, who provides it, what does it touch, who in our org owns it.

Start with a clean spreadsheet. The columns I use, in order:

System name — the friendly name, the way your team refers to it: “menu-copy generator,” “drive-thru voice,” “shift-swap recommender.”

Vendor — the company on the invoice. Not the underlying model provider. The vendor is who you yell at.

Underlying model(s) — every GPAI that touches a customer-facing output. If your vendor uses OpenAI for one function and Anthropic for another, list both. If they refuse to tell you, that’s a finding for the questionnaire.

Use case category — recommender, generator, classifier, voice. Map to the Act’s categories where possible: this matters because the high-risk Annex III list and the Article 50 transparency cases are written in terms of categories, not products.

Data inputs — what personal data, if any, enters the system. Customer name? Order history? Loyalty ID? Free-text complaint? Voice recording? Camera frame? Be precise; “customer data” is not an entry.

Data outputs — what comes back, where it shows up, and whether a human is in the loop before it reaches a customer.

Customer-facing flag — yes/no. This drives the Article 50 transparency obligations downstream.

Risk classification — minimal, limited (transparency), high-risk, or prohibited. Get a lawyer to sign this column. I’ve seen operators check the wrong box for the most consequential reason: their lawyer wasn’t shown the screenshot.

Provider status — has the vendor’s underlying model provider published an Article 53 training-data summary? Has the vendor itself signed any code? Has the vendor passed your questionnaire?

Owner — a named human in your organisation. Not “IT.” Not “operations.” A person. Phone number in another column.

Last reviewed — a date column. Quarterly review is the floor; monthly until December if you’re a multinational with EU exposure.

This is more rigour than most operators have ever applied to their tech stack. It is also exactly what your insurer is going to ask for in the next renewal cycle. I have spoken to two cyber underwriters in the last fortnight who are now asking for AI inventories on the operator side at quote, and both said the absence of one moves quotes by 8-12% — not on day one, but by Q1 2026.

Build the inventory in plain Google Sheets or Excel and put it on the same shared drive as the data-protection impact assessments. Don’t buy a “GenAI governance platform” yet. The vendors selling those are still figuring out what their own product is and pricing reflects optionality, not value.

There is a tactical move that pays off here. When you do the inventory, walk every customer-facing AI feature in your unit, including the ones nobody mentioned because they came bundled with the POS or the loyalty engine. Most operators I’ve worked with discover three or four AI features that no one knew were AI, because the vendor enabled them in a release note. McDonald’s discovered the same thing on a different scale — the forthcoming May piece on the McDonald’s AI drive-thru walks through what happens when an enterprise loses track of where the AI is in its own stack. The inventory is the antidote.

The vendor questionnaire: ten questions, no more

This is the document I get asked for most often. The vendor questionnaire is what you send to every AI vendor in the inventory — the menu-copy people, the recommender people, the voice agent people — to get on paper what their compliance posture is.

The temptation is to send something forty questions long. Don’t. Vendors won’t answer it, and the answers you get back will be generic. Ten questions, written so they cannot be answered with marketing language.

1. Identify every GPAI model that produces output exposed to our customers, by provider and version. This is the question vendors hate most because it forces them to commit to a specific OpenAI/Anthropic/Google/Mistral lineage and version string.

2. For each model, has the provider published an Article 53 training-data summary? Provide the URL or PDF. Don’t accept “we’ll forward when available.” Accept “here it is” or “here’s our timeline.”

3. Has the model provider signed the GPAI Code of Practice? If not, what is their alternative compliance posture? A “no, but” answer can be fine. A “we don’t know” answer is not.

4. What personal data flows into the model? Is it used for inference only, or for training/fine-tuning? Provide the data-processing agreement clause. This is your DPA hook. If their answer is inconsistent with the DPA, you have a finding.

5. Where are inputs and outputs stored, for how long, and under whose control? Provide the regional infrastructure diagram. Operators with EU customers need to know whether prompts route through the US, where the responses live, and how long the vendor retains them. Most vendor questionnaires duck this; yours shouldn’t.

6. How is the system protected against prompt injection, jailbreaks, and adversarial inputs in a customer-facing setting? This is the question I’d most like to see in every operator questionnaire and almost never do. The threat model for a customer-facing GenAI in hospitality is “customer attempts to get the bot to promise something we can’t deliver.” You need to know how the vendor defends against it.

7. What incidents have you experienced in the last 12 months that affected customer-facing output? Describe each and how it was resolved. A vendor that has had zero incidents is either too small to know or lying. Their answer here predicts how they’ll handle yours.

8. How are we, the deployer, notified of model updates or behavioural changes? What is the notice period? This is the most underrated question. The day your menu-copy assistant starts writing in a different register because the underlying model was silently swapped, you want to have a contractual right to advance notice.

9. What is your roadmap for compliance with Article 50 transparency obligations effective August 2, 2026? Forward-looking, but the answer separates serious vendors from opportunistic ones.

10. Provide a named contact, in your organisation, responsible for EU AI Act compliance, with email and phone. No named contact is a finding by itself.

Send the questionnaire by email, give vendors three weeks, and grade the answers. The grading matters more than the questions. A vendor that takes three weeks to answer with substance is in a different category from one that returns boilerplate in 24 hours. The third category — vendors who claim the questionnaire is “not applicable because we are not a GPAI provider” — needs a follow-up call. They may be right (most vendors are deployers themselves), but they still owe you a usable answer because their answers determine your inheritance of obligations from theirs.

I’ve heard pushback from operators who say this much rigour reads as adversarial. It isn’t. The vendors you want to work with are grateful for the structure — it tells them you take their product seriously enough to govern it — and the vendors who can’t tolerate the questions are vendors you don’t want anyway. The upcoming May piece on Yelp’s AI stack walks through what mature vendor governance looks like from the platform side; the same logic runs in reverse on the operator side.

The incident-response plan: what good looks like

The third document is the one operators most often skip. The model inventory and the vendor questionnaire are paperwork. The incident-response plan is what you actually use when something goes wrong at 9:47 on a Saturday night.

Three triggers. Define each one specifically.

Trigger one: customer-facing factual error. The menu-copy AI hallucinates a gluten-free claim for a dish containing wheat. The drive-thru voice agent quotes the wrong price. The recommender suggests an allergen the customer flagged. The plan needs to say, in one paragraph, who at the operator (named human, named role) decides whether to (a) take the feature offline, (b) post a correction, (c) notify affected customers, and (d) escalate to the vendor. There should be a 30-minute SLA on the first three of those.

Trigger two: data-protection incident. Personal data flowing into the AI ends up somewhere it shouldn’t — exposed to another customer, leaked through a model’s training, or breached at the vendor. This trigger has to hook into your existing GDPR breach-notification process and add the AI-specific bits: model version, prompts logged, outputs reviewed.

Trigger three: vendor change without notice. Your vendor swaps the underlying model, changes its retention policy, or pushes a behavioural update that your team notices in production. This is the trigger most operators don’t have written down. The response is to invoke the contractual notice clause, pause the feature, and document.

The plan needs a paragraph on each. Then it needs four roles named: the on-shift manager who detects, the IT or operations duty officer who triages, the named owner from the inventory who decides, and the compliance lead who reports. Phone numbers next to each name. Backup contacts in another column.

The plan needs an annual tabletop exercise. I run them with operators using a single scenario card and a one-hour Zoom. The scenario for July 2025 I’d use is this: Saturday 19:30. A customer in unit four screenshots the recommender suggesting a paella as “ideal for our pescatarian guests” — the dish contains chicken stock. The screenshot is on a regional food blog by 20:15. By 21:00, the operations director gets a press call. If you cannot run that scenario through your plan and answer every question in under 30 minutes, the plan needs more work.

The plan also needs an audit trail. Every incident needs a one-page write-up: what happened, who decided what, when the vendor was told, what changed. File the write-ups in the same shared drive as the inventory. By the end of the year, the write-ups become the evidence you produce if a regulator asks.

The forthcoming May piece on the EU AI Act applied to restaurants covers the regulatory architecture in more detail; my point here is narrower and more practical. Compliance is operational discipline expressed as paperwork. The plan is the operational part.

What a fourteen-unit operator should do this week

I’ll be specific because the Belgian operator from Saturday asked me for a checklist and the checklist is generalisable. If you operate between five and fifty units in the EU and have any GenAI in customer-facing production, your week looks like this.

Monday. Calendar a 30-minute call with your IT lead, your operations director, and your DPO. Agenda: build the model inventory. Schedule the call before lunch. Use the columns from this piece. Aim to fill ten rows by Wednesday.

Tuesday. Draft the vendor questionnaire — the ten questions are above. Send it to every vendor in your inventory by end of day. Three-week deadline. CC the named contact at each vendor; if you don’t have a named contact, that is question ten and the call to find one is also today.

Wednesday. Draft the incident-response plan. One page is fine for v1. Three triggers, four roles, phone numbers. Send it to the operations director for review by close of business.

Thursday. Internal walkthrough. Twenty-minute meeting with the unit managers of two pilot units. Walk them through the three triggers, the named-owner column, and how they’d raise an issue. Test the phone numbers.

Friday. Run the tabletop scenario above. One hour. Record the call. If anyone in the room cannot answer a question, the plan needs that question added. Iterate over the weekend.

Following Monday. Send the inventory, questionnaire (sent, awaiting responses), and v1 plan to your insurer’s broker, your DPO, and the CEO’s chief of staff. The point is not approval. The point is that three people outside the working group know the documents exist.

Operators who do this in the next two weeks will be in the top decile of EU hospitality compliance posture by August. That is not a high bar. The vast majority of operators — including ones who have been talking publicly about AI for two years — do not have a model inventory. They will when something goes wrong; better to have it before.

The cost question, which I will not duck

I get asked some version of this every week: isn’t this a lot of overhead for a margin business? The honest answer is yes and also no. Yes, because the documents take real time to build and maintain — call it 80 hours of senior time in year one, 30 hours in year two. No, because the alternative is a contingent liability that lands on your CFO’s desk the first time something goes publicly wrong, and the size of that liability is unbounded.

There is a related question, sharper, which is whether the customer-facing AI was worth deploying in the first place. The upcoming May piece making the case against the AI premium argues — persuasively, I think — that a lot of customer-facing AI in hospitality is reverse-justified after the spend. I largely agree. But the operator’s situation in July 2025 is not whether to deploy. It’s that they have already deployed. The recommenders, the voice agents, the menu generators are live in production for hundreds of EU operators. The decision in front of you is not whether to use AI; it’s whether to govern the AI you’re already using.

The framing matters because the budget conversation goes differently if you treat the documents as governance for an existing capability rather than as a tax on a new one. The CFO who balks at “AI compliance line item” approves “operational risk documentation for vendor X.”

The piece I am not writing

There is a version of this column where I tell you the EU AI Act is going to be enforced harshly in 2026, that the first big operator fine is coming, and that you need to scramble. I am not writing that piece because I do not know that it’s true. The enforcement posture of the Commission and the national supervisory authorities is genuinely uncertain. The Code of Practice exists in part to signal that the Commission would rather get to compliant providers than punish defectors in year one. There is a real chance — Mark interpretation — that the first eighteen months of enforcement focus on the largest model providers and that operator-side scrutiny is light through 2026.

That doesn’t change my advice. The reason to build the three documents is not the marginal probability of a fine in 2026. It’s the certainty that you will be asked the questions the documents answer — by your insurer, by a journalist, by a regulator, by a customer’s lawyer, by your own board — and the documents are how you answer in 30 minutes instead of three weeks.

The documents are also how you discover the dumb stuff in your stack. Every inventory exercise I have facilitated has surfaced at least one AI feature that the operator did not know was AI, was paying for, and was not using. The first hour pays for itself.

Final note for the operations director

The operator from Saturday will be on a call with me again next week. He plans to have the inventory done, the questionnaire sent, and v1 of the plan drafted. He told me his real worry isn’t the August 2 deadline. It’s the conversation with his vendors three months from now, when he hands them the questionnaire and finds out which ones can answer it. He thinks the answers are going to determine which vendors his group renews with in 2026.

I think he’s right. The forcing function of the Act, for operators, is not the immediate August 2 obligation on the providers. It’s the new clarity it gives operators about which vendors are serious and which were riding the hype cycle. Compliance posture is becoming a procurement signal. Vendors who can’t answer the ten questions on the page above are about to discover that they’ve lost the renewal — not because the operator wants to switch, but because the operator’s lawyer won’t sign off.

That’s the part of the August 2 story the trade press isn’t writing yet. The Act is going to consolidate the hospitality AI vendor market, not by enforcement, but by procurement. The operators who build the three documents this month will be the ones making the consolidation happen.

Build the documents.

— Priya covers operators for TableTransfers. Tips: [email protected].