Bảo mật dữ liệu sản xuất khi dùng cloud và AI Copilot

I. Bắt đầu bằng phân loại dữ liệu

Không phải mọi dữ liệu đều có mức nhạy cảm như nhau. Nhà máy có thể phân loại tối thiểu:

Mức	Ví dụ	Kiểm soát gợi ý
Công khai	Tài liệu marketing, hướng dẫn công khai	Kiểm soát cơ bản
Nội bộ	SOP chung, checklist, dashboard tổng hợp	Đăng nhập, phân quyền
Nhạy cảm	Sản lượng, OEE, lịch sử hỏng, tài liệu kỹ thuật	MFA, log, encryption, giới hạn chia sẻ
Hạn chế/critical	Công thức, thông số độc quyền, dữ liệu khách hàng, an toàn	Phê duyệt riêng, scope tối thiểu, giám sát cao

Phân loại giúp quyết định dữ liệu nào được phép đưa vào SaaS, AI Copilot, cloud server hoặc chỉ được xử lý trong môi trường riêng.

II. Mô hình trách nhiệm chung

Nhà cung cấp thường chịu trách nhiệm

Bảo mật hạ tầng và nền tảng theo mô hình dịch vụ.
Patch, backup hoặc availability theo hợp đồng.
Tách tenant và bảo vệ dữ liệu ở lớp nền tảng.
Quản lý nhân viên có quyền vận hành.
Logging, incident response và chứng cứ kỹ thuật theo phạm vi.

Nhà máy vẫn phải chịu trách nhiệm

Phân loại dữ liệu và quyết định dữ liệu nào đưa lên.
Quản lý tài khoản, vai trò và quyền truy cập.
Chất lượng tài liệu và phiên bản.
Cấu hình chia sẻ, integration và data export.
Đào tạo người dùng và xử lý prompt/dữ liệu nhạy cảm.
Kiểm tra hợp đồng, retention và exit plan.

Không nên cho rằng mua dịch vụ cloud đồng nghĩa mọi trách nhiệm bảo mật đã chuyển cho nhà cung cấp.

III. Mười hai câu hỏi phải làm rõ với cloud

Dữ liệu được lưu ở quốc gia/data center nào?
Dữ liệu giữa các khách hàng có được tách biệt thế nào?
Dữ liệu có mã hóa khi truyền và khi lưu không?
Ai quản lý khóa mã hóa?
Nhà cung cấp và đối tác phụ nào có thể truy cập?
Có MFA, SSO và RBAC không?
Log truy cập, sửa, xuất và xóa dữ liệu được lưu bao lâu?
Backup ở đâu, tần suất và restore đã được kiểm thử chưa?
Có cơ chế cảnh báo truy cập bất thường không?
Khi xảy ra incident, thời gian thông báo và trách nhiệm là gì?
Khi kết thúc hợp đồng, dữ liệu được xuất, bàn giao và xóa thế nào?
Có API hoặc chức năng export đủ để tránh lock-in không?

Câu trả lời nên nằm trong tài liệu và hợp đồng, không chỉ ở slide bán hàng.

IV. Những câu hỏi riêng cho AI Copilot

Dữ liệu có được dùng để huấn luyện mô hình chung không?

Cần phân biệt việc gửi dữ liệu để xử lý một yêu cầu với việc dùng dữ liệu để huấn luyện/cải thiện mô hình. Nhà máy phải yêu cầu chính sách rõ và cấu hình hoặc cam kết phù hợp.

Prompt và câu trả lời có được lưu không?

Nếu có, cần biết mục đích, vị trí, retention, quyền truy cập và khả năng xóa. Prompt có thể chứa thông tin nhạy cảm dù tài liệu nguồn đã được bảo vệ.

AI có tuân theo phân quyền tài liệu không?

AI Copilot phải kiểm tra quyền ở thời điểm truy vấn. Người không có quyền xem SOP hoặc tài liệu thiết bị không nên nhận câu trả lời suy ra từ tài liệu đó.

AI có hiển thị nguồn không?

Nguồn giúp người dùng kiểm chứng, nhưng cũng có thể làm lộ tên tài liệu hoặc đoạn nội dung. Cần thiết kế citation theo quyền.

Dữ liệu được gửi đến mô hình nào và qua nhà cung cấp phụ nào?

