Does DeepL Sell Your Data? A Product-by-Product Privacy Decision Packet

Decision in brief. The current DeepL privacy policy says text submitted to the Free Translator, Free Write, and Free API is processed for a limited time to train or improve its neural networks and algorithms. In the passages reviewed, it does not say DeepL sells submitted translation text. “Not sold” and “not used to improve the service” are different questions. For Translator Pro, Write Pro, and API Pro, the policy says submitted content is used to provide the service, held temporarily, deleted after service completion, and not used to improve DeepL’s models. Those statements still leave feature-level exceptions for saved translations, glossaries, translation memories, reference documents, document metadata, operational logs, and organizational usage reporting.

There is also a material wording mismatch to resolve before promising an EEA-only route: DeepL’s privacy policy says document-translation services process on its EEA infrastructure, while its current infrastructure help page describes multiple regions and AWS, and says default processing may span regions depending on contract and selection. I found no basis to say DeepL routinely sends every document outside Europe; I also found no basis to assume every plan and feature is EEA-only. Ask for the applicable plan, feature, subprocessor list, region setting, and contract version in writing.

Our earlier Trust-Vault DeepL field report used broad regional wording. This packet narrows that statement into a product-by-product verification process that expands the Trust-Vault DeepL profile into a decision record distinguishing content use, saved features, metadata, and regional controls.

Practical rule: do not put personal, confidential, regulated, or commercially sensitive text into a free surface. A paid plan is not a universal “safe” switch: identify which DeepL surface receives the data, whether any feature saves it, who can view account or usage information, what region applies, and which written terms govern that configuration. If any required answer is unknown, hold the data and ask the vendor or your privacy/security owner.

What “sell my data” can mean

People often use “sell” to describe several different events: a vendor selling a dataset to another party, retaining a copy, using submitted text to improve a model, disclosing data to a subprocessor, exposing usage information to an employer, or keeping an optional saved translation. These are distinct processing operations. A review that asks only “does the vendor sell it?” can miss a more relevant risk: Free Translator text may be used to improve the service even if no sale takes place.

The policy reviewed here does not establish a sale of submitted translation text. That is a limited finding about the documents examined, not proof that no data could ever be shared for another purpose. A subprocessor may receive data to deliver a service; that is not automatically a sale. Conversely, a service can use content to improve a model without selling it. Ask what happens to each data class, for each product surface, under the terms attached to the account.

Treat these as separate questions in your intake form:

1. Is text used to provide the requested translation?
2. Is text used for training, quality improvement, or another secondary purpose?
3. Is text or associated metadata saved after the operation?
4. Which service providers or regional systems process it?
5. What can an employer or administrator see?
6. What deletion, retention, and transfer rules apply?

A precise answer is more useful than a broad “DeepL sells data” or “DeepL never keeps data” slogan. The answer may differ for a free web translator, a signed-in account, a mobile app, a Pro document workflow, a saved glossary, or an API integration.

The current policy, by product surfaceThe source of truth for the statements below is DeepL’s Privacy Policy, retrieved on November 1, 2026. The policy distinguishes Free and Pro services and describes specific stored features. Read the current version again before making a procurement promise: product names, plan entitlements, and subprocessors can change.

The table separates policy statements from recommendations. “Temporarily processed” does not mean “never logged”; “not used for model improvement” does not mean “no metadata”; “saved only when requested” does not mean every product feature is unsaved by default. Preserve those distinctions in internal guidance.

Free Translator, Write, and API Free

DeepL’s Privacy Policy, in its Free-service section says content submitted to Free Translator and Free Write, including translations and corrections, can be used for a limited time to train and improve neural networks and algorithms. It says personal data should not be submitted to these Free services under DeepL’s applicable terms. That is stronger and more specific than a generic warning that “free tools might train on your data”: it is an explicit service-use statement in the current policy.

