Search

What are you looking for?

Search our services, use cases and practical insights.

Enter at least 2 characters

Popular starting points

Data & governance

No training, no storage or data residency: What is the difference?

Similar-sounding promises answer different questions. A review limited to whether data is used for training can miss storage, regions, support access and third-party services.

The short answer

No training limits the use of customer data to improve models, no storage concerns the retention of content, and data residency designates regions for certain processing or storage. None of these promises automatically includes the others.

In brief

  • Training, storage, processing, deletion and location are separate properties.
  • Scope may vary by product, plan, endpoint and feature.
  • Operational and billing metadata can exist even without content retention.
  • The contract, documentation, configuration and actual data flow must agree.

Use a comparison matrix, not similar-sounding labels

Providers often group several data controls under labels such as enterprise privacy. The matrix deliberately separates the promises: it shows which question each statement answers, what remains open and what should prove it for the exact feature in use.

Use a comparison matrix, not similar-sounding labels
PromiseWhat it meansWhat it does not meanEvidence required
No trainingCustomer data is not used to train or improve models.No storage, no support access or processing only in a particular region.Contract term, product documentation and the setting for the account, model and feature.
Limited retentionDefined content is removed after a stated period.Immediate deletion or the same period for files, logs, backups and metadata.Periods by data type and feature plus a documented deletion and backup process.
Zero data retentionCovered customer content is not persistently retained after processing by explicitly covered features.No processing, no metadata, no third parties or one universal promise for the whole product.Written feature scope, proof of activation and a test of the actual data flow.
Data residencySpecified data is stored or processed in the promised regions.Complete localisation of all support, identity, safety and subprocessor data.A region matrix by data type and processing step plus a current subprocessor list.
No human reviewPeople do not inspect content during the agreed normal operation.Technical systems do not process content or exceptions for support, safety and law never exist.Contractual access purposes, exception process, role model and auditable access logs.
Deletion capabilityStored data can be removed through a defined route within a stated period.Every copy, log and external connector is deleted automatically at the same time.Deletion procedure, period, scope, confirmation and tests for primary systems, backups and downstream systems.

Scope matters more than the headline

A promise may apply only to business accounts, selected models or specific API endpoints. File uploads, conversation history, web search, prompt caching or evaluation features can follow different rules.

  • Which organisation, projects, accounts and keys are covered?
  • Which models, regions and endpoints are included?
  • Which features create application state or additional storage?
  • What exceptions exist for abuse monitoring, support or legal duties?
  • Do preview features and third-party tools change the promise?

Data residency is not complete data localisation

A regional commitment may cover stored customer data, model processing or only selected components. Identity, billing, safety and support data may be processed elsewhere. A region also does not by itself establish whether a cross-border disclosure is lawful.

  • Assess storage and processing separately.
  • Include support access and global operational services.
  • Record subprocessors and their locations.
  • Do not replace legal safeguards with a region label on a map.

Make provider statements comparable

Marketing language becomes comparable only through a common review table. Every answer should have a source, a date and an accountable owner inside the organisation.

  1. Step 1

    List data types

    Separate inputs, outputs, files, prompts, logs, feedback and metadata.

  2. Step 2

    Describe the lifecycle

    Record processing, location, duration, deletion and any secondary use.

  3. Step 3

    Map features

    Verify the promise for every endpoint and connector in use.

  4. Step 4

    Preserve evidence

    Version the contract, product documentation and active settings.

Example from day-to-day business

Example: An API with European data residency

A company selects a European region and disables training. Its review still finds that a stateful file feature stores content and that operational metadata is processed globally. The project therefore uses only covered API endpoints, keeps files in its own storage and documents the remaining metadata flows separately.

What to remember

For each data promise, require a precise answer covering data type, feature, region, retention period, exception and evidence. Only then can products and plans be compared fairly.

Sources and further reading

These primary sources provide further detail on definitions, technical foundations or responsible use.

Content reviewed

Reviewed 17 July 2026. General information, not legal advice. The specific legal position and applicable scope must be assessed for each use case.

Would you like to apply this to your situation?

Together, we clarify what makes sense for your process, data and systems – in plain language and without unnecessary complexity.

Discuss Your Project