Not per person — per data class. An approval list per employee goes stale with the first role change and does not answer the audit question. The durable rule is "which data class may reach which model class", enforced for everyone who uses BRANE.
The wrong axis and the right one
The obvious answer is an approval list per person. It goes stale with the first role change, and it does not answer the audit question, because that question is not about people but about content.
The durable axis is the data class: one rule for whether detected personal data may go to the cloud masked or must stay local, plus company rules in your own words for confidential material such as contracts or source code. Compliance defines it once, enforcement happens in the chat and at the API.
Three model classes, one decision
- Cloud models. Performance and quality, reachable per policy and normally masked.
- Local open-source models. Run entirely inside your instance. No egress.
- Embedding and specialist models. For retrieval, classification and narrowly bounded tasks.
Which class a request gets is not decided by the user in the chat box but by policy, based on what the prompt actually contains.
What that means day to day
A developer pasting source code and the same developer asking about a meeting date get different models — without needing to know two tools or make a decision. That is the point: the policy applies where the content originates, not in a training session.
What this layer does not do. It enforces policy — it does not write it. Which data classes exist and what applies to them is your decision.