Mistral says it may use non-enterprise users’ inputs and outputs for model training by default unless they opt out, creating a material privacy distinction between standard and enterprise deployments.
state: resolvedheat: lowuncertainty: mediumconvergesscott: mediumdata-privacy llm-apis model-trainingMistral AI
What is this?
Mistral AI’s privacy policy says user inputs and outputs may be used to train its models, subject to the user opting out. Its help center states that Vibe users on Free, Pro, or Education plans should disable a privacy toggle if they do not want interactions—including uploaded documents—used for training, while Team and Enterprise data is not used for training. The exact boundary is more granular than simply “non-enterprise versus enterprise”: a secondary source says paid API and Scale-plan usage also receives protections, while another reports broader training eligibility under commercial terms effective March 12, 2026.
Why it matters to Scott
Mistral’s tier-dependent training defaults reinforce Scott’s position that sensitive enterprise data needs a governed gateway and tokenized boundary rather than reliance on consumer-provider defaults. This bears directly on model routing and client guidance for OpenClaw and the AWS Marketplace Knowledge Appliance, although the radar already tracks analogous retention-policy distinctions at Anthropic and OpenAI.
ip:concept.company-ai-gatewaydev:concept.privacy-tokenized-agent-boundarydev:project.openclawdev:project.applianceradar:anthropic-data-retention-policy-changeradar:openai-frontier-model-zero-data-retentionradar:concept.training-dataradar:concept.data-retentionradar:concept.ai-privacy
queries asked of Scott's wikis
- LLM provider training-data defaults and consent
- privacy boundaries for coding agents and uploaded repositories
- zero-data-retention requirements for AI APIs
- enterprise versus consumer AI data governance
- local models as data-sovereignty infrastructure
- agent memory and confidential-data leakage
Measured heat
no measured readings yet — the hourly heat pass fills this in
How the heat travelled
no chain yet — the hourly chain pass fills this in
Evidence (2) — ⭐ canonical anchor
Interpretation history
2026-09-02T18:36:00Z
The refreshed comments only repeat objections and ambiguities already captured, without an authoritative policy change or new implementation evidence. The established tier-dependent privacy distinction is now absorbed; remaining uncertainty about exact plan boundaries does not sustain a developing episode.
2026-09-02T18:03:01Z
Repeated discussion continues to surface governance concerns, but adds no authoritative clarification of Team-plan controls, policy scope, or whether the default recently changed. The case remains a concrete but already-absorbed privacy distinction rather than a developing escalation.
2026-09-02T14:42:23Z
The refreshed discussion raises operational concern about centrally enforcing opt-outs and possible Team-plan ambiguity, but supplies no authoritative change to the already established policy boundary. It remains amplification rather than a new consequential development.
2026-09-02T13:33:40Z
The first-party policy establishes a real tier-dependent training-data default, but the simple non-enterprise/enterprise split is too broad and there is still no evidence that this is a recent change. This re-evaluation adds no consequential delta, so the case should remain monitored rather than amplified.
2026-09-02T13:31:28Z
grounded: converges/medium — Mistral’s tier-dependent training defaults reinforce Scott’s position that sensitive enterprise data needs a governed gateway and tokenized boundary rather than
2026-09-02T13:29:10Z
origin walked (codex/luna, conf 0.98): anchor hn.story.49535284 -> echo.other.441ed5a219 by Mistral AI
2026-09-02T13:28:07Z
case created — The linked first-party policy is a concrete and immediately actionable privacy event for developers sending production data to Mistral.
Decision trace
- 09-03 04:36resolveThe refreshed comments only repeat objections and ambiguities already captured, without an authoritative policy change or new implementation evidence. The established tier-dependent privacy distinctio
- 09-03 04:36alert_silentNo consequential new delta occurred: refreshed discussion merely reinterprets the known policy, so it can wait for routine coverage or a future first-party clarification.
- 09-03 04:36alert_routeNo consequential new delta occurred: refreshed discussion merely reinterprets the known policy, so it can wait for routine coverage or a future first-party clarification.
- 09-03 04:21sensor_dirtycomment_update
- 09-03 04:03repriceRepeated discussion continues to surface governance concerns, but adds no authoritative clarification of Team-plan controls, policy scope, or whether the default recently changed. The case remains a c
- 09-03 04:03alert_silentThe refreshed comments only reinterpret the known policy and provide no verified policy change, scope clarification, or implementation evidence that warrants interrupting Scott before the next briefin
- 09-03 04:03alert_routeThe refreshed comments only reinterpret the known policy and provide no verified policy change, scope clarification, or implementation evidence that warrants interrupting Scott before the next briefin
- 09-03 03:22sensor_dirtycomment_update
- 09-03 02:21sensor_dirtycomment_update
- 09-03 01:21sensor_dirtycomment_update
- 09-03 00:42repriceThe refreshed discussion raises operational concern about centrally enforcing opt-outs and possible Team-plan ambiguity, but supplies no authoritative change to the already established policy boundary
- 09-03 00:42alert_silentThe new delta consists only of comments interpreting the known policy; there is no new first-party policy, verified scope change, or implementation evidence that merits interrupting Scott again.
- 09-03 00:42alert_routeThe new delta consists only of comments interpreting the known policy; there is no new first-party policy, verified scope change, or implementation evidence that merits interrupting Scott again.
- 09-03 00:21sensor_dirtycomment_update
- 09-02 23:33repriceThe first-party policy establishes a real tier-dependent training-data default, but the simple non-enterprise/enterprise split is too broad and there is still no evidence that this is a recent change.
- 09-02 23:33alert_silentScott has already been routed the actionable policy distinction, and this look contains only an unchanged reobservation with no new policy, access, or scope change.
- 09-02 23:33alert_routeScott has already been routed the actionable policy distinction, and this look contains only an unchanged reobservation with no new policy, access, or scope change.
- 09-02 23:31alert_shadowMistral’s first-party help article establishes a deployment-tier privacy distinction relevant to model routing and confidential-data controls: Vibe users must opt out, while Enterprise customers are o
- 09-02 23:31alert_routeMistral’s first-party help article establishes a deployment-tier privacy distinction relevant to model routing and confidential-data controls: Vibe users must opt out, while Enterprise customers are o
- 09-02 23:31groundMistral’s tier-dependent training defaults reinforce Scott’s position that sensitive enterprise data needs a governed gateway and tokenized boundary rather than reliance on consumer-provider defaults.
- 09-02 23:29promote_anchororigin walk conf 0.98
- 09-02 23:28createThe linked first-party policy is a concrete and immediately actionable privacy event for developers sending production data to Mistral.