Microsoft Purview bảo vệ AI agent trên AWS Bedrock: quản trị dữ liệu đa đám mây
Doanh nghiệp đang triển khai AI rất nhanh, và nhiều workload AI không nằm gọn trong một đám mây. Một đội có thể dùng Microsoft 365 và Microsoft Purview để quản trị, nhưng vẫn chạy AI agent trên AWS Bedrock hay Google Cloud. Thách thức: làm sao giữ một bộ kiểm soát bảo mật, quản trị và tuân thủ nhất quán khi agent chạy ngoài Azure? Bài viết phân tích cách Purview trở thành “policy engine” trung tâm cho dữ liệu, qua ví dụ agent duyệt chi phí chạy trên Amazon Bedrock.
Vì sao Microsoft Purview nên là policy engine trung tâm?
Hầu hết tổ chức không muốn có bộ chính sách riêng cho mỗi đám mây, mỗi model endpoint, mỗi đội ứng dụng — điều đó dẫn tới kiểm soát trùng lặp, thực thi thiếu nhất quán và lỗ hổng kiểm toán. Mô hình tốt hơn: tách nơi workload chạy khỏi nơi ra quyết định chính sách. Với Microsoft Purview trong kịch bản AI đa đám mây, bạn có:
- Một lớp chính sách nhất quán cho thông tin nhạy cảm (số thẻ tín dụng, dữ liệu tài chính, nội dung bị quản lý…).
- Một mặt phẳng quản trị mở rộng ra ngoài workload Microsoft sang môi trường multi-cloud.
- Khung tuân thủ với khả năng kiểm toán, truy vết chính sách.
- Cách áp kiểm soát dựa trên dữ liệu cho tương tác AI, không chỉ cho nơi lưu trữ.
Nói cách khác: tổ chức đang tin Purview để quản trị Exchange, SharePoint, Teams và Copilot cũng có thể dùng Purview để quản trị prompt và phản hồi trong một agent chạy trên Bedrock. Ứng dụng không cần tự xây policy engine — nó gọi Purview tại các điểm có rủi ro.
Kiến trúc cross-cloud
Giải pháp mẫu là một pattern AI đa đám mây: frontend chat trên trình duyệt; người dùng đăng nhập bằng Microsoft Entra ID (MSAL); backend chạy trên AWS Lambda; model là Amazon Bedrock (Nova 2 Lite); và Microsoft Purview đánh giá prompt cùng phản hồi để phát hiện vi phạm DLP.
Luồng end-to-end: người dùng đăng nhập qua Entra ID → frontend gửi token + prompt tới API trên AWS → Lambda đổi token bằng luồng On-Behalf-Of để Purview đánh giá theo danh tính người dùng → Purview quét prompt tìm thông tin nhạy cảm trước khi gọi model → nếu hợp lệ, Lambda gửi tới Bedrock → Purview quét phản hồi trước khi trả về → frontend hiển thị kết quả kèm “Purview evaluation badge”.
Hai kiểm soát quản trị mạnh: chặn DLP in-line (chặn yêu cầu rủi ro trước khi tới model) và thực thi ở thời điểm phản hồi (ngăn dữ liệu nhạy cảm bị trả về dù model có sinh ra). Quan trọng: quyết định dựa trên danh tính người hỏi, không chỉ ứng dụng đang chạy.
Tích hợp tối thiểu: pipeline 3 cổng DLP
Việc tích hợp Purview với Bedrock để kiểm tra nội dung vào/ra khá gọn: Gate 1 kiểm prompt (UPLOAD_TEXT) — chặn nếu vi phạm; Gate 2 gọi Bedrock; Gate 3 kiểm phản hồi (DOWNLOAD_TEXT) — chặn nếu vi phạm. Cần hai chính sách trong Purview: một collection policy cho Enterprise AI Apps và một DLP policy.
Vì sao đáng chú ý với đội bảo mật & tuân thủ?
- Gắn chính sách với rủi ro, không với nơi host: compute ở Lambda, model ở Bedrock, nhưng điểm quyết định chính sách vẫn là Purview.
- Rõ ràng vận hành: đội bảo mật không phải học một bộ công cụ quản trị khác cho mỗi AI stack.
- Hợp thực tế: phần lớn doanh nghiệp lớn đã hybrid và multi-cloud; pattern quản trị chỉ chạy cho một runtime là không đủ.
Ý nghĩa với doanh nghiệp Việt Nam
Nhiều doanh nghiệp Việt Nam dùng song song Microsoft 365 và AWS. Mẫu này cho thấy có thể tập trung hoá chính sách bảo mật/tuân thủ trong khi kiến trúc AI ngày càng phân tán. Đội bảo mật giữ được mô hình quản trị quen thuộc (Purview) và áp DLP cho cả AI chạy ngoài Azure — đặc biệt hữu ích cho ngành tài chính, sản xuất nơi dữ liệu nhạy cảm phải được kiểm soát chặt.
Kết luận
Câu chuyện lớn hơn không chỉ là Microsoft Purview bảo vệ được một agent trên Amazon Bedrock, mà là tổ chức có thể tập trung hoá chính sách dữ liệu ngay cả khi kiến trúc AI trải rộng nhiều đám mây. Lập trình viên vẫn tự do chọn runtime/model tốt nhất, còn quản trị vẫn nhất quán tại một điểm.
Theo dõi Office365Vietnam.info để cập nhật các phân tích mới nhất về Microsoft 365, bảo mật và hệ sinh thái AI doanh nghiệp.
