Đăng nhậpLiên hệBắt đầu miễn phí
Enterprise Controls and Trust13 tháng 7, 2026Flatkey Team

Phạm vi SOC 2 cho AI API Gateway: Báo cáo nên và không nên chứng minh điều gì

Hãy dùng danh sách kiểm tra phạm vi SOC 2 cho AI API gateway này để phân biệt những gì một báo cáo có thể chứng minh với bằng chứng cần theo dõi về route, nhà cung cấp, logging, lưu giữ dữ liệu và phần việc do bên mua tự xác minh.

Phạm vi SOC 2 cho AI API Gateway: Báo cáo nên và không nên chứng minh điều gì

Một bài đánh giá phạm vi SOC 2 cho AI API gateway không nên bắt đầu bằng huy hiệu. Nó nên bắt đầu bằng một câu hỏi đơn giản: hệ thống nào, trong khoảng thời gian nào, các kiểm soát nào, các phụ thuộc nào và những trách nhiệm do bên mua sở hữu nào đã thực sự được báo cáo bao phủ?

Sự khác biệt đó rất quan trọng đối với việc định tuyến mô hình. Một AI API gateway có thể nằm giữa ứng dụng của bạn và nhiều nhà cung cấp mô hình, các họ endpoint, log, quy trình hỗ trợ, hồ sơ thanh toán và các đường dự phòng. Báo cáo SOC 2 Type 2 có thể là bằng chứng hữu ích cho hệ thống được mô tả của nhà cung cấp gateway và các tiêu chí dịch vụ tin cậy được bao phủ. Nó không nên được coi là bằng chứng rằng mọi nhà cung cấp mô hình upstream, mọi tuyến, mọi cài đặt lưu giữ prompt, mọi cấu hình tài khoản của bên mua, hay mọi thay đổi mô hình trong tương lai đều đã được phê duyệt.

Hãy dùng danh sách kiểm tra phạm vi SOC 2 cho AI API gateway này khi bộ phận mua sắm, an ninh, pháp chế và kỹ thuật nền tảng cần quyết định báo cáo nên chứng minh điều gì, không nên chứng minh điều gì, và bằng chứng theo dõi nào thuộc về bộ hồ sơ phê duyệt.

Flatkey có liên quan đến bài đánh giá này vì trang công khai hiện tại định vị flatkey.ai là một AI API gateway và nền tảng vận hành mô hình để định tuyến lưu lượng chính thức của GPT, Claude, Gemini và các mô hình khác qua một key duy nhất, với các bề mặt dashboard, billing, routing, usage và bằng chứng vận hành. Các trang công khai của Flatkey và các trang tra cứu chứng nhận chỉ là bằng chứng sàng lọc ban đầu. Để phê duyệt cho môi trường production, hãy yêu cầu báo cáo SOC 2 riêng tư, hợp đồng/DPA đã ký nếu áp dụng, cài đặt tài khoản, cấu hình route và xác nhận từ bộ phận hỗ trợ cho workload bạn sẽ chạy.

Để có bối cảnh mua sắm rộng hơn, hãy ghép bài viết này với danh sách kiểm tra bằng chứng SOC 2 cho AI API gateway, bộ hồ sơ bằng chứng mua sắm AI gateway, và đánh giá rủi ro nhà cung cấp AI API.

Phạm Vi SOC 2 Cho AI API Gateway: Bảng Quyết Định Nhanh

Trang đầu tiên của quá trình xem xét nên tách bằng chứng trong báo cáo khỏi bằng chứng theo dõi từ bên mua.

