You fine-tune a model on user-submitted data. What risk must you control?

You want your model to improve from real usage, so you pipe user-submitted text straight into the next fine-tuning run. The convenience hides a serious integrity problem: you are now letting strangers help write your model's weights.

The risk: data poisoning

Whoever contributes training data can influence what the model learns. An attacker who submits crafted examples can implant a backdoor — the model behaves normally until it sees a secret trigger phrase, then misclassifies, leaks, or emits attacker-chosen output. More subtly, they can skew behavior or bias the model in a direction that benefits them, or degrade quality across the board. This is training data poisoning, and because it's baked into the weights, it can sit dormant and pass casual testing while remaining fully exploitable.

The dangerous part is timing: the damage is done at training time but only surfaces in production, often long after the poisoned batch is forgotten.

Controls that actually work

• Vet and filter the data. Don't ingest raw user submissions. Clean, deduplicate, and filter for obviously adversarial or off-distribution content before it ever reaches a training run.
• Track provenance. Record where every example came from so you can attribute, quarantine, and roll back a poisoned source after the fact.
• Run anomaly detection on the dataset. Look for clusters, near-duplicate triggers, label-flipping, and statistical outliers that signal coordinated injection.
• Evaluate model behavior after training. Test against held-out adversarial and trigger probes, compare against the previous model, and gate releases on those evals — not just on aggregate accuracy.

Why the distractors are wrong

• "More data is always better": raw volume ignores integrity. A small poisoned slice can compromise the whole model.
• "It'll get faster" / "only disk usage": these reframe a security problem as a performance or storage one. The real concern is an attacker steering model behavior.

What interviewers want to hear

That you name poisoning, treat user data as untrusted training input, and build a pipeline of vetting, provenance, dataset anomaly detection, and post-training behavioral evaluation rather than blindly fine-tuning on whatever arrives.