Skip to main content

3 docs tagged with "data retention"

View all tags

Fine-tuning-as-a-service privacy: where your fine-tuning data goes, and how fine-tuning erodes alignment (privacy refusals included)

In one sentence how long it's retained, whether it's used for training or human review, whether the resulting fine-tuned model is yours alone — none of this is a single number; verify each vendor's current terms item by item (most vendor docs say fine-tuning inputs/outputs aren't used for training by default and the fine-tuned model is for your use alone — but still check the terms for your tier, your endpoint, your region, and remember they change). Face 2 — fine-tuning itself erodes alignment handing data to a vendor fine-tuning API means you must both verify the data boundary and assume fine-tuning will weaken alignment — including the privacy refusals the model would otherwise make. (Note: Qi et al. is primarily a result about safety-alignment erosion, not a direct data-leak / PII-extraction result — this entry uses it to say "fine-tuning weakens privacy refusals along with the rest," and does not overstate it as "fine-tuning can extract the training data.")

Inference-service data boundary: "they don't train on it" is one cell — verify each, and it expires

In one sentence how long it's retained, how long abuse-monitoring logs are kept, how enterprise vs. consumer tiers differ, whether there's zero data retention (ZDR), who the subprocessors are, which region the data lands in, and whether there's a DPA/BAA. And remember: these terms change, and can be overridden by a legal order. Treating one line — "we don't train on it" — as the whole boundary is the most common operational-phase false security.