The Free API is not a shortcut around that rule. The policy places its free API version under the Free-service treatment. A developer who sees an API endpoint and assumes API traffic is automatically private has confused interface type with contract. Check whether the key belongs to API Free or API Pro, and retain the plan evidence in procurement records.The policy also distinguishes an unauthenticated glossary from an account-based glossary: a glossary used without an account is described as stored locally, while an account glossary may be forwarded. “May” matters. It does not establish that every glossary is always sent to the same backend or retained for the same period. It does mean the user should not treat a glossary as harmless configuration. Product terminology, customer names, preferred phrases, project titles, and sector vocabulary can reveal a client relationship or strategy.

Recommendation: allow Free services only for material your organization has explicitly classified as public and non-sensitive. Use synthetic text for demos. If a Free feature must be evaluated, create a clean test account, do not seed it with real terminology or documents, and capture the plan, date, feature, and current terms. This is a risk-control choice, not a claim that every free translation is published or sold.

Pro content: the important promise and its boundaries

For Translator Pro, Write Pro, and API Pro, DeepL’s Privacy Policy says submitted content is processed temporarily as required to provide the service, then deleted after performance is complete. It also says Pro service content is not used to improve DeepL’s models. For an organization considering sensitive translation, these are important contractual and operational distinctions from the Free-service section.

Do not shorten this to “Pro stores nothing.” The policy separately describes optional saved translations and glossary/customization features. It also describes Translation Memories and reference documents or embeddings associated with Adaptive Translation. Those resources support repeat work; they are not the same as the ephemeral text path. Some are retained for the account until the user deletes them, and output memory or reference assets can remain after the one-time input used to create them is removed.

A Pro user should therefore ask two questions at setup: “What happens to this translation request?” and “What persistent feature did we enable around it?” A one-time translation can have a different lifecycle from a saved translation, glossary, translation memory, or reference document. If an administrator enables a memory feature for convenience, the risk assessment must include the resulting asset, its access controls, deletion path, and whether a project or client boundary is respected.

The Pro policy is a meaningful protection for transient text. It is not a substitute for checking the actual feature list, organizational settings, DPA, role allocation, region, and retention of related records. Record the clause and exceptions together so the short version does not overpromise.

Files create a metadata trail too

A document translation is not just a block of text. DeepL’s Privacy Policy lists file-related operational metadata such as processing status and progress, file type, language pair, estimated time, glossary references for Pro or glossary content for Free, character count, and error information. It says this document metadata is stored for 14 days and is accessible to selected employees for the stated service purposes, after which it is automatically deleted.

That 14-day statement concerns the listed metadata; it should not be misquoted as a promise that the uploaded document body is retained for 14 days. The policy separately describes Free and Pro treatment of document content. Conversely, it is also wrong to say “the file disappears after translation” without mentioning metadata. Content and operational records are different categories, with different stated handling.

Metadata can be revealing even when it omits full text. File names may contain a client or case identifier. Language pairs can reveal a market launch or litigation venue. A glossary label, character count, processing time, or error can reveal that a large project or specialized document was processed. An error message may include user-provided information depending on how the application reports it; do not assume every error log is content-free without checking the exact workflow.Before uploading, remove names and identifiers from file names, strip unnecessary document properties, use an approved glossary only, and test with a synthetic document. If a sector rule prohibits external processing even where content is short-lived, the plan’s content promise does not override that rule. Have the data owner classify the file, not just the text inside it.

Saved translations, glossaries, and Translation Memories

The word “save” is not always an obvious switch. DeepL’s Privacy Policy describes saved translations as optional and says the user can ask to retain them; saved material remains accessible until deleted. It also describes account-based glossaries and Translation Memories. Translation memories are particularly important because they are useful precisely because they persist: they store aligned source/translation segments for future work. Adaptive Translation can also use reference documents or embeddings for a specific account.

A persistent asset can become more sensitive than a one-off sentence. A translation memory might accumulate contract clauses, recurring customer language, product names, or internal terminology. A reference document may be much longer than the fragment a user intended to translate. The data subject might also be different: a translator can upload a client’s material even though the translator owns the account.

