Đánh giá rủi ro trước khi cho phép dùng Copilot hoặc chatbot AI trong công ty
Mẫu playbook giúp SOC, security engineer và compliance đánh giá dữ liệu, quyền truy cập, lưu trữ, log, tích hợp và prompt injection trước khi phê duyệt Copilot hoặc chatbot AI.
Một yêu cầu “bật Copilot cho nhân viên” có thể trông đơn giản. Nhưng phía sau nó là các câu hỏi vận hành quan trọng: AI được đọc dữ liệu nào, phản hồi được lưu ra sao, có thể kết nối tới hệ thống nào, và ai chịu trách nhiệm khi kết quả sai hoặc bị thao túng?
Với SOC, security engineer và nhóm risk & compliance, câu hỏi không nên chỉ là “Copilot có an toàn không?”. Câu hỏi cần trả lời là:
> Công cụ này được phép truy cập gì, xử lý gì, lưu gì và có thể thực hiện hành động nào?
Bài viết này cung cấp một playbook để đánh giá trước khi cho phép dùng Microsoft Copilot hoặc chatbot AI trong doanh nghiệp.
1. Xác định đúng bề mặt rủi ro
Microsoft Copilot kết hợp mô hình ngôn ngữ lớn (LLM), dữ liệu trong Microsoft Graph và các ứng dụng Microsoft 365 như Word, PowerPoint hoặc Excel.
Theo tài liệu Microsoft, Copilot có thể sử dụng nội dung và ngữ cảnh từ Microsoft Graph, gồm tài liệu, email, lịch, chat, cuộc họp và danh bạ mà người dùng được phép truy cập.
Điểm quan trọng nhất với đội bảo mật là:
Copilot chỉ hiển thị dữ liệu tổ chức mà người dùng có ít nhất quyền xem.
Quyền truy cập sẵn có trong Microsoft 365 vẫn là ranh giới kiểm soát chính.
Các quyền chia sẻ quá rộng, nhóm cũ hoặc quyền cộng tác liên tổ chức cần được rà soát trước khi mở rộng sử dụng AI.
Nói cách khác, AI có thể khiến dữ liệu mà người dùng vốn đã có quyền xem trở nên dễ tìm, dễ tổng hợp và dễ đặt vào ngữ cảnh hơn. Vì vậy, triển khai Copilot là thời điểm phù hợp để rà soát lại quyền trên SharePoint, Teams và các kho dữ liệu dùng chung.
2. Tách bạch: không dùng để huấn luyện không có nghĩa là không lưu trữ
Microsoft nêu rằng prompt, phản hồi và dữ liệu được truy cập qua Microsoft Graph không được sử dụng để huấn luyện các foundation LLM phục vụ Copilot.
Tuy nhiên, Microsoft cũng cho biết dữ liệu về tương tác được lưu, bao gồm prompt của người dùng và phản hồi của Copilot.
Khi đánh giá rủi ro, cần tách rõ hai vấn đề:
Dữ liệu có được dùng để huấn luyện mô hình hay không?
Dữ liệu có được xử lý, lưu trữ hoặc chịu các nghĩa vụ quản trị dữ liệu hay không?
Đây là các câu hỏi khác nhau. Một công cụ không dùng dữ liệu để huấn luyện mô hình vẫn có thể xử lý và lưu lại dữ liệu tương tác theo điều khoản dịch vụ và cam kết hợp đồng áp dụng.
Cũng không nên tự động áp cam kết của Microsoft Copilot cho chatbot AI khác. Mỗi sản phẩm, phiên bản, tính năng web search, agent hoặc tích hợp bên thứ ba có thể có luồng dữ liệu và điều khoản riêng.
Khi sử dụng agent để mở rộng Copilot, Microsoft khuyến nghị kiểm tra riêng điều khoản sử dụng và tuyên bố quyền riêng tư của agent đó.
Khi bật web search, Copilot có thể xác định các thuật ngữ trong prompt để tạo truy vấn và gửi truy vấn đó tới Bing Search. Đây cần là một phạm vi đánh giá riêng.
3. Phiếu đánh giá rủi ro: sáu câu hỏi bắt buộc
Hãy biến mọi yêu cầu mở AI thành một ticket có cấu trúc. Chủ hệ thống, data owner và security nên cùng chịu trách nhiệm hoàn tất hồ sơ.
| Hạng mục | Câu hỏi cần trả lời | Bằng chứng nên có |
|---|---|---|
| Mục đích sử dụng | AI phục vụ tác vụ nào? Kết quả có ảnh hưởng tới quyết định nghiệp vụ hay không? | Mô tả use case, owner, nhóm người dùng |
| Phân loại dữ liệu | Prompt, tệp, dữ liệu truy xuất và phản hồi có thể chứa dữ liệu cá nhân hoặc dữ liệu nhạy cảm không? | Danh mục dữ liệu được phép và bị cấm |
| Quyền truy cập | AI dùng quyền của người dùng hay có danh tính/quyền riêng? Có truy cập dữ liệu chia sẻ, guest hoặc shared channel không? | Sơ đồ quyền, nhóm được cấp, xác nhận của data owner |
| Lưu trữ và xử lý dữ liệu | Prompt, phản hồi và dữ liệu liên quan được xử lý hoặc lưu theo cam kết nào? | Tài liệu nhà cung cấp, điều khoản áp dụng, xác nhận từ compliance |
| Logging và điều tra | Có log nào cho hoạt động AI? Ai được xem? SOC cần bổ sung nguồn log hoặc quy trình điều tra nào? | Yêu cầu log, kế hoạch giám sát, quy trình xử lý sự cố |
| Hành động và tích hợp | Công cụ chỉ trả lời hay có thể gửi email, sửa dữ liệu, gọi API hoặc kích hoạt workflow? | Danh sách hành động, quyền, điểm phê duyệt |
Đừng chỉ ghi “có PII” hoặc “không có PII”. Cần xác định dữ liệu nhạy cảm có thể xuất hiện ở đâu:
Trong prompt do nhân viên nhập.
Trong tài liệu hoặc email mà AI tìm thấy.
Trong phản hồi do AI tạo ra.
Trong dữ liệu phục vụ điều tra, giám sát hoặc quản trị.
Với Microsoft Copilot, một câu hỏi thực tế là:
> Người dùng có thể xem tài liệu này trước khi bật Copilot hay không?
Nếu có, nhưng data owner không muốn nội dung đó được tổng hợp hoặc đưa vào một ngữ cảnh mới, doanh nghiệp cần xem lại mô hình phân quyền, phạm vi dữ liệu hoặc phạm vi triển khai.
4. Đánh giá prompt injection: coi nội dung ngoài là không đáng tin
OWASP mô tả LLM01:2025 Prompt Injection là rủi ro khi nội dung đầu vào làm thay đổi hành vi hoặc đầu ra của mô hình theo cách không mong muốn.
Prompt injection có thể xảy ra theo hai dạng chính:
Trực tiếp: người dùng nhập chỉ dẫn nhằm làm mô hình bỏ qua hướng dẫn hoặc thay đổi hành vi.
Gián tiếp: mô hình đọc trang web, tệp, email hoặc nguồn dữ liệu bên ngoài chứa chỉ dẫn gây ảnh hưởng đến hành vi của mô hình.
Nội dung gây ảnh hưởng không nhất thiết phải hiển thị rõ ràng với con người. Với hệ thống đa phương thức, rủi ro còn có thể liên quan đến hình ảnh và các loại dữ liệu khác.
Đây là lý do chatbot có web search, RAG hoặc agent cần được đánh giá kỹ hơn.
RAG (Retrieval-Augmented Generation) là phương pháp truy xuất tài liệu liên quan và đưa chúng vào ngữ cảnh để mô hình tạo câu trả lời. OWASP lưu ý RAG và fine-tuning có thể cải thiện tính liên quan, nhưng không loại bỏ hoàn toàn prompt injection.
Điều kiện giảm thiểu nên đưa vào hồ sơ phê duyệt
Phân tách và đánh dấu rõ nội dung tin cậy với nội dung từ web, tệp người dùng tải lên hoặc nguồn dữ liệu ngoài.
Không để mô hình tự quyết các hành động đặc quyền.
Xử lý hành động có tác động bằng logic ứng dụng, thay vì chỉ dựa vào đầu ra tự do của mô hình.
Áp dụng nguyên tắc least privilege cho tài khoản, token và tích hợp của ứng dụng.
Yêu cầu người phê duyệt đối với hành động rủi ro cao.
Xác định định dạng đầu ra khi có thể, sau đó kiểm tra bằng mã hoặc quy tắc xác định.
Áp dụng lọc đầu vào và đầu ra phù hợp với chính sách nội bộ.
Thực hiện kiểm thử đối kháng trước khi mở rộng phạm vi sử dụng.
OWASP cũng lưu ý không có biện pháp chắc chắn tuyệt đối để ngăn prompt injection. Mục tiêu của kiểm soát là giảm tác động khi mô hình bị ảnh hưởng, không phải giả định rằng mô hình sẽ luôn nhận biết và chặn mọi chỉ dẫn độc hại.
5. Walkthrough: biến yêu cầu “bật Copilot” thành quyết định có điều kiện
Giả sử một nhóm muốn dùng Copilot để tóm tắt email và tài liệu nội bộ.
Người yêu cầu nên mở ticket và điền thông tin tối thiểu sau. Không đưa dữ liệu thực tế nhạy cảm vào ticket.
text
Mục đích sử dụng: <tóm tắt / soạn thảo / tra cứu>
Nhóm người dùng: <nhóm>
Nguồn dữ liệu dự kiến: <email / chat / tài liệu / web>
Dữ liệu bị cấm đưa vào prompt: <danh sách>
Dữ liệu AI được phép truy xuất: <phạm vi đã được data owner duyệt>
AI có thể thực hiện hành động ngoài việc trả lời: <có/không>
Nếu có: <hành động>, <quyền>, <người phê duyệt>
Prompt và phản hồi được xử lý hoặc lưu theo chính sách nào: <chính sách>
Nguồn log hoặc bằng chứng phục vụ điều tra: <nguồn>
Kịch bản kiểm thử đối kháng đã thực hiện: <liệt kê>
Chủ hệ thống chấp nhận trách nhiệm: <vai trò>
Security reviewer có thể sử dụng một mẫu prompt nội bộ để chuẩn hóa nhận xét, với điều kiện chỉ đưa vào thông tin đã được phép chia sẻ:
text
Bạn là người rà soát rủi ro AI nội bộ.
Dựa trên hồ sơ dưới đây, hãy trả về:
dữ liệu nào cần cấm;
quyền nào cần xác minh lại;
điểm thiếu về xử lý, lưu trữ và logging;
kịch bản prompt injection cần kiểm thử;
điều kiện để phê duyệt có giới hạn.
Không suy đoán về khả năng của nhà cung cấp.
Hồ sơ: <nội dung ticket đã được làm sạch dữ liệu nhạy cảm>
Kết quả cần hướng tới không phải là nhận xét chung chung như “rủi ro thấp”. Một quyết định tốt phải có thể thực thi, ví dụ:
Chỉ mở cho nhóm người dùng đã xác định.
Chỉ dùng dữ liệu trong phạm vi data owner phê duyệt.
Chưa bật agent hoặc web search nếu chưa đánh giá riêng.
Không cho AI tự thực hiện hành động có tác động.
Bổ sung log hoặc quy trình điều tra cần thiết trước khi mở rộng.
Rà soát lại khi thay đổi tính năng, mô hình, agent hoặc luồng dữ liệu.
6. Logging: đặt câu hỏi điều tra trước khi triển khai
Trước khi mở rộng sử dụng AI, SOC nên xác định năng lực điều tra tối thiểu cần có.
Các câu hỏi cần trả lời gồm:
Có thể xác định ai đã sử dụng công cụ AI hay không?
Có bằng chứng nào về thời điểm và ứng dụng được sử dụng?
Có thể xác minh phạm vi dữ liệu hoặc tích hợp liên quan theo chính sách đã phê duyệt không?
Nếu công cụ có hành động ngoài việc trả lời, có thể xác định hành động nào đã được kích hoạt không?
SOC, chủ hệ thống và compliance có đầu mối xử lý khi phát hiện dấu hiệu bất thường hay không?
Không phải mọi sản phẩm AI đều cung cấp cùng loại log hoặc cùng mức độ chi tiết. Vì vậy, yêu cầu logging cần được kiểm tra trên tài liệu, cấu hình và hợp đồng áp dụng thay vì giả định có sẵn.
7. Chấp nhận rủi ro có điều kiện
Microsoft cho biết Copilot có nhiều lớp bảo vệ, gồm chặn nội dung gây hại, phát hiện tài liệu được bảo vệ và cơ chế chặn prompt injection.
Đây là các lớp phòng vệ hữu ích, nhưng không thay thế cho kiểm soát quyền truy cập, nguyên tắc đặc quyền tối thiểu, kiểm thử đối kháng và giám sát của doanh nghiệp.
Một quyết định “chấp nhận có điều kiện” nên ghi rõ:
Phạm vi người dùng và tác vụ được phép.
Các loại dữ liệu bị cấm.
Nguồn dữ liệu ngoài chưa được phép sử dụng.
Agent, web search, tích hợp hoặc hành động nào bị vô hiệu hóa.
Thao tác nào bắt buộc có người phê duyệt.
Yêu cầu logging, giám sát và đầu mối phản ứng sự cố.
Thời điểm rà soát lại khi có thay đổi về tính năng hoặc luồng dữ liệu.
Checklist cuối cùng
Trước khi phê duyệt, đội bảo mật cần trả lời được sáu câu hỏi:
Dữ liệu nào có thể đi vào AI?
AI kế thừa hoặc được cấp những quyền nào?
Prompt, phản hồi và dữ liệu liên quan được xử lý hoặc lưu như thế nào?
SOC có bằng chứng cần thiết để điều tra khi xảy ra sự cố không?
AI có thể thực hiện hành động nào ngoài việc tạo câu trả lời?
Rủi ro còn lại đã được business owner chấp nhận rõ ràng chưa?
Nếu thiếu một trong các câu trả lời này, chưa nên mở rộng quyền sử dụng AI trong doanh nghiệp.