> ## Documentation Index > Fetch the complete documentation index at: https://docs.recepai.ai/llms.txt > Use this file to discover all available pages before exploring further. # Guest data protection > How the platform protects your guests' data: what it collects and refuses, where it lives, who can see it, how every look is bounded, how erasure and retention work, and how it is all kept that way. Your guests hand a hotel more than a name. A phone number, an e-mail address, where they slept, what they asked for, what they told your AI staff in confidence. Protecting that is not a setting on this platform — it is how the platform is built. This page describes what it does, so that you can read it yourself and hand it to whoever reviews these things for your hotel. Everything below exists today, on the platform your guests already use. *** ## Collect little, refuse the rest Your AI staff hold what a receptionist would write on a guest card, and nothing more. **What is held:** the guest's name, the phone number or e-mail address they chose to be reached on, the stay (room, dates, party size, preferred language), what they asked for, the preferences they chose to have remembered, their ratings, and the conversation itself. **What is refused, by design — there is no field for it, so it cannot be stored by accident:** | Refused | How | | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Identity documents** — passport or national ID numbers | Never read from a PMS. Never asked for on any form. | | **Card details** | A guest pays on a hosted payment page. The platform holds a reference to the card, never the card itself. | | **A child's contact details** | When a PMS lists a minor, their name, date of birth, phone and e-mail are dropped before the record is written. Only the fact that a child is in the room remains. | | **Anything beyond the stay** | No guest screen asks for an address, a birthday, a contact list or a location. | A PMS feed tells the platform **who is in which room** — it is not treated as proof of identity. Before a guest can see their own record, they prove they hold their own phone. Room number and surname alone open nothing personal. *** ## Every hotel is walled off from every other Your guests' data is separated from every other hotel's, and that separation is enforced by the platform, not by people remembering to be careful. Every way the platform reads or writes guest data is checked automatically for that boundary before it can be released; a screen that could reach another hotel's guest does not ship. *** ## Where it lives The platform's stores, backups and processing run in the **European Union**. Data is encrypted in transit and at rest. All traffic to the platform passes through a protective edge that filters attacks before they reach the application. The application accepts nothing that did not come through it. *** ## Who can see it — and how every look is bounded This is the part most systems get wrong, and it is where this platform is most deliberate. Most guest-data incidents in hospitality are not break-ins: they are legitimate accounts reading lists they were allowed to read. So the platform is built on one principle — **a list is not a file** — and every look at a full contact detail is bounded and on record. Every staff screen shows a guest's phone number and e-mail address **masked** — enough to recognise the guest, not enough to copy the number. That applies to every list, every detail panel, every live update pushed to a screen, every log your team can read. To see a full phone number or e-mail, a team member opens that one guest's record and chooses to show it. The platform records **who** looked, at **which guest**, at **which field**, and **when**. Each person has a small hourly allowance for this — a receptionist calling guests all day never notices it; a session reading through the guest list is stopped and reported to us. Copy-to-clipboard and click-to-call keep working from the guest's record, so nobody's job gets harder. A team member sees only the areas they were granted, at the level they were granted — view or manage — and settings only if they were given settings. A screen not explicitly opened to them is closed. A manager can grant only what they themselves hold; nobody can hand out more access than they have. New team members are invited by e-mail and set their own password. A manager never knows it. Changing a password, an e-mail address or someone's access ends that person's existing sessions at once, everywhere. Anyone who manages settings, people or data proves a second factor at sign-in — a code on their phone, an authenticator app or a code by e-mail — and re-proves it periodically. A hotel can require it for every member of its team. The e-mails your team receives about a new booking or a request show the guest's contact details masked; the full value lives on the guest's record and is reached from there. The platform's own logs are scrubbed of guest phone numbers, addresses and message text. When a booking is passed to your channel manager, the guest's name travels in full and their contact details travel **masked, or not at all** — your choice, per hotel. The platform's own record of what was sent never contains the contact details. Our own staff cannot download a hotel's guest data — not the address book, not a consent file, not a guest's record. The right to download belongs to a named person at your hotel and is granted only by us. Every download then needs a fresh one-time code sent to that person's phone, is recorded, and is announced to your hotel's managers by a notice that cannot be switched off. A consented address book leaving a hotel is exactly the event that should never go unnoticed, so it cannot. *** ## Your AI staff take instructions from you, not from a document or a guest What a guest types, and what an uploaded document says, are treated as **information**, never as instructions. Your AI staff show a guest only the record that guest has proven is their own, and a document in the library cannot change the rules they work under. Prices are calculated by the platform, never by the language model, so a figure a guest is quoted is one your settings produced. *** ## The guest's rights, built in | A guest asks to… | What you do | What the platform does | | --------------------------- | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **See their data** | Export it from the guest's profile | Produces the guest's record, behind the download code, and records the export | | **Be forgotten** | Erase them from their profile | Removes or anonymises the guest across **every** place their data reached — profile, stays, conversations, requests, reviews, bookings, notifications, the room list. Money and tax records keep their figures with the person removed. A run that cannot finish alerts us and is retried automatically; it is never silently half-done | | **Have a detail corrected** | Edit it on the profile | Records the change. A new phone number or e-mail is treated as new for marketing purposes — the earlier consent does not carry over | | **Stop marketing** | Nothing — the guest does it themselves | An unsubscribe link or a stop reply is honoured on that channel and stays honoured, whatever audience is built later. See [Marketing consent](/ai-manager/account/marketing-consent) | Merged duplicates are one person, so a request applies to the whole history. An erased guest stays erased: a later edit or merge cannot quietly bring them back. *** ## Nothing is kept for ever Retention is a mechanism, not a policy document. A scheduled process removes what has expired, hotel by hotel, and reports what it did. | Data | Kept for | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Conversations with your AI staff | **12 months** by default; your hotel can set a shorter or longer window | | Contact details on a stay, a survey or a booking | **90 days** after the stay ends — the stay record remains, without the contact | | Names on a closed request | **90 days** after it closes | | Recipients and search text in the platform's own records | **90 days** | | Departed guests in the room list | **90 days** after check-out | | A guest's profile | A set number of years after their **last activity of any kind** — a stay, a booking, a message, a review, a request. Five by default; your hotel can set its own. An inactive profile is anonymised, not hidden | | The record of a booking passed to your channel manager | About **three months**, and it never contains contact details | | The record of a connected PMS's activity | **90 days**, without guest contact details | *** ## Backups you cannot lose Backups are kept in the European Union, independently of the live system, with a **deletion lock**: neither a mistake nor an intruder with our own credentials can remove them. Every backup is verified before it is stored. A restore has been rehearsed against a real copy, not assumed. *** ## Kept that way * **Every change** that touches security, money, identity or guest data is reviewed by an independent reviewer before release, and is not released on a failed review. * **The platform was audited end to end in 2026** — secrets, the perimeter, the wall between hotels, sign-in and sessions, everything reachable without an account, and guest data itself. Every finding was fixed by a mechanism, and every fix carries an automated check that fails the build if the same class of fault ever returns. * **The rules above are enforced by the platform**, not remembered by people: the tenant wall, the masking, the reveal record, the download gate and the retention sweep are all checked automatically on every release. We do not publish thresholds, findings or the inner workings of individual controls. Publishing them would help exactly the people they exist to stop. *** ## Ask us Tell us your hotel name and what your review is asking. We answer security questionnaires directly. **Do not send a guest's details to us by e-mail.** If a request concerns one guest, act on their profile — the platform records what it did.