Danh sách kiểm tra lưu trữ dữ liệu AI API nên trả lời một câu hỏi đơn giản trước khi lưu lượng sản xuất bắt đầu: những bản ghi nào sẽ tồn tại sau một lệnh gọi mô hình, ai có thể đọc chúng, chúng tồn tại trong bao lâu, và người mua có thể xem lại bằng chứng nào sau này?
Câu hỏi đó nhanh chóng trở nên phức tạp. Một yêu cầu AI duy nhất có thể tạo ra các bản ghi câu lệnh, bản ghi kết quả đầu ra, nhật ký yêu cầu cổng, nhật ký giám sát lạm dụng của nhà cung cấp, sự kiện kiểm toán, dấu vết, mục bộ nhớ đệm, các dòng thanh toán, phiếu hỗ trợ, các bản xuất, ảnh chụp màn hình và ghi chú sự cố. Một số bản ghi giúp kỹ thuật gỡ lỗi. Một số giúp tài chính đối chiếu chi tiêu. Một số giúp bộ phận mua sắm chứng minh rằng một cài đặt của nhà cung cấp đã được xem xét. Một số hoàn toàn không nên tồn tại đối với các khối lượng công việc nhạy cảm.
Sử dụng danh sách kiểm tra lưu trữ dữ liệu AI API này để phân tách các bản ghi đó trước khi bạn định tuyến dữ liệu khách hàng thực qua một cổng. Mục tiêu không phải là giữ ít bản ghi hơn một cách mù quáng. Mục tiêu là giữ lại bằng chứng phù hợp cho hoạt động, bảo mật, tài chính và mua sắm mà không biến mọi câu lệnh và kết quả đầu ra thành một kho lưu trữ dữ liệu lâu dài.
Đối với người mua Flatkey, việc xem xét này thuộc về tệp phê duyệt cổng. Trang web công khai hiện tại của Flatkey định vị sản phẩm là một cổng AI API và nền tảng vận hành mô hình để truy cập mô hình, định tuyến, thanh toán, phân tích sử dụng và kiểm soát hoạt động. Điều đó làm cho nó trở thành một nơi tự nhiên để tập trung bằng chứng về tuyến đường, mô hình, chủ sở hữu, việc sử dụng và chi phí. Nó không loại bỏ nhu cầu xác minh việc lưu trữ cụ thể của tài khoản, hợp đồng nhà cung cấp và hành vi lưu trữ tải trọng trước khi phê duyệt.
Danh sách kiểm tra lưu trữ dữ liệu AI API
Bắt đầu với loại bản ghi, không phải khẩu hiệu của nhà cung cấp. “Lưu trữ dữ liệu bằng không” cho một tính năng của nhà cung cấp không tự động mô tả nhật ký cổng, dấu vết quan sát, sổ cái thanh toán, các bản xuất hoặc quy trình hỗ trợ của bạn.
| Bề mặt lưu trữ | Cần quyết định gì | Bằng chứng cần giữ | Tư thế mặc định |
|---|---|---|---|
| Câu lệnh | Liệu các thông điệp thô của người dùng/hệ thống/nhà phát triển, ngữ cảnh được truy xuất, tệp và đầu vào công cụ có được lưu trữ hay không | Sơ đồ luồng dữ liệu, cài đặt tải trọng, kiểm tra biên tập, kiểm tra xóa | Không lưu trữ câu lệnh thô theo mặc định |
| Kết quả đầu ra | Liệu các phản hồi của mô hình, đối số gọi công cụ, tệp được tạo và các đoạn truyền trực tuyến có được lưu trữ hay không | Chính sách ghi nhật ký đầu ra, cài đặt lưu trữ, kiểm tra truy cập | Không lưu trữ kết quả đầu ra thô theo mặc định |
| Nhật ký yêu cầu | Những trường siêu dữ liệu nào được giữ lại để gỡ lỗi và vận hành | Sự kiện nhật ký mẫu, từ điển trường, thời gian lưu trữ | Lưu trữ siêu dữ liệu không có phần thân tải trọng |
| Nhật ký kiểm toán | Những sự kiện quản trị và chính sách nào đủ bất biến để xem xét | Nhật ký thay đổi vai trò, nhật ký sự kiện chính, nhật ký thay đổi chính sách tuyến đường | Lưu trữ lâu hơn tải trọng gỡ lỗi |
| Hồ sơ thanh toán | Những bản ghi sử dụng, chi phí, hóa đơn, nạp tiền, thuế và bồi hoàn nào còn tồn tại | Mẫu hóa đơn, xuất dữ liệu sử dụng, các trường đối chiếu | Lưu trữ theo nhu cầu tài chính và hợp đồng |
| Hồ sơ nhà cung cấp | Các nhà cung cấp mô hình thượng nguồn lưu giữ những gì để giám sát lạm dụng, trạng thái ứng dụng, bộ nhớ đệm và lưu trữ tính năng | Tài liệu nhà cung cấp, điều khoản hợp đồng, ảnh chụp màn hình tài khoản | Xác minh theo từng nhà cung cấp, điểm cuối và tài khoản |
| Các bản xuất quan sát | Những dấu vết, cảnh báo, bảng điều khiển, phiếu và kho dữ liệu nào nhận được bản sao | Danh sách đích, cấu hình che giấu, mẫu xuất | Giảm thiểu và biên tập trước khi xuất |
| Hồ sơ hỗ trợ | Liệu ghi chú sự cố có bao gồm các đoạn câu lệnh/kết quả đầu ra hay không | Quy trình hỗ trợ, lưu trữ phiếu, quy tắc biên tập | Lưu trữ bằng chứng đã được làm sạch, không phải tải trọng thô |
Đây là danh sách kiểm tra lưu trữ dữ liệu AI API cốt lõi: xác định mọi loại bản ghi, chỉ định người sở hữu lưu trữ, chứng minh cài đặt bằng một bản đọc lại có ghi ngày tháng và đặt trình kích hoạt gia hạn cho mọi nơi dữ liệu có thể được sao chép.
Tách biệt việc lưu trữ khỏi việc huấn luyện
Chính sách huấn luyện của nhà cung cấp chỉ là một hàng trong bài đánh giá. Các đội mua sắm thường hỏi liệu dữ liệu API có được sử dụng để huấn luyện mô hình hay không. Điều đó quan trọng, nhưng nó không trả lời câu hỏi liệu câu lệnh hoặc kết quả đầu ra có được lưu trữ để giám sát lạm dụng, trạng thái ứng dụng, các tính năng sản phẩm, hỗ trợ, phân tích hoặc thanh toán hay không.
Các kiểm soát dữ liệu nền tảng của OpenAI phân biệt giữa việc huấn luyện mô hình, lưu trữ để giám sát lạm dụng và lưu trữ trạng thái ứng dụng. Tài liệu tương tự cho biết nhật ký giám sát lạm dụng có thể bao gồm câu lệnh và phản hồi và được lưu giữ tối đa 30 ngày theo mặc định, trong khi khách hàng đủ điều kiện có thể đăng ký các biện pháp kiểm soát như Giám sát Lạm dụng Sửa đổi hoặc Lưu trữ Dữ liệu Bằng không. Nó cũng liệt kê các ngoại lệ cụ thể cho từng điểm cuối, bao gồm trạng thái ứng dụng được lưu trữ cho một số API và hành vi cụ thể theo tính năng cho các tệp, cuộc hội thoại, video, bộ nhớ đệm, tìm kiếm trên web, các container được lưu trữ và các khả năng khác.
Tài liệu lưu trữ dữ liệu API của Anthropic định nghĩa Lưu trữ Dữ liệu Bằng không là dữ liệu khách hàng không được lưu trữ ở trạng thái nghỉ sau khi phản hồi API được trả về, với các ngoại lệ cho các yêu cầu pháp lý, phòng chống lạm dụng và lưu trữ cụ thể theo tính năng. Nó cũng lưu ý rằng tính đủ điều kiện của tính năng có thể khác nhau tùy theo khả năng của API.
Tài liệu ZDR của Gemini Developer API của Google cho biết các câu lệnh và phản hồi của Dịch vụ trả phí không được sử dụng để cải thiện các sản phẩm của Google, đồng thời cũng mô tả việc ghi nhật ký câu lệnh và phản hồi có giới hạn để giám sát lạm dụng và lưu trữ cụ thể theo tính năng cho một số khả năng nhất định. Trang này làm cho ZDR trở thành một bài đánh giá về cấu hình và lựa chọn tính năng, chứ không phải là một giả định phổ quát.
Bài học thực tế cho người mua là: hãy lưu giữ bằng chứng về chính sách của nhà cung cấp, nhưng đừng để nó thay thế chính sách lưu trữ dữ liệu AI API của riêng bạn. Nhà cung cấp có thể lưu trữ một thứ, cổng (gateway) có thể lưu trữ một thứ khác, và hệ thống quan sát (observability stack) của bạn có thể sao chép cả hai.
Câu lệnh và kết quả đầu ra cần có quy tắc riêng
Câu lệnh và kết quả đầu ra là những bản ghi có rủi ro cao nhất trong danh sách kiểm tra lưu trữ dữ liệu AI API vì chúng thường chứa bằng chứng gỡ lỗi hữu ích nhất và dữ liệu kinh doanh nhạy cảm nhất.
Hãy xem việc lưu trữ câu lệnh và kết quả đầu ra như một quy trình xử lý ngoại lệ:
- Mặc định không lưu trữ payload thô cho các tuyến (route) sản phẩm trừ khi một khối lượng công việc cụ thể yêu cầu.
- Cho phép lưu trữ payload đã được biên tập lại (redacted) chỉ sau khi các bộ dữ liệu thử nghiệm (fixtures) chứng minh rằng việc che giấu (masking) hoạt động hiệu quả trên các câu lệnh, kết quả đầu ra, kết quả công cụ, các đoạn truy xuất, lỗi và các sự kiện truyền dữ liệu (streaming).
- Cho phép lưu trữ payload đầy đủ chỉ cho một sự cố được chỉ định, kiểm thử dàn dựng (staging test), quy trình làm việc được khách hàng phê duyệt, hoặc khi cần chuyển giao cho nhà cung cấp.
- Đặt thời gian hết hạn trước khi thu thập để khoảng thời gian gỡ lỗi không thể trở thành nơi lưu trữ vĩnh viễn.
- Ghi nhật ký truy cập vào nhật ký payload vì trình xem nhật ký trở thành một hệ thống nhạy cảm.
- Giữ lại bản tóm tắt sự cố đã được làm sạch sau khi payload hết hạn, không giữ lại câu lệnh hoặc kết quả đầu ra thô.
Tài liệu OWASP Logging Cheat Sheet rất hữu ích ở đây vì nó xem các giá trị nhạy cảm trong nhật ký là một vấn đề thiết kế, chứ không phải là vấn đề định dạng. Thông tin bí mật, mã thông báo truy cập, dữ liệu cá nhân nhạy cảm, dữ liệu thanh toán, chuỗi kết nối, khóa mã hóa và dữ liệu phân loại cao thường nên được loại bỏ, che giấu, làm sạch, băm (hashed) hoặc mã hóa trước khi ghi nhật ký. Các câu lệnh AI có thể chứa tất cả các loại dữ liệu đó.
Đối với các mẫu biên tập (redaction), tài liệu của các công cụ cũng chỉ theo cùng một hướng. Tính năng che giấu của Langfuse (Langfuse masking) có thể biên tập dữ liệu trước khi dữ liệu theo dõi (trace data) rời khỏi ứng dụng. Tính năng Bỏ qua Nhật ký của Helicone (Helicone Omit Logs) được thiết kế để giữ lại các chỉ số hoạt động trong khi bỏ qua phần thân của yêu cầu và phản hồi. Các kiểm soát ghi nhật ký yêu cầu của Portkey (Portkey request logging controls) tách biệt nội dung yêu cầu/phản hồi khỏi việc ghi nhật ký tập trung vào chỉ số. Ngay cả khi bạn sử dụng một hệ thống (stack) khác, mẫu chung vẫn là: biên tập hoặc bỏ qua trước khi lưu trữ và xuất dữ liệu.
Nhật ký yêu cầu nên ưu tiên siêu dữ liệu (metadata)
Nhật ký yêu cầu thường là công cụ chính trong các hoạt động AI API. Chúng không cần chứa câu lệnh thô để trở nên hữu ích.
Đối với hầu hết các tuyến sản phẩm, một sự kiện ưu tiên siêu dữ liệu là đủ:
{
"request_id": "req_01jz4...",
"timestamp": "2026-07-04T04:00:00Z",
"environment": "production",
"owner_key_id": "support_summarizer_prod",
"route": "support-summary",
"endpoint_family": "chat_completions",
"requested_model": "approved-summary-route",
"served_provider": "selected_by_gateway",
"prompt_tokens": 1840,
"output_tokens": 312,
"status": "success",
"latency_ms": 1420,
"cost_usd": "0.0042",
"payload_storage": "none",
"retention_class": "ops_metadata_90d"
}
Sự kiện đó hỗ trợ việc xem xét thanh toán, tương quan sự cố, xem xét định tuyến, xem xét SLO, điều tra lạm dụng và bồi hoàn cho chủ sở hữu mà không cần lưu trữ phần thân của câu lệnh hoặc phản hồi.
Tính năng ghi nhật ký của Cloudflare AI Gateway cho thấy tại sao các quyết định về nhật ký yêu cầu cần phải rõ ràng. Nhật ký của cổng (gateway) có thể bao gồm nhà cung cấp, mô hình, trạng thái, lượng token sử dụng, chi phí, thời gian, câu lệnh, phản hồi và các hành động chính sách, và các kiểm soát trên từng yêu cầu có thể ảnh hưởng đến việc liệu phần thân của yêu cầu và phản hồi có được lưu trữ hay không. Một danh sách kiểm tra lưu trữ nên ghi lại cả cài đặt mặc định của cổng và bất kỳ đường dẫn ghi đè nào cho từng yêu cầu.
Sử dụng danh sách kiểm tra nhật ký yêu cầu này:
| Nhóm trường | Giữ lại theo mặc định? | Ghi chú |
|---|---|---|
| ID yêu cầu, ID theo dõi, dấu thời gian | Có | Cần thiết để hỗ trợ và xem xét sự cố |
| Khóa, dự án, tuyến, môi trường | Có | Sử dụng ID nội bộ ổn định; tránh các thông tin bí mật thô |
| Nhà cung cấp, mô hình, họ điểm cuối (endpoint) | Có | Cần thiết cho việc định tuyến và làm bằng chứng với nhà cung cấp |
| Trạng thái, loại lỗi, lý do thử lại/dự phòng | Có | Cần thiết để xem xét độ tin cậy |
| Số lượng token, độ trễ, chi phí | Có | Cần thiết cho tài chính và phát hiện bất thường |
| Kết quả an toàn/DLP/chính sách | Thường là có | Lưu trữ siêu dữ liệu quyết định, không lưu văn bản khớp nhạy cảm trừ khi được yêu cầu |
| Phần thân câu lệnh | Mặc định là không | Chuyển qua quy trình gỡ lỗi |
| Phần thân kết quả đầu ra | Mặc định là không | Chuyển qua quy trình gỡ lỗi |
| Đầu vào và đầu ra của công cụ | Mặc định là không | Thường chứa dữ liệu hệ thống riêng tư |
| Các đoạn và tệp truy xuất | Mặc định là không | Thường chứa tài liệu, hợp đồng hoặc dữ liệu khách hàng |
Đây là lúc việc lưu trữ dữ liệu AI API trở nên thực tiễn thay vì lý thuyết: các kỹ sư vẫn nhận được những bản ghi họ cần, trong khi những người chịu trách nhiệm về quyền riêng tư và bảo mật có thể thấy những gì đã được cố ý bỏ qua.
Nhật ký kiểm toán không phải là nhật ký payload
Nhật ký kiểm toán trả lời câu hỏi ai đã thay đổi điều gì, khi nào nó thay đổi, và liệu đường dẫn kiểm soát có hoạt động hay không. Chúng thường nên tồn tại lâu hơn các payload gỡ lỗi, nhưng không nên trở thành một kho lưu trữ payload cửa sau.
Danh sách kiểm tra lưu trữ dữ liệu AI API nên bao gồm các sự kiện kiểm tra cho:
- Việc tạo, xoay vòng, vô hiệu hóa và xóa khóa API.
- Các thay đổi về không gian làm việc, dự án, tuyến đường, nhà cung cấp và chính sách mô hình.
- Các thay đổi về hạn ngạch, ngân sách và kiểm soát thanh toán.
- Việc bật, tắt ghi nhật ký payload và phê duyệt ngoại lệ.
- Các sự kiện truy cập vào nhật ký nhạy cảm và các tệp xuất.
- Các thay đổi về vai trò quản trị và cấp quyền.
- Các sự kiện xuất, xóa dữ liệu và leo thang hỗ trợ.
Nhật ký kiểm tra nên nêu rõ tác nhân, mục tiêu, hành động, dấu thời gian, hệ thống nguồn, tham chiếu phê duyệt và trạng thái trước/sau. Chúng nên tránh lưu trữ các câu lệnh thô, kết quả đầu ra thô, khóa API thô, token truy cập, dữ liệu thẻ thanh toán và dữ liệu khách hàng chưa được biên tập.
Hãy kết nối bài viết này với hướng dẫn của Flatkey về nhật ký kiểm tra cho việc sử dụng AI API khi bộ phận mua sắm cần một mô hình sự kiện bền vững cho các hoạt động cổng kết nối. Nhật ký kiểm tra nên chứng minh rằng một chính sách lưu trữ đã được áp dụng; nó không cần phải bảo tồn payload nhạy cảm đã kích hoạt chính sách đó.
Hồ sơ thanh toán có nhu cầu lưu trữ khác nhau
Hồ sơ thanh toán dễ bị bỏ qua trong danh sách kiểm tra lưu trữ dữ liệu AI API vì chúng không giống như dữ liệu câu lệnh. Nhưng chúng vẫn quan trọng.
Hồ sơ thanh toán và tài chính có thể bao gồm:
- ID khóa API, không gian làm việc, nhóm, dự án, khách hàng hoặc môi trường.
- Mô hình, nhà cung cấp, họ điểm cuối và tuyến đường.
- Token câu lệnh, token đầu ra, token được lưu trong bộ nhớ đệm, đơn vị hình ảnh/video, thời lượng hoặc số lượng yêu cầu.
- Đơn giá, giá hiệu lực, mức tăng giá, tín dụng, thuế, dòng hóa đơn, hồ sơ nạp tiền, hoàn tiền và biến động số dư.
- Dấu thời gian, kỳ thanh toán, ID hóa đơn, ID nhà cung cấp thanh toán và tham chiếu sổ cái.
Những hồ sơ này thường cần tồn tại lâu hơn các payload gỡ lỗi vì các nhóm tài chính, thuế, hỗ trợ khách hàng và mua sắm cần bằng chứng đối chiếu. Chúng vẫn cần được tối thiểu hóa. Một sổ cái thanh toán không cần các câu lệnh hoặc kết quả đầu ra thô để chứng minh chi tiêu.
Sử dụng bảng lưu trữ thanh toán này:
| Hạng mục thanh toán | Chủ sở hữu điển hình | Câu hỏi về lưu trữ | Cần payload không? |
|---|---|---|---|
| Dòng sử dụng | Hoạt động tài chính và nền tảng | Chúng ta cần bằng chứng bồi hoàn trong bao lâu? | Không |
| Hóa đơn | Tài chính | Những quy tắc về thuế, kiểm toán và hợp đồng khách hàng nào được áp dụng? | Không |
| Nạp tiền hoặc biến động số dư trả trước | Tài chính | Nhóm có thể đối chiếu các thay đổi số dư với việc sử dụng không? | Không |
| Ảnh chụp nhanh giá cả | Mua sắm và tài chính | Đơn giá nào có hiệu lực khi yêu cầu được chạy? | Không |
| Hồ sơ tranh chấp của khách hàng | Hỗ trợ và tài chính | Bằng chứng đã được làm sạch nào giải thích cho khoản phí? | Thường là không |
| Hóa đơn nhà cung cấp | Tài chính và mua sắm | Chi tiêu đầu vào có thể được liên kết với việc sử dụng nội bộ không? | Không |
Trang giá hiện tại của Flatkey mô tả giá mô hình minh bạch, sử dụng trả theo dung lượng, giới hạn hạn ngạch, phân tích sử dụng, kiểm soát chi phí và các lộ trình xem xét thanh toán. Hãy coi đó là những tuyên bố sàng lọc công khai hữu ích, sau đó xác minh bảng điều khiển trực tiếp, điều khoản tài khoản, hóa đơn và các tệp xuất cho hồ sơ người mua của riêng bạn.
Xây dựng một tệp bằng chứng do người mua sở hữu
Các trang tin cậy rất hữu ích, nhưng hạng mục bền vững nên do người mua sở hữu. Một người đánh giá sau sáu tháng nữa sẽ có thể thấy những gì đã được kiểm tra vào ngày phê duyệt và những gì đã thay đổi sau đó.
Tạo một thư mục hoặc hồ sơ quản trị với cấu trúc này:
| Hạng mục bằng chứng | Nội dung cần ghi lại | Tác nhân gia hạn |
|---|---|---|
| Sơ đồ luồng dữ liệu | Đường dẫn yêu cầu từ ứng dụng đến cổng kết nối, nhà cung cấp, khả năng quan sát, thanh toán, hỗ trợ và các tệp xuất | Nhà cung cấp, công cụ, tuyến đường hoặc trình xuất mới |
| Cài đặt nhà cung cấp | Ảnh chụp màn hình hoặc đọc lại API về lưu trữ, đào tạo, ZDR/MAM, khu vực và hành vi trạng thái ứng dụng | Thay đổi hợp đồng hoặc tính năng của nhà cung cấp |
| Cài đặt cổng kết nối | Ghi nhật ký yêu cầu, ghi nhật ký payload, biên tập, xóa, chính sách tuyến đường và kiểm soát xuất | Bản phát hành hoặc thay đổi cấu hình cổng kết nối |
| Nhật ký siêu dữ liệu mẫu | Sự kiện giống sản xuất đã được làm sạch không có nội dung payload | Họ điểm cuối hoặc tuyến đường mới |
| Kiểm tra biên tập | Kết quả cố định cho câu lệnh, kết quả đầu ra, dữ liệu công cụ, các đoạn truy xuất và các đoạn luồng | SDK, mô hình, công cụ hoặc trình xuất mới |
| Hồ sơ ngoại lệ payload | Ai đã phê duyệt ghi nhật ký payload đầy đủ, tại sao, phạm vi, thời hạn và bằng chứng xóa bỏ | Mọi sự cố |
| Mẫu sự kiện kiểm tra | Các sự kiện về khóa, tuyến đường, hạn ngạch, vai trò, ghi nhật ký, xuất và xóa | Thay đổi vai trò hoặc quy trình làm việc của quản trị viên |
| Mẫu thanh toán | Dòng sử dụng, ảnh chụp nhanh giá cả, bằng chứng hóa đơn/nạp tiền và ánh xạ chủ sở hữu | Thay đổi giá cả hoặc quy trình thanh toán |
| Xem xét quyền truy cập | Ai có thể xem nhật ký, kho payload, tệp xuất, hóa đơn và phiếu hỗ trợ | Hàng quý hoặc khi có thay đổi vai trò |
| Kiểm tra xóa | Bằng chứng cho thấy nhật ký, payload, tệp xuất và phiếu hỗ trợ có thể hết hạn hoặc bị xóa bỏ | Thay đổi chính sách lưu trữ hoặc quy trình xóa khách hàng |
Tệp bằng chứng này biến việc lưu trữ dữ liệu AI API từ một tuyên bố của nhà cung cấp thành một quy trình xem xét có thể lặp lại. Nó cũng giúp việc gia hạn dễ dàng hơn vì người đánh giá có thể so sánh trạng thái hiện tại với trạng thái trước đó thay vì bắt đầu lại từ tài liệu tiếp thị.
Thiết lập các lớp lưu trữ trước khi ra mắt
Đừng để mỗi hệ thống tự đặt ra thời gian lưu trữ của riêng mình. Hãy xác định các lớp lưu trữ và ánh xạ mọi hồ sơ vào một lớp.
retention_classes:
ops_metadata_90d:
stores_payload: false
records:
- request_id
- route
- provider
- model
- status
- latency
- token_usage
- cost
access: engineering_ops_finance_security
debug_payload_72h:
stores_payload: true
approval_required: true
redaction_required: true
expiration_required_before_collection: true
access: named_incident_responders
audit_control_1y:
stores_payload: false
records:
- actor
- action
- target
- before_after_state
- approval_reference
access: security_procurement_admins
finance_ledger_contract_term:
stores_payload: false
records:
- usage
- pricing_snapshot
- invoice
- recharge
- balance_movement
access: finance_procurement
Thời gian chính xác nên được lấy từ hợp đồng, chính sách bảo mật, yêu cầu về thuế và cam kết của khách hàng. Điều quan trọng là lớp (class) phải tồn tại trước khi lưu lượng truy cập bắt đầu và việc lưu trữ payload phải được hiển thị như một thuộc tính riêng biệt.
Điều này phù hợp với Flatkey như thế nào
Flatkey có thể hỗ trợ mô hình vận hành vì bề mặt sản phẩm công khai tập trung vào một cổng API, định tuyến mô hình, khả năng hiển thị sử dụng, thanh toán, kiểm soát hạn ngạch và đánh giá hoạt động. Kiểm tra API giá trực tiếp vào ngày 4 tháng 7 năm 2026 đã trả về success=true, 45 hàng mô hình, 48 bản ghi nhà cung cấp, phiên bản giá a42d372ccf0b5dd13ecf71203521f9d2, và các đường dẫn điểm cuối được hỗ trợ bao gồm /v1/chat/completions, /v1/messages, Gemini generateContent, tạo hình ảnh và các điểm cuối video.
Sử dụng Flatkey làm bề mặt bằng chứng của cổng, sau đó xác minh các chi tiết cụ thể của tài khoản mà các trang công khai không thể chứng minh:
- Flatkey lưu trữ siêu dữ liệu yêu cầu nào.
- Liệu nội dung câu lệnh và phản hồi thô có được lưu trữ hay không.
- Liệu việc lưu trữ payload có thể bị vô hiệu hóa, giới hạn phạm vi, biên tập lại hoặc giới hạn thời gian hay không.
- Những sự kiện kiểm toán nào có sẵn cho khóa, định tuyến, hạn ngạch, thanh toán và quyền truy cập nhật ký.
- Những bản xuất thanh toán nào có sẵn để đối chiếu tài chính.
- Cài đặt lưu trữ của nhà cung cấp nào được áp dụng sau mỗi định tuyến.
- Những đường dẫn hỗ trợ, xuất dữ liệu và quan sát nào có thể sao chép dữ liệu yêu cầu.
Sự phân biệt này rất quan trọng. Một cổng có thể đơn giản hóa hoạt động và thu thập bằng chứng, nhưng người mua vẫn là người sở hữu danh sách kiểm tra lưu trữ dữ liệu AI API cuối cùng.
Chạy thử nghiệm lưu trữ trước khi sản xuất
Trước khi phê duyệt một định tuyến sản xuất, hãy chạy danh sách kiểm tra đối với một khối lượng công việc thử nghiệm.
- Gửi một yêu cầu bình thường và xác nhận nhật ký siêu dữ liệu xuất hiện mà không có nội dung câu lệnh hoặc kết quả đầu ra.
- Gửi một yêu cầu chứa các dữ liệu nhạy cảm được gieo sẵn như email, chuỗi có dạng token truy cập, ID tài khoản, các giá trị giống thanh toán và các dấu hiệu mã độc quyền.
- Xác nhận những dữ liệu đó không xuất hiện trong nhật ký, dấu vết, cảnh báo, bản xuất hỗ trợ hoặc hồ sơ thanh toán trừ khi định tuyến đó đã đi vào một làn gỡ lỗi được phê duyệt một cách rõ ràng.
- Bật một ngoại lệ payload gỡ lỗi có phạm vi trong môi trường không phải sản xuất và xác minh sự phê duyệt, ghi nhật ký truy cập, biên tập và hết hạn.
- Xóa hoặc đợi hết thời gian lưu trữ gỡ lỗi và xác nhận việc đọc lại không còn trả về payload nữa.
- Lấy một sự kiện kiểm toán cho thay đổi chính sách ghi nhật ký và việc xóa dữ liệu.
- Lấy một hàng thanh toán hoặc sử dụng và xác nhận nó đối chiếu được mà không có nội dung payload.
- Ghi lại ảnh chụp màn hình, kết quả đọc lại API, dấu thời gian, ID tài khoản và tên người đánh giá trong tệp bằng chứng.
Thử nghiệm này phát hiện ra lỗi phổ biến: một nhóm vô hiệu hóa việc lưu trữ payload trong cổng nhưng vẫn làm rò rỉ văn bản câu lệnh thông qua một trình xuất dấu vết, tin nhắn cảnh báo, phiếu hỗ trợ hoặc ảnh chụp màn hình gỡ lỗi.
Vị trí của điều này trong đánh giá tin cậy
Lưu trữ dữ liệu AI API là một phần của việc đánh giá cổng rộng hơn. Sử dụng danh sách kiểm tra cổng AI API doanh nghiệp để bao quát quyền truy cập, định tuyến, thanh toán, hạn ngạch và quyền sở hữu vận hành. Sử dụng đánh giá rủi ro nhà cung cấp AI API để so sánh các hợp đồng của nhà cung cấp thượng nguồn và các bên xử lý thứ ba. Sử dụng hướng dẫn nhật ký kiểm toán cho việc sử dụng AI API khi bộ phận mua hàng hỏi làm thế nào một cổng chứng minh được ai đã thay đổi khóa, định tuyến, hạn ngạch và chính sách ghi nhật ký.
Những đánh giá đó nên được kết nối với nhau. Danh sách kiểm tra cổng cho thấy bề mặt kiểm soát. Đánh giá rủi ro nhà cung cấp cho thấy hợp đồng thượng nguồn và ranh giới dữ liệu. Hướng dẫn nhật ký kiểm toán cho thấy bằng chứng quản trị lâu dài. Danh sách kiểm tra lưu trữ dữ liệu AI API này cho thấy những gì còn lại sau mỗi yêu cầu.
Câu hỏi thường gặp
Lưu trữ dữ liệu AI API là gì?
Lưu trữ dữ liệu AI API là chính sách và hành vi hệ thống xác định thời gian lưu trữ các câu lệnh, kết quả đầu ra, nhật ký siêu dữ liệu, sự kiện kiểm toán, dấu vết, các hàng thanh toán, hồ sơ hỗ trợ và hồ sơ phía nhà cung cấp sau một yêu cầu AI API.
Lưu trữ dữ liệu bằng không có giống như không có nhật ký không?
Không. Lưu trữ dữ liệu bằng không thường mô tả một sự kiểm soát cụ thể của nhà cung cấp hoặc tính năng đối với nội dung của khách hàng. Nó có thể không bao gồm siêu dữ liệu cổng, nhật ký kiểm toán, hồ sơ thanh toán, bản xuất quan sát, phiếu hỗ trợ hoặc mọi tính năng của nhà cung cấp. Luôn xác minh phạm vi và các ngoại lệ.
Có nên lưu trữ câu lệnh và kết quả đầu ra để gỡ lỗi không?
Chỉ trong trường hợp ngoại lệ. Nhật ký siêu dữ liệu nên là mặc định cho lưu lượng sản xuất. Chỉ lưu trữ payload đã được biên tập hoặc đầy đủ cho các quy trình công việc được phê duyệt, các sự cố có phạm vi, các bài kiểm tra dàn dựng hoặc các làn được khách hàng phê duyệt, và đặt thời gian hết hạn trước khi thu thập.
Nhật ký yêu cầu AI API nên được giữ trong bao lâu?
Không có một khoảng thời gian chung nào. Nhật ký siêu dữ liệu thường cần đủ thời gian để xem xét sự cố, đối chiếu thanh toán và điều tra lạm dụng. Payload câu lệnh và kết quả đầu ra thô thường nên có thời gian lưu trữ ngắn hơn nhiều so với siêu dữ liệu, nhật ký kiểm toán hoặc hồ sơ thanh toán.
Những hồ sơ thanh toán nào quan trọng cho việc lưu trữ AI API?
Lưu giữ các hàng sử dụng, số lượng token, mã định danh mô hình/nhà cung cấp, ảnh chụp nhanh giá cả, hóa đơn, hồ sơ nạp tiền, hoàn tiền và ánh xạ chủ sở hữu làm bằng chứng tài chính. Những hồ sơ này không nên yêu cầu nội dung câu lệnh hoặc kết quả đầu ra thô.
Bộ phận mua hàng nên hỏi gì một nhà cung cấp cổng kết nối?
Yêu cầu bằng chứng có ghi ngày tháng về siêu dữ liệu yêu cầu, hành vi lưu trữ payload, việc biên tập lại, xóa, nhật ký kiểm toán, kiểm soát truy cập, xuất dữ liệu thanh toán, cài đặt lưu trữ của nhà cung cấp và đích xuất dữ liệu của bên thứ ba. Sau đó, so sánh bằng chứng đó với chính sách phân loại dữ liệu và ứng phó sự cố của riêng bạn.
Kết luận
Một danh sách kiểm tra lưu trữ dữ liệu AI API biến những tuyên bố tin cậy mơ hồ thành một tệp hoạt động có thể xem xét được. Tách biệt câu lệnh khỏi kết quả đầu ra, nhật ký yêu cầu khỏi nhật ký kiểm toán, và hồ sơ thanh toán khỏi payload gỡ lỗi. Lưu giữ siêu dữ liệu theo mặc định, chỉ lưu trữ payload thô trong trường hợp ngoại lệ, kiểm tra việc biên tập lại trước khi lưu trữ, và bảo quản bằng chứng có ghi ngày tháng cho việc gia hạn. Khi bạn sẵn sàng tập trung hóa việc truy cập mô hình, sử dụng, thanh toán và định tuyến thông qua một giao diện cổng kết nối duy nhất, hãy xem xét bảng giá và danh mục mô hình hiện tại của Flatkey, sau đó nhận một khóa.
