# AI Gateway

One layer for all your applications' language model traffic: masking, audit trail, quota, and usage collected in one place. Your code stays the same.

An AI gateway is the layer that sits between your applications and language models. Instead of going straight to the provider, requests pass through it first; the organization sees every request in one place and applies its rules in one place.

Gurubase Gateway runs this layer in Turkey and adds one more step at the moment of passage: personal data is masked before the request leaves for the external model.

Diagram: requests from every application, including the customer assistant, the support flow and internal tools, arrive at Gurubase Gateway as a single entry point. The gateway runs in Türkiye and passes each request through Siper masking; raw data stays there. The masked text then fans out to providers: hosted providers such as OpenAI, Anthropic and Gemini, or vLLM and Ollama on your own server. Audit trail, quota and usage are collected at the same point.

## Why a single point of passage

When usage is scattered, each team goes to its own provider, with its own key, from its own code. No one can see who sent what across the organization; this is the picture known in enterprise literature as shadow AI. A single point of passage changes that in four places.

**Personal data control.** Masking is applied in one place. Instead of expecting every application to get it right on its own, the rule sits at the point of passage and works the same way no matter which team the request comes from.

**Visibility.** Which team uses which model and how much, which categories are detected and how often, which requests returned an error. It is collected on a single screen, broken down by virtual key and model.

**Resilience.** When a provider slows down or returns an error, the decision to retry or switch to an alternative is made at the gateway, not in application code.

**Budget.** Token budget, quota, and warning thresholds are tracked per key; usage is read from one place across the organization.

## What changes in your code

Two values. The rest stays the standard OpenAI SDK: the model name, the parameters, and the response format are the same.

```diff
  client = OpenAI(
-     base_url="https://api.openai.com/v1",
-     api_key=OPENAI_API_KEY,
+     base_url="https://gw-tr.gurubase.io/v1",
+     api_key=VIRTUAL_KEY,
  )
```

The provider’s real key stays inside the Gateway; your application carries only the virtual key you generated in the panel. For a step-by-step switch, see [Gateway integration](/docs/en/guides/gateway-integration/).

## Guardrails

Masking is the first guardrail running at the point of passage, and the default one. Input is masked on every request; response masking is turned on optionally. Prompt injection protection and hallucination protection will be added to the same layer; they are coming soon. For details and current status, see [Guardrails](/docs/en/guardrails/).

## Models and providers

The Gateway offers a single OpenAI-compatible interface. Behind it there can be general providers such as OpenAI, Anthropic, and Gemini, or models running on your own servers; the only thing that changes on the client side is the `model` field. You get the models you can access from the `/v1/models` endpoint. For provider selection, retry, and fallback behavior, see [Models and providers](/docs/en/models/).

## Visibility and governance

The panel makes the data that accumulates at the gateway readable: request and token counts, characters processed, the distribution of detected categories, and the breakdown by model and virtual key. Administrative events are written to an append-only audit trail and can be exported. For the screens, see [Panel](/docs/en/panel/); for retention and access rules, see [Security](/docs/en/security/).

## Runs in Turkey

The Gateway and masking run on infrastructure hosted in Turkey. Only masked text goes to the external model; raw personal data is processed in Turkey and stays there. If masking cannot be completed, the request does not go to the external model at all, and the Gateway returns a 502. This behavior is called fail-closed; the details are on the [Concepts](/docs/en/concepts/) page.

- [Getting started](/docs/en/getting-started/): Get your virtual key and send your first masked request.
- [Guardrails](/docs/en/guardrails/): Input and response masking, and the layers coming soon.
- [Models and providers](/docs/en/models/): Model selection, retry, and fallback.
- [Panel](/docs/en/panel/): Usage charts, quota, user and key management.