Field note · AI Engineering · · 2 min read
Your fallback model needs the same data rules
An employee sends a sensitive document to an AI feature. The approved model is unavailable, so the application tries a backup. The answer arrives and the feature looks healthy. The backup may have kept a copy of a document the original route was required to discard.
The component choosing where to send the request, often called a router, needs the data rules before it tries a fallback. A successful response cannot tell you whether the route was acceptable.
What happens when the approved route is down?
Primary unavailable
Route A meets the request's data policy but cannot serve it.
Check the fallback
Route B retains content for 30 days, so the application excludes it before sending the document.
Return an unavailable result
If no permitted route remains, explain that the request cannot be completed. Any exception requires authorization before the data is sent.
Check the deployment, including its exceptions
Provider name alone is not enough to make this decision. As of September 6, 2026, OpenAI describes zero data retention for eligible API customers, with exceptions including images flagged for potential child sexual abuse material. Its Private Safety Processing approach was announced as a preview. An announcement does not establish that a particular account and feature have that configuration.
Anthropic's retention policy describes 30-day retention for covered models under the standard arrangement. Its current covered-model guidance also describes a temporary zero-retention option for eligible customers using Fable for internal business applications. Eligibility and the applicable agreement matter; the default cannot be treated as the only possible arrangement.
For every deployment the application can select, keep a dated record of the permitted data, retention period, storage arrangement, and relevant exceptions. Tie that record to the account, platform, and model version actually used. The person responsible for the organization's data policy should approve those rules; the router should enforce them.
Test the route that normally stays idle
In a test environment, make the primary deployment unavailable. Check where the request goes, what policy allowed that choice, and whether any disallowed service received the content before the decision. Test the path that reports no acceptable fallback as well. A later routing change should have to pass those checks again.
The application can also retain its own copy in conversation history or diagnostic logs. Check those separately when approving the feature. A provider's zero-retention setting covers its part of the arrangement, not every place your software might store the document.
Keep the policy check attached to the routing configuration so an engineer changing the fallback sees the constraint. If the provider changes its terms, that dated record shows which routes need another review.
Written by the Moga principals.