Khu vực xem xét Báo cáo SOC 2 nên giúp chứng minh điều gì Bản thân nó không nên chứng minh điều gì
Pháp nhân Đơn vị cung cấp dịch vụ nào đã được kiểm toán Rằng mọi công ty liên kết, đại lý bán lại hoặc nhà cung cấp mô hình upstream đều được bao phủ
Ranh giới hệ thống Nền tảng, dịch vụ, địa điểm, hạ tầng, con người và quy trình nào nằm trong hệ thống được mô tả Rằng mọi tính năng dashboard, họ endpoint, route khách hàng, hay tích hợp trong tương lai đều nằm trong phạm vi
Thời kỳ báo cáo Khoảng thời gian được bao phủ bởi cuộc kiểm tra Type 2 Rằng các kiểm soát hiện tại không thay đổi sau khi giai đoạn kết thúc
Danh mục dịch vụ tin cậy Những tiêu chí nào đã được bao phủ, như security, availability, confidentiality, processing integrity hoặc privacy Rằng các danh mục không được chọn cũng đã được kiểm tra
Các kiểm soát đã thử nghiệm Những kiểm soát nào kiểm toán viên đã thử nghiệm và kết quả trong kỳ Rằng cấu hình của bên mua, chính sách route hoặc phân loại dữ liệu workload đã được kiểm tra
Ngoại lệ Có ghi nhận ngoại lệ kiểm soát hay không và ban quản lý đã phản hồi thế nào Rằng các ngoại lệ là không trọng yếu đối với workload cụ thể của bạn
Tổ chức dịch vụ phụ Các phụ thuộc chính có được bao gồm, loại trừ hay được xử lý bởi các báo cáo khác hay không Rằng việc lưu giữ, huấn luyện, ghi log hoặc hành vi theo khu vực của nhà cung cấp mô hình upstream đều được bao phủ
CUECs Những kiểm soát người dùng bổ trợ mà bên mua phải vận hành Rằng nhà cung cấp chịu trách nhiệm cho việc lưu trữ key của bên mua, redaction, danh sách cho phép của nhà cung cấp, hay phân loại dữ liệu ở cấp ứng dụng

Đây là quy tắc cốt lõi về phạm vi SOC 2 cho AI API gateway: báo cáo là bằng chứng về một hệ thống của tổ chức dịch vụ được mô tả trong một khoảng thời gian xác định. Nó không phải là sự chấp thuận toàn diện cho mọi route AI mà nhóm của bạn có thể tạo.

Khóa Năm Trường Phạm Vi Trước Khi Đọc Các Kiểm Soát

Đừng bắt đầu bằng cách rà soát xem có ý kiến kiểm toán “đẹp” hay không. Hãy bắt đầu với năm trường.

Trường Câu hỏi của bên mua Bằng chứng cần lưu
Thực thể Tổ chức dịch vụ nào đã được kiểm toán? Trang bìa báo cáo, pháp nhân, đối tác hợp đồng, tra cứu chứng nhận nếu công khai
Hệ thống Những dịch vụ, hạ tầng, nhóm, quy trình và luồng dữ liệu nào được bao gồm? Mô tả hệ thống, danh sách sản phẩm/dịch vụ, sơ đồ ranh giới hệ thống
Khoảng thời gian Báo cáo đã bao phủ giai đoạn Type 2 nào? Ngày bắt đầu, ngày kết thúc, thư bắc cầu nếu cần
Tiêu chí Những danh mục dịch vụ tin cậy nào đã được đưa vào? Phạm vi security, availability, processing integrity, confidentiality, privacy
Phụ thuộc Những tổ chức dịch vụ phụ và CUECs nào ảnh hưởng đến ý kiến? Phương pháp inclusive/carve-out, danh sách subservice, danh sách kiểm soát của bên mua

Đối với một AI gateway, trường hệ thống đáng được chú ý nhiều nhất. “API gateway” có thể chỉ là định tuyến base URL, hoặc cũng có thể bao gồm truy cập dashboard, danh mục mô hình, số dư tài khoản, đo lường usage, log yêu cầu, cảnh báo, quy trình hỗ trợ, ứng phó sự cố và quản lý key. Báo cáo riêng tư nên cho bạn biết những gì nằm trong mô tả hệ thống. Nếu không, hãy yêu cầu nhà cung cấp đối chiếu phạm vi báo cáo với route chính xác mà bạn dự định sử dụng.

