Hosted in Australia
Application and database layers run in DigitalOcean’s Sydney region (syd1) for every HotelStack.ai product.
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.
HotelStack.ai’s intelligence features run on frontier models from Anthropic, with Google models for image generation. Four rules govern every interaction:
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.
What actually reaches a model
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.
True today
Application and database layers run in DigitalOcean’s Sydney region (syd1) for every HotelStack.ai product.
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.
Models don’t query our systems. The server assembles the minimum context a question needs and passes only that slice to the model.
When an AI proposes a change, it lands as a pending action. A person approves it — or doesn’t. Nothing self-executes.
An append-only audit log records every data change and every AI action — actor, before and after, outcome.
HotelStack.ai ingests POS trading as summary aggregates. We do not store or process cardholder data, by design.
Presence and occupancy analytics use environmental and network signals and are reported as aggregates — no individual is identified or tracked as a person. This is an architectural choice, not a setting.
TLS 1.2+ with modern ciphers and HSTS across our public surfaces; legacy protocols are rejected.
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
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.
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.
MFA enforcement is committed, starting with high-privilege accounts. Until it ships, we won’t claim it.
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.
Deletion on account closure is our operating commitment; the formal, published retention schedule is in progress.
An Australian-region inference option for sovereignty-strict clients is designed and offered on request — built when a client needs 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. Presence analytics are non-biometric. 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.
Security questionnaires, data-flow diagrams, the unvarnished answer on any line of this page — we’d rather have that conversation early.
Talk to us