Chuyển đến nội dung chính
Khi một chủ thể dữ liệu viện dẫn quyền được lãng quên của họ, bạn cần hai thứ: một bản sao di động dữ liệu của họ, và một lần xóa không đảo ngược thực sự vươn tới mọi bề mặt mà hoạt động của họ chạm tới — không chỉ hàng người dùng. OrcaRouter làm cả hai tự phục vụ. Một tài khoản đã đăng nhập có thể xuất dữ liệu của chính nó và lên lịch xóa chính nó; việc xóa chạy như một cửa sổ ân hạn 30 ngày theo sau bởi một lần scrub PII cascade-thanh-lọc các bản ghi khả quan sát buộc với tài khoản đó. Trang này bao quát luồng xóa mà khách hàng quan sát được. Về nơi các artifact bằng chứng sống, xem Data residency; về việc request log tồn tại bao lâu độc lập với xóa, xem Lưu giữ.

​
1. gdpr erasure llm: luồng DSAR tự phục vụ

Ba hành động console bao quát một yêu cầu truy cập chủ thể dữ liệu từ đầu đến cuối. Mỗi cái là một route UserAuth dưới /api/user/* — được điều khiển bởi session console của bạn, không bao giờ một relay key (sk-orca-…):

Xuất

Tải xuống một bản sao JSON di động của dữ liệu cá nhân của bạn trước khi xóa.

Xóa

Soft-delete ngay lập tức; lên lịch scrub không đảo ngược cho +30 ngày.

Hủy

Khôi phục tài khoản bất kỳ lúc nào trong cửa sổ ân hạn.
Xuất là tính di động dữ liệu — nửa truy cập của một DSAR. Xóa là nửa xóa. Hãy chạy xuất trước; một khi scrub kích hoạt, không còn gì để xuất.

​
2. Xuất dữ liệu của bạn (một luồng cụ thể)

Từ console, mở Account → Privacy và chọn Export my data. Console điều khiển route đọc này bằng session của bạn: 
GET /api/user/self/export
Authorization: Bearer <your console session>
Phản hồi là một tài liệu JSON tải xuống được của hồ sơ và dữ liệu cá nhân không-bí-mật của bạn. Bản xuất là một danh sách cho phép tường minh — nó không bao giờ bao gồm hash mật khẩu của bạn, system access token của bạn, các secret OAuth, thông tin xác thực webhook/thông báo, hay các thân payload request-log.
Xuất vẫn khả dụng trong cửa sổ ân hạn. Một tài khoản được lên-lịch-xóa được soft-delete nhưng vẫn có thể tiếp cận xuất và hủy — tính di động là toàn bộ điểm mấu chốt của việc giữ cánh cửa đó mở cho đến khi scrub chạy.

​
3. Lên lịch xóa

Account → Privacy → Delete my account soft-delete tài khoản ngay lập tức và lên lịch scrub PII cho bây giờ + 30 ngày: 
DELETE /api/user/self
Authorization: Bearer <your console session>
Content-Type: application/json

{ "password": "<current password>" }
Phản hồi mang ngày scrub đã lên lịch. Một vài rào chắn áp dụng:
Các tài khoản mật khẩu phải cung cấp mật khẩu hiện tại của họ trên request xóa — phòng vệ chống một session bị chiếm quyền hủy diệt dữ liệu vĩnh viễn. Các tài khoản chỉ-OAuth không có mật khẩu; session đã xác thực là bằng chứng.
Nếu bạn là chủ sở hữu duy nhất của một workspace nhóm chia sẻ vẫn còn các thành viên khác, việc xóa bị từ chối — nếu không các đồng đội sẽ kế thừa một workspace không-chủ. Hãy chuyển quyền sở hữu hoặc lưu trữ workspace trước.
Tài khoản root của instance bị từ chối — tự xóa nó sẽ để lại deployment không có super-admin. Hãy bàn giao vai trò root trước.
Gọi xóa lại khi đã đang pending trả về một phản hồi “already scheduled” thân thiện thay vì một lỗi.
Một khi đã lên lịch, session của bạn bị giới hạn cho các endpoint hủy và xuất trong phần còn lại của cửa sổ ân hạn — một cookie được giữ không còn vượt qua xác thực trên phần còn lại của /api/user/*. Hủy gỡ bỏ hạn chế và khôi phục quyền truy cập đầy đủ mà không cần đăng nhập lại.

​
4. Cửa sổ ân hạn 30 ngày

Cửa sổ ân hạn là một bộ đệm hoàn tác có chủ ý. Cho đến khi nó trôi qua tài khoản được soft-delete, không phải bị xóa, và một cuộc gọi khôi phục nó: 
POST /api/user/self/deletion/cancel
Authorization: Bearer <your console session>
Nếu một lần hủy đáp xuống trong cuộc đua giữa lần quét chọn tài khoản của bạn và scrub chạy, tài khoản giờ-đang-hoạt-động không bị ẩn danh — scrub rào chắn trên một trạng thái vẫn-còn-pending và bỏ qua bất cứ thứ gì đã được hồi sinh.
Hãy coi 30 ngày như bộ đệm SLA hoàn thành DSAR của bạn. Một chủ thể đổi ý, hoặc một request được nêu nhầm, hoàn toàn khôi phục được cho đến khi cửa sổ đóng — sau đó scrub không đảo ngược theo thiết kế.

​
5. Lần scrub PII và cascade thanh lọc của nó

Khi cửa sổ ân hạn trôi qua, một lần quét chạy scrub. Nó không chỉ ẩn một hàng — nó tước các định danh trực tiếp và cascade-thanh-lọc các bản ghi mà hoạt động của bạn để lại trên mọi bề mặt khả quan sát:
Bề mặtScrub làm gì
AccountCác định danh trực tiếp bị ẩn danh; thông tin xác thực, key, ràng buộc OAuth, passkey, và 2FA bị hard-delete
Request logBị thanh lọc khỏi kho request-log
Các hàng accounting / usageUsername bị che giấu và IP bị xóa trên các hàng giữ lại cho billing
Guardrail matchBị thanh lọc — bao gồm bất kỳ chuỗi con đã khớp thô nào
Firewall eventBị thanh lọc — tên tool, IP, và request ID quy cho bạn
Các trường tài khoản bị ẩn danh tại chỗ (username và email được viết lại thành một placeholder deleted-…, status disabled), nên các hàng accounting và audit có cơ sở pháp lý để persist giữ hình dạng của chúng trong khi mất dữ liệu cá nhân nhúng. Mọi thứ mang-thông-tin-xác-thực bị hard-delete — xóa thật, không phải một soft-delete chỉ đơn thuần ẩn.
Cascade vươn tới cùng ba bề mặt mà bạn đọc ở nơi khác trong console: match Guardrail, event Firewall, và request log. Sau scrub, không cái nào trong số chúng phân giải ngược về người đã bị xóa. Đây là cái khiến việc xóa đối xứng trên tầng nội dung, tầng hành động, và log.
Lưu ý sự phân biệt với nội dung đã khớp thô. Các guardrail match chỉ lưu một chuỗi con đã khớp khi toggle Log raw content của guardrail đó bật (tắt theo mặc định). Dù sao đi nữa, scrub thanh lọc các bản ghi đó hoàn toàn — nên toggle thay đổi những gì từng được ghi, không phải những gì sống sót qua một lần xóa.

​
6. Xóa so với lưu giữ

Xóa và lưu giữ là hai chiếc đồng hồ khác nhau — đừng lẫn lộn chúng:
  • Lưu giữ làm các request log già đi trên một cửa sổ trượt cho mọi người — một mặc định 30 ngày, server kẹp về mức tối đa cứng 180 ngày. Xem Lưu giữ.
  • Xóa là một sự kiện một-lần, theo-phạm-vi-tài-khoản được kích hoạt bởi một DSAR: cửa sổ ân hạn 30 ngày, rồi scrub.
Các log của một chủ thể có thể đã già đi dưới lưu giữ trước khi họ từng nộp một DSAR; scrub vẫn chạy đối với bất cứ thứ gì còn lại và che giấu các hàng accounting được giữ lại.

​
7. Phần này khớp vào đâu

Quyền-được-xóa là một mảnh của các nghĩa vụ chủ thể dữ liệu của bạn. Hãy ghép nó với bằng chứng đóng dấu khu vực và vòng compliance rộng hơn:

Lưu giữ

Cửa sổ request-log trượt — mặc định 30 ngày, kẹp 180 ngày — chạy độc lập với xóa.

Data residency

Khu vực mà các báo cáo compliance có chữ ký của bạn được lưu trữ và phục vụ dưới đó.

GDPR pack

Cài đặt các control và vận chuyển bằng chứng GDPR có chữ ký cho một auditor.

Trách nhiệm chia sẻ

Những gì gateway xóa cho bạn và những gì vẫn là quyết định của bạn.
Gateway cho bạn một DSAR tự phục vụ vươn tới mọi bản ghi nó sở hữu. Quyết định khi nào một lần xóa là bắt buộc, và đáp ứng bất kỳ thời hạn nào theo khu vực pháp lý cụ thể, vẫn là quyết định của bạn — cửa sổ ân hạn 30 ngày là bộ đệm của bạn để đưa ra nó.