Báo Cáo SOC 2 Nên Chứng Minh Điều Gì Đối Với Một AI Gateway

Một báo cáo SOC 2 Type 2 được giới hạn phạm vi nên giúp người mua trả lời các câu hỏi sau.

Khu vực chứng minh Bằng chứng SOC 2 hữu ích Diễn giải cho AI gateway
Thiết kế và vận hành kiểm soát Các kiểm soát được kiểm thử trong suốt kỳ báo cáo Việc kiểm soát truy cập, quản lý thay đổi, giám sát, ứng phó sự cố, quản lý nhà cung cấp và các kiểm soát liên quan có vận hành đối với hệ thống gateway được mô tả hay không
Phạm vi khả dụng Tiêu chí về khả dụng, giám sát liên quan đến SLA, quy trình sự cố nếu được bao gồm Việc dịch vụ được bao phủ có các kiểm soát giám sát và phản ứng được xác định hay không, chứ không phải liệu từng nhà cung cấp mô hình có luôn sẵn sàng hay không
Phạm vi bảo mật và quyền riêng tư Tiêu chí và các kiểm soát nếu các hạng mục này được bao gồm Việc các kiểm soát xử lý dữ liệu khách hàng cho hệ thống được mô tả có được xem xét hay không, chứ không phải mọi tính năng của nhà cung cấp đều có cùng thiết lập lưu giữ
Quản lý thay đổi Triển khai, phê duyệt và các kiểm soát thay đổi đã được kiểm thử Việc các thay đổi mã/cấu hình của gateway có được kiểm soát hay không, chứ không phải một tuyến do bên mua phê duyệt sẽ không thể bị bên mua thay đổi sau này
Kiểm soát truy cập Truy cập của lực lượng lao động, truy cập đặc quyền, xem xét quản trị viên, các kiểm soát quản lý tài khoản Việc truy cập ở phía nhà cung cấp có được kiểm soát hay không, chứ không phải bên mua lưu trữ khóa API một cách an toàn
Bảo mật logic Xác thực, ủy quyền, ghi log, lỗ hổng và các kiểm soát giám sát Việc các kiểm soát bảo mật được mô tả của gateway có tồn tại hay không, chứ không phải ứng dụng của bên mua có che giấu bí mật trước khi gửi prompt hay không
Quản lý nhà cung cấp Tổ chức dịch vụ phụ và các kiểm soát giám sát nhà cung cấp Việc các phụ thuộc nhà cung cấp có được quản lý hay không, chứ không phải mọi SOC 2, DPA hoặc thiết lập lưu giữ của từng nhà cung cấp thượng nguồn đều bao phủ route của bạn

Đây là lúc phạm vi SOC 2 cho AI API gateway trở nên thực tế. Báo cáo có thể hỗ trợ sàng lọc rủi ro nhà cung cấp. Tuy nhiên, nó vẫn phải được diễn giải thành các факt về tuyến: họ endpoint, loại dữ liệu, danh sách nhà cung cấp được cho phép, chính sách dự phòng, ghi log prompt/output, lưu giữ metadata, quyền truy cập hỗ trợ và đường dẫn xóa dữ liệu.

Báo cáo Không Nên Chứng Minh Điều Gì

Lỗi mua sắm phổ biến nhất là dùng báo cáo SOC 2 để thay cho những quyết định mà nó không được thiết kế nhằm đưa ra.

Không nên chỉ dựa vào báo cáo để chứng minh:

