24 thg 10, 2025·8 phút
Đưa prototype AI vào hệ thống sẵn sàng triển khai
Hướng dẫn thực tế để biến prototype AI thành hệ thống sẵn sàng triển khai: mục tiêu, dữ liệu, đánh giá, kiến trúc, bảo mật, giám sát và các bước phát hành.
Hướng dẫn thực tế để biến prototype AI thành hệ thống sẵn sàng triển khai: mục tiêu, dữ liệu, đánh giá, kiến trúc, bảo mật, giám sát và các bước phát hành.
Một prototype được xây để trả lời một câu hỏi: “Cái này có thể hoạt động không?” Hệ thống sản xuất phải trả lời một tập câu hỏi khác: “Cái này có thể hoạt động hàng ngày, cho nhiều người, với chi phí chấp nhận được và trách nhiệm rõ ràng không?” Khoảng cách này là lý do nhiều prototype AI tỏa sáng trong demo nhưng vấp khi đưa vào hoạt động.
Prototype thường chạy trong điều kiện lý tưởng: tập dữ liệu nhỏ được chọn lọc, một môi trường duy nhất và có người can thiệp khi cần. Trong demo, độ trễ tăng đột biến, trường dữ liệu thiếu, hoặc một câu trả lời sai có thể được giải thích dễ dàng. Trong sản xuất, những vấn đề đó trở thành ticket hỗ trợ, mất khách, và rủi ro.
Sẵn sàng cho sản xuất ít liên quan đến một mô hình tốt hơn mà nhiều hơn về vận hành có thể dự đoán được:
Nhóm thường bất ngờ bởi:
Bạn sẽ có một kế hoạch chuyển đổi lặp lại được: cách định nghĩa thành công, chuẩn bị dữ liệu, đánh giá trước khi mở rộng, chọn kiến trúc sản xuất, lên kế hoạch chi phí/độ trễ, đáp ứng yêu cầu bảo mật, thiết kế giám sát con người, theo dõi hiệu suất, và triển khai an toàn—để prototype tiếp theo của bạn không chỉ là một demo một lần.
Prototype có thể trông “đủ tốt” vì nó demo tốt. Sản xuất khác: bạn cần một thỏa thuận chung có thể kiểm tra được về mục đích AI, những gì nó không làm, và cách bạn đánh giá thành công.
Mô tả chính xác thời điểm AI được sử dụng và những gì xảy ra trước/sau đó. Ai kích hoạt yêu cầu, ai tiêu thụ đầu ra, và quyết định (hoặc hành động) nào được hỗ trợ?
Giữ cụ thể:
Nếu bạn không thể vẽ luồng trong năm phút, phạm vi chưa sẵn sàng.
Gắn AI với kết quả mà doanh nghiệp đã quan tâm: giảm thời gian xử lý hỗ trợ, rà soát tài liệu nhanh hơn, tỷ lệ lead đủ điều kiện cao hơn, giảm lỗi thoát, v.v. Tránh mục tiêu mơ hồ như “dùng AI để hiện đại hóa” mà không đo được.
Chọn một bộ nhỏ các chỉ số cân bằng giữa hữu ích và giới hạn thực tế:
Ghi lại những ràng buộc không thể vi phạm: mục tiêu uptime, chế độ thất bại chấp nhận được, giới hạn quyền riêng tư (dữ liệu nào được gửi/không được gửi), và yêu cầu leo thang.
Rồi tạo một checklist v1 đơn giản: trường hợp sử dụng nào được bao gồm, trường hợp nào nằm ngoài phạm vi, ngưỡng chỉ số tối thiểu, và bằng chứng bạn chấp nhận (bảng điều khiển, kết quả kiểm tra, phê duyệt). Đây sẽ là điểm neo cho mọi quyết định sau này.
Prototype có thể ấn tượng với một tập dữ liệu nhỏ được chọn lọc. Sản xuất khác: dữ liệu đến liên tục, từ nhiều hệ thống, và các trường hợp “lộn xộn” trở thành bình thường. Trước khi bạn mở rộng bất kỳ thứ gì, hãy rõ ràng về dữ liệu sẽ dùng, nguồn gốc và ai phụ thuộc vào đầu ra.
Bắt đầu bằng việc liệt kê chuỗi đầy đủ:
Bản đồ này làm rõ quyền sở hữu, quyền truy cập cần thiết và “đầu ra tốt” nghĩa là gì cho từng người tiêu thụ.
Ghi rõ những gì bạn có thể lưu, trong bao lâu và vì lý do gì. Ví dụ: lưu cặp yêu cầu/phản hồi để gỡ lỗi nhưng chỉ giữ trong thời gian ngắn; lưu chỉ số tổng hợp lâu hơn để phân tích xu hướng. Đảm bảo kế hoạch lưu trữ phù hợp với kỳ vọng quyền riêng tư và chính sách nội bộ, và định nghĩa ai được truy cập dữ liệu thô so với mẫu đã ẩn danh.
Dùng checklist nhẹ có thể tự động hóa:
Nếu kết quả thay đổi, bạn cần biết cái gì đã thay đổi. Phiên bản hóa dataset (snapshot hoặc hash), quy tắc gán nhãn, và prompt/template. Gắn mỗi bản phát hành mô hình với phiên bản dữ liệu và prompt chính xác đã dùng, để đánh giá và điều tra sự cố có thể lặp lại.
Demo prototype thường “cảm giác” tốt vì bạn đang kiểm thử các đường xử lý thành công. Trước khi đưa tới người dùng thực, bạn cần cách đo chất lượng lặp lại để quyết định không dựa trên cảm nhận.
Bắt đầu với kiểm thử offline chạy theo yêu cầu (trước mỗi phát hành), sau đó thêm tín hiệu online khi hệ thống hoạt động.
Offline trả lời: Thay đổi này có làm mô hình tốt hơn hay tệ hơn trên các nhiệm vụ quan trọng không? Online trả lời: Người dùng có thành công không, và hệ thống có an toàn khi chịu lưu lượng thực không?
Tạo tập ví dụ được chọn lọc phản ánh việc sử dụng thực: các yêu cầu điển hình, luồng hay gặp, và đầu ra ở định dạng mong đợi. Giữ nó nhỏ ban đầu (ví dụ 50–200 mục) để dễ bảo trì.
Với mỗi mục, định nghĩa “tốt” nghĩa là gì: câu trả lời tham chiếu, rubric chấm điểm, hoặc checklist (độ chính xác, đầy đủ, giọng điệu, trích dẫn, v.v.). Mục tiêu là độ nhất quán—hai người nên chấm cùng một kết quả tương tự.
Bao gồm kiểm thử những thứ dễ gây lỗi trong sản xuất:
Quyết trước những gì chấp nhận được: độ chính xác tối thiểu, tỷ lệ hallucination tối đa, tỷ lệ vượt qua kiểm tra an toàn, ngân sách độ trễ, và chi phí mỗi yêu cầu. Đồng thời định nghĩa những điều khiến rollback ngay lập tức (ví dụ: lỗi an toàn trên X%, tăng ticket hỗ trợ, hoặc giảm độ thành công nhiệm vụ).
Với điều này, mỗi lần phát hành trở thành một thí nghiệm có kiểm soát—không phải một canh bạc.
Prototype thường trộn mọi thứ vào một nơi: điều chỉnh prompt, tải dữ liệu, UI, và đánh giá trong cùng một notebook. Kiến trúc sản xuất tách rời trách nhiệm để bạn có thể thay đổi một phần mà không làm vỡ phần còn lại—và để lỗi được cô lập.
Bắt đầu bằng cách quyết định hệ thống chạy như thế nào:
Lựa chọn này quyết định hạ tầng, cache, SLA và kiểm soát chi phí.
Hệ thống AI đáng tin cậy thường là tập hợp các phần nhỏ với ranh giới rõ ràng:
Ngay cả khi triển khai cùng lúc lúc đầu, hãy thiết kế như thể mỗi thành phần có thể bị thay thế.
Mạng chậm, nhà cung cấp giới hạn tần suất, và mô hình đôi khi trả về đầu ra không dùng được. Xây hành vi dự đoán:
Quy tắc tốt: hệ thống nên thất bại “an toàn” và giải thích chuyện gì xảy ra, không tự đoán mò.
Đối xử với kiến trúc như một sản phẩm, không phải một script. Duy trì bản đồ thành phần đơn giản: phụ thuộc gì, ai sở hữu, và cách rollback. Điều này tránh bẫy sản xuất phổ biến khi “mọi người sở hữu notebook” nhưng không ai sở hữu hệ thống.
Nếu nút thắt chính của bạn là biến demo thành app dễ bảo trì, dùng nền tảng có cấu trúc có thể đẩy nhanh công việc “điện nước”: scaffold UI web, lớp API, DB, xác thực và triển khai.
Ví dụ, Koder.ai là một nền tảng vibe-coding cho phép đội tạo ứng dụng web, server và mobile qua giao diện chat. Bạn có thể prototype nhanh, rồi tiếp tục hướng tới sản xuất với các tính năng thực tế như chế độ lập kế hoạch, triển khai/hosting, miền tuỳ chỉnh, xuất mã nguồn và snapshot kèm rollback—hữu ích khi bạn lặp prompt, định tuyến, hoặc logic truy hồi nhưng vẫn cần phát hành sạch và có thể hoàn nguyên.
Prototype có thể trông “rẻ” khi chỉ vài người dùng. Trong sản xuất, chi phí và tốc độ trở thành tính năng sản phẩm—vì phản hồi chậm khiến trải nghiệm tệ, và hoá đơn bất ngờ có thể giết một đợt phát hành.
Bắt đầu với bảng tính đơn giản giải thích được với người không phải kỹ sư:
Từ đó ước tính chi phí cho 1.000 yêu cầu và chi phí hàng tháng ở lưu lượng kỳ vọng. Bao gồm cả “ngày xấu”: dùng token nhiều hơn, retry nhiều hơn, hoặc tài liệu nặng hơn.
Trước khi bạn thiết kế lại prompt hoặc mô hình, tìm cải tiến không làm thay đổi đầu ra:
Những cách này thường giảm chi phí và cải thiện độ trễ cùng lúc.
Quyết trước điều gì là “chấp nhận được” (ví dụ: chi phí tối đa/ yêu cầu, hạn mức tiêu dùng hàng ngày). Rồi thêm cảnh báo cho:
Mô hình tải đỉnh, không phải trung bình. Đặt rate limit, cân nhắc queue cho lưu lượng đột biến, và thiết lập timeout rõ ràng. Nếu một số tác vụ không trực tiếp với người dùng (tóm tắt, lập chỉ mục), chuyển chúng sang job nền để trải nghiệm chính luôn nhanh và ổn định.
Bảo mật và quyền riêng tư không phải chuyện “sau này” khi bạn chuyển từ demo sang hệ thống thực—chúng định hình những gì bạn có thể an toàn phát hành. Trước khi mở rộng, ghi ra hệ thống có thể truy cập gì (dữ liệu, công cụ, API nội bộ), ai có thể kích hoạt hành động, và thất bại trông như thế nào.
Liệt kê các cách thực tế tính năng AI của bạn có thể bị lạm dụng hoặc thất bại:
Mô hình mối đe dọa này hướng dẫn phê duyệt thiết kế và tiêu chí chấp nhận.
Tập trung rào chắn quanh đầu vào, đầu ra và cuộc gọi công cụ:
Giữ API key và token trong secrets manager, không lưu trong code hay notebook. Áp dụng nguyên tắc ít quyền nhất: mỗi service account chỉ truy cập dữ liệu/hành động tối thiểu cần thiết.
Về tuân thủ, định nghĩa cách bạn xử lý PII (lưu gì, redact gì), giữ audit logs cho hành động nhạy cảm, và đặt quy tắc lưu giữ cho prompt, đầu ra và trace. Nếu cần điểm khởi đầu, căn chỉnh chính sách với tiêu chuẩn nội bộ và tham chiếu checklist tại /privacy.
Prototype thường giả định mô hình “đủ đúng”. Trong sản xuất, bạn cần kế hoạch rõ ràng khi con người vào cuộc—đặc biệt khi đầu ra ảnh hưởng đến khách hàng, tiền bạc, an toàn hoặc uy tín. HITL không phải thất bại của tự động hóa; nó là hệ thống kiểm soát giữ chất lượng cao trong khi bạn học hỏi.
Bắt đầu bằng việc phân loại quyết định theo rủi ro. Nhiệm vụ ít tác động (soạn thảo tóm tắt nội bộ) chỉ cần kiểm tra ngẫu nhiên. Quyết định tác động lớn (quyết định chính sách, tư vấn y tế/tài chính) cần review, chỉnh sửa hoặc phê duyệt trước khi thực hiện.
Định nghĩa các kích hoạt review, như:
“Thumbs up/down” là khởi đầu, nhưng hiếm khi đủ để cải thiện hệ thống. Thêm cách nhẹ để reviewer và người dùng cuối cung cấp sửa và mã lý do cấu trúc (ví dụ: “thông tin sai”, “không an toàn”, “giọng điệu”, “thiếu ngữ cảnh”). Đặt feedback ngay cạnh đầu ra để thu thập khi vấn đề còn mới.
Khi có thể, lưu:
Tạo đường leo thang cho đầu ra gây hại, tác động lớn hoặc vi phạm chính sách. Có thể là một nút “Báo cáo” chuyển mục vào hàng đợi với người trực ca, SLA rõ ràng và playbook chứa biện pháp cô lập (vô hiệu hoá tính năng, thêm rule blocklist, thắt chặt prompt).
Niềm tin tăng khi sản phẩm trung thực. Dùng dấu hiệu rõ ràng: hiển thị giới hạn, tránh tuyên bố quá chắc chắn, và cung cấp trích dẫn hoặc nguồn khi có thể. Nếu hệ thống sinh bản nháp, ghi rõ—và làm cho việc chỉnh sửa dễ dàng.
Khi prototype AI hoạt động sai, bạn thấy ngay vì bạn đang theo dõi. Trong sản xuất, vấn đề ẩn trong các trường hợp biên, spike lưu lượng và lỗi chậm. Khả năng quan sát giúp bạn nhìn thấy vấn đề sớm—trước khi trở thành sự cố khách hàng.
Bắt đầu bằng việc quyết định những gì cần để tái tạo một sự kiện sau này. Với hệ thống AI, “có lỗi” không đủ. Ghi log:
Làm log có cấu trúc (JSON) để lọc theo tenant, endpoint, phiên bản mô hình và loại lỗi. Quy tắc tốt: nếu bạn không thể trả lời “có gì thay đổi?” từ log, bạn đang thiếu trường.
Giám sát truyền thống bắt lỗi sập. AI cần giám sát bắt “vẫn chạy nhưng tệ hơn.” Theo dõi:
Xem những thứ này là chỉ số hạng nhất với ngưỡng và người chịu trách nhiệm rõ ràng.
Bảng điều khiển nên trả lời: “Nó có khỏe không?” và “Sửa nhanh nhất là gì?” Ghép mỗi cảnh báo với runbook trực ca: kiểm tra gì, cách rollback, và ai cần thông báo. Cảnh báo nhiều tiếng ồn còn tệ hơn là không có—tinh chỉnh để chỉ page khi ảnh hưởng tới người dùng.
Thêm các yêu cầu “canary” theo lịch mô phỏng việc sử dụng thực để kiểm tra hành vi mong đợi (định dạng, độ trễ, và độ chính xác cơ bản). Giữ một bộ prompt/stable nhỏ, chạy chúng sau mỗi phát hành, và cảnh báo khi có suy giảm. Đây là hệ thống cảnh báo sớm rẻ tiền bổ sung cho giám sát người dùng thực.
Prototype có thể trông “xong” vì nó chạy trên máy của bạn. Công việc sản xuất phần lớn là làm cho nó chạy đáng tin cậy, cho các đầu vào đúng, với các phát hành có thể lặp lại. Đó là những gì quy trình MLOps cung cấp: tự động hóa, truy xuất nguồn và đường an toàn để phát hành thay đổi.
Đối xử với dịch vụ AI như bất kỳ sản phẩm khác: mọi thay đổi nên kích hoạt pipeline tự động.
Tối thiểu, CI của bạn nên:
Rồi CD deploy artifact đó tới môi trường mục tiêu (dev/staging/prod) bằng cùng các bước mỗi lần. Điều này giảm hiện tượng “chạy được trên máy tôi” và làm rollback thực tế.
Hệ thống AI thay đổi theo nhiều cách hơn ứng dụng truyền thống. Phiên bản hoá và có thể xem xét:
Khi sự cố xảy ra, bạn muốn trả lời: “Prompt + model + cấu hình nào đã sinh ra đầu ra này?” mà không phải đoán mò.
Dùng ít nhất ba môi trường:
Promote cùng artifact qua các môi trường. Tránh “build lại” cho production.
Nếu bạn muốn checklist sẵn dùng cho cổng CI/CD, quy ước phiên bản và thăng tiến môi trường, xem /blog cho mẫu và ví dụ, và /pricing cho gói hỗ trợ phát hành.
Nếu bạn dùng Koder.ai để xây xung quanh ứng dụng (ví dụ: React web UI kèm Go API với PostgreSQL, hoặc client Flutter), coi snapshot/rollback và cấu hình môi trường của nó là một phần của kỷ luật phát hành: test ở staging, ship bằng rollout có kiểm soát, và giữ đường dẫn sạch để quay lại phiên bản tốt trước đó.
Đưa prototype AI lên mạng không phải chỉ một nút “deploy”—mà là một thí nghiệm có kiểm soát với rào chắn. Mục tiêu của bạn là học nhanh mà không phá hoại niềm tin người dùng, ngân sách hoặc vận hành.
Shadow mode chạy mô hình/prompt mới song song nhưng không ảnh hưởng người dùng. Lý tưởng để xác thực đầu ra, độ trễ và chi phí trên lưu lượng thực.
Canary releases gửi một phần nhỏ request đến phiên bản mới. Tăng dần khi các chỉ số ổn định.
A/B tests so sánh hai biến thể (mô hình, prompt, chiến lược truy hồi hoặc UI) theo các chỉ số thành công định trước. Dùng khi bạn cần bằng chứng cải thiện, không chỉ an toàn.
Feature flags cho phép bật tính năng AI theo phân khúc người dùng (nhân viên nội bộ, người dùng năng, một vùng cụ thể) và chuyển đổi ngay lập tức mà không deploy lại.
Trước lần rollout đầu, ghi lại ngưỡng “go/no-go”: điểm chất lượng, tỷ lệ lỗi, tỷ lệ hallucination (với LLMs), độ trễ, và chi phí mỗi yêu cầu. Định nghĩa điều kiện dừng sẽ tự động tạm ngưng—ví dụ: spike trong đầu ra không an toàn, ticket hỗ trợ, hoặc p95 latency tăng.
Rollback nên là thao tác một bước: quay về mô hình/prompt và cấu hình trước đó. Với luồng hướng tới người dùng, thêm fallback: câu trả lời dựa trên quy tắc đơn giản, đường review con người, hoặc phản hồi “không thể trả lời” thay vì đoán mò.
Thông báo cho support và các bên liên quan về thay đổi, ai bị ảnh hưởng và cách nhận biết lỗi. Cung cấp runbook ngắn và FAQ nội bộ để đội phản ứng nhất quán khi người dùng hỏi “Tại sao AI trả lời khác hôm nay?”.
Phát hành là bắt đầu một giai đoạn mới: hệ thống AI giờ tương tác với người dùng thực, dữ liệu thực và các trường hợp biên thực sự. Xem vài tuần đầu là cửa sổ học hỏi, và biến “công việc cải tiến” thành phần kế hoạch của vận hành—không phải phản ứng khẩn cấp.
Theo dõi kết quả sản xuất và so sánh với benchmark trước phát hành. Chìa khóa là cập nhật tập đánh giá thường xuyên để phản ánh điều người dùng thực hỏi, định dạng họ dùng và lỗi quan trọng nhất.
Đặt nhịp (ví dụ hàng tháng) để:
Dù bạn huấn luyện lại mô hình hay điều chỉnh prompt/công cụ cho LLM, hãy chạy thay đổi qua cùng quy trình kiểm soát áp dụng cho phát hành sản phẩm. Ghi rõ điều gì đã thay đổi, vì sao và kỳ vọng cải thiện. Dùng rollout theo giai đoạn và so sánh các phiên bản để chứng minh tác động trước khi chuyển toàn bộ.
Nếu bạn mới bắt đầu, định nghĩa workflow nhẹ: đề xuất → đánh giá offline → rollout hạn chế → rollout toàn bộ.
Chạy review sau ra mắt kết hợp ba tín hiệu: sự cố (chất lượng hoặc sập), chi phí (chi tiêu API, compute, thời gian review của con người), và phản hồi người dùng (ticket, đánh giá, rủi ro churn). Tránh “sửa theo trực giác”—biến mỗi phát hiện thành hành động có thể đo lường.
Kế hoạch v2 nên tập trung vào nâng cấp thực tế: tự động hoá nhiều hơn, mở rộng bộ kiểm thử, quản trị rõ ràng hơn, và giám sát/cảnh báo tốt hơn. Ưu tiên công việc giảm sự cố lặp lại và làm cho cải tiến an toàn và nhanh hơn theo thời gian.
Nếu bạn chia sẻ bài học từ rollout, cân nhắc biến checklist và postmortem thành tài liệu nội bộ hoặc ghi chú công khai—một số nền tảng (bao gồm Koder.ai) có chương trình tặng tín dụng cho đội tạo nội dung hoặc giới thiệu người dùng, giúp bù đắp chi phí thí nghiệm trong khi bạn lặp.
Một prototype trả lời “Có thể làm được không?” trong điều kiện lý tưởng (tập dữ liệu nhỏ, có người sửa lỗi thầm lặng, độ trễ được châm chước). Hệ thống sản xuất phải trả lời “Có thể hoạt động ổn định mỗi ngày không?” với dữ liệu thực, người dùng thực và trách nhiệm rõ ràng.
Trong thực tế, sự sẵn sàng cho sản xuất được điều khiển bởi vận hành: mục tiêu độ tin cậy, cách thất bại an toàn, giám sát, kiểm soát chi phí và sự phân công trách nhiệm—không chỉ là một mô hình tốt hơn.
Bắt đầu bằng cách định nghĩa quy trình người dùng chính xác và kết quả kinh doanh mà nó cần cải thiện.
Sau đó chọn một tập nhỏ các chỉ số thành công trên các trục:
Cuối cùng, viết ra định nghĩa v1 về “hoàn thành” để mọi người đồng ý điều gì là “đủ tốt để phát hành”.
Hãy vẽ luồng dữ liệu đầu-cuối: đầu vào, nhãn/feedback và các hệ thống tiêu thụ đầu ra.
Rồi thiết lập quản trị:
Điều này ngăn các vấn đề “demo chạy nhưng thực tế không chạy” do đầu vào lộn xộn và thay đổi không được theo dõi.
Bắt đầu bằng một bộ vàng nhỏ, đại diện (thường 50–200 mục) và chấm điểm nó nhất quán với rubric hoặc câu trả lời tham chiếu.
Thêm các trường hợp biên sớm, bao gồm:
Đặt ngưỡng và trước để mỗi lần phát hành là một thí nghiệm có kiểm soát, không phải tranh luận theo cảm tính.
Các bước thủ công ẩn là “độ kết dính” do con người tạo ra giúp demo trông ổn—đến khi người đó không có mặt thì mọi thứ vỡ.
Ví dụ phổ biến:
Khắc phục bằng cách làm cho mỗi bước rõ ràng trong kiến trúc (xác thực, retry, fallback) và thuộc trách nhiệm của dịch vụ, không phải cá nhân.
Tách trách nhiệm để mỗi phần có thể thay đổi mà không làm vỡ cả hệ thống:
Chọn chế độ vận hành (API, batch, real-time), rồi thiết kế để xử lý lỗi với timeouts, retries, fallbacks và suy giảm mềm.
Xây dựng mô hình chi phí cơ bản sử dụng:
Rồi tối ưu mà không đổi hành vi:
Bắt đầu với mô hình đe dọa đơn giản tập trung vào:
Áp dụng rào chắn thực tế:
Hãy coi con người như một hệ thống điều khiển, không phải giải pháp vá lỗi.
Xác định nơi cần review (đặc biệt cho quyết định tác động cao) và thêm các kích hoạt như:
Ghi nhận feedback có thể sử dụng được (mã lý do, bản chỉnh sửa) và cung cấp đường leo thang (hàng đợi + on-call + playbook) cho kết quả gây hại hoặc vi phạm chính sách.
Sử dụng chế độ rollout phù hợp với mức rủi ro:
Đảm bảo rollback một bước (phiên bản/prompt/cấu hình trước đó) và có fallback an toàn (đáp án theo luật, review con người hoặc “không thể trả lời” thay vì đoán).
Thêm hạn mức chi tiêu và cảnh báo dị thường (tăng tokens/yêu cầu, surge retry).
Ngoài ra dùng quản lý bí mật, nguyên tắc ít quyền nhất, quy tắc giữ dữ liệu và lưu giữ nhật ký; liên kết chính sách/checklist tại /privacy.