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 per role and per use case.
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: separate rules for PII, PHI, intellectual property and contracts, per role and per use case. Compliance defines it once, enforcement happens everywhere.
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.