Khẳng định Vì sao cần kiểm tra bổ sung
"Tất cả các nhà cung cấp mô hình đều được bao phủ." Các nhà cung cấp thượng nguồn có thể là tổ chức dịch vụ phụ, bị loại trừ khỏi phạm vi, hoặc nằm ngoài báo cáo của gateway. Hãy yêu cầu bản đồ nhà cung cấp và bằng chứng áp dụng cho từng nhà cung cấp.
"Không có prompt hay output nào được lưu ở bất kỳ đâu." Log của gateway, log giám sát lạm dụng của nhà cung cấp, trạng thái ứng dụng, ticket hỗ trợ và bản sao lưu có thể có hành vi lưu giữ khác nhau.
"Không có training nào áp dụng cho mọi route." Các cam kết về training và lưu giữ thường phụ thuộc vào nhà cung cấp, tài khoản, endpoint và tính năng. Hãy lưu bằng chứng ở cấp tài khoản.
"Fallback đã được phê duyệt." Một route dự phòng có thể gửi dữ liệu sang nhà cung cấp hoặc khu vực khác. Hồ sơ phê duyệt nên nêu tên các nhà cung cấp fallback được phép.
"Ứng dụng của bên mua tuân thủ." SOC 2 nói về các kiểm soát của tổ chức cung cấp dịch vụ. Che giấu dữ liệu, lưu trữ khóa, phân loại dữ liệu và kiểm soát truy cập ứng dụng của bên mua là trách nhiệm của bên mua.
"Đã hoàn tất đánh giá quyền riêng tư hoặc DPA." SOC 2 không phải là một DPA đã ký, đánh giá chuyển giao dữ liệu, thông báo quyền riêng tư, BAA hay cam kết xử lý theo khu vực.
"Trạng thái hiện tại giống hệt kỳ báo cáo." Kỳ báo cáo có thể đã kết thúc từ nhiều tháng trước. Hãy yêu cầu thư cầu nối, chính sách hiện tại, cấu hình route hiện tại và bằng chứng gần đây.
"Giá, khả dụng của mô hình và kết quả SLA được đảm bảo." Danh mục mô hình, giá, giới hạn tốc độ của nhà cung cấp và khả dụng của bên thứ ba có thể thay đổi ngoài báo cáo SOC 2.

Nếu một nhà cung cấp nói rằng "SOC 2 bao phủ điều đó," hãy yêu cầu họ chỉ ra đúng mục, ngôn ngữ ranh giới hệ thống, tiêu chí được bao phủ, kiểm soát, kết quả kiểm thử và bất kỳ ghi chú CUEC hay tổ chức dịch vụ phụ nào.

Đọc về Các Tổ Chức Dịch Vụ Phụ Trước Khi Phê Duyệt Nhà Cung Cấp

Một AI gateway có thể phụ thuộc vào hạ tầng đám mây, hệ thống thanh toán, công cụ phân tích, công cụ hỗ trợ, nhà cung cấp quan sát, công cụ bảo mật và các nhà cung cấp mô hình thượng nguồn. Báo cáo SOC 2 nên giải thích cách xử lý các tổ chức dịch vụ phụ. Người mua thường thấy một trong hai cách tiếp cận:

Phương pháp Ý nghĩa đối với bên mua
Phương pháp bao gồm Các kiểm soát liên quan của tổ chức dịch vụ phụ được đưa vào phạm vi báo cáo. Hãy xem kiểm soát nào được bao gồm.
Phương pháp loại trừ Tổ chức dịch vụ phụ bị loại khỏi phạm vi báo cáo. Hãy xem bằng chứng riêng và các kiểm soát bổ trợ của tổ chức dịch vụ phụ.

Đối với định tuyến mô hình, các phần loại trừ rất quan trọng. Báo cáo SOC 2 của một gateway có thể bao phủ các kiểm soát quản lý nhà cung cấp của gateway trong khi để OpenAI, Anthropic, Google hoặc một nhà cung cấp thượng nguồn khác nằm ngoài hệ thống được kiểm toán. Điều đó không làm báo cáo trở nên vô dụng. Nó có nghĩa là việc xem xét phạm vi SOC 2 cho AI API gateway phải bao gồm một dòng bằng chứng nhà cung cấp cho mỗi route được phê duyệt.

