Privacy Policy.

The Aikebom platform is provided by a sole trader (empresário em nome individual) registered in Portugal (“Aikebom”, “we”). Contact: hello@aikebom.com.

For this website (including the book-a-demo form), Aikebom is the data controller. For a deployed concierge, the client — the event organiser or the hotel — is the controller of their guests’ data, and Aikebom processes it on their behalf under a data-processing agreement (available on request).

No account, no sign-up. Using a concierge in the browser creates a session (an HMAC-signed, httpOnly cookie) holding: the conversation history (including transcripts of voice conversations), the trip preferences you mention (dates, interests, dietary needs), and any itinerary you build. That is what lets you leave and pick up where you stopped. The session is anonymous unless the link you arrived on identifies you — a verified guest link, or a reference of the client’s own, both described below.

A hotel or resort concierge is normally not open to the public: by default it opens only for the property’s own guests, who arrive on a verified link the property issues at check-in. That is a door, not a login — there is still no account and no password. But the session it opens is not anonymous: it keeps what the link carries about you (below) for as long as the session lasts, so the concierge can greet you and route your requests.

Three optional additions exist when a client uses them: a reference of the client’s own on the link you arrive on (such as a ticket or booking number, which we do not check), kept with your session and shown to staff with any request you raise; a verified guest link (a signed link carrying, at most, your booking reference, your name, your room or seat, and a guest tier if the property uses one — so the concierge can greet you and route requests. It is issued for your booking and stops opening after a set time: a week to 30 days by default, never more than a year — and, where the property’s booking system reports your checkout, shortly after your stay), and reservation data pushed by the property’s management system (booking dates, room number, moves, and the contact details it holds for you — email address, phone number, language) so answers stay current.

Where a property switches on the check-in welcome, that link is emailed to you as you check in, to the address its booking system holds — and, where the property has also told us it collects WhatsApp consent at check-in, a short greeting goes to the number that system holds. The two carry different things, deliberately: the email carries your first name and the link, while the WhatsApp greeting is a fixed message carrying your first name. Neither carries anything you have written. You can stop the WhatsApp messages by replying STOP, and you can ask us to stop the emails at any time.

When you ask the concierge to pass a request to the staff of the event or property, they see it together with the booking it was raised under, where there is one (such as your name, room and dates), and how you raised it: in the web chat, by voice, on WhatsApp or through your own AI assistant.

Events have one published cut-off for everyone: shortly after the event ends (by default about two weeks after the final day), every session — conversations, profiles, itineraries — is deleted automatically.

Hotels & resorts delete per guest, on the guest’s own clock, triggered by inactivity: once you stop using the concierge, your conversations, your plan and what you told the concierge are deleted about a week after your last message, and no later than the daily deletion run 45 days after it. Booking details a property’s booking system sends us (your name, room, dates and contact details) follow your stay instead: where that system reports your checkout or a cancellation, they are deleted about a week later; and no later than the daily deletion run 45 days after the later of your stay and the last update we receive about your booking. A few operational records — such as a request you raised through your own AI assistant — follow their own, equally short clocks. A known checkout date only ever protects a still-in-house guest from early deletion; it is never what triggers deletion. Conversations are not kept for the life of the property; the short notes that remain are listed below.

Where the property’s booking system reports your checkout, checkout also closes the door: access to the concierge ends shortly after your checkout day. Where it does, that is a separate and much shorter clock than deletion, and it is what guarantees the inactivity clock actually starts — so a guest who has left cannot keep a session alive indefinitely simply by carrying on the conversation.

Both schedules are enforced by Aikebom in the engine itself — they are not settings a client can quietly extend. After deletion, what remains in our systems is usage statistics — counts and costs, plus short notes: the topics of questions the concierge could not answer, each with an example written by the AI and with most email addresses and phone numbers removed; brief summaries of replies guests rated poorly, with the same removal; the names and dates of places it offered to book; and short excerpts of requests from outside AI agents we could not serve. These have no fixed deletion date. What reached the providers listed under Sub-processors below follows their retention terms, not this schedule. We also keep, if you asked us to stop messaging you, or an email to your address bounced permanently or was reported as spam, a keyed-hash record of that email address or phone number, kept for no other purpose than to keep that exclusion in place. Deleting a session also disables any itinerary share links it created.

Voice conversations are processed in real time: audio is streamed for transcription and replies are synthesized as speech. We do not store the audio. The text transcript joins your conversation history and follows the same retention as chat, above.

No advertising or tracking cookies, no profiling for ads, no selling or renting data — ever. No feature pools one client’s guest conversations into another client’s knowledge or reports. Our platform administrators can see, across clients, the topics guests could not get answered and how often each came up, with the properties and events concerned and a download; we use that to decide what public local facts to add to the shared layer that every property and event in a place draws on. They see a client’s example questions and suggested fixes only one client at a time: when supporting that client, on that client’s own dashboard and reports, as its staff see them. We do not train any model on your data ourselves, and the providers that see your conversation text to generate a reply — OpenAI and Anthropic, and the Vercel AI Gateway that routes to them — are used under terms that exclude training on the content we send. The other providers listed under Sub-processors operate under their own terms, and we don’t make that commitment on their behalf.

