Danh sách kiểm tra DPA cho AI Gateway: Các câu hỏi về xử lý dữ liệu dành cho người mua giải pháp định tuyến mô hình

Danh sách kiểm tra DPA cho AI gateway nên làm nhiều hơn là xác nhận rằng một nhà cung cấp có một trang pháp lý. Đối với người mua giải pháp định tuyến mô hình, câu hỏi thực sự là liệu thỏa thuận xử lý dữ liệu đã ký có khớp với tuyến mà ứng dụng của bạn thực sự sẽ sử dụng hay không: nhật ký gateway, các nhà cung cấp mô hình đầu nguồn, quyền truy cập hỗ trợ, định tuyến theo khu vực, kiểm soát lưu giữ, quyền xóa và thông báo sự cố.

Sử dụng danh sách kiểm tra DPA cho AI gateway này trước khi phê duyệt một lớp truy cập mô hình thống nhất, DPA cho LLM gateway hoặc thỏa thuận xử lý dữ liệu AI API. Đây không phải là tư vấn pháp lý. Đây là danh sách bằng chứng thực tiễn dành cho các nhóm nền tảng, bảo mật, mua sắm và pháp lý cần DPA khớp với hành vi định tuyến kỹ thuật.

Flatkey phù hợp với đánh giá này vì trang công khai hiện tại định vị flatkey.ai xoay quanh một API key, một base URL tương thích với OpenAI tại https://router.flatkey.ai/v1, khả năng hiển thị mức sử dụng và chi phí, nhật ký yêu cầu, định tuyến mô hình và quyền truy cập của nhà cung cấp thông qua một bảng điều khiển duy nhất. Hãy xem các trang sản phẩm đó như bằng chứng sàng lọc đã lỗi thời. Để phê duyệt, hãy đính kèm biểu mẫu đặt hàng đã ký, DPA, cài đặt tài khoản và bất kỳ xác nhận hỗ trợ nào kiểm soát khối lượng công việc thực tế của bạn.

Nếu bạn đang xây dựng bộ kiểm soát rộng hơn, hãy kết hợp đánh giá này với danh sách kiểm tra cổng AI API về GDPR, danh sách kiểm tra cổng AI API dành cho doanh nghiệp, danh sách kiểm tra lưu giữ dữ liệu AI API, và bảng giá Flatkey hiện tại.

Danh sách kiểm tra DPA cho AI Gateway: Bắt đầu từ tuyến

Sai lầm đầu tiên là xem xét nhà cung cấp một cách chung chung. DPA phải khớp với một tuyến cụ thể. Một chatbot hỗ trợ, một bộ phân loại tài liệu hàng loạt, một trợ lý lập trình và một quy trình làm việc đa phương thức cho phương tiện truyền thông có thể có các lớp dữ liệu, điểm cuối, điều khoản nhà cung cấp, hành vi lưu trữ và quyền truy cập hỗ trợ khác nhau.

Trước khi rà soát pháp lý, hãy cố định các thông tin tuyến sau:

Danh sách kiểm tra DPA cho AI gateway nên kết thúc bằng một hồ sơ phê duyệt theo từng tuyến cụ thể, chứ không phải một tuyên bố chung rằng "AI đã được phê duyệt."

Mười câu hỏi về xử lý dữ liệu mà người mua nên hỏi

Hãy dùng các câu hỏi này làm danh sách kiểm tra DPA nhà cung cấp AI cốt lõi cho bất kỳ giao dịch mua định tuyến mô hình nào.

Nếu câu trả lời thay đổi theo endpoint, tính năng, nhà cung cấp hoặc cấp tài khoản, hãy ghi ngoại lệ đó trong danh sách kiểm tra DPA của AI gateway thay vì làm cho nó trở nên chung chung.

Đối chiếu Ngôn Ngữ DPA Với Xử Lý Kỹ Thuật

Các hợp đồng xử lý theo kiểu Điều 28 tập trung vào đối tượng, thời hạn, tính chất, mục đích, danh mục dữ liệu, quyền của bên kiểm soát dữ liệu, chỉ thị của bên xử lý, bảo mật, bên xử lý phụ, xóa hoặc trả dữ liệu, và hỗ trợ các quyền của chủ thể dữ liệu. Đó là các điều khoản pháp lý. Nhưng người mua gateway vẫn phải chuyển chúng thành các факт kỹ thuật.

Hãy dùng bảng đối chiếu này:

Đây là nơi nhiều đợt rà soát thỏa thuận xử lý dữ liệu API của AI bị đổ vỡ. DPA có thể nói rằng bên xử lý hành động theo chỉ thị, trong khi tuyến sản phẩm âm thầm cho phép chuyển dự phòng sang nhiều nhà cung cấp. Hồ sơ phê duyệt nên nêu rõ nhà cung cấp nào được phép, nhà cung cấp nào bị chặn, và ai có thể thay đổi chính sách đó.

Xác Minh Việc Lưu Giữ Theo Endpoint Và Tính Năng

Các kiểm soát dữ liệu của nhà cung cấp thường phụ thuộc vào từng tính năng. Tài liệu kiểm soát dữ liệu nền tảng của OpenAI mô tả các hạn chế huấn luyện đối với API, lưu giữ mặc định để giám sát lạm dụng, các kiểm soát Zero Data Retention hoặc Modified Abuse Monitoring đã được phê duyệt, và hành vi trạng thái ứng dụng theo từng endpoint. Tài liệu lưu giữ dữ liệu API của Anthropic tách riêng xử lý qua Claude API khỏi xử lý trên marketplace đám mây và giải thích điều kiện đủ điều kiện ZDR theo tính năng. Tài liệu ZDR của Gemini Developer API của Google giải thích các hạn chế huấn luyện đối với dịch vụ trả phí và các trường hợp ở cấp tính năng mà prompt, phản hồi, tệp, grounding, trạng thái hoặc hành vi cache vẫn có thể quan trọng.

Điều đó có nghĩa là "chúng tôi có ZDR" là chưa đủ đối với một DPA cho LLM gateway. Hãy hỏi:

• Liệu endpoint chính xác có đủ điều kiện áp dụng kiểm soát lưu giữ không?
• Liệu project, organization hoặc account chính xác đã được phê duyệt chưa?
• Fallback có chuyển sang nhà cung cấp hoặc tính năng không nằm trong phạm vi được bao phủ không?
• Các tệp, hình ảnh, âm thanh, video, công cụ, tìm kiếm web, thực thi mã, bộ nhớ ngữ cảnh, job theo lô hoặc các cuộc hội thoại có trạng thái có làm thay đổi việc lưu giữ không?
• Các nhật ký giám sát lạm dụng, trạng thái ứng dụng, nhật ký gateway, hồ sơ hỗ trợ, hồ sơ thanh toán và bản sao lưu có được xử lý riêng biệt không?

Đối với một route production, hãy lưu một ma trận lưu giữ một dòng:

Danh sách kiểm tra DPA cho AI gateway chỉ hoàn chỉnh khi mỗi bản sao được lưu giữ đều có chủ sở hữu, lý do và đường dẫn xóa hoặc hết hạn.

Xem xét nhật ký Gateway tách biệt với các điều khoản của nhà cung cấp

Nhật ký gateway hữu ích cho độ tin cậy, kiểm soát chi phí, gỡ lỗi và xem xét kiểm toán. Chúng cũng là một bề mặt xử lý dữ liệu riêng biệt. Tài liệu công khai về gateway từ các nhà cung cấp hạ tầng cho thấy vì sao người mua nên hỏi rõ điều này: nhật ký yêu cầu có thể bao gồm prompt của người dùng, phản hồi của mô hình, nhà cung cấp, dấu thời gian, trạng thái, mức sử dụng token, chi phí, thời lượng và metadata của client, và giới hạn lưu nhật ký liên tục có thể khác nhau theo gói.

Hãy đặt các câu hỏi về nhật ký sau trước khi ký:

• Gateway có thể lưu toàn bộ prompt hoặc đầu ra, hay chỉ metadata?
• Việc ghi lại prompt và phản hồi có thể tắt theo route, môi trường, workspace hoặc khách hàng không?
• Các trường nhạy cảm có thể bị loại bỏ, che, băm hoặc ẩn danh trước khi ghi nhật ký không?
• Nhật ký có được sao chép sang analytics, kho dữ liệu, hệ thống cảnh báo, ticket hỗ trợ hoặc xuất dữ liệu không?
• Ai có thể xem nhật ký, và mọi quyền truy cập có được ghi lại không?
• Nhật ký có thể bị xóa sớm, xuất ra để kiểm toán, hoặc loại trừ khỏi quy trình hỗ trợ không?
• DPA có bao gồm nhật ký như dữ liệu khách hàng, dữ liệu hệ thống hay cả hai không?