Tài liệu của nhà cung cấp cho thấy vì sao không thể suy luận điều này. Tài liệu API của OpenAI tách riêng nhật ký giám sát lạm dụng, trạng thái ứng dụng, Zero Data Retention, Modified Abuse Monitoring và hành vi theo từng endpoint. Tài liệu về lưu giữ dữ liệu API của Anthropic giải thích rằng các API và tính năng khác nhau có nhu cầu lưu trữ khác nhau và ZDR là một thỏa thuận mà khách hàng yêu cầu cho các trường hợp sử dụng đủ điều kiện. Tài liệu ghi log của AI Gateway từ Cloudflare cho thấy một gateway có thể hiển thị prompts, responses, provider, timestamp, token usage, cost, duration, các hành động DLP và các điều khiển ghi log ở cấp payload. Đây là những ví dụ về các bề mặt kiểm soát mà người mua nên kiểm tra cho bất kỳ route nào của gateway, chứ không phải các tuyên bố về báo cáo riêng tư của Flatkey.

Hãy xem CUECs là công việc của bên mua, không phải văn bản mẫu

Kiểm soát người dùng bổ sung của thực thể không phải là phần lấp chỗ trống. Đó là những kiểm soát mà bên mua phải vận hành để các kiểm soát của tổ chức dịch vụ có ý nghĩa.

Đối với một AI gateway, các công việc CUEC phổ biến từ phía bên mua bao gồm:

Kiểm soát do bên mua sở hữu Bằng chứng cần lưu giữ
Lưu trữ và xoay vòng khóa Đường dẫn secret manager, chủ sở hữu, ngày xoay vòng, runbook xoay vòng khẩn cấp
Phê duyệt route Các nhóm endpoint đã được phê duyệt, allowlist nhà cung cấp, chính sách fallback, các lớp dữ liệu
Che bớt prompt Các quy tắc che bớt ở cấp ứng dụng, bản ghi kiểm thử, ví dụ về trường bị chặn
Rà soát quyền truy cập Danh sách quản trị, chủ sở hữu khóa, hồ sơ offboarding, rà soát quyền truy cập dashboard
Chính sách ghi log Prompt và output có được lưu hay không, quy tắc chỉ lưu metadata, lịch lưu giữ
Theo dõi mức sử dụng Chủ ngân sách, thiết lập hạn mức, ngưỡng cảnh báo, tần suất rà soát tài chính
Quy trình xử lý sự cố Request ID, đường leo thang hỗ trợ, gói bằng chứng, chủ sở hữu thông báo
Kích hoạt gia hạn Ngày rà soát và các điều kiện kích hoạt cho nhà cung cấp mới, nhóm endpoint mới, lớp dữ liệu mới hoặc thay đổi ghi log

Một memo tốt về SOC 2 AI API gateway scope nên gắn danh sách CUEC với công việc kỹ thuật. Nếu bên mua phải che bớt bí mật trước khi gửi prompt, phê duyệt nên dẫn tới bài kiểm thử che bớt đó. Nếu bên mua phải phê duyệt các nhà cung cấp model, cấu hình route nên hiển thị allowlist.

Bằng chứng sàng lọc cụ thể cho Flatkey cần yêu cầu và lưu giữ

Các trang công khai hiện tại của Flatkey, được kiểm tra vào ngày 11 tháng 7 năm 2026, ủng hộ việc sử dụng Flatkey trong quy trình mua sắm này, nhưng chúng không thay thế được bằng chứng dành riêng cho từng tài khoản.