Build an asset inventory with these fields: feature name, purpose, source documents, owner, account/workspace, user access, retention rule, deletion procedure, export path, and whether the feature is enabled by default. Keep the inventory separate from the transient request log. When a contract ends, deleting the account may not be the same as exporting, deleting, and verifying all saved resources; ask the vendor how each feature is removed and what evidence is returned.

If persistent features are not approved, disable them or block them by policy. If they are approved, limit them to a single client or project workspace where practical, restrict membership, and review access when a translator or employee leaves. Do not put client-specific terminology into an account-wide glossary and assume the transient-content clause protects it.

Organizational reporting and administrator visibility

DeepL’s Privacy Policy says that Pro usage-analysis information may be shared with the employer or organization holding the subscription, including information such as characters or documents translated and last-use/session information. This is not the same as a statement that an employer can read every translated sentence. The policy’s example categories describe usage information, not necessarily the text payload. Keep the distinction explicit when briefing employees.

Usage data can still be sensitive. A record that a named employee translated many documents on a particular date may reveal work on a transaction, investigation, medical case, or client matter. An administrator may also manage account access, saved assets, or workspace membership. Exact dashboard fields can vary by plan and product. Do not assure users about administrator visibility based only on a general privacy paragraph; inspect the actual organization console with a test user and ask DeepL support for a field-level description.

A privacy notice should answer: which usage fields are visible; who can view them; whether exports are available; how long the organization retains its own copy; whether it can see saved translations or glossaries; and how access is removed when an account is disabled. The organization’s retention and access practices are separate from DeepL’s practices.

Control: use a dedicated test user and synthetic content, inspect administrator and member views separately, record visible field names, and avoid using real employee activity to probe visibility. If a field is unclear, classify it as unknown and do not promise invisibility. Log the test date and plan because a dashboard change can invalidate old screenshots.

IP addresses, app telemetry, and technical logsA service may delete translation text while still handling technical information needed to run and secure it. DeepL’s Privacy Policy discusses website logs and technical information from mobile or desktop apps. In the reviewed policy, full IP address retention differs between Free and Pro contexts: Free is described with a maximum period of 14 days in relevant cases, while the Pro policy describes full IP address handling for the contract duration. These statements refer to IP information, not retention of all translated content.

Some product surfaces can call other providers for a function. The policy’s app and voice sections describe technical data and indicate that speech may be transmitted to another provider, potentially in the United States. That does not tell us ordinary typed text in every DeepL product follows the same route. It does mean “DeepL” is not always one data path. A desktop client, mobile application, voice feature, browser extension, and API integration may involve different endpoints and operating-system services.

Inventory the client surface as well as the plan: website, desktop app, mobile app, browser extension, API, or integrated third-party application. For each, ask which telemetry is sent, what the OS or app store receives, whether crash reports include content, which subprocessors are involved, and whether voice or dictation invokes a separate provider. Keep the question scoped. If users only use the web translator, do not imply a mobile voice route is relevant; if they use it, do not hide it under the generic web policy.

The region question: a live mismatch in first-party pages

The most important unresolved point is regional processing. DeepL’s Privacy Policy document-translation section says document-translation services process content on DeepL’s EEA infrastructure. DeepL’s infrastructure and data-protection help page, retrieved on the same date, describes a multi-region setup involving DeepL and AWS, including Europe, the United States, and Asia-Pacific. It says customer content may be processed in different regions by default, while region or data-residency choices can depend on a sales-managed plan or subscription selection. The help page also discusses an AWS subprocessor and region selection.

These first-party statements are not perfectly aligned. They might describe different product generations, features, customer contracts, or wording updates. The retrieved pages do not let us decide which explanation applies to every account. The safe conclusion is not “DeepL always processes documents in Europe” and not “DeepL sends every file worldwide.” It is “the public documents leave a plan- and feature-specific question that must be resolved before making an EEA-only commitment.”

