Does xAI use API prompts to train models?

The xAI API security FAQ states that API inputs and outputs are excluded from training unless the customer gives explicit permission. Preserve the current source page and contract version in the vendor file. Keep API use separate from consumer Grok experiences and other xAI surfaces because the API statement applies to the documented API. The customer still needs an approved purpose and data-class policy for the workflow sending content to that API, plus its endpoint and feature inventory.

Does the US endpoint guarantee complete data residency?

The official regional documentation is specific: it guarantees US handling for API requests and inference. Moderation and retained request data fall inside the same guarantee. The guarantee excludes Files and Collections. Server-side tools and the network path are outside it too. xAI also states that the endpoint alone is not a complete contractual residency guarantee. Record each function against the documented scope and obtain contractual terms where the organization's residency requirement extends beyond that technical boundary.

What evidence proves Zero Data Retention is active?

Capture the x-zero-data-retention response header from a synthetic request made through the production route. Store the timestamp, team, endpoint, model, and correlation identifier with the result. Also compare the enabled feature set against xAI's ZDR restrictions. A settings screenshot is useful configuration evidence. The response header proves the live request received the expected retention state at that moment.

Can DeepInspect govern Grok Build activity?

DeepInspect can govern a customer-controlled HTTP model route that passes through its stateless proxy. It can evaluate application-supplied identity and destination, then prompt classification and policy. It records the decision. Local Grok Build history, repository access, file reads, terminal commands, consumer sessions, and xAI provider-internal activity require separate controls. The architecture record should show which model calls traverse the proxy and which local actions are outside it.

Grok Enterprise Compliance Starts with Route and Retention Scope

TL;DR

The first compliance facts are the exact xAI surface and endpoint in use, then the retention mode and the enabled capability set.
There is no processing-region guarantee on the global API; the US endpoint covers a defined subset of API processing.
Zero Data Retention changes which capabilities remain available and can be verified through a response header.
Grok Build and consumer Grok experiences need their own scope decisions. Files and Collections do too, along with server-side tools.

The deployment surface is the first control decision

"Grok Enterprise" spans several distinct technical surfaces. An organization may use the direct xAI API, Grok Build, grok.com, Files or Collections, generated media, server-side tools, or an experience delivered through X. Each route has its own authentication and storage rules, and its own capability and evidence behavior.

Begin the compliance record with the exact hostname, product, team, model, enabled capabilities, client and contract. Include the project owner and approved user population. Name any ancillary service that stores a file or executes a tool. A terminal showing api.x.ai while the approval memo says only "Grok" is a small black window into a much larger scope problem.

The Grok enterprise security review covers authentication and application controls around these surfaces. The Grok enterprise audit-log analysis focuses on reconstruction. This article stays with the compliance decision: which documented route and retention behavior the customer approved, and how operations prove that the live workflow still matches it.

Default API retention is part of the approval file

The official xAI API security FAQ says API inputs and outputs are excluded from model training unless the customer gives explicit permission. Under the default setting, requests and responses are encrypted at rest and retained for 30 days for abuse auditing before deletion. The same page documents SOC 2 Type 2 and directs eligible customers under a signed nondisclosure agreement to the xAI Trust Center.

Record the selected retention mode and approving owner. Store the contract reference and review date. Note which capabilities were tested under that mode. If the organization needs HIPAA coverage, preserve the submitted BAA questionnaire and the signed agreement rather than treating the public security page as an automatic BAA.

The AI vendor risk-management framework is the broader ownership model. Procurement owns the contractual statement. The application owner chooses which capabilities to enable. Security and privacy approve the route and data classes. Operations need evidence that requests still use the selected team and endpoint after a deployment change.

Zero Data Retention changes the architecture

The security FAQ says Zero Data Retention (ZDR) is a team-wide setting. Prompts and outputs are kept out of persistent storage under that mode, and xAI returns an x-zero-data-retention response header so applications can inspect the active state. The header is testable evidence that a policy memo cannot supply.

