Should translation vendors exclude conversation data by default?

We’re evaluating an AI translation startup, and I think customer conversation data should be excluded from model evaluation and fine-tuning by default. “We don’t train on your data” is too vague if logs still sit around for operations. OpenAI’s API documentation, for example, distinguishes training use from abuse-monitoring retention of up to 30 days; Google Cloud Translation and Azure Translator describe stronger non-training or limited-storage positions.

My practical observation from startup work is that privacy-conscious customers care less about a reassuring sentence than a deadline: say 30 days for operational logs, then provide a deletion receipt with the dataset ID, scope, timestamp, and verification status. Rare translation failures still need debugging, but that can be a separate, customer-approved sample path rather than a default harvest of sensitive speech.

Are opt-out controls enough, or should privacy-preserving defaults be a requirement for translation vendors?

Opt-out is a weak control when the customer has to understand every hidden data path first. Default exclusion gives you a much smaller threat surface. I’d allow approved samples, but make the approval specific to a failure class and expiration date—not a standing “help improve the model” checkbox.

The deletion receipt is the important engineering demand. “Deleted” should identify which stores, indexes, replicas, and backups were covered, or at least state the verification boundary. Otherwise it’s a support assertion, not an auditable event.

Customers will say they want maximum privacy until a recurring translation bug damages their workflow. The product answer is probably two lanes: zero-retention by default, plus an explicit diagnostic program with narrower consent and visible expiry. Don’t make every buyer negotiate this from scratch.

I agree with the distinction between training and retention. They answer different questions. I’d be careful presenting 30 days as a norm, though; it is a proposed policy choice, not a universal standard. The useful commitment is a stated deadline that the vendor can actually evidence.

As a developer, I’d also want the failure-reporting tool to accept redacted text or synthetic reproductions. Otherwise “customer-approved sample” becomes the only practical debugger and people will approve more than they intended just to get support moving.

Procurement will ask for this in three separate places: training exclusion, operational retention, and deletion evidence. Vendors often answer the first and leave the other two fuzzy. A short, machine-readable receipt would be easier to file and verify than another paragraph of policy language.

There’s a risk of making the default so strict that smaller vendors cannot diagnose their worst edge cases. I’d accept a limited, time-boxed diagnostic exception, but only after the customer names the affected conversations and the vendor commits to deleting them on schedule.

Opt-outs are still valuable for customers with unusual needs, but they should be an escape hatch, not the privacy architecture. Sensitive speech is exactly where consent fatigue and misunderstandings are most costly.

The operational detail matters more than the slogan. Someone needs an owner, a queue, and a failed-deletion escalation path. If a receipt can say “requested” but never “verified,” the process is incomplete even if the policy sounds excellent.