> ## Documentation Index
> Fetch the complete documentation index at: https://docs.requesty.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance

> Manage traffic-handling controls, compare current policy with observed AI traffic, and download audit-ready evidence

The Compliance page puts your organization's traffic-handling policies and the traffic observed against them in one place. Admins can review or change supported controls, investigate guardrail violations and configuration changes, and download the same information as an evidence report.

<Note>
  **[Open Compliance](https://app.requesty.ai/compliance)** in the Requesty Console.
</Note>

## Who can use it

Compliance is **admin only** and covers the whole organization. Members who open the URL directly are redirected to Analytics. See [RBAC](/features/rbac) for the full role breakdown.

## Current policy and observed traffic

The page separates each control into two columns:

* **Current policy** reads the organization's configuration now.
* **Observed** summarizes traffic during the selected reporting period.

Choose **Last 7 days**, **Last 30 days**, or **Last 90 days**. The default is 30 days. Changing the period regenerates the observed figures; it does not change your policies.

<Warning>
  Policy settings are live, but observed figures and the downloadable evidence are a point-in-time report. After changing a setting, select **Regenerate** to include it in the evidence. The page shows a warning while the report snapshot is stale.
</Warning>

### Requesty controls

These rows describe how traffic is handled inside Requesty's infrastructure:

| Control                  | Current policy                      | Observed traffic                                          | How to configure it                |
| ------------------------ | ----------------------------------- | --------------------------------------------------------- | ---------------------------------- |
| Provider requests routed | Not configurable                    | Total provider attempts                                   | —                                  |
| Zero data retention      | Enabled or Off                      | Coming soon                                               | Select **Edit**                    |
| Serving region           | Unrestricted or the allowed regions | Requests served in EU, US, APAC, or not recorded          | Select **Edit**                    |
| Sensitive-data scanning  | Configured or Not configured        | Scanned, not scanned, scan error, and not recorded counts | Select **Edit** to open Guardrails |

#### Requesty zero data retention

Enabling Requesty zero data retention stops Requesty from storing request and response content across every existing and future API key. It overrides content logging configured on individual keys, while usage metadata such as model, token counts, cost, and latency is still recorded.

This setting takes effect immediately. After it is enabled, contact [support@requesty.ai](mailto:support@requesty.ai) to turn it off.

#### Allowed Requesty regions

Leave serving regions **Unrestricted** to allow all current and future Requesty regions, or choose one or more of **EU**, **US**, and **APAC**. A restricted organization must send requests to an allowed regional domain, such as `router.eu.requesty.ai`; requests through the global domain or a disallowed region are rejected.

See [EU Routing](/features/eu-routing) for endpoint details and the distinction between Requesty's serving region and a model provider's hosting location.

### Model provider controls

These rows describe what happens after Requesty forwards traffic to a model provider:

| Control                | Current policy                               | Observed traffic                                                                   | How to configure it                     |
| ---------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------- |
| Zero data retention    | Required or Not required                     | Requests split by provider data practice                                           | Select **Edit**                         |
| Model hosting location | Coming soon                                  | Requests split by model hosting location                                           | Not yet configurable here               |
| Credentials used       | Not configurable                             | Requesty-managed credentials versus customer [BYOK](/features/bring-your-own-keys) | —                                       |
| Approved models        | Enforced with model count, or Not configured | Enforced per request                                                               | Select **Edit** to open Approved Models |

#### Require zero-data-retention models

When this policy is required, Requesty only routes to models whose providers neither retain request data nor use it for training. A model that does not meet the requirement is rejected even if it is on your approved-model list.

This setting takes effect immediately. After it is enabled, contact [support@requesty.ai](mailto:support@requesty.ai) to remove the requirement.

<Info>
  Model hosting locations and data practices are resolved from the model catalog when the report is generated. Traffic for a model that is no longer in the catalog appears as **Not recorded**.
</Info>

## Guardrail violations

The Guardrail violations section shows what sensitive-data scanning found during the selected period:

* **Outcome breakdown** counts requests that were Flagged or Masked.
* **Violations by data class** groups violations into `pii`, `financial`, `secrets`, and `other`, split by the action taken.

The JSON artifact also includes `matches`, the number of individual sensitive values found. The page and PDF show `violations`, the number of requests that tripped a policy.

See [Guardrails](/features/guardrails) to configure scanners and understand each action.

## Configuration changes

This section counts configuration changes and distinct actors during the selected period. Select **Audit log** to inspect the individual events.

## How requests are counted

<Warning>
  Traffic and guardrail verdict counts are **provider requests**, not user requests. A user request that falls back across three providers counts up to three times. Requests blocked by Requesty policy before reaching a provider are excluded. Violation counts are per user request.
</Warning>

This counting basis evidences how many provider attempts handled the traffic. It can therefore be higher than counts on [Overview](/features/overview) and [Usage Analytics](/features/usage-analytics), which count user requests.

## Downloading evidence

Select **Download PDF** for the human-readable report. Use the adjacent dropdown to choose a format:

<Tabs>
  <Tab title="PDF">
    A formatted document for auditors, customer security teams, or your own records. It includes the policy snapshot, observed traffic, guardrail activity, configuration changes, scope, and limitations. Each page footer carries the payload SHA-256 that identifies the corresponding JSON artifact.

    Saved as `compliance-report-<period>-<date>.pdf`.
  </Tab>

  <Tab title="JSON (verifiable)">
    The raw evidence artifact exactly as the gateway produced it. Keep this copy if you intend to verify its payload hash; reformatting or re-serializing it can change the bytes used during verification.

    Saved as `compliance-report-<period>-<date>.json`.
  </Tab>
</Tabs>

The report is generated on demand and streamed directly to you. Requesty does not store a report archive. Its configuration snapshot reflects settings at generation time, not the historical settings for every moment in the selected period.

### Verifying a JSON report

The JSON file contains a `payload` and its `payload_sha256`. The hash is the SHA-256 of the compact JSON encoding of `payload`. To re-derive it:

```bash theme={"dark"}
jq -cj '.payload' compliance-report-30d-2026-08-27.json | shasum -a 256
```

The result must match `payload_sha256` in the downloaded file. Automated consumers should also check `payload.schema_version`; it is incremented when the artifact shape changes incompatibly. Default-valued fields may be omitted, so treat a missing boolean as `false`, a missing count as `0`, and a missing list as empty.

<Warning>
  This hash provides **report identity, not tamper evidence**. It confirms that two copies contain the same payload, but it is not a Requesty signature. Anyone who edits the payload can recompute the hash. Sign the downloaded JSON with your own key if you require cryptographic non-repudiation.
</Warning>

Use the information icon next to the page title to reopen **Report details & verification** after dismissing it.

## Data Processing Agreement

The Compliance page also hosts Requesty's Data Processing Agreement, pre-signed on our side:

<Steps>
  <Step title="Open the DPA">
    Select **View DPA**, then **Open PDF**.
  </Step>

  <Step title="Sign the customer sections">
    Have an authorized representative complete and sign the customer sections.
  </Step>

  <Step title="Return the signed copy">
    Email the completed PDF to [sales@requesty.ai](mailto:sales@requesty.ai).
  </Step>
</Steps>

A DPA with Requesty covers Requesty as a processor, not the upstream model providers. For provider-side terms, review the provider data practices surfaced in the [Model Library](/features/data-privacy) or use [BYOK](/features/bring-your-own-keys) so your own provider agreement applies.

## Scope and limitations

The report is evidence, not a certification, and does not make your organization compliant with a framework. Its main limitations travel with every downloaded copy:

* Traffic evidence currently covers chat completions only.
* Requests recorded before guardrail verdicts were introduced have no scan outcome and appear as **Not recorded**.
* Traffic and verdict counts use provider attempts; violation counts use user requests.
* Model hosting locations and data practices use the catalog at generation time.
* The configuration snapshot is current at generation time; use the audit log to establish when a policy changed during the reporting period.

## Related features

* [Data Privacy and Zero Data Retention](/features/data-privacy)
* [Guardrails](/features/guardrails)
* [EU Routing](/features/eu-routing)
* [Approved Models](/features/approved-models)
* [Bring Your Own Keys](/features/bring-your-own-keys)
* [RBAC](/features/rbac)