01 / Purpose
Set the boundary.
The business question is not simply whether staff can access a model. It is who can use which model, with what company information, for which task and under whose authority.
This is an architecture pattern, not a customer deployment or a claim that every company needs the same stack.
Authentication, roles and team membership.
Provider routing, limits and cost controls.
Owned documents, scoped retrieval and citations.
Requests, tools, outcomes and review evidence.
Named responsibility for consequential action.
Customer cloud, controlled service or hybrid.
02 / Identity and roles
Name every request.
Use the company’s identity provider where practical. Roles should map to real responsibilities rather than generic access levels invented for the AI system.
A user who can ask a general model for help does not automatically need access to HR documents, financial records, customer files or operational tools. Retrieval and tool permissions should follow the same boundaries the company already recognises.
03 / Model gateway
Choose models centrally.
A gateway can route approved requests to suitable providers, apply limits, record cost and make model changes without rewriting each internal tool. It should not become a reason to hide which provider processed the request.
Different tasks may justify different models. Deterministic extraction, private retrieval and open-ended drafting do not have identical accuracy, latency or data requirements.
04 / Approved knowledge
Preserve source ownership.
Start with a bounded collection that has a clear owner, access policy and update route. Keep the source reference with the answer so the user can inspect the evidence.
Do not pour every shared drive into one index. Duplicates, stale files, draft policies and conflicting permissions become an AI problem only after they were already an information-management problem.
05 / Logging and approval
Observe with restraint.
Record enough to investigate cost, tool use, failures and consequential outputs. Retention should match the sensitivity and operational need, not the storage system’s default.
When the workspace can prepare an external message, change a record, spend money or trigger another system, require a named approval or a narrowly defined rule with an accountable owner.
06 / Deployment boundary
Self-hosting is one control.
A customer-cloud deployment can improve ownership and network boundaries. A managed model can still be appropriate when its contract, retention and access controls fit the task. A hybrid system may keep company knowledge and orchestration inside the customer boundary while using approved external inference.
The correct choice depends on the information, users, recovery expectations, engineering capacity and cost. Architecture should follow those constraints rather than a preference for one hosting label.