大家好，我是TIMEWELL的濱本。
看WARP的學員，最近有一件事讓我在意。他們上手新的AI API很快。 讀篇文章、拿到金鑰、把範例跑起來，三十分鐘都不用。
然後公司內部有人問「這個可以放我們的資料嗎」，就停住了。因為沒有讀條款。
這篇文章以我們實際在用的Jev（TypeSafe AI）為題材，用一手資料讀條款，畫出可用到哪裡的界線。這既是Jev的事，也是「SaaS的條款該怎麼讀」的方法。
先講重點。
- 公開的使用條款只涵蓋「網站」。 沒有寫API付費使用的條件
- 不會拿去訓練。這在隱私權政策裡是明文，容易確認
- 資料全部在美國。次處理者四家，公開資訊裡沒有美國以外的區域選項
- 保存期限沒有用天數寫出來。 這裡最弱
- 有SOC 2 Type II，但報告要申請才拿得到
- 跑得動與能用是兩回事。要採用，就得去取得沒有公開的書面
條款分散在四個地方
我認為這是沒人讀的最大原因。它們不在同一個地方。
| 文件 | 位置 | 最後更新 |
|---|---|---|
| 使用條款 | typesafe.ai/terms |
2026年9月19日 |
| 隱私權政策 | typesafe.ai/privacy-policy |
2025年11月19日 |
| 資料處理附錄（DPA） | typesafe.ai/data-processing |
2026年4月24日 |
| 信任中心 | trust.typesafe.ai |
隨時更新 |
而且很重要的一點，技術文件（docs.typesafe.ai）裡完全沒有寫資料的處理方式。 翻索引只有API用法與SDK。工程師如果只讀技術文件，可以一次都沒碰到條款就上到正式環境。
這不是TypeSafe獨有的狀況。技術文件與法務文件分在不同網站是常態，而那個分裂正是確認遺漏的溫床。先把該讀的四個地方定位出來，這是第一個要領。
陷阱：公開的條款只涵蓋網站
這是本文最想傳達的一段。
打開 typesafe.ai/terms，責任限制條款是這樣寫的。
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.
責任上限一百美元。光看這個，多數公司的簽核是過不了的。
但不要太早下判斷。 同一份條款的定義寫著，「Site」限定於 https://typesafe.ai 及其子網域。而且開頭寫明，若就TypeSafe的產品或服務另行簽訂契約，以該契約為準1。
也就是說，這個一百美元是因瀏覽網站而生的請求的上限，不是API付費使用時的責任範圍。付費使用的條件在另一份契約裡，而那份契約沒有公開。
從這裡可以得出兩件事。
第一，「上限一百美元所以不能用」是讀錯了。 不看條文的適用範圍只抓數字，就會變成這樣。
第二，但也不能因此放心。 正確的狀態是：付費使用的責任範圍，從公開資訊讀不出來。讀不出來就只能去問。
讀條款的時候，先看適用範圍的定義，數字放後面。 這是第二個要領。
訓練：明文寫著不會
這一段很清楚。隱私權政策對於透過API送出的資料有明確記載2。
在把「prompts, data, instructions, and other input」列為蒐集對象之後，寫了兩件事。
- 不會用你的提示或其他Input訓練或微調任何AI或機器學習模型
- 除服務供應商外，不會向第三方揭露任何Input
生成式AI要在公司內部使用，第一個被問的就是「放進去的資料會不會被拿去訓練」，所以這裡是明文，實務上很有幫助。簽核文件可以直接引用。
不過要注意。「不拿去訓練」與「不保存」是兩回事。 就算不訓練，只要以日誌形式留著，那就是需要對內說明的事實。接下來看這一點。
弱的地方：保存期限沒有用天數寫
老實說，這裡最弱。
隱私權政策關於保存的敘述，大意是在「為提供服務所合理必要的期間，或在支持其業務、商業目的的範圍內」保存2。DPA那邊則是「考量處理目的、依適用法令所必要的期間」3。
兩邊都沒有寫天數。 公開資訊裡沒有「三十天後刪除」或「可選零資料保存」這種具體承諾。
有一個補強材料。信任中心公開的控制項清單裡有**「Customer data deleted upon leaving」**（契約終止時刪除顧客資料），同時還有「Data retention procedures established」「Data classification policy established」4。這些是SOC 2稽核範圍內的控制項，所以程序本身是存在的。
即使如此，如果公司內規要求「必須能明示輸入資料的保存期限」，這樣還不夠。 那就得用書面去把天數要到。
資料在哪裡：全部在美國
隱私權政策寫明服務託管於美國境內2。信任中心公開了四家次處理者，附所在地4。
| 次處理者 | 角色 | 所在 | 記載的處理方式 |
|---|---|---|---|
| Amazon Web Services | 雲端 | 美國 | 即時請求的顧客資訊，在AWS內的資料庫、快取與運算節點上保存與處理 |
| Modal | AI基礎設施 | 美國 | 顧客的AI提示在運算節點上處理但不保存 |
| Slack | 內部協作、客戶溝通 | 美國 | 顧客資訊可能透過支援頻道被呈現 |
| Google Workspace | 內部協作、客戶溝通 | 美國 | 顧客資訊可能透過郵件與文件交換 |
Modal的記載很具體，值得參考。 依角色把「處理」與「不保存」分開寫，就能讀出提示不會留在推論節點上。相對地，AWS那一列寫的是「保存與處理」，所以某個地方是會留下的，這樣理解比較自然。
公開資訊裡看不到美國以外的區域選項。 若案子的要求是境內保管，界線在這裡就畫下來了。我們的ZEROCK之所以以日本境內的AWS為前提，正是因為真的有客戶有這個要求。
從歐洲經濟區與英國的移轉，備有標準契約條款。歐盟用的是委員會實施決定2021/914的模組二（管理者對處理者），英國用的是國際資料移轉附錄（B1.0版）3。
DPA的內容是實用的
資料處理附錄不是形式文件，該有的都有3。
- 明確寫出顧客是管理者、TypeSafe是處理者
- 侵害通知為知悉後不得遲延，且不超過72小時
- 每12個月一次，允許顧客稽核（顧客負擔費用、營業時間內）
- 起用新的次處理者前事前通知，顧客可在15日內提出異議
- 對次處理者課以與TypeSafe自身義務實質相當的保護義務
72小時通知與一年一次的稽核權，以企業級DPA來說是標準水準。次處理者的15日異議期，實際要運作的話得先在公司內部決定由誰收通知。 沒注意就過期，是很常見的失誤。
有SOC 2 Type II，但報告要申請
信任中心刊登了 SOC 2 Type II（2026年）4。控制項分組公開，基礎設施安全20項、組織安全13項、產品安全4項等。
但報告本體在「Request access」的後面。 這是一般的做法，我們自己的ISO/IEC 27001登錄證也是這樣，給需要的對象看。
重點在於，有徽章和讀過報告是兩回事。 美國的企業採購要的是查核人員的意見書本身。要做採用判斷，就去申請並把內容讀完。 排除事項與例外指摘寫在報告裡，不在徽章上。
準據法是德拉瓦州
使用條款的準據法是德拉瓦州法，專屬管轄為該州的州法院與聯邦法院1。有仲裁條款，並允許30日內選擇退出。
對日本企業來說，爭議時到美國去打官司並不現實。話雖如此，海外SaaS這樣是常態，以此為由全部不採用的話，能用的東西就幾乎沒有了。以「打不了官司」為前提，把影響範圍縮小，才是務實的判斷。
界線畫在哪裡
讀完條文之後，寫一下我的畫法。
可以用的範圍。 公開資訊、自己寫的文章、公司內部的公開資料的分類。我們用Jev分類1,852篇文章就屬於這一類。本文早就公開了，經過美國伺服器也沒有實害。
有條件可以用的範圍。 遮蔽客戶名稱與交易條件之後的業務資料分類。條件是遮蔽處理要在送出前由自己的程式完成。先放進提示再想「反正不會被訓練」，順序是反的。
拿到書面之前不要用的範圍。 個人資料、向客戶借來的資料、圖面與設計資訊等營業秘密。在保存期限沒有以天數呈現之前，這裡應該先停住。
不能用的範圍。 契約上要求境內保管的案子。公開資訊的範圍內，沒有美國以外的區域選項。
採用前該取得的書面
把公開資訊補不上的項目列出來。可以從信任中心的申請表或業務窗口索取。
- 實際規範API付費使用的契約本身。 責任限制、補償、解約條件。公開條款是網站用的，這份才是本體
- 以天數表示的Input保存期限，以及有沒有零資料保存的選項
- SOC 2 Type II報告本體。 涵蓋期間、排除事項、例外指摘
- SLA與稼動率的定義。 公開資訊裡看不到稼動率的承諾
- 資料所在地的選項。 能不能選日本或歐盟
這五點不限於Jev，是採用海外AI API的共通項，可以直接當成公司內部的檢查表。
不讀的代價，會晚一點才來
最後寫一下我對學員說的話。
不讀條款就往前走，一陣子什麼事都不會發生。 跑得動、速度快、成果也出得來。問題會出現在公司內部稽核、客戶的資安檢查表，或是事故發生的時候。那時候說「我沒讀」是過不去的。
而且讀起來沒有想像中辛苦。這篇文章看的範圍，就是打開四個頁面、大約三十分鐘。 知道寫了什麼、沒寫什麼，界線就畫得出來。
重要的是，不要把「沒有寫」讀成「沒有問題」。 保存期限沒有寫，不代表不保存。沒寫就去問，就這樣而已。
我們在WARP的AI導入訓練裡，把時間放在判斷基準上多過操作步驟。工具會換，條款的讀法會留下來。
補充一下，我們實際在業務上使用Jev。這裡寫的不是批評，而是讓使用者自己畫界線的讀解。就公開資訊而言，它整理得比多數同類要好。備有正式的DPA，而且次處理者連角色與所在地都公開，這其實不常見。
總結
- 條款分散在四個地方。技術文件裡完全沒寫資料的處理
- 公開的使用條款只涵蓋「網站」。 一百美元的上限是網站使用的事，不是API付費使用的條件
- 不會拿去訓練。 這是明文
- 資料全部在美國。次處理者四家，公開資訊沒有美國以外的區域
- 保存期限沒有用天數寫。 這裡最弱
- DPA內容實用：標準契約條款、72小時通知、年度稽核、次處理者15日異議
- 有SOC 2 Type II，但報告要申請。要讀報告，不是看徽章
- 採用前該取得的書面五項，這是海外AI API的共通項
想討論自家可以用到哪裡，或如何落到公司內規，歡迎從聯絡我們與我們談。
本文不是法律意見。個別判斷請洽貴公司的顧問律師與資訊安全負責人。條款會修訂，做採用判斷時請務必直接確認最新版本。
參考資料
Footnotes
-
Terms of Use（TypeSafe AI，2026年9月19日最後更新，英文）。「Site」定義限於
https://typesafe.ai及其子網域、就產品或服務另行簽約時以該契約為準、責任總額限於一百美元、準據法為德拉瓦州法並以該州法院為專屬管轄，均出自該條款。2026年9月20日確認 ↩ ↩2 -
Privacy Policy（TypeSafe AI，2025年11月19日最後更新，英文）。不以Input訓練或微調模型、除服務供應商外不向第三方揭露Input、服務託管於美國境內，以及保存期間的敘述，均出自該政策。2026年9月20日確認 ↩ ↩2 ↩3
-
Data Processing Addendum（TypeSafe AI，2026年4月24日最後更新，英文）。管理者與處理者的角色、歐盟標準契約條款（委員會實施決定2021/914模組二）與英國國際資料移轉附錄（B1.0版）、72小時內的侵害通知、每12個月一次的稽核權、次處理者的事前通知與15日內異議，均出自該DPA。2026年9月20日確認 ↩ ↩2 ↩3
-
Trust Center（TypeSafe AI，英文）。SOC 2 Type II（2026年）的刊登、報告採申請制、四家次處理者（Amazon Web Services、Modal、Slack、Google Workspace）的角色與所在地及處理方式的記載，以及控制項清單包含「Customer data deleted upon leaving」等，均出自該信任中心。2026年9月20日閱覽 ↩ ↩2 ↩3
