Trust & Security

The most sensitive data never touches our servers

HiLucy is designed around data minimization: collect as little as possible, hand the highest-risk data to certified processors, and put a deletion clock on the rest. This page explains what we store, where it lives, who else processes it, and — just as plainly — what we have not certified yet.

Questions about anything on this page? [email protected]

Payments & PCI

A breach of HiLucy could not expose a guest's card number, because we never have it

Every payment on the platform is processed by Stripe, a PCI DSS Level 1 service provider — the most stringent level of payment security certification. Guests type their card details into Stripe's own embedded payment form, which sends them directly from the guest's browser to Stripe. HiLucy's servers receive only a token.

Because all card functions are outsourced to Stripe and no cardholder data is stored, processed, or transmitted by HiLucy, our integration stays within the minimal PCI scope (SAQ-A) by design.

What we store — and what we never do

Data	Stored by HiLucy?
Card number (PAN)	No — never reaches our servers; held by Stripe
CVV / security code	No — never stored by anyone, including Stripe
Stripe charge ID	Yes — an opaque reference, not card data
Amount, currency, and payment status	Yes

For hotel partners: you are the merchant of record

Under our settlement model, your property is the Stripe merchant of record. Guest payments settle directly to your own Stripe account — guest funds never pass through HiLucy's balance.

When a guest saves a card on file (for example at check-in), it is captured through Stripe's SetupIntent flow and vaulted with Stripe — for connected properties, on the property's own Stripe account — so the card number bypasses HiLucy there too.

Guest data & privacy

Every guest data element has a lawful basis and a deletion clock

For property operations, HiLucy acts as a data processor on behalf of your property. For guests who chat with Lucy directly, we act as a joint controller. A data processing addendum (DPA) is available to every customer.

Retention schedule

Data	Kept for
AI conversations and chat logs	30 days after the last interaction, deleted automatically
Guest check-in personal data	Length of the booking + 30 days
Financial records	7 years (legal obligation)
Security and audit logs	1 year
Consent records	3 years

Consent is granular and opt-in: no pre-checked boxes and no bundled agreements. Every consent is recorded with a timestamp and the policy version it was given under.

Guests can request access, correction, erasure, or a portable copy of their data, and we run a documented process for handling those requests.

If a breach ever affects personal data, our written procedure commits us to notifying affected parties and regulators within 72 hours, in line with GDPR.

The same documented program covers CCPA and the WhatsApp Business Policy, including recorded opt-in and STOP handling for WhatsApp messaging.

Subprocessors & data residency

Your data is hosted in Canada, and we tell you exactly who else touches it

HiLucy runs on dedicated, single-tenant hardware in OVH's Beauharnois datacenter in Canada — a jurisdiction covered by an EU adequacy decision. Where a subprocessor operates in the United States, international transfers rely on Standard Contractual Clauses.

Who processes what

Provider	Purpose	Data involved
OVH (Canada)	Dedicated hosting	All platform data
Stripe (US)	Payment processing	Card and payment data (never touches HiLucy)
OpenAI (US)	AI language models behind Lucy	Conversation text — 30-day API retention, never used for training, under a signed DPA
Meta — WhatsApp Business API (US)	WhatsApp message delivery	WhatsApp messages and phone numbers
Pinecone (US)	Knowledge-base search index	Property knowledge content that grounds Lucy's answers
LangSmith (US)	AI conversation tracing for debugging	Conversation traces, deleted automatically after 30 days

We maintain a full subprocessor register and will share it — and notify you of changes to it — on request.

What we deliberately keep in-house

Product analytics runs on a self-hosted PostHog instance on our own infrastructure — guest behavioral data does not go to a third-party analytics service.

The mirroring of guest WhatsApp conversations that gives your staff visibility and handoff runs on a self-hosted Matrix messaging server — also our own infrastructure, not a SaaS.

AI transparency

You should know exactly what the AI is, what it sees, and when a human takes over

Lucy is built on OpenAI's GPT-4o model family, accessed through the API. Conversations are routed per audience — a guest mid-stay and a prospect asking about your property can be served by different models suited to each conversation.