Bằng chứng Kiểm tra công khai cho thấy gì Cách sử dụng
Trang chủ Flatkey công khai định vị dịch vụ xoay quanh các API chính thức của GPT, Claude và Gemini thông qua một key, điều phối model, xem xét dashboard, khả năng hiển thị usage, cost, routing và lỗi. Hãy dùng làm bằng chứng sàng lọc sản phẩm có ngày tháng. Không coi đó là phạm vi báo cáo SOC 2 riêng tư.
Trang giá và pricing API Các bề mặt giá/danh mục công khai trả về một trang giá trực tiếp và phản hồi từ pricing API với 158 dòng model và các nhóm endpoint bao gồm openai, openai-response, anthropic, image-generationopenai-video. Chỉ dùng như một ảnh chụp danh mục có ngày tháng. Sự sẵn có của model và endpoint có thể thay đổi.
Trang SLA SLA nói rằng nó áp dụng cho dashboard lưu trữ do Flatkey vận hành, API gateway, routing, metering và dịch vụ tài khoản, đồng thời loại trừ các nhà cung cấp model AI bên thứ ba và các hệ thống bên ngoài khác. Hãy dùng để xác định những gì Flatkey trực tiếp vận hành so với các phụ thuộc bên thứ ba.
Trang quyền riêng tư và điều khoản Các trang chính sách công khai thảo luận về truy cập API, điều phối model, bản ghi sử dụng, thanh toán, hỗ trợ, các nhà cung cấp model bên thứ ba và các quy tắc thay đổi model/nhà cung cấp. Dùng làm bằng chứng sàng lọc; phê duyệt cuối cùng vẫn cần điều khoản đã ký và bằng chứng xử lý dữ liệu theo từng route.
Tra cứu chứng chỉ Tra cứu CAI công khai cho thấy chứng chỉ VOC AI Inc. USA-SOC2-220513, SOC 2 Type II, đang hoạt động, thời hạn từ 15 tháng 7 năm 2025 đến 14 tháng 7 năm 2026. Chỉ dùng như một tra cứu công khai. Yêu cầu báo cáo SOC 2 thực tế và xác nhận hệ thống được bao phủ, tiêu chí, thời kỳ, ngoại lệ, CUECs và cách xử lý subservice.

Đối với Flatkey hoặc bất kỳ AI API gateway nào, phê duyệt nên ghi: "Đã kiểm tra các trang công khai; đã yêu cầu báo cáo riêng tư; đã đính kèm bằng chứng route; đã liệt kê các giả định không được hỗ trợ."

Xây dựng một bộ bằng chứng từ phạm vi đến route

Kết quả của đợt rà soát này nên là một bộ bằng chứng nhỏ, chứ không phải một phê duyệt mơ hồ.

Mục gói hồ sơ Tệp cần lưu Người phụ trách
Báo cáo SOC 2 Báo cáo riêng, kỳ báo cáo, tiêu chí, ý kiến, ngoại lệ, thư cầu nối nếu cần Mua sắm/an ninh
Bản đồ phạm vi Ranh giới hệ thống trong báo cáo được ánh xạ tới dashboard, gateway, API, đo lường, nhật ký, hỗ trợ và cấu hình route Kỹ thuật nền tảng
Bản đồ nhà cung cấp Các nhà cung cấp đã được phê duyệt, thứ tự dự phòng, cách xử lý subservice, bằng chứng riêng cho từng nhà cung cấp An ninh/nền tảng
Bản đồ dữ liệu Prompt, đầu ra, tệp, siêu dữ liệu, hồ sơ thanh toán, nhật ký, phiếu hỗ trợ, bản sao lưu An ninh/pháp lý
Ma trận lưu giữ Lưu giữ theo endpoint family cho gateway, nhà cung cấp, ứng dụng, hỗ trợ và bản sao lưu An ninh/pháp lý
Hồ sơ CUEC Các kiểm soát của bên mua và bằng chứng rằng từng kiểm soát đã được triển khai Nền tảng/an ninh
Bằng chứng kiểm thử Một yêu cầu thành công có rủi ro thấp và một lỗi dự kiến với request ID và nhật ký đã che bớt thông tin Kỹ thuật nền tảng
Biên bản phê duyệt Phạm vi, hạn chế, rủi ro còn mở, tên người rà soát, kích hoạt gia hạn Chủ doanh nghiệp/mua sắm

