Workflow and actors
With engineering, operations, data protection and PMS owners, we trace the concierge or widget from guest to booking, messaging and payment boundaries, reproduce failures, and prioritise remediation and retest.
Service · AI code audit · Hotels & hospitality
AI code audit for hotels and hospitality.
You shipped an AI concierge on Lovable, a booking widget on v0 or a review-reply bot on Cursor. We audit before one guest reads another's conversation, or before a PMS token ends up in the client bundle.
The workflows, examples and figures on this page are illustrative composites and modelled targets, not measured client results. In a real project, we define the baseline, thresholds and human review with your data before rollout.
What we solve
PCI scope doesn’t disappear because an AI built it.
An AI concierge has access to guest requests, reservation records and, if the booking-engine integration was rushed, fields close to payment data. A booking widget built on v0 can ship with the Supabase service_role key in the bundle. A review-reply bot sometimes trains on past responses that contain last names and room numbers.
We audit the code your team built with AI through the sector lens: guest and reservation isolation, careful handling of PCI scope, custody of PMS and booking-engine tokens, and the logs where last names, dates and truncated card references show up when they shouldn’t.
Implementation contract
How it runs in production
Systems and data
We review client and server code, APIs, authentication, database and RLS policies, storage, secrets, logs and PMS or booking-engine connectors handling bookings, messages, last names and payment references.
Exceptions and risks
Testing avoids real data and booking or payment operations unless explicitly authorised in a safe environment. An exposed key, cross-booking leak or unexpected payment field triggers immediate containment.
Human review
The hotel confirms property, guest and booking boundaries; privacy or the PCI owner validates applicable handling, and engineering accepts the fix. The auditor retests before closure.
Implementation pattern
We model guest, booking and property boundaries, then combine code review, API ownership tests, bundle and secret inspection, data-flow tracing, and verification of logs and policies.
Relevant integration
We audit only the tokens, webhooks and scopes actually used by Mews, Cloudbeds, Opera, SiteMinder, Booking or other systems in scope, without assigning the same capabilities to every provider.
What we build for this sector
Use cases that ship to production.
Isolation
Guest and reservation isolation
Ownership filters on reservation, message and request queries. The target control should prevent an authenticated guest from reading another's conversation, invoice or request by changing an ID.
Modelled acceptance target: no cross-reservation leaks
PCI
Watch what touches payment scope
If the AI agent sees any payment-flow data, even truncated fields or card references, PCI scope follows. We trace what reaches the model, what stays in logs and what travels to external providers.
Modelled acceptance target: PCI scope drawn and documented
Tokens
Custody of PMS and booking-engine tokens
Tokens for Mews, Cloudbeds, Opera, SiteMinder, Booking, where they live, what they can do, whether they're in the client bundle, whether they rotate. And what happens if one property's token leaks into another's.
Modelled acceptance target: tokens off the client · rotatable
PII in logs
Last names, room numbers and dates in logs
console.log statements with guest data surviving the build. Hosting platforms retaining logs for weeks. What's ‘debug’ for your team is personal-data retention under GDPR.
Modelled acceptance target: no guest PII in external logs
Illustrative composite scenario · modelled figures and targets, not client results
A hotel group with 11 properties.
Hypothetical boutique chain with 11 hotels and one shared AI concierge built on Lovable. Illustrative composite scenario modelling the scope of an audit before enabling requests involving reservations and billing; it does not describe a client or actual findings.
Modelled audit hypothesis
Modelled risk to test: the concierge might handle wifi, breakfast and transfer questions correctly while a reservations API without an ownership filter could accept any reservation ID. The check-in photo upload could also expose a Supabase service_role key in the client.
Modelled remediation target
Modelled illustrative outcome: an audit could prioritise 3 critical findings within a set of 9: an ownership filter on the reservations API, removal of the client-side service_role through a signed upload endpoint, RLS policies on reservation and message tables, and scrubbing external logs that might contain last names or room numbers.
Modelled target: 3 criticals remediated before rollout to 11 properties
We connect to your stack
Integrations that matter in this sector
Frequently asked
What clients ask us
- 01
We handle guest data and room numbers. How do you treat it?
Under NDA, with read-only repository access. We don't touch real data: we read code and migrations. If we need to probe an endpoint, we use synthetic accounts in a staging environment.
- 02
We have an old PMS (Opera, Sihot) and the AI agent talks to it via API. Do you cover that?
Yes. We audit the connector, what permissions it asked for, what tokens it stores, how it handles errors and retries. If your PMS has no modern API and integration runs on flat files, we read that too.
- 03
If the AI agent brushes against the payment flow, does it affect our PCI scope?
Probably yes, though the exact shape depends on what the agent sees. We document which payment-flow data reaches the model and logs, tell you how to isolate it, and provide what your PCI auditor will ask for.
- 04
We get reviews on Booking and reply with a bot. Is there risk in that?
Small but real: the bot can train on past replies that include last names, cite room numbers or specific stays, and post text you wouldn't want on a public review. We audit what context reaches it and what it publishes before it goes live.
- 05
What is the end-to-end process, and who closes the audit?
At intake we agree scope, environments and owners. We combine static review with dynamic tests in staging using synthetic accounts across reservations, PMS connections and logs; the report prioritises findings and assigns each remediation to an owner on your team. We then retest corrected controls, and the hotel's designated owner accepts closure against the agreed criteria.
Same sector, other services
Trust
Safe, traceable AI,
enterprise-ready.
We design for privacy from the start, human control, traceability, usage limits, permissioning and documentation. For sensitive processes, we help assess risk and applicable obligations under GDPR and the EU AI Act.
- 01We never train models on your data without explicit authorization.
- 02Human review built-in for processes where risk demands it.
- 03Traceability: prompts, sources, permissions, errors and metrics, all documented.
- 04Privacy, security and control integrated from day one.
- 05Solutions engineered to be maintained, audited and improved over time.
GDPREU AI ActAEPDISO 27001 readyEU data residency
Personal diagnosis
We work with
few clients.
Every engagement is led personally by one of the partners. If there's a fit, you get a personal first read of your case within one business day, not a canned demo.
How we work
- 01Tell us which process eats your time
- 02Personal reply within one business day
- 0320-minute call, no demo, no pitch