Is Jev Enterprise-Ready? Reading the Terms and the DPA

Hello, this is Ryuta Hamamoto from TIMEWELL.

Something I have noticed among people going through our WARP programme. They are fast at picking up a new AI API. Read a post, get a key, run the sample — under thirty minutes.

Then someone internally asks "can we actually put our data in this?" and everything stops. Because nobody read the terms.

This piece uses Jev (TypeSafe AI), which we use in production, as the worked example. It is about Jev, and it is equally about how to read a SaaS agreement.

The short version:

• The published terms of use cover "the Site" only. They do not set the conditions for paid API use
• Input is not used for training. This is explicit in the privacy policy, so it is easy to verify
• Data sits entirely in the US. Four subprocessors, and no non-US region in the public information
• Retention is not stated in days. This is the weakest point
• SOC 2 Type II exists, but the report is gated behind a request
• Working and usable are different. Adoption requires obtaining documents that are not published

The terms are split across four places

I think this is the main reason nobody reads them. They are not in one place.

Document	Location	Last updated
Terms of Use	typesafe.ai/terms	19 September 2026
Privacy Policy	typesafe.ai/privacy-policy	19 November 2025
Data Processing Addendum	typesafe.ai/data-processing	24 April 2026
Trust Center	trust.typesafe.ai	Continuously

And importantly, the technical documentation at docs.typesafe.ai says nothing about data handling at all. The index lists API usage and SDKs. A developer reading only the docs can reach production without ever touching the legal terms.

This is not specific to TypeSafe. Technical docs and legal documents living on separate sites is the norm, and that split is where review gaps come from. Identify the four places before you start reading. That is pattern one.

The trap: the published terms cover the website only

This is the part I most want to land.

Open typesafe.ai/terms and the limitation of liability reads:

TO THE FULLEST EXTENT PERMITTED BY LAW, THE AGGREGATE LIABILITY OF THE TYPESAFE ENTITIES TO YOU FOR ALL CLAIMS ARISING OUT OF OR RELATING TO THE USE OF OR ANY INABILITY TO ACCESS OR USE ANY PORTION OF THE SITE OR OTHERWISE UNDER THESE TERMS, WHETHER IN CONTRACT, TORT, OR OTHERWISE, IS LIMITED TO $100 USD.

A hundred dollars. On that alone, most procurement processes stop.

But do not jump. The same document defines "Site" narrowly as https://typesafe.ai and its subdomains. And the opening states that where you enter a separate agreement for TypeSafe products or services, that agreement controls¹.

So the $100 is the cap on claims arising from using the website, not the liability position for paid API use. The conditions for paid use live in a separate agreement, and that agreement is not published.

Two conclusions follow.

First, "the cap is $100 so we can't use it" is a misreading. That is what happens when you take the number without the scope.

Second, that is not the same as reassurance. The accurate position is that the liability terms for paid use cannot be determined from public information. If you cannot read it, you have to ask.

When reading terms, look at the scope definition before the numbers. That is pattern two.

Training: explicitly ruled out

An easy part. The privacy policy addresses data sent through the API directly².

It lists "prompts, data, instructions, and other input" as collected, then commits to two things:

• It will not train or fine tune any AI or machine learning model on your prompts or other Input
• It will not disclose any Input to a third party other than its service providers

Since "does our data get trained on?" is the first question asked in any internal review of generative AI, having this in writing is genuinely useful. It can be quoted directly into an approval document.

One caveat. "Not used for training" and "not stored" are different claims. Even without training, retained logs are a fact you have to be able to explain internally. Which brings us to the weak spot.

The weak spot: retention is not stated in days

Being straight about this. It is the thinnest part.

The privacy policy says data is retained "for as long as reasonably necessary to provide you with the Services, or otherwise in support of our business or commercial purposes"². The DPA says Customer Personal Data is retained "for as long as necessary taking into account the purpose of the Processing, and in compliance with applicable laws"³.

Neither states a number of days. There is no published "deleted after 30 days" or zero-data-retention option.

There is one supporting data point. The trust center's control list includes "Customer data deleted upon leaving", alongside "Data retention procedures established" and "Data classification policy established"⁴. These are controls within the SOC 2 scope, so the procedures exist.

Even so, if your internal policy requires a stated retention period for input data, this is not enough. In that case you have to get the number in writing.

Where the data sits: all in the US

The privacy policy states the services are hosted in the United States². The trust center lists four subprocessors with locations⁴.

Subprocessor	Role	Location	What the entry says
Amazon Web Services	Cloud	USA	Customer information for live requests stored and processed on databases, caches, and compute nodes within AWS
Modal	AI infrastructure	USA	Customer AI prompts processed, but not stored, on compute nodes
Slack	Collaboration, customer comms	USA	Customer information may be surfaced through support channels
Google Workspace	Collaboration, customer comms	USA	Customer information may be exchanged via email and documents

The Modal entry is usefully specific. Separating "processed" from "not stored" per role tells you prompts do not persist on the inference nodes. The AWS entry, by contrast, says "stored and processed", so something does persist somewhere.

No non-US region appears in the public information. Where in-country storage is a contractual requirement, the line is drawn right here. We built ZEROCK on AWS infrastructure in Japan precisely because that requirement is real for some customers.

For EEA and UK transfers, standard contractual clauses are in place — EU Module 2 (controller to processor) under Commission Implementing Decision 2021/914, and the UK International Data Transfer Addendum (version B1.0)³.

The DPA is substantive

The data processing addendum is not a formality. It contains the things you would want³.

