Data Routing Policy

Definitions

Local inference. Model weights execute on client-owned hardware on client premises. The prompt, the retrieved context and the output never cross a network boundary the client does not control.

Domain retrieval. Client documents are indexed, embedded and stored on client hardware. The embedding model runs locally. This matters more than it looks: if embeddings are computed by a hosted API, the entire document corpus goes to that provider a chunk at a time, in the background, with no user watching. Local retrieval with a hosted embedding model is not private.

Managed frontier passthrough. An on-premises gateway sends a request to a third-party model provider's API under a named agreement. The hardware stays on premises; the request does not.

Assembled payload. What actually leaves is the user's text, plus retrieved document chunks, plus the system prompt, plus prior turns in the session. The user typed one sentence; the payload may carry twenty pages of their files. Every rule below applies to the assembled payload, not to what the user typed.

Control

Default deny. Requests run locally unless a workload has been explicitly enabled. No workload routes on day one.

Routing is decided per workload, not per request. A named workload is enabled in gateway configuration by documented change request, signed by the client's designated owner.

Leaving the choice to the end user puts a compliance judgment on whoever is typing at 5pm on a Friday. Automatic content classification cannot be the authorizer either: a classifier that is 98% accurate still leaks 2% of protected data, and no one can say which 2%. Classification is used only as a second blocker -- deny on detection, inside an already-enabled workload.

Routing is scoped to the session, not the turn. Conversation history is resent on every turn, so turn one may be clean while turn seven carries everything above it. A session cannot change modes partway through.

Every routed request is logged at the gateway: timestamp, user, workload, destination provider, model and version, token counts, and a content hash. Metadata and hash are logged by default. Full prompt content is opt-in and stored on client hardware, because a full-content log is a second protected-data repository with none of the first one's protections. The logs belong to the client.

Eligibility

By default, regulated data never routes. Protected health information, attorney-client privileged material, client trust account data and anything covered by a BAA stay on local inference. Passthrough is for workloads that carry none of it.

An exception requires all five of the following, not any of them:

1. A signed BAA or DPA with that provider covering that specific API service.
2. Zero data retention configured on the account and confirmed in writing by the provider.
3. The client's written authorization naming the workload, the provider and the data classes.
4. An enterprise or API tier. Consumer chat products are never eligible, at any provider.
5. A named review date, because provider terms change.

For legal clients, the decision is the firm's. Whether privileged material may reach an outside provider is a professional judgment under the firm's own obligations; ABA Formal Opinion 512 (2024) and California bar guidance both point toward informed client consent. IT CloudLink LLC provides the mechanism, the disclosure and the log. The firm decides.

Path and account

Routed requests go directly from the client's gateway to the provider. They do not pass through IT CloudLink LLC infrastructure.

API keys live on the client's own provider account. The client is the contracting party with the provider. IT CloudLink LLC configures the path and does not sit in the middle of it.

Egress is pinned. The gateway is the only host with outbound access to provider endpoints, restricted to those endpoints.