An assistant that structurally cannot make a number up

Not retrieval, and not text-to-SQL

There is no vector store, no embedding index and no document retrieval anywhere in this feature. That rules out the usual failure where an assistant confidently answers a question about your current consent counts from a policy document written last year.

There is also no path by which the model writes a query. It cannot compose SQL, it cannot pass a table name, and it cannot pass a filter that was not anticipated. What it can do is name one of twelve prepared queries and supply the small number of parameters that query accepts.

The exchange runs in two shots. In the first, the model reads the question and emits a single line naming a tool and its arguments. The server runs the corresponding parameterised query. In the second, the model is handed the resulting rows as JSON and asked to summarise them. The model never touches the database; it chooses a question and describes an answer.

The twelve questions it can actually answer

Publishing the list is the point. An assistant whose scope is a mystery gets asked things it cannot answer and produces something anyway; one whose scope is on a page gets asked the right questions.

• Records captured under a named purpose, and how many.
• Records that have gone stale for a named purpose.
• Records overdue under the retention policy.
• Open grievances.
• Recent re-consent campaigns.
• The overall consent summary.
• Recent withdrawals, and withdrawals broken down by purpose.
• Records broken down by purpose.
• Every record held for a named data principal.
• The most recent records captured.
• The list of purposes currently configured.

Where your organisation identifier comes from

This is the part that matters for a security review. Every one of the twelve queries carries a fixed clause restricting it to one organisation, and the value bound into that clause comes from the server's own resolution of the authenticated session — a membership-verified organisation on the request, not a field in the conversation.

The model is never told the identifier, never asked for it, and could not supply a different one if it tried, because the parameter is not part of any tool's argument list. Prompt injection in a question cannot widen the scope of a query whose scope is not expressible in the question.

Access to the assistant at all is gated on the same workflow-view permission as the rest of the consent module, so a person who cannot see consent records in the interface cannot see them through the assistant either.

What it does when asked something outside the list

It says so, in one fixed sentence, pointing the person at the data protection officer. Not a hedged paraphrase, not an attempt to be helpful with adjacent information — a specific refusal string.

That rigidity is deliberate. An assistant that improvises around the edge of its competence is more dangerous than one that stops, because the improvisation is indistinguishable in tone from the part that was grounded. A flat refusal is a signal a person can act on.

The second failure mode: the invented number

Refusing to answer out-of-scope questions solves half the problem. The other half is a question that is in scope, where the model answers from its own impression rather than from the rows it was given — and a plausible-looking count is the hardest kind of wrong answer to catch.

Two controls run against that. If the model tries to answer a data question without naming a tool, the server does not accept the answer; it forces the summary query and re-runs the second shot against real rows. And the second shot's instruction is explicit about arithmetic: use the numbers in the JSON, and do not add to them, round them, scale them, estimate them or invent them.

The answer is also capped at a dozen lines. A long answer to a short data question is where invention creeps in, and a cap is a blunter instrument than a prompt but a more reliable one.

What it cannot see, and what it does not remember

Four tables, and no others: consent records, consent purposes, consent grievances and re-consent campaigns. It cannot read your assessment answers, your policy documents, your breach records, your RoPA or your vendor risk data.

Assessment data is the gap people most often assume is not there, so it is worth saying directly: there is no path in the code that reaches an assessment answer or score. Ask the assistant about readiness and you get the fixed refusal; the assessment reports are where those numbers live.

It also holds no memory between questions. Each exchange is independent, which makes it worse at conversation and better at not carrying a mistaken assumption from one answer into the next.

When there is no model available

The assistant degrades to a plain message saying no provider is configured, rather than failing with an error or, worse, answering from nothing. It is an optional layer over data that is fully accessible through the ordinary dashboard and exports.

Which is the right way to think about the whole feature. It is a faster way to ask a question you could already answer with a filter and a count. It is not a system of record, it should not appear in an audit response, and the artefact you hand a regulator is the export, not a transcript.