Zero retention at the model. Your logs keep everything.

The vendor will hold none of it. Your retrieval index, your transcripts and your review queue still hold all of it, and those are the copies a regulator can reach.

What happened

Anthropic released Claude Fable 5.1 and Claude Mythos 5.1. Most of the attention went to the benchmarks and to the price, which is real enough: cache reads dropped 75% to $0.25 per million tokens, and typical workloads now cost about 25% less than they did on the previous model.

The part that changes a buying conversation sits further down the page. Anthropic is rolling out something it calls Enterprise Frontier Safeguards, and the description is unusually specific. Customers store their data on their own cloud infrastructure rather than on Anthropic's systems, and any human review of flagged activity is done by the customer by default. Eligible customers can already run the new model with zero data retention while that rolls out in phases this autumn.

One other detail is worth noting. The stronger model is gated. Mythos 5.1 is reached through verification programmes for defensive security and life sciences work, not by adding a credit card. Access to a capability tier is now a permission somebody grants you.

Why this matters to your business

For the past two years the sentence that killed most support automation projects was some version of "we cannot send customer records to a company that keeps them." Legal said it, the project went back in the drawer, and everyone moved on to a pilot with fake data.

That objection now has an answer, which relocates the question rather than settling it. A model that retains nothing tells you nothing about what your own systems retain, and in a working support automation the customer's data gets copied several times before it ever reaches a model. It lands in the retrieval index. It lands in the conversation log. It sits in whatever queue holds the cases a person has to look at, and in the traces your team keeps so they can debug a bad answer next week.

Every one of those copies is on your side of the line. When a customer asks to be deleted, or an auditor asks what you hold on a named individual, the vendor's retention policy answers for the vendor only. The rest of the answer is yours to produce.

Why this is a CX-Builder use case

Read the safeguards description again and notice what it assumes. Your own cloud infrastructure. Your own people doing the review. Both of those are architecture, and neither is something you bolt on after launch once the lawyers ask.

CX-Builder is self-hosted, which means the flow, the vector store, the conversation history and the review queue all sit on hardware you chose, inside a network boundary you drew. The model is the only piece that has to leave, you pick which one, and a local model that never leaves the building is one of the options.

That ownership is what makes deletion answerable. If the index is yours, you can list what is in it and remove a customer's documents on a schedule you set. If it lives inside somebody else's product, you raise a support request and hope. Review works the same way. A human-in-the-loop gate holds the sensitive class of case for a named person, and the record of who approved what stays in your database rather than a vendor's.

What this looks like if you build it

It is one flow with retention decided at every point where data comes to rest. Retrieval reads from a vector store you host, so purging a customer and re-indexing is a job you run rather than a request you file. Conversation history gets an expiry you set instead of a default you inherited. An approval step routes the regulated categories to a reviewer and writes down the decision. The model connector stays a dropdown, so a zero-retention endpoint today and something running on your own GPU next quarter is a configuration change rather than a rebuild.

None of that is exotic. It is the difference between knowing where your customer data sits and believing a paragraph on a vendor's website.