Key facts
| Access control | Scoped API keys with rotation; enterprise SSO and RBAC options |
| Deployment | Cloud, VPC, on-prem or air-gapped for property or group placement |
| Auditability | Request, model and response logging for guest-issue review |
| Data grounding | Embeddings and RAG are live for property facts and brand standards |
| Structured output | JSON mode returns maintenance and request records in fixed schemas |
| Models | 30+ models behind one OpenAI-compatible API |
| Pricing model | Flat monthly self-serve plans; no per-token billing on self-serve |
| Endpoint roadmap | Audio, images, moderation, files, batch and fine-tuning are coming soon |
TL;DR
- Decide per data class whether it stays at property or group level.
- Issue a scoped key per property system and integration, with rotation.
- Apply retention to chat transcripts, which are guest records.
- Log interactions so guest issues can be reconstructed per property.
- Escalate compensation and exceptions to named property staff.
How it works, step by step
- Inventory guest-facing AI use cases per property and label the data each one touches.
- Agree the split between property-level and group-level data processing.
- Choose deployment per class: region-selected cloud, VPC, on-prem or air-gapped.
- Issue per-property and per-integration keys, stored and rotated centrally.
- Define log fields and retention: request ID, model, sources, output, property and agent.
- Approve a model allow-list and ground answers in current property facts.
- Define escalation paths for compensation, upgrades and complaints.
Try it yourself
Open the data residency checker →
Guest data across properties
A hotel group processes guest data at several levels: the property, the brand, the loyalty program and central marketing. Classification should state where each class lives and which system may query it. Room numbers, folio details and incident notes belong to the property; loyalty tier and preferences usually sit centrally.
Write the rule down before a workflow queries across levels, because a concierge assistant that blends them can expose information a property would never share with another.
Per-property keys and access
Issue a distinct API key per property system and integration, and keep a central inventory with rotation schedules. Front-desk, housekeeping and revenue systems should not share credentials, and a management change at one property should trigger revocation without touching the rest of the group.
Enterprise SSO and RBAC options keep console access aligned with staff turnover, which is high in hospitality, and with seasonal and agency staff who join for short periods.
Residency, retention and audit trails
Decide where processing happens and how long transcripts live. Region selection covers many group needs; VPC, on-prem and air-gapped deployment supports operators who require data to remain in a jurisdiction or inside the estate. Retention is your policy applied to prompts, outputs, logs and retrieval indexes, and chat transcripts count as guest records.
Log enough to reconstruct an interaction: request ID, model and version, retrieved source identifiers, output, property and handling agent. See AI audit logs for a schema.
Model governance and escalation paths
Keep an approved model list with evaluation evidence and re-test when versions change. Ground answers in current property facts and brand standards with citations, so front-desk staff can trust them during a busy check-in. Compensation, upgrades and complaint resolutions stay with named property staff, and the checklist should document who reviews exceptions and how quickly.
Honest comparison
| Control area | Plugsky capability | Common gap | Owner |
|---|---|---|---|
| Identity | Per-property scoped keys, rotation, SSO and RBAC options | Group-wide shared key | IT security |
| Data boundary | Cloud, VPC, on-prem or air-gapped deployment | Transcript path undocumented | Data protection |
| Retention | Configurable logging of requests and responses | Chat logs kept indefinitely | Data protection |
| Audit trail | Request, model, source and property logging | Issues not traceable | Guest relations |
| Grounding | Embeddings and RAG over property facts | Outdated local answers | Property operations |
| Human sign-off | Citations and structured output for staff | Automated compensation promises | General manager |
Frequently asked questions
Does Plugsky make us compliant?
No. Compliance is your program. Plugsky provides deployable controls - scoped keys, private deployment, logging - that you document and audit against your own guest-data obligations.
Can each property keep its data separate?
Yes. Issue separate keys per property system and keep retrieval indexes per property so one site cannot query another's guest data.
What should we log?
Request IDs, model names and versions, retrieved sources, outputs, the property and the handling agent, retained under your policy so guest issues can be reconstructed.
How do we handle loyalty data?
Classify it centrally, restrict retrieval to workflows that genuinely need it, and document which properties may see which fields.
Can a small property use this affordably?
Yes. Self-serve plans are flat monthly with no per-token billing, and the free plan includes plugsky-micro and plugsky-lite with no card.
Are voice and image features available?
Audio, images and moderation endpoints are coming soon. Chat, streaming, JSON mode, function calling, embeddings, RAG and agents are live today.
Where should a pilot start?
Pilot on public property information and brand FAQs with the free plan, then extend to reservation and loyalty workflows on private deployment.