Bộ hồ sơ này cũng là cầu nối giữa quá trình rà soát SOC 2 và vận hành kỹ thuật. Khi thêm nhà cung cấp mới, lớp mô hình mới, chế độ ghi log mới hoặc lớp dữ liệu mới, nhóm cần biết những tệp nào phải cập nhật.

Dấu hiệu đỏ cần tạm dừng phê duyệt

Tạm dừng phê duyệt nếu có bất kỳ điểm nào sau đây chưa được giải quyết:

  • Báo cáo SOC 2 không có sẵn và chỉ cung cấp huy hiệu hoặc tra cứu chứng chỉ.
  • Kỳ báo cáo đã kết thúc và không có thư cầu nối hoặc bằng chứng hiện tại.
  • Mô tả hệ thống không nêu rõ đường dẫn gateway mà bạn dự định sử dụng.
  • Báo cáo loại trừ các tổ chức subservice liên quan và không kèm bằng chứng riêng của nhà cung cấp.
  • Các nhóm trust services được chọn không khớp với rủi ro mà bên mua nêu ra, chẳng hạn như quyền riêng tư hoặc bảo mật.
  • CUEC yêu cầu các kiểm soát của bên mua nhưng chúng chưa được triển khai.
  • Giả định rằng việc ghi log prompt/output đã bị tắt nhưng không có bằng chứng từ tài khoản hoặc route chứng minh điều đó.
  • Fallback có thể gửi dữ liệu tới một nhà cung cấp chưa được phê duyệt.
  • Hỗ trợ có thể xem nội dung yêu cầu nhưng quyền truy cập hỗ trợ, thời hạn lưu giữ ticket và che bớt thông tin không được tài liệu hóa.
  • Phê duyệt không có người phụ trách, ngày hết hạn hoặc kích hoạt thay đổi route.

Những dấu hiệu đỏ này không phải lúc nào cũng có nghĩa là nhà cung cấp không đạt. Chúng có nghĩa là việc rà soát phạm vi cổng API AI SOC 2 chưa hoàn tất.

Một tuyên bố phê duyệt thực tế

Một tuyên bố phê duyệt hữu ích cần ngắn gọn, cụ thể và có thể kiểm thử:

Trường Cách diễn đạt ví dụ
Bằng chứng báo cáo "Đã rà soát báo cáo SOC 2 Type 2 cho Nhà cung cấp X, kỳ A đến B, tiêu chí bảo mật và khả dụng, không có ngoại lệ nào chưa được chấp nhận cho route này."
Phạm vi được phê duyệt "Quy trình hỗ trợ văn bản chỉ ở môi trường production thông qua base URL gateway đã phê duyệt và endpoint chat."
Nhà cung cấp "Nhà cung cấp A là chính, Nhà cung cấp B dự phòng; không có endpoint hình ảnh, video, tệp, tìm kiếm web hoặc batch."
Lớp dữ liệu "Văn bản hỗ trợ khách hàng sau khi che bớt ở cấp ứng dụng; không có dữ liệu thanh toán, bí mật, PHI hoặc hồ sơ được quản lý."
Ghi log "Cho phép log siêu dữ liệu gateway; tắt ghi log prompt/output thô hoặc đã được phê duyệt riêng; kèm bằng chứng lưu giữ của nhà cung cấp."
Kiểm soát của bên mua "Khóa được lưu trong secret manager, rà soát quyền truy cập hàng quý, allowlist route, rà soát mức sử dụng hàng tháng, đã chỉ định chủ sự cố."
Kích hoạt gia hạn "Cập nhật trước khi thêm nhà cung cấp, bật các họ endpoint mới, thay đổi ghi log, định tuyến dữ liệu được quản lý, hoặc sau khi kỳ SOC 2 hết hạn."

Đó là ý nghĩa đúng của "đã phê duyệt". Nhà phát triển biết route nào họ có thể dùng. Bộ phận mua sắm biết bằng chứng nào đã được rà soát. An ninh biết cần theo dõi điều gì. Pháp lý biết những giả định nào vẫn cần điều khoản hợp đồng.