ZDR also changes the available architecture. xAI documents restrictions affecting per-key request logging, stateful Responses, Files, Collections, Batch, deferred completions, stored media outputs, and voice history. An application built on one of those functions needs a different design or an approved retention exception. Store that choice beside the capability inventory.

I would fail a review that records "ZDR enabled" without one captured production response. Test the actual team and API route with synthetic content. Preserve the response header, request timestamp, endpoint, model, feature, and correlation identifier. Repeat the check after team changes and release updates. A key rotation alone fails to prove continuity, since the same team setting governs every key.

Regional endpoints have a documented edge

The xAI regional-endpoint documentation says there is no processing-region guarantee on the global api.x.ai endpoint. The US regional endpoint guarantees US handling for API requests and inference. The same guarantee covers moderation and retained request data. That is specific enough for an approved routing control.

The documented edge is just as important. xAI excludes Files, Collections, server-side tools, and the network path to xAI from the US endpoint guarantee. It also warns that a regional endpoint alone is not a complete contractual data-residency commitment. Record the hostname and covered operation for each workflow. Add every excluded feature as a separate row with its own decision.

A compliance test should resolve the configured base URL from production settings and capture the destination used by a synthetic request. Inspect failover behavior too. If an application silently falls back to the global endpoint during a regional outage, the approval file should state that behavior and the policy outcome. The AI policy enforcement architecture explains where an enterprise-controlled route policy can allow the US endpoint and block an unapproved fallback.

Grok Build has local and provider-side state

The official Grok Build enterprise deployment guide describes managed configuration and system-level settings that administrators can pin so users cannot override them. It also documents a separate data lifecycle. Under ZDR, inference-layer prompts and responses avoid provider persistence, and so does submitted code, while local session history is still on the user's machine under ~/.grok/.

That split is part of the control record. Endpoint management owns the local directory, device encryption, user access, backup behavior, and secure deletion. The xAI team setting governs provider retention for the covered inference traffic. Managed configuration controls the approved endpoint and model options. Keep evidence for each layer with a named owner.

Grok Build can also interact with local tools and repositories. Local execution is outside DeepInspect's HTTP AI boundary. The gateway can inspect the model request if the configured route passes through it. It cannot govern files read locally or commands executed by the CLI. A clear architecture diagram should draw that boundary at the HTTP call instead of wrapping the entire developer workstation in one vendor-control label.

Runtime evidence proves the chosen route

A defensible compliance file pairs the contract and configuration with runtime evidence. The runtime record should identify the authenticated user or agent, xAI surface, hostname, team, model, requested feature, retention-header value, data classification, policy outcome, timestamp, and correlation identifier. Sensitive content can stay in the source system while the record stores a controlled reference or digest.

Select one permitted request and one prohibited request during each quarterly review. Verify the approved endpoint and ZDR header. Exercise the normal failover path. If Files or Collections are enabled, test them separately against their documented scope. Do the same for media and server-side tools. Record the reviewer and remediation ticket.

This operating evidence prevents a familiar failure: the order form, architecture diagram, and production base URL describing three different systems. The route that carried the request is the compliance fact. The customer needs a record that can reconstruct that route without relying on the engineer who configured it six months earlier.

DeepInspect

DeepInspect is a stateless proxy between authenticated users or agents and LLMs on customer-controlled HTTP routes. For an xAI API deployment, it can enforce the approved endpoint and caller, plus the model route and data-class policy, before a request leaves the enterprise boundary, then produce a per-decision audit record.

That control complements xAI's retention and regional settings. DeepInspect can record the selected route and policy outcome. It cannot extend a US endpoint guarantee to excluded services or manage local Grok Build history. It cannot replace contract review or govern provider-internal operations and consumer Grok sessions.

Book a technical deep dive at deepinspect.ai.