Đây là sự khác biệt giữa một cuộc rà soát DPA pháp lý và một danh sách kiểm tra DPA cho AI gateway ở cấp vận hành. Nếu chính sách bảo mật của bạn quy định prompt không được lưu trữ, route phải chứng minh rằng gateway, nhà cung cấp và các đường dẫn hỗ trợ đều tuân theo cùng một quy tắc.

Kiểm tra các bên xử lý phụ và việc chuyển đổi nhà cung cấp

Một tài khoản nhà cung cấp trực tiếp thường có một chuỗi xử lý chính. Một bộ định tuyến mô hình có thể có chuỗi dài hơn vì một route ứng dụng có thể chạm tới gateway, nhà cung cấp thượng nguồn, công cụ quan sát, hạ tầng thanh toán, công cụ hỗ trợ và lưu trữ đám mây. Nếu bật fallback, một yêu cầu có thể được chuyển sang nhà cung cấp thứ hai khi nhà cung cấp đầu tiên gặp lỗi.

Bộ DPA nên trả lời:

Đối với người mua Flatkey, hãy kết hợp bằng chứng công khai về route và giá với các kiểm soát theo tài khoản cụ thể. Nếu route của bạn dùng một key cho nhiều mô hình, bằng chứng DPA vẫn phải nêu rõ những nhà cung cấp thượng nguồn nào có thể xử lý từng lớp dữ liệu đã được phê duyệt.

Yêu cầu bằng chứng về hỗ trợ, sự cố và kiểm toán

Quyền truy cập hỗ trợ rất dễ bị bỏ qua vì nó thường diễn ra sau khi có sự cố. Đối với một cuộc rà soát DPA của gateway, hỗ trợ là một phần của xử lý.

Hãy yêu cầu:

• Thông tin liên hệ hỗ trợ và lộ trình leo thang cho các sự cố bảo mật hoặc quyền riêng tư.
• Liệu nhân viên hỗ trợ có thể xem prompt, đầu ra, nhật ký, tệp đã tải lên, ảnh chụp màn hình hoặc metadata của khách hàng hay không.
• Liệu quyền truy cập hỗ trợ có bị giới hạn thời gian, cần phê duyệt và được ghi log hay không.
• Liệu có sẵn hồ sơ minh bạch về quyền truy cập cho các tài khoản đủ điều kiện hay không.
• Cách ticket hỗ trợ được ẩn/xóa thông tin khi chứa ví dụ về prompt hoặc đầu ra.
• Khung thời gian thông báo sự cố nào áp dụng theo DPA, điều khoản, SLA hoặc phụ lục bảo mật.
• Liệu nhà cung cấp có hỗ trợ các yêu cầu của chủ thể dữ liệu, xóa, xuất dữ liệu và các yêu cầu từ cơ quan quản lý hay không.

Khung Quản lý Rủi ro AI của NIST hữu ích ở đây như một tài liệu tham chiếu về quản trị vì nó khuyến khích các tổ chức quản trị, lập bản đồ, đo lường và quản lý rủi ro AI thay vì phê duyệt một tuyến đường một lần rồi quên đi. Đối với bộ định tuyến mô hình, điều đó có nghĩa là việc rà soát DPA phải có thể gia hạn. Hãy đặt ngày rà soát, phân công người chịu trách nhiệm cho bằng chứng và kiểm tra lại điều khoản của nhà cung cấp trước những thay đổi tuyến đường lớn.

Xây dựng bộ hồ sơ bằng chứng

Kết quả thực tế là một bộ hồ sơ bằng chứng nhỏ mà các nhóm pháp lý, bảo mật, mua sắm và nền tảng đều có thể đọc được.

Đối với Flatkey, hãy bổ sung bằng chứng công khai hiện tại từ trang chủ, chính sách quyền riêng tư, trang giá, điều khoản, SLA và bảng điều khiển tài khoản. Các trang công khai có thể giúp người mua sàng lọc dịch vụ, nhưng bằng chứng dành riêng cho tài khoản phải quyết định lựa chọn cuối cùng.

Các dấu hiệu cảnh báo nên tạm dừng phê duyệt

Tạm dừng rà soát tuyến đường khi bất kỳ điều nào sau đây chưa được làm rõ:

