Hosted in Australia
Application and database layers run in DigitalOcean’s Sydney region (syd1) for every HotelStack.ai product.
Trust. Stated plainly.
Hotels hand us trading data and guest-adjacent data. This page is exactly how we treat it — what is true today, what is still on the roadmap, and the difference between the two. No invented certifications, no “bank-grade” anything. We’re a governance consultancy’s own product; this page has to survive our own profession reading it.
The AI is a guest in your data, and it’s treated like one.
HotelStack.ai’s intelligence features run today on frontier models from Anthropic, with Google models for image generation. That is a choice, not a dependency. The model is one component behind what we call the harness: the server that assembles context, the governed metric layer it reads from, the append-only audit log, and Boardroom’s accountability layers. The harness is ours and it is the constant. Nothing in the metric layer, the audit log or the rules below depends on which model sits behind it; the model is chosen per task, can be changed without touching your data, and can be one you bring. Four rules govern every interaction, whichever model is answering:
- The model never queries our databases — the server hands it a minimum, role-scoped context.
- What it can see is what you can see: role permissions apply to the AI’s context, not just your screen.
- Its writes are proposals — a human approves every change before it lands.
- Every call and every action goes to the append-only audit log.
Two things said plainly, because a careful reader will ask. First: AI inference is processed by our model providers in the United States — your application data lives in Sydney, but the context slice sent to a model crosses the border for the duration of the request. An onshore option is designed for clients who need it. Second: we are formalising our data-use terms with each AI provider, and until that work is done we won’t publish a “your data never trains a model” badge. When we can evidence it, it will appear here first.
If your estate already has its own answer to these questions, a model you trust, a data platform your analysts work in, or a rule that nothing leaves your cloud, the harness is designed to sit on top of it. The four rules above travel with it unchanged. Bring your own model, data platform or cloud →
What actually reaches a model
- ViP Operate
- Venue context — POS summaries, bookings, occupancy, costs — scoped to your role. No individual guest profiles are sent by design.
- HiP / AiP Invest
- Assumptions, benchmarks and page-level excerpts — deliberately minimal. Bulk documents and raw models stay behind.
- All products
- POS data arrives as aggregates; we hold no cardholder data anywhere, so none can reach a model.
The perimeter
Your data stays inside a fence in Sydney. The AI outside is handed a small slice through one door. It can only propose; a person approves before anything changes.
What we can prove, and what we’re still building.
A specific, honest posture reads stronger than a badge wall. Everything below is written the way we’d want a vendor to write it to us.
Last reviewed 6 September 2026 · every line traces to our internal governance record
True today
Tenant isolation on every path
Row-level tenant isolation is enforced in the application layer on every data access — including every AI tool call. The same gate guards the UI and the model.
AI never touches the database
Models don’t query our systems. The server assembles the minimum context a question needs and passes only that slice to the model.
AI writes wait for a human
When an AI proposes a change, it lands as a pending action. A person approves it — or doesn’t. Nothing self-executes.
Everything is on the record
An append-only audit log records every data change and every AI action — actor, before and after, outcome.
No payment card data
HotelStack.ai ingests POS trading as summary aggregates. We do not store or process cardholder data, by design.
Presence sensing without identity
Presence and occupancy analytics use environmental, network and camera signals and are reported as aggregates only — no facial recognition, no individual identified or tracked as a person, no per-person record. This is an architectural choice, not a setting.
Hardened transport
TLS 1.2+ with modern ciphers and HSTS across our public surfaces; legacy protocols are rejected.
Clean secret history
A full-history scan across our entire engineering estate — 33 repositories, 11,000+ commits — found no committed credentials, and scanning now gates new commits.
On the roadmap · not yet true
SOC 2 & ISO 27001
Self-assessed today, not attested. We publish no badge we can’t evidence; formal alignment is on the roadmap and our gap analysis is honest about the distance.
Independent penetration testing
An internal, evidence-chained red-team programme is authorised and standing up. No external penetration test has been commissioned to date — when one is, we’ll say so here.
Multi-factor authentication
MFA enforcement is committed, starting with high-privilege accounts. Until it ships, we won’t claim it.
Formal incident response
A documented, tested incident-response programme is being built. Today, incidents would be handled by the engineering team directly — we’d rather tell you that than gesture at a plan that doesn’t exist yet.
Published retention & deletion policy
Deletion on account closure is our operating commitment; the formal, published retention schedule is in progress.
Onshore AI inference
An Australian-region inference option for sovereignty-strict clients is designed and offered on request — built when a client needs it.
Guests didn’t choose us. We act like it.
Your guests have a relationship with your hotel, not with HotelStack.ai — so the platform is built to need as little of their data as possible. Trading arrives as aggregates. Camera analytics do no facial recognition and reach us as aggregates only. Where personal information is handled, we work to the Australian Privacy Principles, and our product decisions track the OAIC’s enforcement positions and New Zealand’s Biometric Processing Privacy Code.
Data rooms: what we record when you sign in.
DRiP, at drip.hotelstack.ai, is a data room HotelStack runs on behalf of a room owner, open only to people the owner has invited by name. When you use one, we record it against your name, organisation and email address: each sign-in code we send you, each sign-in and failed sign-in, your acceptance of the terms of access, each time you open the room’s index, view or download a document or download a zip, and any attempt the room refuses. Each record carries the time, your IP address and your browser, and, where it applies, the release and the reference stamped on the document.
We keep this record to secure the room, to show the room owner who has seen what, and to trace a stamped document back to the view or download it came from. The room owner’s administrators can see and export it; HotelStack can see it to run and secure the room. It is stored with the room in DigitalOcean’s Sydney region. The record is append-only, so it cannot be edited or deleted in the normal running of the room, and it is kept after the room closes; our published retention schedule is still in progress (see above). To ask about the record we hold about you, write to [email protected].
Security of this site.
We hold this website to the same standard we hold the software we build. Here is what is true of hotelstack.ai today. It is about the site and how we handle your message, not a claim about the product and not a certification.
Encrypted, always.
Every request is served over HTTPS with modern TLS; plain HTTP is redirected to the secure version.
A locked-down page policy.
The site runs under a Content Security Policy that only allows scripts and network connections from us, our own analytics and the bot check on the contact form. Injected or third-party code has nowhere to run.
Verifiable email.
Our domain publishes SPF, DKIM and an enforcing DMARC policy, so a recipient can confirm mail really came from hotelstack.ai and forged mail is filtered out.
Privacy by default.
We use our own, cookie-free analytics. No third-party trackers, no advertising pixels, no cross-site profiling.
The contact form keeps nothing.
When you write to us, your message becomes a single email to our team, delivered through Resend from our own domain. We keep no database of enquiries and use no marketing tool. The form is protected against bots and abuse with Cloudflare Turnstile and server-side checks.
Kept current.
Our dependencies are monitored for known vulnerabilities, changes are version-controlled and ship through pull requests, and we review this site’s security posture on a regular cadence.
Found something? Tell us.
We would rather hear about a problem from you than read about it. Report anything security-related to [email protected]; our policy and contact details are published in our security.txt. We read every report and reply. security.txt →
Ask us the hard questions.
Security questionnaires, data-flow diagrams, the unvarnished answer on any line of the Trust page. We would rather have that conversation early.
What happens next. A founder reads every message and replies by email, usually within two business days. No sequence, no sales development rep. Prefer email? [email protected].
What the form does with your message: it becomes one email to [email protected], sent through Resend from our own domain, and nothing is stored anywhere else. Site analytics run on our own server (Umami, in our DigitalOcean Sydney account): no cookies, no personal data, nothing shared with a third party. The hosting edge in front of the site sets one short-lived bot-management cookie that carries no identity.