Kiến trúc có thể gồm ứng dụng, vector database, model provider, storage và monitoring. Mỗi thành phần cần được đánh giá.

V. Permission-aware retrieval

Một AI Copilot an toàn không chỉ giới hạn giao diện. Luồng truy vấn nên:

Xác thực người dùng.
Xác định vai trò và phạm vi nhà máy/dây chuyền.
Chỉ truy xuất tài liệu người đó được phép xem.
Gửi lượng dữ liệu tối thiểu cần thiết đến mô hình.
Tạo câu trả lời có nguồn và cảnh báo giới hạn.
Ghi log truy vấn, nguồn và hành động phù hợp.

Nếu hệ thống index tất cả tài liệu vào một kho nhưng chỉ ẩn menu, nguy cơ rò rỉ qua câu trả lời vẫn còn.

VI. Các rủi ro thường gặp của AI Copilot

Trả lời dựa trên tài liệu cũ

SOP hết hiệu lực hoặc manual phiên bản cũ có thể dẫn đến hướng dẫn sai. Cần version control, effective date và owner cập nhật.

Prompt injection từ tài liệu hoặc người dùng

Tài liệu hoặc prompt có thể cố khiến hệ thống bỏ qua quy tắc. Cần giới hạn tool, lọc nguồn, phân quyền và kiểm thử adversarial.

Hallucination

AI có thể tạo câu trả lời nghe hợp lý nhưng không có trong tài liệu. Hệ thống nên ưu tiên grounded answer, biết từ chối và hiển thị nguồn.

Rò rỉ qua lịch sử trò chuyện

Một phiên chat dùng chung hoặc lưu không đúng scope có thể lộ thông tin. Cần session isolation và policy retention.

Quá nhiều quyền cho tích hợp

Service account có quyền đọc toàn bộ drive, database hoặc CMMS sẽ làm tăng blast radius. Dùng least privilege và scope theo use case.

VII. Kiểm soát tối thiểu cho AI Copilot nhà máy

Lớp	Kiểm soát
Identity	SSO/MFA, tài khoản cá nhân, session timeout
Authorization	RBAC/ABAC, scope nhà máy/dây chuyền, permission-aware retrieval
Data	Classification, minimization, encryption, retention
Knowledge	Version, owner, approval, effective date
Model	Chính sách training, provider, region, model version
Output	Citation, refusal, warning, human review
Logging	User, prompt, source, response, action, admin change
Monitoring	Unauthorized access, unusual usage, quality drift
Incident	Escalation, containment, notification, investigation
Exit	Export, deletion confirmation, revocation of access

Mức kiểm soát phải tăng theo độ nhạy cảm và rủi ro use case.

VIII. Data minimization: chỉ đưa vào phần cần thiết

Một lỗi phổ biến là kết nối toàn bộ thư mục hoặc database để “AI biết nhiều”. Cách an toàn hơn:

Chọn use case và nhóm người dùng cụ thể.
Chỉ index tài liệu đã duyệt.
Loại bỏ dữ liệu cá nhân hoặc bí mật không cần thiết.
Tách knowledge base theo nhà máy/bộ phận.
Giới hạn trường dữ liệu khi gọi API.
Đặt retention ngắn nhất phù hợp.

Ít dữ liệu hơn nhưng đúng phạm vi thường vừa an toàn vừa cải thiện chất lượng câu trả lời.

IX. Log gì và ai được xem log?

Log có thể gồm:

User, thời gian, IP/device.
Câu hỏi hoặc mã tham chiếu câu hỏi.
Tài liệu/record được truy xuất.
Model/version và cấu hình.
Câu trả lời, citation và confidence/quality marker.
Feedback của người dùng.
Hành động downstream nếu có.
Thay đổi admin, quyền và knowledge base.

Log cũng chứa dữ liệu nhạy cảm nên phải phân quyền, mã hóa và có retention. Không phải mọi quản trị viên đều cần xem toàn bộ nội dung prompt.

X. Kế hoạch sự cố và khôi phục

Trước khi go-live, cần xác định:

Ai nhận cảnh báo và trong bao lâu?
Có thể tắt AI hoặc thu hồi connector nhanh không?
Làm sao cô lập tài khoản bị lộ?
Có thể xác định dữ liệu nào đã bị truy cập không?
Có bản sao dữ liệu và cấu hình để phục hồi không?
Ai chịu trách nhiệm thông báo nội bộ/khách hàng theo yêu cầu?
Sau incident, bộ test và policy được cập nhật thế nào?