• DPA nêu tên nhà cung cấp gateway nhưng không nêu đường đi của nhà cung cấp mô hình ở thượng nguồn.
• Chế độ dự phòng có thể gửi dữ liệu nhạy cảm đến một nhà cung cấp chưa được phê duyệt.
• Nhật ký prompt hoặc output đã được bật, nhưng DPA hoặc rà soát bảo mật không bao gồm chúng.
• Nhà cung cấp nói "không huấn luyện" nhưng không thể trả lời về lưu giữ, quyền truy cập của hỗ trợ, xóa dữ liệu hoặc subprocessors.
• ZDR được hứa hẹn rộng rãi, nhưng điểm cuối, tính năng hoặc tài khoản đã chọn không đủ điều kiện.
• Phiếu hỗ trợ có thể bao gồm prompt thô mà không có quy trình che giấu.
• Không có đường thông báo cho các thay đổi subprocessor.
• Việc định tuyến theo khu vực được giả định nhưng không được chứng minh bằng hợp đồng, cài đặt tài khoản hoặc bằng chứng sử dụng.
• Giá, nhật ký và xuất dữ liệu sử dụng chứa các định danh khách hàng không được đưa vào bản đồ dữ liệu.
• Phê duyệt không có chủ sở hữu hoặc ngày rà soát.

Những dấu hiệu cảnh báo này không phải lúc nào cũng có nghĩa là nhà cung cấp không thể sử dụng. Chúng có nghĩa là danh sách kiểm tra DPA của AI gateway chưa hoàn thành.

Một phê duyệt tốt trông như thế nào

Một hồ sơ phê duyệt mạnh mẽ phải ngắn gọn và có thể kiểm tra được:

Định dạng này giúp DPA đi vào vận hành. Nhà phát triển biết họ có thể định tuyến điều gì. Bộ phận mua sắm biết điều gì đã được phê duyệt. Bộ phận bảo mật biết cần giám sát gì. Pháp lý có bằng chứng thay vì những lời hứa rời rạc.

Danh sách kiểm tra DPA cuối cùng cho AI Gateway

Trước khi mua hoặc mở rộng một bộ định tuyến mô hình, hãy xác nhận các mục sau:

• Danh sách kiểm tra DPA của AI gateway nêu rõ tuyến đường, điểm cuối, danh sách nhà cung cấp, chính sách dự phòng và lớp dữ liệu chính xác.
• Thỏa thuận xử lý dữ liệu API AI bao gồm prompt, output, tệp, nhật ký, metadata, phiếu hỗ trợ, hồ sơ thanh toán và subprocessors khi áp dụng.
• Việc ghi log của gateway và lưu giữ của nhà cung cấp được xem xét như các hệ thống riêng biệt.
• Các tuyên bố ZDR, không huấn luyện, hoặc thay đổi lưu giữ được gắn với đúng tài khoản, dự án, điểm cuối và tính năng.
• Việc chuyển đổi nhà cung cấp có danh sách cho phép, chủ sở hữu và ngưỡng kích hoạt rà soát.
• Quy trình xóa, xuất dữ liệu, quyền truy cập hỗ trợ, thông báo sự cố và thông báo thay đổi subprocessor đều được ghi lại.
• Các trang công khai của nhà cung cấp được coi là bằng chứng sàng lọc có ngày tháng, không phải thay thế cho DPA đã ký.
• Phê duyệt có chủ sở hữu, ngày hết hạn và quy tắc cho các thay đổi tuyến đường.

Nếu nhóm của bạn muốn một API key và một dashboard cho truy cập đa mô hình, hãy bắt đầu với Flatkey và giữ danh sách kiểm tra DPA của AI gateway này bên cạnh phần rà soát tuyến đường kỹ thuật. Nhận một key, xác nhận các kiểm soát tài khoản hiện tại, và phê duyệt từng tuyến đường với cùng mức độ kỷ luật mà bạn áp dụng cho bất kỳ bộ xử lý dữ liệu production nào khác.

Nguồn cần xem xét

• Trang chủ Flatkey
• Bảng giá Flatkey
• Chính sách quyền riêng tư của Flatkey
• Điều khoản dịch vụ của Flatkey
• Thỏa thuận mức dịch vụ của Flatkey
• Hướng dẫn về hợp đồng của ICO
• Các biện pháp kiểm soát dữ liệu của OpenAI
• Phụ lục Xử lý Dữ liệu của OpenAI
• API và lưu giữ dữ liệu của Anthropic
• Lưu giữ dữ liệu bằng 0 của Gemini Developer API
• Ghi log của Cloudflare AI Gateway
• Giá của Cloudflare AI Gateway và nhật ký lưu trữ lâu dài
• Khung Quản lý Rủi ro AI của NIST