Your Data Is Not Used for Training

The core question: What happens to your data?

This is the first question any CISO or DPO asks when considering an AI API integration: will my data be used to train the model? The underlying fear is legitimate—no one wants fragments of their contracts or customer data absorbed into the weights of a model accessible to the world. xAI’s answer is clear: no.

Data sent via the Grok API—prompts, responses, images—is not used to train xAI models. This principle applies to the API, meaning the professional integration context. It is distinct from using Grok on grok.com or via the app, where privacy settings may vary based on user choices.

API vs. application: Two different contexts

This distinction between API and application is the point you will need to explain most often internally, because confusion is common: an employee who reads the consumer terms of use for the app will incorrectly draw conclusions about the API, and vice versa.

On the API side, the rules are those of the professional contract: data is not used for training, you control retention via the store parameter, and conditions are defined by the API contract (ToS Enterprise). This framework applies to all your integrations.

On grok.com and the app, privacy settings are configurable by each user, Collections—saved conversation history—are managed separately, and the general terms of use apply. If your employees use the app individually, that regime concerns them, not your API contract.

The store parameter: Controlling retention

Not being used for training is one thing; not being stored at all is another. The Grok API offers a store parameter that gives you granular control over request storage:

{
  "model": "grok-4.3",
  "messages": [{"role": "user", "content": "Analyze this contract..."}],
  "store": false
}

With store: false, the request and response are not retained after processing: no trace remains in xAI logs. This setting suits sensitive data—medical, financial, legal—and is particularly recommended for requests containing images. Imagine a firm analyzing confidential contracts: with store: false, the document exists at xAI only for the duration of inference, which radically simplifies risk analysis.

With store: true (or by default), the request may be retained temporarily for quality monitoring, enabling debugging via the xAI console. This is a useful compromise during development, when being able to replay and inspect requests saves time—but it must remain restricted to non-sensitive data.

Collections: Understanding the distinction

Collections are a feature of the Grok application—not the API—that lets you save conversations. Important point, and often misunderstood: Collections are not used to train models. Saving a conversation to a Collection means keeping it for the user, not adding it to a training corpus.

Let’s recap the full map: the API does not feed training and you control retention via store; app Collections save conversations without feeding training; for app usage outside Collections, check each account’s privacy settings.

Legal and contractual implications

For your DPA under GDPR, the fact that xAI does not reuse your data for training significantly simplifies the analysis: the processing purpose is limited to inference—generating a response—and not model improvement. This purpose limitation is precisely what the regulator expects from a well-defined subprocessor relationship.

The argument also holds sector by sector. In healthcare, PHI is not reused, which, combined with the BAA covered in lesson 1, makes usage defensible before a HIPAA auditor. In finance, market data or customer data does not leak into the model. In legal, professional privilege is preserved: the content of a case file will never resurface in a response made to another user.

Translating these guarantees into internal policy

What you just read describes what xAI does. Your organization still needs to decide what it does, and that requires a written policy your developers can apply without case-by-case arbitration.

Start by classifying your data by sensitivity level: public, internal, confidential, secret. This scale is not theoretical, because it dictates the store setting. Confidential and secret data require store: false without exception. Internal data calls for the same setting, this time as a strong recommendation. Only public data allows store: true, notably to benefit from debugging via the console during tuning phases.

Next, enforce this policy. Train your developers so they understand the real impact of the parameter: this is the decisive link, because a perfect policy on paper is worthless if a rushed developer leaves the default value on a confidential data flow. Then regularly audit the calls actually made by your services, sampling production requests—drift is silent, and only periodic verification reveals it.

Key takeaways

• API data is not used to train Grok models
• The store: false parameter prevents any data retention after processing
• Collections (Grok app) are also not used for training
• Use store: false systematically for sensitive data and images
• Document your API data management policy for compliance