Strictly functional only — every cookie we set is listed below, with what it is for and how long it lasts. We set no advertising or tracking cookies, which is why you don’t see a consent banner. A concierge guest normally gets only the first one; the others need a staff pass, a password, a staff sign-in or a choice of language on this website.

The concierge also keeps a few small things in your browser’s own storage rather than in a cookie — for example an offline copy of the chat and map pages, and which announcements and daily briefings you have dismissed.

If you book a demo or join the early-access list, we store what you submit (email, and whatever else you choose to fill in) and use it solely to respond — including a confirmation email. Write to us and we’ll delete it.

Where someone is invited to sign in to the Aikebom admin with their own Google or Microsoft account — a member of a client’s staff, or of ours — we keep the email address they were invited under. Once they sign in, we also keep their name as the provider gives it, the provider’s identifier for their account (for Microsoft, together with their organisation’s identifier), their Google Workspace domain or Microsoft organisation, shown for display, and when their account was first linked, when they last signed in and when they last signed out. For each hotel, event or group they are given access to, we also keep when they first and last opened it, and the name the provider gave for them at the time.

At sign-in, Google sends us their email address, whether Google has verified it, their name, their account identifier and, for a Google Workspace account, its domain — and also the address of their profile picture and their given and family names, which we do not keep; where the sign-in is with Microsoft, it sends the equivalent for a work or school account, including their organisation’s identifier. We use these only to check the invitation and sign them in. Anyone who clicks the button sends us the same details: if they have not been invited, the sign-in is refused, no record of them is kept, and the refusal is logged naming only the provider and, where there is one, their Google Workspace domain or Microsoft organisation identifier. Beyond the sign-in itself we call no Google or Microsoft service, and any access or refresh token the provider issues is discarded. The first time an account is linked, we email ourselves a notice of it.

We keep this record until the person is removed from the admin, which deletes it, or until a nightly clean-up does. The clean-up deletes an invitation that was never opened once 30 days have passed since it expired, and someone who never signed in once they hold no invitation that is still open or expired less than 30 days ago. It deletes someone who has signed in but no longer has any access they can use or accept once 90 days have passed since they last signed in. The nightly clean-up never deletes someone we have disabled, or their invitations. Signing out of the admin does not sign them out of Google or Microsoft.

When someone is given access to the admin of a hotel, event or group, we email them an invitation on its behalf. It names the hotel, event or group and the access given and, where one of its organisers invited them, that organiser’s email address, to which replies go; its only link is to our sign-in page. Every change made to a property’s admin team in the admin — by its organisers or by us: an invitation, access given or taken away, a removal, a sign-out, an invitation sent again — is emailed to the property’s staff address, to its other organisers who have opened its admin, and to whoever made the change, naming the person by email address, the change and who made it (an organiser by email address, or Aikebom); someone whose access is taken away is told too, if they had opened it. Access we give from our own command line sends none of these emails, and neither does our disabling, signing out or removing someone from the admin as a whole, nor our taking away an invitation that has expired unopened, which the property no longer sees. Once a property has reached its daily limit of these emails, a sign-out still goes ahead, but nobody is emailed about it, and whoever made it is told so. The first time someone opens a property’s admin with a role they were given, its staff address and its organisers who have opened its admin are emailed that person’s email address, the role, when they opened it and the name they last signed in with there, and that person is told too, at their own address. Where the property has no usable staff address and no other organiser who has opened its admin, we are emailed those details as well; and where these emails could not all be confirmed within a day of the opening, we try once more and are emailed those details too. When a property’s staff address is changed, the previous address is told, without being given the new one. We email ourselves when we change a property’s team and when one of its organisers gives someone the organiser role. To limit how many of these emails a property can send, we keep a record of each attempt to send one — each invitation to a hotel’s or event’s admin, each team-change email, each first-opening email other than those to us, and each staff-address notice: its kind, when it was attempted and a keyed hash of the address, specific to that property — for a staff-address notice, a keyed hash of the address together with who made the change, and a second record holding a keyed hash of who made it. Each of these records is deleted after 30 days.

Running the service means using specialised providers. Each receives the minimum the feature needs:

Reply generation moved from Anthropic to OpenAI on 24 August 2026: OpenAI generates the concierge’s replies today. Anthropic stays named above for two separate reasons — it processes uploaded documents either way, and it remains the fallback we can move reply generation back to, either entirely or for spoken replies alone. Both stay named for as long as either can be the one generating your replies.

Some providers process data outside the EU (notably in the United States) under their standard contractual clauses. Queries sent to search and mapping providers carry the content needed to answer, which can include trip details you mentioned. Each provider above keeps what we send it under its own retention terms, on its own clock: the deletion schedule above governs our systems, and we don’t claim it reaches inside theirs.

Under the GDPR you can request access, correction, deletion, restriction or portability of your data, and complain to a supervisory authority (in Portugal, the CNPD). For a deployed concierge, the event or property you used it at is the controller — you can go to them or directly to us at hello@aikebom.com and we’ll handle or route it. Since there are no accounts, we may ask you for details that locate the right data — the device, share link or WhatsApp number you used, or your booking reference if the property verified you.

We’ll update this page as the service evolves; material changes move the date below. Last updated: 20 October 2026.