Kết luận

Một cuộc rà soát phạm vi cổng API AI SOC 2 có giá trị khi nó giữ được tính chính xác. Báo cáo nên giúp chứng minh hệ thống được mô tả của tổ chức dịch vụ đã được kiểm toán, các tiêu chí được bao phủ, vận hành kiểm soát, kỳ báo cáo, ngoại lệ, cách xử lý subservice và trách nhiệm của bên mua. Báo cáo không nên bị kéo giãn thành bằng chứng cho mọi route, mọi nhà cung cấp, mọi thiết lập lưu giữ, mọi hành vi fallback, mọi điều khoản DPA, mọi tuyên bố về nơi lưu trú dữ liệu, hoặc mọi cấu hình của bên mua.

Với Flatkey, hãy bắt đầu từ bằng chứng công khai hiện có, sau đó yêu cầu báo cáo SOC 2 riêng và ánh xạ nó với route mà nhóm của bạn thực sự sẽ chạy. Nếu bạn muốn một API key và một dashboard cho quyền truy cập đa mô hình, lấy một key, đính kèm checklist phạm vi cổng API AI SOC 2 vào bộ hồ sơ mua sắm, và phê duyệt từng route production với bằng chứng rõ ràng về nhà cung cấp, ghi log, lưu giữ và CUEC.

Câu hỏi thường gặp

Phạm vi cổng API AI SOC 2 là gì?

Phạm vi cổng API AI SOC 2 là ranh giới của báo cáo SOC 2 khi áp dụng cho một cổng API AI. Nó bao gồm thực thể được kiểm toán, hệ thống được mô tả, kỳ báo cáo, các nhóm trust services, các kiểm soát đã được kiểm thử, các tổ chức subservice, các phần loại trừ và các CUEC thuộc về bên mua.

SOC 2 có chứng minh rằng mọi nhà cung cấp mô hình AI đều được bao phủ không?

Không. SOC 2 có thể cho thấy nhà cung cấp gateway quản lý hệ thống được mô tả và các phụ thuộc của nó như thế nào, nhưng các nhà cung cấp mô hình upstream có thể được bao gồm, được loại trừ, hoặc được chứng minh bằng bộ bằng chứng riêng. Bên mua nên lưu một sơ đồ nhà cung cấp cho từng tuyến đã được phê duyệt.

Báo cáo SOC 2 Type 2 có chứng minh rằng không lưu giữ prompt hay không?

Không, tự nó thì không. Việc lưu giữ prompt và đầu ra có thể khác nhau giữa gateway, các nhà cung cấp upstream, trạng thái ứng dụng, ticket hỗ trợ, log và bản sao lưu. Bên mua nên xác minh bằng chứng lưu giữ theo từng endpoint, tài khoản và tuyến đường cụ thể.

Bộ phận mua sắm nên yêu cầu gì sau khi thấy huy hiệu SOC 2?

Yêu cầu báo cáo SOC 2 riêng tư, kỳ báo cáo, các tiêu chí được bao phủ, mô tả hệ thống, các ngoại lệ, cách xử lý tổ chức dịch vụ phụ, CUECs, thư cầu nối nếu cần, sơ đồ nhà cung cấp, cấu hình tuyến, cài đặt logging, ma trận lưu giữ, và bằng chứng hợp đồng/DPA đã ký khi áp dụng.

Tần suất làm mới việc rà soát phạm vi nên là bao lâu?

Làm mới việc rà soát phạm vi AI API gateway SOC 2 khi kỳ báo cáo hết hạn, khi nhà cung cấp cung cấp báo cáo mới, trước khi thêm một nhà cung cấp hoặc một họ endpoint, trước khi định tuyến một lớp dữ liệu mới, khi logging hoặc lưu giữ thay đổi, và sau các sự cố đáng kể.

Nguồn cần xem xét