Resource

How to let an AI answer questions about your business without giving it guest data.

Every operator who considers AI eventually asks the same question. Does my guest data go to the model? Most vendors answer with a policy. The only honest answer is one you can test. Here is the architecture, and the test.

An AI that can answer "how did direct bookings do last month compared to the same month last year" is genuinely useful to a busy operator. It is also the feature that makes a careful operator nervous, for good reason. To answer that question, the model has to read your data. The question is which data, and who decided.

What follows is how we built it. None of it is clever. All of it is checkable, which is the point.

01Policy is not architecture

The easy version of this feature reuses the existing read-only database role, the one the dashboards use, and adds a line to the AI's instructions telling it not to look at personal data.

That is a policy. It works until it does not. The read-only role can see the staging layer, the staging layer carries guest email addresses, and query results travel to an external model. The instruction not to look is the only thing standing between a guest's email and a third party. An instruction is not a wall.

The right version makes the sensitive data unreachable by construction. Not forbidden. Unreachable. The model cannot read what its database role cannot see, no matter what it is asked or how it is asked.

02Two schemas, audited, nothing else

A warehouse for an operator has layers. Raw data lands as the source sent it. Staging types and keys it. Core and mart hold the cleaned dimensions, facts and display models that reports read from.

The AI role can read core and mart only. Before granting that, both schemas were audited column by column and confirmed to contain no email address, no phone number and no postal address. Guest identity lives in raw and staging, and the AI role is denied both, along with the operational tables and the system's own authentication tables.

Then the denial was verified by probe: log in as the AI role and try to read each forbidden schema. Every attempt fails. That result is recorded.

03A test that fails the build

An audit is a snapshot. The risk is what happens six months later, when someone adds a convenient email column to a mart table for a report, and the guarantee silently stops being true.

So there is a test. It scans every column the AI role can reach and fails the build if any of them looks like contact data. The first person to add an email column to the wrong place finds out before the change ships, not after a guest does.

This is the part to ask any vendor about. Not "do you protect guest data" but "what breaks if someone adds an email column to the tables your AI reads?" If the answer is a person noticing, the guarantee is a hope.

04The query guard

The model writes database queries. Those queries need a fence around them, separate from the schema permissions above.

• One statement only. No chaining.
• Read verbs only. SELECT or WITH. Anything that writes, drops, alters or touches files is rejected before it reaches the database.
• A hard row cap, applied by wrapping the query, not by appending a limit to the end. Appending is trivially defeated and breaks on queries that already have one.
• A statement timeout at the role level, so a runaway query cannot tie up the warehouse. This is the backstop the others do not need but should have anyway.

One detail, because everyone writes this bug first: blank out string literals before scanning for forbidden keywords. Otherwise a perfectly legitimate where status = 'create' is rejected because the scanner sees a write verb inside a piece of data.

05Three smaller things that matter more than they sound

Read the catalogue at runtime. The list of tables and columns handed to the model is built from the database's own catalogue when the system starts, never by hand. A new view becomes answerable the moment it exists, and the model's picture of the database cannot drift from the real one.

One write, explicitly bounded. Every question and every query the model generates is logged, which needs a write, and the role is read-only. That one write is opened with an explicit, transaction-level escalation, and then tested to confirm it grants nothing else: the role still cannot create tables, and it cannot delete from its own log. Test the boundary. Do not assume it.

Hand the model the local date. A model given a date in universal time told an executive it was Sunday the 14th when Sunday was the 13th. Small, and it undermines everything else in the answer. The model gets the local business date, and the house style rules live in its instructions and are checked in its output.

06What we have not built yet

Honesty cuts both ways. The piece that is designed and not yet built is the feedback loop: a helpful or not-helpful control on each answer, captured against the question, the generated query and the shape of the result.

It matters because it is the only mechanism that turns use into improvement. It is how you learn which questions the data layer cannot yet answer well. It should be in the first version of any product like this, and in ours it is next.