Capture the exact URL, retrieval date, product surface, plan, region selection, applicable terms, DPA, and subprocessor list. Ask the account representative or privacy contact to state where request bodies, document metadata, saved assets, backups, logs, and support access are processed. Ask whether any region choice covers all of those classes or only the main content path. Request the answer for the contract version you will sign, not a general sales statement.

Residency is not the whole sovereignty question

The Forrester analysis of sovereign AI and cloud argues that sovereignty involves more than a data-center location: operational control, legal jurisdiction, governance, and who can administer systems matter. Apply that as a decision lens, not as evidence about DeepL’s exact service configuration.A service can store data in a region while support staff, identity systems, billing systems, or subprocessors operate under another jurisdiction. Conversely, an international vendor can provide a region-restricted customer configuration with additional controls. Neither company headquarters nor a marketing label settles the question. Ask which data is in scope, which entities provide the service, which subprocessors are involved, who can access it, and what legal and technical controls apply.

Make the requirement measurable. Instead of writing “must be sovereign,” specify: document content remains in the EEA; no non-EEA support access; named subprocessors only; administrator access logged; saved assets deleted within a verified period; organization usage metrics limited to approved fields; incident notification within the contract window. Some of these requirements may be unavailable on a given plan. That is a procurement decision, not a reason to silently redefine “sovereign.”

If the need is only to comply with a data-residency rule, ask for the precise region control and evidence. If it concerns foreign government access, vendor control, or operational access, data-center location alone is not enough. Keep separate questions separate so the vendor can answer accurately.

Controller, processor, and the reason labels are not enough

The European Data Protection Board’s technical training on AI and data protection explains that organizations deploying AI may have controller responsibilities and that controller or processor status depends on the purposes and means of the particular processing. It is a general regulatory framework, not a DeepL-specific classification.

For a translation workflow, the organization that chooses to translate customer records may determine the purpose and categories of data. DeepL may process content to provide the translation under a service relationship, while separate saved-feature, analytics, or account operations can raise different role questions. A contract label matters, but the real data flow and decision-making matter too. Do not infer the legal role for every feature from one paragraph or from the product’s marketing description.

Create a small role map: data controller or responsible organization; vendor processor or independent controller where applicable; account administrator; employee or translator; subprocessor; and data subject. Then map each purpose: translation delivery, model improvement, saved translation, memory generation, service security, usage analytics, billing, and support. For each purpose, record data fields, legal basis, retention, recipient, and the instruction or choice that governs it.

If personal data is involved, have the privacy or legal owner verify the DPA, processing instructions, transfer mechanism, and any impact assessment required for the organization. This article is an operational decision aid, not a legal opinion. The point is to avoid treating “we use Pro” as a complete compliance record.

A fail-closed decision matrix

Use this matrix before a user pastes text or uploads a file. “Hold” means pause until the named evidence is available. “Block” means do not put the data in that surface under the current internal rule. “Review” means a human owner must confirm the conditions; it is not automatic approval.| Situation | Default result | Evidence needed to change the result |
|---|---|---|
| Free Translator, Write, or API Free with personal or confidential data | Block | Formally approved exception and a product configuration whose terms explicitly cover the data; do not rely on a casual user setting. |
| Free service with public, non-personal text | Review | Data owner confirms classification, no client or secret vocabulary is embedded, and synthetic testing is adequate. |
| Pro one-time translation of ordinary business text | Review | Current Pro terms, exact surface, retention statement, region answer, and organization controls recorded. |
| Pro workflow containing personal data | Hold for privacy review | Legal basis, DPA, role allocation, transfer analysis, and any required assessment. |
| Translation Memory, saved translation, glossary, or reference document enabled | Hold until inventory | Feature-specific retention, workspace access, deletion/export method, and project boundary. |
| EEA-only requirement with unresolved policy/help-center mismatch | Hold | Written plan-specific answer covering content, metadata, support access, and subprocessors. |
| Voice or third-party integration used | Hold for route mapping | Exact providers, endpoints, telemetry, locations, and data categories for that feature. |
| Administrator visibility not tested | Review | Field-level console test and support confirmation; never promise activity is invisible. |

