the short answer
TypeSafe’s model documentation states that customer requests and responses are not used for training. That statement does not by itself specify request retention duration, abuse-monitoring logs, backups, regional processing, deletion SLAs or every provider’s data handling. Verify the current contract and privacy documentation for the route you use, minimize Jev state, redact secrets, and document each processor before sending sensitive data.
- Training use
- TypeSafe says requests and responses are not used for training
- Retention duration
- Must be verified contractually for the chosen route
- Provider effect
- Direct and third-party paths can have different subprocessors
- Safe default
- Minimize and redact state before transmission
- Evidence date
- September 22, 2026
The Documented No-Training Claim Answers One Question
TypeSafe’s model page says customer requests and responses are not used for training. That is useful and specific. It should not be expanded into “nothing is logged,” “zero retention,” “never leaves the region” or “no employee can access it” without separate evidence.
Privacy review should list each requirement and its source: service terms, privacy policy, data-processing agreement, provider documentation and negotiated commitments. Record the document version and review date.
Map the Actual Request Path Before Assessing Exposure
Calling Jev through TypeSafe directly, Cloudflare Workers AI or another gateway changes the entities and terms in the path. Cloudflare publishes separate Workers AI data-use documentation. Review the route actually deployed, not a different provider’s assurances.
Build a Field-Level Data Inventory Before Approving the Route
Data minimization is not accomplished by deleting names after sending a full transcript. Define the smallest evidence projection first, then redact within it. A stable pseudonym can still be personal data when it can be linked back to a person, so protect the mapping and document its purpose.
Mark every field as required, optional or forbidden for each criterion. This makes privacy review testable: a fixture containing a forbidden secret should fail before the Jev client is invoked, while removing a required passage should produce an unscorable application state rather than a guessed verdict.
| Field class | Example | Default treatment |
|---|---|---|
| Direct identifier | Email, account ID or IP address | Remove or pseudonymize unless the criterion requires identity |
| Credential or secret | API key, token or connection string | Detect and remove deterministically; never send |
| Conversation content | User message or agent response | Select only the turns needed for the question |
| Tool evidence | Arguments, result and error | Allowlist fields; remove headers and unrelated payloads |
| Retrieved document | Passage used by the agent | Send the cited span, not an entire private corpus |
| Derived metadata | Jev distribution, threshold band and review result | Classify and retain according to its linkability and purpose |
Treat Unanswered Procurement Fields as Unknown
Do not fill a documentation gap with a reassuring assumption. “Not used for training” and “not retained” are different claims.
| Question | Required evidence |
|---|---|
| How long are request bodies retained? | Current service terms or signed DPA |
| Are security or abuse logs different? | Logging schedule and purpose |
| Where is data processed and stored? | Region and subprocessor documentation |
| How are backups deleted? | Deletion and backup lifecycle |
| Is zero data retention available? | Written feature and scope confirmation |
| Who can access support logs? | Access-control and audit description |
Minimize State Before It Crosses the Boundary
Jev works best with short, relevant state, which aligns with data minimization. Project the specific messages, tool fields or retrieved passages needed for the question. Replace direct identifiers with stable pseudonyms when identity is irrelevant, and omit full transcripts when one event is enough.
Run deterministic secret detection and redaction before the request. Never include credentials to test whether a model can identify them. The state guide covers provenance and redaction; limitations explains why irrelevant long state also harms reliability.
Evaluation Logs Can Be More Sensitive than the Model Call
OWASP recommends excluding or masking access tokens, passwords, sensitive personal data and other secrets from logs. Apply that discipline to traces, retries, exception objects, analytics events and reviewer exports. A sanitized success path is not enough if the HTTP client prints the full request on failure.
- Store an evidence reference or keyed hash instead of duplicating raw content where possible.
- Separate restricted trace access from aggregate metrics.
- Redact error payloads and CI artifacts as well as successful responses.
- Apply deletion and subject-request workflows to derived evaluation records.
- Limit reviewer access and record overrides without exposing unnecessary identity.
Give Every Artifact a Purpose and Deletion Clock
Retention should be enforced by the storage system, not left as prose in a checklist. Test expiry, deletion propagation, backup behavior and subject-request joins. If a trace is deleted but a reviewer export still contains its text, the workflow has not actually honored the deletion boundary.
Hashing is not anonymization when the input space is guessable or a lookup table exists. Use keyed hashes for controlled joins, rotate keys according to policy and restrict who can resolve the identifier.
| Artifact | Purpose | Possible retention trigger |
|---|---|---|
| Raw state payload | Short-term debugging or dispute evidence | Delete after the shortest approved diagnostic window |
| Native Jev response | Replay, calibration and incident analysis | Retain with evaluator-version evidence if payload is minimized |
| Evidence reference or hash | Link result without copying source content | Follow source-system deletion and key-rotation policy |
| Human label and reason | Evaluator validation and appeals | Retain only while the documented evaluation purpose remains |
| Aggregate metric | Trend monitoring | Retain when re-identification risk is controlled |
Model the Privacy Failures Created by the Evaluation Pipeline
NIST’s Privacy Framework treats privacy risk as a system concern, not a model setting. The useful unit of analysis is therefore the full evidence path: source trace, projection, transport, provider, application log, evaluation store, reviewer interface, export and deletion process.
| Failure | Control | Verification |
|---|---|---|
| Secret copied into state | Pre-send allowlist and secret scanner | Synthetic canary must be blocked before network invocation |
| Gateway logs request bodies | Route configuration and contractual restriction | Inspect settings and sampled logs |
| Retry duplicates sensitive payload | Bound retries and keep payload logging disabled | Induce a transient failure and inspect all destinations |
| Reviewer sees another tenant’s trace | Tenant-scoped authorization and evidence references | Cross-tenant negative access test |
| Deleted source survives in exports | Deletion propagation and export inventory | End-to-end deletion drill |
| Provider changes subprocessors | Change notification and reapproval gate | Scheduled evidence review |
Complete a Route-Specific Privacy Checklist
- Classify the exact state fields and jurisdictions involved.
- Identify every processor, gateway and logging destination.
- Obtain retention, training-use, region, subprocessor and deletion evidence.
- Test redaction and confirm the evaluator still has enough evidence.
- Document incident response and provider-change review.
- Revalidate when the model route or surrounding platform changes.
Keep a Reviewable Evidence Pack for Each Deployment Route
A provider page can change without an application deploy. Recheck evidence on a schedule and whenever the route, model host, gateway or logging configuration changes. The platform map separates direct TypeSafe, Cloudflare and other access paths; the model card records the dated first-party no-training statement.
- Architecture diagram naming every processor and storage boundary.
- Field inventory, purpose, classification and redaction rule by criterion.
- Current terms, DPA, subprocessor list, region and retention commitments.
- Access roles, audit-log locations and reviewer authorization tests.
- Deletion, incident, provider-failure and route-change test results.
- Owner, approval date, next review date and unresolved questions.
FAQ
Does TypeSafe train Jev on my requests?
TypeSafe’s model documentation says customer requests and responses are not used for training. Verify the current wording for your contract and route.
Does that mean zero retention?
No. Training use and retention are separate. Obtain current retention, logging, backup and deletion terms.
Is Cloudflare’s Jev route governed only by TypeSafe terms?
Do not assume so. Review Cloudflare Workers AI data-use terms and every processor in the deployed path.
Should I send full agent traces to Jev?
Usually no. Project and redact only the evidence required for the specific question, then validate that the reduced state remains sufficient.
Sources
Checked against the sources below on September 22, 2026. Model versions, prices and limits change.
- TypeSafe AI docs: Models
- TypeSafe AI: Privacy policy
- Cloudflare Workers AI: TypeSafe Jev
- Cloudflare Workers AI: Data usage
- TypeSafe AI docs: State
- TypeSafe AI docs: Jev 1.13 jaggedness
- NIST Privacy Framework
- OWASP: Logging Cheat Sheet