The Jev GDPR Contract Exists, but Your Data Still Goes to the US

Jev AI has a GDPR-ready contract, and every call to it still sends your data to the United States. Jev AI is the decision model TypeSafe released on September 15, 2026: your code sends it a piece of text and a question, and it returns a choice, a score or a yes/no probability. As of September 29, 2026 it is not in the Microsoft Foundry model catalog, so calling it from Azure means sending that text outside your tenant.

The contract covers the transfer. Whether a given workflow should send its data is a decision your organization has to take, one workflow at a time.

• Where does the data go? See the four routes to Jev and who handles your data on each.
• What does the contract leave open? Learn the three questions to put to TypeSafe in writing.
• When does Jev need extra care? Understand why decisions about people carry GDPR duties a chatbot does not.
• How do you decide and enforce it? Get a per-workflow rule and the Microsoft controls that hold it.

Every Jev Call Sends Your Data to the United States

Each call carries the text your code wants judged, which TypeSafe calls the state. In practice that is business data, such as a customer email or a job application. TypeSafe's privacy policy says its services are hosted in the United States, so the text leaves the EU whichever route you take. The route only changes how many companies handle it on the way.

Figure 1. Every route to Jev ends at TypeSafe in the United States. View full-size image

The routes are not equal. Cloudflare's model catalog lists Jev with zero data retention, meaning nothing is kept after the answer, while Vercel applies it only if you turn that setting on. OpenRouter also offers Jev, served by TypeSafe, and its listing says TypeSafe keeps no prompts from those calls.

When the text contains personal data, each company in the chain is a processor, a company handling that data on your behalf, and each belongs in your records of processing.

Microsoft's Model Router in Foundry, which I compared with Jev in Jev on Azure, can run in an EU Data Zone and keep processing inside the EU. Jev has no such option, so read TypeSafe's contract before you compare prices.

The Jev GDPR Contract Covers the Transfer but Leaves Three Questions Open

TypeSafe's data processing addendum, updated April 24, 2026, covers the transfer the standard way. It includes the EU Standard Contractual Clauses (Commission Decision 2021/914), the EU's model contract terms for sending personal data outside the EU, plus the UK Addendum. It promises notice of a security incident within 72 hours, and gives you 15 days to object to a new subprocessor.

Clause 14 still leaves you one task: assessing whether US law lets TypeSafe honor those clauses. That is the transfer impact assessment your data protection officer will ask for.

Three points in TypeSafe's documents need a written answer before customer data goes through:

• Are Jev's answers telemetry? TypeSafe's Master Customer Agreement lets it use telemetry, the data generated by your use of the service, "without restriction", and the definition includes "classifications". Jev's whole output is classifications. The documents do not say whether that covers your answers, so I would assume it does until TypeSafe says otherwise.
• When is your data deleted? TypeSafe has no obligation to keep your data and may delete it at any time, while backups may remain. That suits data minimization but gives you no deletion date to show an auditor.
• How long is personal data kept? The privacy policy says "as long as reasonably necessary". Your records of processing need a period.

None of these rules Jev out. They decide how much personal data you can responsibly send, and for some workflows the answer also depends on what Jev's answer is used for.

Jev Decisions About People Carry GDPR Duties a Chatbot Does Not

A chatbot writes a draft that a person usually reads before anything happens. Jev returns a verdict your code can act on at once: approve, flag, reject. When nobody checks that verdict first and it concerns a person, Article 22 of the GDPR comes into play. Its first paragraph reads:

The data subject is the person the data is about, and the test is whether Jev's verdict changes something that matters to that person. Sorting a ticket into "billing" is far from that line. Dropping a job applicant from a shortlist, or declining an insurance claim, can cross it.

Fully automated decisions like these are allowed only when they are necessary for a contract, authorized by law, or based on explicit consent. Under a contract or consent, the person must still be able to get a human to review the decision, give their view and contest it. Running this kind of scoring systematically also requires a data protection impact assessment under Article 35.

Explaining the decision is the harder duty. The person is entitled to meaningful information about the logic involved, and 0.83, Jev's probability that the answer is yes, explains nothing to a rejected applicant. Jev returns no reasoning text, so your own records must supply it: the question asked, the threshold applied, the model version and the reviewer who confirmed the result. Keep them with your AI data risk documentation.

The contract's open questions and these duties together give a simple way to sort your workflows.

The Data in Each Workflow Decides Whether Jev May Handle It

The same ticket classifier can be harmless with product names and sensitive with patient notes, so judge each workflow by what it sends and what the answer is used for:

A workflow can match two rows: declining a claim based on health data needs both the Foundry route and human review. The first row covers more than most teams expect: routing IT requests or tagging product feedback rarely needs a name once you remove it from the text.

The third row is where Jev's price stops mattering. Health data, union membership and the other special categories in Article 9 need a stronger legal basis, and a US transfer makes that harder to defend. Foundry is not free of retention questions either: its abuse monitoring can store flagged prompts for human review, and you can apply to Microsoft to modify that, as I covered in Azure OpenAI security and privacy.

Record the route per workflow with a named owner, as you would any other entry in your AI risk management process.

A rule on paper holds only if every call has to pass through a point you control.

One Gateway You Control Makes the Rule Hold

The Microsoft stack cannot keep Jev in the EU, but it can make every call pass one checkpoint in your own Azure environment. Azure API Management's AI gateway gives your applications an endpoint of your own that forwards each call to TypeSafe. It keeps the TypeSafe key out of application code and logs each request and response to Azure Monitor in your region. That log is your record of what was sent and what Jev decided.

An Azure Firewall rule that lets only API Management reach TypeSafe's API closes the side doors. The gateway does not remove personal data, so your applications should replace names and IDs with codes before the call (pseudonymize them).

The gateway also gives teams an approved way to try Jev. Without one, curious staff turn to TypeSafe's web playground, where anyone can paste a customer email in seconds and you see nothing. Purview's data security for AI watches only the third-party AI sites on its supported list, and TypeSafe is not on it.

Treat the playground like any other shadow AI tool: Defender for Cloud Apps can mark it unsanctioned, and with Defender for Endpoint that blocks it on managed devices.

Work with Precio Fishbone

The Jev GDPR contract covers the US transfer. Which workflows should send data is your decision, and that decision holds only when every call passes a gateway you control.

If you want to test Jev without customer data reaching the US by accident, talk to our AI data governance team, or email me at par.johansson@preciofishbone.se.

Frequently Asked Questions