The matrix deliberately avoids a “safe” label. The positive path is conditional: the owner confirms the data class, evidence matches the plan and feature, and remaining uncertainty is accepted by the organization’s privacy/security process. If the vendor’s answer is vague, record the uncertainty and choose another route for restricted data.

A decision flow you can apply at the point of upload

flowchart TD
  A[Classify text and file] --> B{Free product surface?}
  B -->|Yes| C{Personal, confidential, regulated, or secret?}
  C -->|Yes| D[BLOCK: use another approved route]
  C -->|No| E{Public text and owner approved?}
  E -->|No| F[HOLD: classify and approve]
  E -->|Yes| G[REVIEW: use synthetic test first]
  B -->|No, Pro| H{Exact plan, feature, and terms captured?}
  H -->|No| I[HOLD: capture evidence]
  H -->|Yes| J{Saved feature, personal data, or region requirement?}
  J -->|Yes| K[HOLD: privacy, retention, and region review]
  J -->|No| L[CONDITIONAL REVIEW: record scope and approver]

This is a routing aid, not a legal conclusion. It makes the order of work visible: classify first, identify the actual surface second, then test exceptions. A product badge should not bypass the data-classification step.

An executable evidence gate

The following Node.js program is a small internal control, not a legal classifier. It accepts a JSON record and fails closed when the plan, feature, evidence version, owner, region, or saved-feature settings are unknown. It never returns “safe.” A human still needs to review any non-blocked request.

Save it as deepl-privacy-gate.mjs and run it with Node 20 or later. The examples are synthetic fixtures, not production records or a statistical sample.

const allowedPlans = new Set(["free", "pro"]);
const allowedSurfaces = new Set(["translator", "write", "api", "document_translation", "saved_translation", "glossary", "translation_memory", "reference_document", "mobile_app", "voice"]);
const restrictedClasses = new Set(["personal", "confidential", "regulated"]);
const persistentFeatures = new Set([
  "saved_translation",
  "glossary",
  "translation_memory",
  "reference_document"
]);

function decide(record) {
  const required = [
    "plan",
    "surface",
    "dataClass",
    "owner",
    "termsVersion",
    "regionEvidence"
  ];

  if (required.some((key) => !record[key])) return "HOLD_MISSING_EVIDENCE";
  if (!allowedPlans.has(record.plan)) return "HOLD_UNKNOWN_PLAN";
  if (!allowedSurfaces.has(record.surface)) return "HOLD_UNKNOWN_SURFACE";
  if (typeof record.regionRequired !== "boolean" || typeof record.personalData !== "boolean" ) return "HOLD_MISSING_EVIDENCE";

  if (record.plan === "free" && restrictedClasses.has(record.dataClass)) {
    return "BLOCK_FREE_RESTRICTED_DATA";
  }

  if (record.regionRequired && record.regionEvidence !== "written-confirmed") {
    return "HOLD_REGION_UNVERIFIED";
  }

  if (
    record.personalData &&
    record.plan === "pro" &&
    (!record.dpa || !record.legalBasis || !record.rolesReviewed)
  ) {
    return "HOLD_PRIVACY_REVIEW";
  }

  if (persistentFeatures.has(record.surface) && !record.retentionAndDeletionReviewed) {
    return "HOLD_PERSISTENT_FEATURE";
  }

  if (record.voiceOrThirdPartyRoute && !record.routeMapReviewed) {
    return "HOLD_ROUTE_MAPPING";
  }

  return "REVIEW_ONLY";
}

