Identity verification at check-in handles some of the most sensitive data a hotel holds: passport details and a face image. Under Thailand's Personal Data Protection Act, a property has to show that it collects that data lawfully, protects it and knows who has accessed it. Most privacy programmes answer that with documents. ENTRIX, the identity and check-in system Opsian builds, answers it with controls in the system itself, and with a compliance view that reads those controls live.
Closed by default
The most important control is the one nobody sees. Since July, personal data in ENTRIX is closed by default. Nothing can be read until access has been explicitly granted, and the grant says who may read what.
A control like that is only as good as its coverage, and coverage tends to erode as a system grows. A new feature is added, and the protection it needs is forgotten. ENTRIX does not leave that to memory. Coverage is checked before every release, and a change that would leave personal data unprotected does not ship.
For a business reader, the practical meaning is simple: protection is the starting state, not a step someone has to remember.
Consent that cannot be rewritten
Before any document is scanned, the guest gives consent. That consent is recorded before capture and cannot be altered. A record of consent can be added to; it cannot be edited or deleted. If a guest's position changes, the change is a new entry, and the earlier one stays on file.
That matters when the question is not whether a guest consented but what they consented to, and when. A record that cannot be altered answers both.
Two logs, not one
ENTRIX keeps an audit log of actions in the system. It also keeps a separate log of every access to personal data. The two are kept apart on purpose. An audit log answers what happened. An access log answers a narrower question the law cares about directly: who looked at this person's data.
When a guest asks who has seen their passport, or an internal review asks whether a staff account viewed records it had no reason to, the answer comes from that log, not from a reconstruction.
A compliance view built on live queries
Since 1 September, ENTRIX has a PDPA compliance view. It reads the live system, not a checklist someone fills in. Each item it shows reflects the current state of the system and its logs.
The difference is the difference between a statement and a measurement. A checklist says a control was designed. A query shows whether it is operating today. When the two disagree, the query is the one an examiner will believe.
Limits at the edges
Privacy also depends on what the system refuses to do.
- Rate limits. Since July, the system limits how much any caller can request, which narrows what an automated attack or a faulty integration can extract or trigger.
- Strict about uploads. Since August, the system accepts only the images it needs, in the forms it expects. An identity system accepts images from the public; it should accept nothing else.
- Failing closed. Since October, if verification is unavailable, the system fails closed to staff review. An outage never becomes a reason to admit a guest without verification.
What an operator gets
For an owner or general manager, the value is evidence on demand. The property can show that consent was captured before collection, that access to personal data is restricted by default and logged, and that the controls are operating now rather than on the day they were designed.
None of this replaces the property's own obligations under the Act, or the advice of its counsel. It changes what the property has to work with when it meets them: a system that can answer the questions, rather than a folder that describes how it should. More on ENTRIX is at opsiantechnologies.com.