• Customer as controller, TypeSafe as processor, stated explicitly
• Breach notification without undue delay and within 72 hours
• One customer audit per 12 months (at customer's expense, during business hours)
• Advance notice before appointing a new subprocessor, with a 15-day objection window
• Subprocessors bound by obligations "substantially as protective" as TypeSafe's own

72-hour notification and an annual audit right are standard for an enterprise DPA. The 15-day objection window needs an owner internally — decide who receives those notices, or the deadline passes unnoticed. That is a common failure.

SOC 2 Type II exists, but the report is gated

The trust center shows SOC 2 Type II (2026)⁴. Controls are published in groups: 20 infrastructure security, 13 organisational security, 4 product security, and others.

The report itself sits behind "Request access." That is normal practice — we handle our own ISO/IEC 27001 registration the same way, showing it to those who need it.

The point is that having a badge and having read the report are different things. US enterprise procurement asks for the auditor's opinion itself. If you are making an adoption decision, request it and read it. Exceptions and exclusions appear in the report, not on the badge.

Governing law is Delaware

The terms are governed by Delaware law, with exclusive jurisdiction in Delaware state and federal courts¹. There is an arbitration clause with a 30-day opt-out.

Litigating in the US is not realistic for most Japanese companies. That said, this is standard for foreign SaaS, and rejecting vendors on this basis leaves you with almost nothing to use. Assume you will not litigate, and limit the blast radius instead.

Where the line sits

Having read it, here is how I draw the line.

Fine to use. Public information, text we wrote ourselves, internal published material. Our classification of 1,852 articles with Jev falls here — the text is already public, so passing it through US servers costs nothing.

Usable with conditions. Business data with customer names and commercial terms redacted. The condition is that the redaction happens in your own code before sending. Putting it in the prompt and then reasoning "it won't be trained on" is the wrong order.

Not until you have documents. Personal data, data entrusted by customers, drawings and design information. Without a retention period in days, I would hold here.

Cannot use. Anything where in-country storage is a contractual requirement. No non-US region is available in the public information.

What to obtain before adopting

The gaps the public pages leave. All can be requested through the trust center or a sales contact.

1. The agreement that governs paid API use. Liability, indemnity, termination. The public terms cover the site, so this is the actual document
2. Input retention stated in days, and whether zero-data-retention is available
3. The SOC 2 Type II report itself. Period covered, exclusions, exceptions
4. The SLA and its uptime definition. No uptime commitment appears publicly
5. Data region options. Whether Japan or the EU can be selected

These five are common to adopting any foreign AI API, not just this one. Use the list as-is.

The cost of not reading arrives later

What I tell people on the programme.

Skipping the terms causes no problems for a while. It works, it is fast, results come. The problems surface at an internal audit, at a customer's security questionnaire, or at an incident. "We hadn't read them" does not survive any of those.

And reading is less work than people expect. Everything in this article came from four pages and about thirty minutes. Once you know what is written and what is not, you can draw the line.

The thing that matters is not reading "unstated" as "fine." No stated retention period does not mean no retention. If it is not written, ask.

In our WARP training we spend more time on the basis for judgement than on procedure, because tools change and the way you read an agreement does not. To gauge where your organisation stands, start with the AI literacy check.

For the record, we use Jev in production. This is not a criticism but a reading intended to help users draw their own line. As published disclosure goes, it is better organised than most: a real DPA, and subprocessors published with roles and locations, are not that common.

In summary

• The terms live in four places. The technical docs say nothing about data
• The published terms of use cover "the Site" only. The $100 cap is about website use, not paid API use
• Input is not used for training. This is explicit
• Data sits entirely in the US. Four subprocessors, no non-US region published
• Retention is not stated in days. The weakest point
• The DPA is substantive: SCCs, 72-hour notification, annual audit, 15-day subprocessor objection
• SOC 2 Type II exists but the report is gated. Read the report, not the badge
• Five documents to obtain before adopting — common to any foreign AI API

To talk through where your own line should sit, or how to write it into internal policy, get in touch.

This article is not legal advice. Check specific questions with your counsel and your information security lead. Terms are revised, so always check the current version directly when making an adoption decision.

References

Footnotes

1. Terms of Use (TypeSafe AI, last updated 19 September 2026). The definition of "Site" as https://typesafe.ai and its subdomains, the precedence of a separate agreement for products or services, the $100 aggregate liability cap, and Delaware governing law with exclusive Delaware jurisdiction all come from these terms. Checked 20 September 2026 ↩ ↩²

2. Privacy Policy (TypeSafe AI, last updated 19 November 2025). The commitments not to train or fine tune on Input and not to disclose Input to third parties other than service providers, the statement that services are hosted in the US, and the retention language all come from this policy. Checked 20 September 2026 ↩ ↩² ↩³

3. Data Processing Addendum (TypeSafe AI, last updated 24 April 2026). Controller and processor roles, EU standard contractual clauses (Module 2 under Commission Implementing Decision 2021/914) and the UK International Data Transfer Addendum (version B1.0), 72-hour breach notification, the 12-month audit right, and advance notice with a 15-day subprocessor objection window come from this DPA. Checked 20 September 2026 ↩ ↩² ↩³

4. Trust Center (TypeSafe AI). The SOC 2 Type II (2026) listing, the report being request-gated, the four subprocessors (Amazon Web Services, Modal, Slack, Google Workspace) with their roles, locations and descriptions, and the control list including "Customer data deleted upon leaving" come from the trust center. Viewed 20 September 2026 ↩ ↩² ↩³