const cases = [
  {
    name: "free with a confidential contract",
    input: {
      plan: "free",
      surface: "translator",
      dataClass: "confidential",
      owner: "legal-ops",
      termsVersion: "captured-2026-11-01",
      regionEvidence: "unknown",
      regionRequired: true,
      personalData: false,
      dpa: false,
      legalBasis: false,
      rolesReviewed: false
    },
    expected: "BLOCK_FREE_RESTRICTED_DATA"
  },
  {
    name: "Pro with unknown region",
    input: {
      plan: "pro",
      surface: "document_translation",
      dataClass: "ordinary-business",
      owner: "procurement",
      termsVersion: "captured-2026-11-01",
      regionEvidence: "unknown",
      regionRequired: true,
      personalData: false,
      dpa: true,
      legalBasis: true,
      rolesReviewed: true
    },
    expected: "HOLD_REGION_UNVERIFIED"
  },
  {
    name: "Pro with a saved memory not reviewed",
    input: {
      plan: "pro",
      surface: "translation_memory",
      dataClass: "ordinary-business",
      owner: "translation-ops",
      termsVersion: "captured-2026-11-01",
      regionEvidence: "written-confirmed",
      regionRequired: true,
      personalData: false,
      dpa: true,
      legalBasis: true,
      rolesReviewed: true,
      retentionAndDeletionReviewed: false
    },
    expected: "HOLD_PERSISTENT_FEATURE"
  }
];

for (const item of cases) {
  const actual = decide(item.input);
  if (actual !== item.expected) {
    throw new Error(item.name + ": expected " + item.expected + ", got " + actual);
  }
  process.stdout.write(item.name + ": " + actual + "\n");
}

The code is intentionally conservative. It does not decide whether a particular legal basis is valid, whether a DPA is sufficient, or whether DeepL’s answer is contractually binding. It makes missing facts visible before a user submits content. A team can extend it with approved plan IDs, contract evidence links, expiry dates, and a named approver. Keep those additions in version control, and require review whenever source terms or product features change.

How to use the gate without creating bureaucracy

A useful gate is short enough to use at the point of work. Put the questions in the upload workflow or translation request form, not in a document users never see. Ask for the source classification, product surface, plan, whether personal data appears, whether a persistent feature is enabled, and whether a region restriction applies. The data owner should answer classification; the user should not guess based on how harmless a sentence looks.

Use three outcomes only: block, hold, or human review. Avoid a green “approved” badge unless the record includes current evidence and a defined scope. If a team cannot identify whether a request goes to Free or Pro, that is a hold. If a translator is using an approved Pro plan but has enabled an unreviewed translation memory, that is also a hold for that feature. If a region is confirmed only in a sales email but not in the governing terms, record that gap and send it to procurement.

Keep the packet proportionate. A marketing team translating public website copy does not need a full impact assessment for every sentence. It still needs a predictable rule that prevents confidential launch plans from being pasted into a free form. A legal team translating client contracts needs a more formal record: data categories, recipients, region, contractual instructions, access controls, and deletion verification. Different sensitivity levels should produce different evidence burdens.

Do not ask users to copy the entire privacy policy into a ticket. Store a stable link and a dated excerpt or contract record in a controlled system. Then the gate can point to the evidence, plan, owner, and last review date.

A reproducible rollout protocolRun a controlled test before broad adoption. First, create one Free test account and one Pro test account only if those are plans your organization is evaluating. Use invented text such as “PROJECT ORCHID / CUSTOMER LANTERN / 2031-Q4” rather than any real person, customer, contract, or secret. Test one-time text, a synthetic document, an optional glossary, and each save/memory feature that matters. Do not upload the same real document to compare outputs.

Second, observe the user and administrator views separately. Record the plan name, feature name, visible save controls, organization usage fields, error messages, and any retention or region selection. Take screenshots only if your records policy allows them; remove account identifiers before placing them in a shared ticket. A test of the interface does not prove backend deletion, so mark that conclusion as “not verified by UI.”

Third, ask the vendor the unresolved contractual questions with the exact use case. Attach no customer data. Ask whether the selected region covers request content, file metadata, saved assets, backups, support access, and subprocessor processing. Ask which agreement controls if the public policy and help page differ. Ask for a current subprocessor list and whether region choices are plan-dependent.

