# Hybrid with a gateway

> A reference deployment where a model gateway decides which tasks may reach a hosted model, logs every such call, and falls back inside.

- Web page: https://www.alesanalytics.com/docs/hybrid-with-a-gateway
- Markdown: https://www.alesanalytics.com/docs/hybrid-with-a-gateway.md
- Last updated: 2026-11-08
- Publisher: Ales Analytics

Reference deployment. Self-hosted models, with approved routes to hosted ones. Published 2026-11-08. Last reviewed 2026-11-08. Reviewed by Ales Analytics engineering.

Reference pattern. This page describes a deployment pattern; it does not describe any client system. Components are named by role, and products are examples.

## Context and constraints

Most work can be done by open-weight models inside the client's environment, but a few approved tasks benefit from a hosted frontier model, for example drafting from non-sensitive material. The client wants one place where that choice is made, enforced and recorded.

## Diagram

![Reference pattern: the gateway is the trust boundary; only approved tasks may use the outside route.](https://www.alesanalytics.com/diagrams/rd-hybrid.svg)

## Components (by role)

| Role               | Notes                                                                                       |
| ------------------ | ------------------------------------------------------------------------------------------- |
| Model gateway      | Routing, policy, keys, budgets, logs; one interface for every application                   |
| Inside route       | Self-hosted models on client GPUs or in the client's cloud account                          |
| Outside route      | A hosted model reached with the client's own account and contract                           |
| Classifier or tags | Decides the data class of a request: by source system, by tag, or by a check before routing |

## Data flow and trust boundaries

The trust boundary is the gateway's outside route. A request may cross it only if its task and data class are on the approved list. Everything else is served inside. Responses from the outside route are treated as untrusted input like any other model output.

## Identity and permissions

Applications authenticate to the gateway with their own scoped keys; the gateway alone holds the outside provider's key. Users never hold provider keys.

## What is logged

Every request: identity, application, task, data class, route chosen and why, model version, tokens and cost. Requests that crossed the boundary are reportable separately.

## Failure modes

- **Misclassification.** A sensitive request is labelled as safe. Mitigations: classify by source system rather than by content where possible, default to the inside route, and review a sample of outside-routed requests.
- **Provider outage or change.** The outside model is withdrawn or changes behaviour. Every outside route has an inside fallback, and is re-scored on the test set when the provider changes the model.
- **Library compromise.** The gateway is a high-value component. Pin and verify its dependencies (see [security controls](https://www.alesanalytics.com/docs/security-controls-for-private-ai)).

## Alternatives

Inside-only, with either [on-premises](https://www.alesanalytics.com/docs/single-on-premises-gpu-server) or [cloud](https://www.alesanalytics.com/docs/private-cloud-tenancy) hosting, when no task justifies the outside route.

## Related decisions

Which tasks may use the outside route; whether redaction is required; budget limits; who approves changes to the policy.

## Contact

solutions@alesanalytics.com, or https://www.alesanalytics.com/contact.

- Every page as Markdown: https://www.alesanalytics.com/llms.txt