OpenAI processes these conversations under a signed data processing agreement: API data is not used to train OpenAI's models and is retained by OpenAI for at most 30 days. On our side, conversations are deleted automatically 30 days after the last interaction.

Lucy is not one open-ended chatbot. Every request first goes through a routing step that classifies it and hands it to a purpose-built assistant — booking, dining, transport, and so on — using structured, constrained outputs rather than free-form generation.

There is always an escape hatch to a person. When Lucy cannot help, when a request needs human judgment, or when a guest simply asks, the conversation escalates to your staff, who see the full thread and take over.

When Lucy gets something wrong, the fix is human: staff step in to correct it with the guest directly, and the property information Lucy answers from can be updated so the same mistake does not come back.

We do not publish accuracy percentages, because no single number honestly describes a system like this.

Infrastructure security

Production runs on dedicated hardware we control, not shared tenancy

Dedicated single-tenant server hosted by OVH in Beauharnois, Canada.
Each environment — production, staging, development — runs in its own isolated container.
Each environment has its own isolated database, reachable only from inside that environment and never exposed to the internet.
TLS 1.2 or higher on every connection, with Cloudflare in front of the production domain.
Server access is over SSH with ed25519 keys only — password logins are disabled.

Application & access security

Admin access is gated by MFA and roles, and integration secrets are encrypted

Multi-factor authentication is required on all admin access.
Role-based access control (guest, staff, manager, administrator) with least-privilege access and no shared accounts.
Modern password hashing (bcrypt-based) and signed JWT sessions.
Rate limiting on authentication and one-time-code endpoints; one-time codes are stored hashed, never in plain text.
Credentials for third-party integrations are encrypted at the field level with libsodium authenticated encryption.

Secure development

No code reaches production without review and automated security checks

Every change goes through pull-request review before it can merge.
CI gates run on every change: automated tests, secret scanning (gitleaks), and dependency audits that fail the build on findings of moderate severity or higher.
Runtime secrets live in server-side environment files, never in the code repository.
Documented patch timelines: critical vulnerabilities within 72 hours, high within 7 days.

Business continuity

Every environment is backed up offsite nightly — and we have actually restored from those backups

Every environment, including production and all supporting systems, is backed up nightly to separate OVH backup storage. The pipeline is fail-closed: nothing is pruned until the offsite copy exists.

Restores from this chain have been performed and verified — not just planned — and a written disaster-recovery runbook covers the full procedure.

Incident response

If something goes wrong, there is a written playbook — and a 72-hour notification commitment

Our Information Security Policy defines incident response end to end: detect, contain, investigate, remediate, notify, and review. Incidents are classified against a severity matrix with response-time targets.

Breaches affecting personal data trigger the GDPR 72-hour notification procedure. Anyone can report a security concern to [email protected].

Compliance roadmap

Here is what we have — and what we don't have yet

We would rather tell you our exact stage than let a badge wall imply more than we can back.

What we have today

A written Information Security Policy (v1.0), in force since March 2026 and reviewed annually.
A documented GDPR and CCPA program: retention schedule, versioned consent records, a data-subject-request process, a 72-hour breach-notification procedure, a subprocessor register, and a customer-facing DPA.
Card data kept out of PCI scope by design via Stripe (SAQ-A scope).
WhatsApp Business Policy compliance, with documented opt-in and STOP handling.

What we don't have yet

No SOC 2 report — neither Type I nor Type II.
No ISO 27001 certification.
No third-party penetration test yet. The security audits we have run so far are internal.
Our GDPR data protection impact assessment (DPIA) is still in progress.

We expect SOC 2 Type I to be the first external attestation we pursue, as our first enterprise deployments require it.

Put us in front of your security team

On request, we will share our Information Security Policy, data processing addendum, and subprocessor list with your security team, and walk them through the architecture — under NDA if needed.

[email protected]

Documents & contact

Security questions, document requests, and vulnerability reports all go to the same place.

[email protected]

Our data processing addendum and subprocessor list are available on request; our Privacy Policy and Terms of Service are public.