Fourth, route the answer to data protection, security, and procurement. The data owner approves classification; privacy reviews roles and lawful basis; security reviews access, transfer, and operational controls; procurement records the terms. If any reviewer rejects or the answer is missing, keep restricted data out of the service. Record the decision expiry date so a new policy version triggers re-review.

Procurement questions worth sending to DeepL

A focused vendor questionnaire is more effective than “Is DeepL GDPR compliant?” Ask for scoped answers:

• Which exact products and endpoints are covered by our plan: Translator, Write, API, document translation, desktop, mobile, browser extension, voice, or integrations?
• For each surface, what happens to request content, response content, corrections, file metadata, error logs, IP address, and usage analytics?
• Which parts are processed transiently, and which can be saved by user or administrator action?
• Are glossaries, translation memories, and reference documents enabled by default? Where are they stored, who can access them, and how are they deleted?
• Which subprocessors receive content or metadata? Does the AWS region statement apply to our product and plan?
• Does our plan lock processing to the EEA? Does that restriction cover support, logs, backups, telemetry, and saved assets?
• Which exact terms and DPA govern this account, and which version controls if a public help page differs?
• What organization-level usage fields can administrators see and export?
• What deletion evidence is available when the account or contract ends?
• Which route is used for speech, dictation, browser plug-ins, and third-party connections?

Ask the vendor to answer by data category, not with a single “yes, encrypted” sentence. Encryption in transit or at rest does not answer model-use, retention, region, administrator access, or deletion questions. If the vendor cannot answer a field, mark it unknown and apply the organization’s rule for unknowns.

Failure modes to design against

Mistaking “no sale” for “no secondary use.” A Free-service training clause can matter even if the vendor does not sell submitted text. State both facts separately.

Assuming API means enterprise privacy. Free API and Pro API are different plan surfaces. A technical endpoint does not change the governing terms.

Calling all Pro data transient. One-time text may be deleted after the operation while saved translations, glossaries, memories, reference documents, or related account assets persist.

Confusing text retention with metadata retention. The 14-day document metadata statement is not the same as document-body retention. Quote it narrowly.Treating an EEA statement as universal. The policy and infrastructure page are not fully aligned. An older Trust-Vault page or a broad marketing statement cannot settle which one applies to your account.

Assuming location equals sovereignty. Region, administrator access, support operations, subprocessors, legal jurisdiction, and governance are separate requirements.

Promising that employers see nothing. The Pro policy describes certain usage-analysis fields shared with the organization. Do not turn that into either “employers can read every text” or “employers see no activity.”

Using a real document to test deletion. A test can accidentally expose client or employee data. Use synthetic content and ask the vendor for contract evidence.

Leaving a shared memory after a project ends. Disabling the translator account may not automatically remove every saved asset. Track asset deletion separately.

Citing a policy without a date. A policy can change while an internal presentation remains online. Record retrieval date, version, and service surface reviewed.

Contradictions and evidence limits

There are three kinds of statement in this packet. First are DeepL’s own current policy statements about Free and Pro content, metadata, saved features, and usage information. Second is DeepL’s help page’s current infrastructure description. Third are external governance lenses, such as the EDPB framework and Forrester’s broader sovereignty discussion. Do not blend them into one claim.

The region mismatch is a contradiction between two first-party pages retrieved on November 1, 2026. The privacy policy describes document translation as processed on EEA infrastructure; the help page describes global regions and AWS with default behavior and choices that can depend on plan. This packet cannot identify which exact plan or deployment a particular account receives. The resolution must come from current account terms or written vendor confirmation.

A July 2023 policy from Bern University of Applied Sciences recommends caution with machine translation and distinguishes free from paid services. It is useful as an institutional example of conservative handling, but it is not evidence that DeepL sells text or that its current plans work a particular way. Likewise, a public translator-forum search result surfaced a question about whether the Free version retains copies. That question reflects user concern, not a verified answer.