Security không hoàn chỉnh nếu chỉ có biện pháp phòng ngừa mà không có khả năng phát hiện và ứng phó.

XI. Exit plan trước khi ký hợp đồng

Nhà máy nên làm rõ:

Định dạng và phạm vi dữ liệu được xuất.
Có lấy được metadata, quyền, log và version không?
Thời gian cung cấp dữ liệu sau yêu cầu.
Chi phí export hoặc migration.
Thời gian nhà cung cấp còn giữ backup sau chấm dứt.
Chứng nhận hoặc xác nhận xóa dữ liệu.
Thu hồi tài khoản, API key và connector.
Cách chuyển knowledge base sang nền tảng khác.

Exit plan là một phần của bảo mật và continuity, không chỉ là điều khoản thương mại.

XII. Cách đánh giá nhà cung cấp

Bằng tài liệu

Security architecture.
Data flow diagram.
Subprocessor list.
Backup/DR policy.
Access control và audit log.
Incident response.
AI data usage policy.
Data export/deletion process.

Bằng demo kỹ thuật

Tạo hai role và chứng minh câu trả lời khác nhau theo quyền.
Xem audit log truy vấn và thay đổi admin.
Xóa tài liệu và kiểm tra nó không còn được truy xuất.
Thử tài khoản bị thu hồi quyền.
Thử câu hỏi không có nguồn và kiểm tra cơ chế từ chối.
Xuất một bộ dữ liệu mẫu.

Bằng pilot

Dùng dữ liệu thật đã giới hạn, người dùng thật và bộ câu hỏi thật. Không nên đưa dữ liệu critical vào ngay khi chưa kiểm soát được quyền và log.

XIII. Những dấu hiệu cảnh báo

Nhà cung cấp trả lời chung chung “dữ liệu được bảo mật tuyệt đối”.
Không mô tả model provider hoặc subprocessor.
Không có quyền theo tài liệu/record.
Không có audit log đủ chi tiết.
Không nói rõ dữ liệu có dùng để training không.
Không hỗ trợ export hoặc deletion confirmation.
Service account yêu cầu quyền quá rộng.
Không có quy trình incident và contact point.
Demo dùng tài liệu mẫu nhưng không kiểm tra phân quyền.

XIV. Checklist trước go-live

Dữ liệu đã được phân loại và phê duyệt chưa?
Knowledge base có owner và version không?
Quyền truy cập đã test theo persona chưa?
Có MFA/SSO và vòng đời tài khoản không?
Logging, retention và access review đã chốt chưa?
Chính sách model training và prompt retention đã rõ chưa?
Bộ test rò rỉ quyền và hallucination đã chạy chưa?
Có quy trình incident, kill switch và escalation không?
Exit plan và data deletion đã có trong hợp đồng chưa?
Người dùng đã được hướng dẫn không nhập dữ liệu ngoài phạm vi chưa?

XV. Câu hỏi thường gặp

AI có tự động học dữ liệu nhà máy và chia sẻ cho nơi khác không?

Không thể trả lời chung cho mọi dịch vụ. Điều này phụ thuộc chính sách, cấu hình và hợp đồng của model/provider. Nhà máy phải yêu cầu xác nhận rõ về training, retention và subprocessor.

Dùng server nội bộ có loại bỏ mọi rủi ro bảo mật không?

Không. On-premise vẫn cần identity, patch, backup, logging, network segmentation và người vận hành. Vị trí server chỉ là một yếu tố.

Có nên cho AI đọc toàn bộ tài liệu kỹ thuật để tăng độ chính xác?

Không nên mặc định. Chỉ đưa tài liệu đã duyệt, đúng phiên bản và đúng phạm vi người dùng. Chất lượng và quyền quan trọng hơn số lượng.

Bài viết này có thay thế đánh giá pháp lý hoặc tiêu chuẩn bảo mật không?

Không. Đây là khung quản trị thực hành. Yêu cầu pháp lý, hợp đồng và tiêu chuẩn phải được chuyên gia phù hợp kiểm tra theo ngành, khách hàng và quốc gia áp dụng.

Bài viết được biên tập từ ebook “Từ số hóa đến AI - Sổ tay chuẩn bị cho nhà máy”, Vietsoft, 06/2026.