Stanford HAI’s AI Index is a broad research and policy resource, not a DeepL product audit. It can frame why organizations need governance, but it cannot tell us which DeepL subprocessor or region a specific request uses. The Forrester article frames sovereignty beyond location, but it is not a regulatory ruling. Keep each source inside its evidentiary boundary.

Questions real users ask

The search question “does DeepL sell data?” is a useful intent signal because the person asking needs a direct purchasing or upload decision. The answer should not be buried in a general privacy article. Say plainly: the documents reviewed do not establish that DeepL sells submitted translation text; the Free-service policy does describe temporary use of content to improve models; Pro has a different content rule; and saved features, metadata, usage data, and processing region require separate checks.

Another real concern is whether Free translations are retained or copied. Explain that the Free policy’s limited training/improvement use is not the same as a public archive or a sale. Do not promise that text is never available to any operational system unless the policy says that. The right follow-up is to check the product terms and the organization’s data classification.

A third question is whether a paid account makes the workflow compliant. The answer is “not by plan name alone.” Pro content protections matter, but personal data still needs an appropriate legal basis, contract, purpose, roles, security controls, region assessment, and feature inventory. A paid product can reduce one risk while leaving another unresolved.Finally, users ask whether their employer can see what they translated. The policy gives examples of organization-level usage information, not a universal promise about content visibility. Test the admin console with synthetic activity and ask which fields the organization can view or export. For a question about a particular user, contract, country, or feature, state that boundary instead of giving a blanket answer.

Method, original asset, and limits

This packet was prepared on November 1, 2026. I reviewed DeepL’s current privacy policy, its infrastructure and data-protection help page, the EDPB’s technical AI/data-protection training, Stanford HAI’s AI Index landing page, Forrester’s sovereignty analysis, and a dated university machine-translation policy. The official DeepL pages support product-specific policy claims; external sources are used for governance framing. A public translator-forum search result and the wording of a real search query were treated only as signals of user questions, not evidence about DeepL’s handling.

The original reusable asset is the fail-closed matrix plus the Node.js gate above. It has synthetic fixtures and no production documents, customer texts, or real user account. No statistical estimate, retention experiment, security test, or ranking claim was produced. The examples demonstrate control behavior only. Exclusions include negotiated enterprise terms not publicly visible, third-party integrations, browser extensions, the full set of mobile/voice providers, individual account settings, and any configuration not represented by the published pages.

An official DeepL legal-industry webinar page was also screened for its topic description. Its on-demand button redirected to the DeepL homepage in this review and no transcript was accessible, so the video was not used as evidence for any guarantee. This is deliberate: a marketing description is not a substitute for a contract clause.

Bottom line checklist

Before a user submits a translation, confirm each box:

• [ ] The exact product surface and plan are known.
• [ ] The source text’s classification and owner are recorded.
• [ ] Free surfaces are blocked for personal, confidential, regulated, or secret material under internal policy.
• [ ] The current content-use clause is captured, including the Free improvement/training rule.
• [ ] Pro’s transient-content clause is not being misapplied to saved features.
• [ ] Document metadata, usage analytics, IP, and technical logs are considered separately from content.
• [ ] Glossaries, saved translations, memories, and reference files have an owner, retention rule, and deletion path.
• [ ] Organization administrator visibility has been checked with synthetic activity.
• [ ] Region, subprocessor, support access, and terms-version questions are resolved in writing if required.
• [ ] Privacy, security, data ownership, and procurement have approved the use case.
• [ ] A date and evidence link are attached to the decision; unknowns result in hold.

If data is restricted and a key answer remains unknown, keep it out of the service while you resolve the issue. If data is public and the organization has approved the exact plan and workflow, document that narrow decision and revisit it when the product, terms, region, or saved features change. The right answer to “does DeepL sell your data?” is not a slogan: it is a scoped statement about which data, on which surface, for what purpose, for how long, and under which evidence.