Tuân thủ EU AI Act trong vận hành: Pipeline có thể kiểm toán

Tuân thủ EU AI Act trong production nghĩa là biến các kiểm soát quản trị thành bằng chứng được tạo ra ngay khi hệ thống chạy. Với các đội kỹ thuật, MLOps và quản trị AI đang triển khai AI rủi ro cao hoặc AI mục đích chung, bằng chứng chỉ nằm trên slide sẽ trở thành rủi ro khi kiểm toán yêu cầu chứng minh trên hệ thống thật. Hướng dẫn này cung cấp thiết kế pipeline có thể kiểm toán, checklist Compliance as Code và runbook sẵn sàng cho giai đoạn minh bạch hiện tại cùng các giai đoạn AI rủi ro cao tiếp theo.

Tại Van Data Team, chúng tôi bắt đầu bằng việc lập bản đồ quyết định, dữ liệu, công cụ, điểm bàn giao và chủ sở hữu chịu trách nhiệm. Những đội ngũ cần lớp vận hành này có thể dùng quy trình AI agent production của chúng tôi để kết nối pipeline dữ liệu, cổng rà soát và báo cáo với chính luồng ra quyết định.

Mốc chuyển đổi về quản trị là ngày 2/8/2026, khi phần lớn nghĩa vụ minh bạch bắt đầu áp dụng. Nghĩa vụ cho mô hình AI mục đích chung đã áp dụng từ ngày 2/8/2025. Các nghĩa vụ với AI rủi ro cao hiện được lùi sang những giai đoạn muộn hơn. Bài viết này là hướng dẫn kỹ thuật, không phải tư vấn pháp lý. Hãy xác nhận phân loại, vai trò và nghĩa vụ của bạn với luật sư.

Điểm chính cần nhớ

• Ngày 2/8/2026 là mốc chính cho các nghĩa vụ minh bạch, không phải ngày thực thi chung cho mọi hệ thống AI rủi ro cao.
• Nghĩa vụ nhà cung cấp GPAI đã áp dụng từ ngày 2/8/2025.
• Nghĩa vụ với hệ thống độc lập theo Annex III lùi sang ngày 2/12/2027, còn nghĩa vụ với sản phẩm theo Annex I lùi sang ngày 2/8/2028.
• Bằng chứng tuân thủ cần được tạo liên tục qua log, lineage, đánh giá, quyết định truy cập và rà soát của con người.
• Mức phạt có thể lên tới 35 triệu EUR hoặc 7% doanh thu toàn cầu hằng năm, tùy mức nào cao hơn.

Lộ trình tuân thủ EU AI Act: yêu cầu nào đang áp dụng

Mốc tháng 8 biến minh bạch thành nghĩa vụ production cần xử lý ngay, trong khi các nghĩa vụ rủi ro cao đến muộn hơn theo lịch đã sửa đổi.

Thông tin được dẫn nguồn: Theo lộ trình thực thi của Data Protection Report, nhà cung cấp các hệ thống tương tác với con người phải cho người dùng biết rõ họ đang tương tác với AI. Các nhà cung cấp thuộc phạm vi điều chỉnh cũng phải hỗ trợ để máy có thể nhận diện nội dung do AI tạo ra hoặc chỉnh sửa. Bên triển khai có nghĩa vụ với deepfake, nhận diện cảm xúc và phân loại sinh trắc học trong các bối cảnh áp dụng.

Lộ trình nên được trình bày như sau:

Trách nhiệm của nhà cung cấp và bên triển khai khác nhau. Nhà cung cấp có thể sở hữu thiết kế mô hình, tài liệu, khả năng logging và kiểm soát phát hành. Bên triển khai có thể kiểm soát đầu vào, quy trình vận hành, giám sát, thông báo cho người lao động và giám sát của con người. Một công ty có thể giữ các vai trò khác nhau trong những workflow riêng biệt.

Phân tích của Van Data Team: Việc lùi thời hạn cho thêm thời gian để triển khai, không phải thời gian để ngồi chờ. Audit trail cần có lịch sử vận hành. Người rà soát cần được thực hành với các nút dừng và ghi đè. Quy tắc giám sát cần được kiểm chứng qua sự cố thật và các cảnh báo false positive trước khi đội ngũ có thể tin cậy.

Sai lầm chúng tôi thường thấy là coi hạn chót muộn hơn là lý do để hoãn việc instrument hệ thống. Việc bổ sung lineage sau khi mô hình, prompt hoặc dataset thay đổi hiếm khi tái dựng được quyết định ban đầu với đủ độ tin cậy.

Pipeline AI có thể kiểm toán biến quản trị thành bằng chứng trực tiếp

Pipeline AI có thể kiểm toán liên kết mọi quyết định chịu quản trị với dữ liệu, phiên bản hệ thống, kiểm tra chính sách, hoạt động công cụ và hành động con người chịu trách nhiệm.

Điểm neo kỹ thuật là yêu cầu lưu hồ sơ tại Article 12. Nghĩa vụ này thuộc khung rủi ro cao sẽ đến ở các giai đoạn sau, nhưng đã đặt ra hướng thiết kế rõ ràng hôm nay. Tài liệu soạn lại sau sự việc không thể tạo ra bằng chứng runtime chưa từng được ghi nhận.

Văn bản AI Act chính thức nêu:

"Hệ thống AI rủi ro cao phải cho phép về mặt kỹ thuật việc tự động ghi nhận các sự kiện (log) trong suốt vòng đời của hệ thống."

Triển khai production cần có các lớp liên kết sau:

• Danh tính thực thi: Gán correlation ID cho mọi request, workflow, lời gọi mô hình, lời gọi công cụ, phê duyệt và đầu ra.
• Lineage phiên bản: Ghi nhận mô hình, prompt, dataset, retrieval index, gói chính sách, code điều phối và contract của công cụ đã triển khai.
• Quản trị dữ liệu: Lưu provenance, quyết định về data residency, kiểm tra độ mới, kết quả chất lượng và kết quả truy cập theo đặc quyền tối thiểu.
• Giám sát của con người: Lưu người rà soát, quyết định, lý do, trạng thái chuyển cấp và việc dùng quyền dừng hoặc ghi đè.
• Bằng chứng chống sửa đổi: Bảo vệ hồ sơ bằng lưu trữ append-only, đường sửa đổi bị hạn chế, kiểm tra tính toàn vẹn và lưu giữ có kiểm soát.
• Truy xuất bằng chứng: Cho phép người rà soát được ủy quyền truy vấn một quyết định và xuất gói bằng chứng mà không phải dựng lại từ ticket.

Đừng để logging biến thành việc sao chép dữ liệu tràn lan. Khi đầu vào chứa nhiều dữ liệu nhạy cảm, hãy lưu tham chiếu hoặc dạng biểu diễn đã được bảo vệ. Schema bằng chứng phải cho thấy dữ liệu nào được dùng, từ đâu, ai truy cập và chính sách lưu giữ nào áp dụng.

Thời hạn lưu giữ không phải một hằng số kỹ thuật áp dụng cho mọi trường hợp. Thời hạn đúng phụ thuộc vào hệ thống, vai trò tổ chức, mục đích dự kiến, luật áp dụng và chính sách được luật sư phê duyệt. Pipeline cần thực thi lớp lưu giữ đã phê duyệt, đồng thời ghi nhận sự kiện xóa hoặc legal hold.

Hướng dẫn của Google Cloud về hạ tầng y tế số được quản lý mô tả kiểm soát lập trình được, audit trail tự động, lưu giữ số và một evidence plane cho phần mềm được quản lý. Đây là quan điểm kiến trúc cloud hữu ích, không phải bằng chứng cho thấy một workload đã tuân thủ. Hướng dẫn kiến trúc này cũng cần được đọc cùng lộ trình rủi ro cao đã sửa đổi.

Việc chuyển sự kiện kiểm toán có thể dùng streaming để phát hiện nhanh, hoặc xử lý batch cho khối lượng bằng chứng ít khẩn cấp hơn. Lựa chọn nên dựa trên nhu cầu về độ mới, khối lượng, khả năng khôi phục và truy vấn kiểm toán. Logic vận hành khi chọn mô hình nạp sự kiện kiểm toán cũng áp dụng ở đây.

Thiết kế tham chiếu cho hệ thống hỗ trợ quyết định lâm sàng

Minh họa sau tóm tắt một quyết định với bằng chứng đầy đủ:

Workflow y tế minh họa này cho thấy bằng chứng có thể đi cùng một quyết định được quản trị như thế nào. Đây là phân tích của Van Data Team, không phải câu chuyện khách hàng hoặc khẳng định hệ thống được phân loại pháp lý.

Thiết kế này không biến mô hình thành bên có thẩm quyền lâm sàng cuối cùng. Nó giúp ranh giới của hệ thống có thể kiểm tra được. Kiểm toán viên có thể xác định dữ liệu và phần mềm nào định hình đầu ra, liệu có rà soát hay không, và điều gì xảy ra sau khi kiểm soát thất bại.

Compliance as Code biến kiểm soát thành cơ chế có thể thực thi

Compliance as Code là một pattern kỹ thuật thể hiện yêu cầu quản trị dưới dạng chính sách có thể kiểm thử, cổng triển khai, quy tắc runtime và schema bằng chứng.

Đây không phải sản phẩm của một nhà cung cấp. Nó cũng không thay thế diễn giải pháp lý. Luật sư và chủ sở hữu quản trị chịu trách nhiệm xác định nghĩa vụ, còn kỹ thuật biến kiểm soát đã phê duyệt thành hành vi hệ thống lặp lại được.

Vòng vận hành là:

policy definition -> deployment test -> runtime enforcement -> evidence generation -> human review -> audit retrieval -> control improvement

Một policy contract gọn có thể trông như sau:

control_id: governed_ai_execution
applies_when: regulated_decision_or_governed_data
requires:
  - correlated_trace
  - approved_versions
  - access_decision
  - evaluation_result
  - human_review_state
on_missing_evidence:
  action: block_or_escalate
  owner: ai_governance

Trong CI/CD, chính sách có thể chặn mô hình, prompt, dataset, công cụ hoặc thay đổi kiểm soát chưa được phê duyệt. Ở runtime, cùng chính sách đó có thể từ chối truy cập trái phép, yêu cầu công bố hoặc chuyển quyết định sang rà soát. Sau đó, hệ thống giám sát phát hiện hồ sơ bị thiếu, policy drift, đánh giá thất bại và các yêu cầu chuyển cấp chưa được xử lý.

AI có khả năng giải thích (explainable AI) cũng cần dùng chung đường bằng chứng này. Hồ sơ phải xác định cơ sở quyết định, đầu vào liên quan, nguồn được truy xuất, phiên bản hệ thống, kết quả kiểm soát, độ bất định và lý do của người rà soát. Nó không nên phụ thuộc vào việc phơi bày hoặc giữ lại chain-of-thought riêng tư của mô hình.

Giám sát của con người cũng cần thẩm quyền vận hành. Một người rà soát chỉ có quyền xác nhận kết quả thì không phải là một kiểm soát hiệu quả. Hãy xác định ai có thể phê duyệt, từ chối, dừng, ghi đè, chuyển cấp và kích hoạt rollback. Hướng dẫn về AI agent có vòng rà soát của con người của chúng tôi chỉ cách đặt các quyết định đó vào workflow.

Framework agent cần kiểm soát tại mọi ranh giới

LangGraph, LangChain, CrewAI, native function calling, MCP và Plan-and-Execute có thể điều phối công việc phức tạp, nhưng không framework nào mặc nhiên mang lại sự tuân thủ.

Framework chỉ là một lớp. Một agent được quản trị đi qua ranh giới mô hình, trạng thái, công cụ, dữ liệu, chính sách và con người. Mỗi ranh giới cần danh tính có thể truy vết, quyết định cấp quyền, kết quả và đường khôi phục chịu trách nhiệm.

Giám sát production phải bao quát đồng thời chi phí, độ trễ, ngân sách token, observability và đánh giá. Một workflow có thể qua được kiểm thử chất lượng nhưng lại vượt ngân sách vận hành. Nó cũng có thể vẫn nhanh trong khi âm thầm mất hồ sơ tool call hoặc dùng dữ liệu cũ.

Theo dõi phiên bản prompt và mô hình, quyền dùng công cụ, số lần retry, đường fallback và kết quả chuyển cấp. Kết nối các trace đó với lineage dữ liệu, độ mới và trạng thái SLA. Đánh giá cần bao quát mục đích dự kiến, độ bền vững, hành vi công bố, chính sách truy cập, lạm dụng công cụ và việc định tuyến tới người rà soát.

Hãy xét một agent tuyển dụng giả định xây bằng native function calling và MCP server. Nó truy xuất hồ sơ ứng viên, chấm tiêu chí công việc và gửi khuyến nghị để rà soát. Chỉ ghi log khuyến nghị cuối sẽ để lại lỗ hổng lớn. Bằng chứng cần có phiên bản dữ liệu được quản trị, kết quả truy xuất, chính sách chấm điểm, ủy quyền công cụ, phiên bản mô hình, quyết định rà soát và mọi ghi đè.

Chạy quy trình đánh giá mức sẵn sàng trước khi có yêu cầu kiểm toán

Bài đánh giá mức sẵn sàng phải chứng minh tổ chức có thể truy vết, giải thích, dừng và xuất bằng chứng cho một lượt thực thi production thực tế.

Hãy dùng runbook này:

• [ ] Lập danh mục hệ thống AI, mô hình GPAI, agent, công cụ, dataset, mục đích dự kiến, chủ sở hữu và khu vực triển khai.
• [ ] Xác lập phân loại, vai trò nhà cung cấp hoặc bên triển khai và nghĩa vụ áp dụng với luật sư.
• [ ] Xác định hợp đồng bằng chứng cho mọi workflow có thể tác động đến kết quả được quản trị.
• [ ] Instrument lineage dữ liệu, công bố, đánh giá, tool call, quyết định truy cập và hành động con người.
• [ ] Diễn đạt kiểm soát phát hành và runtime thành chính sách theo phiên bản.
• [ ] Kiểm thử truy cập bị từ chối, log thiếu, đánh giá thất bại, ghi đè, chuyển cấp, fallback và rollback.
• [ ] Chạy kiểm toán giả lập bằng bằng chứng production thay vì ảnh chụp màn hình chuẩn bị sẵn.
• [ ] Chỉ định chủ sở hữu khắc phục và lặp lại sau thay đổi đáng kể về mô hình, dữ liệu, chính sách hoặc workflow.

Các lỗi thường gặp gồm dùng ngày rủi ro cao ban đầu làm hạn hiện tại, trình bày nghĩa vụ GPAI như thể mới xuất hiện và cho rằng log cloud chung chung là đủ để tuân thủ. Những khoảng trống khác gồm mất lineage prompt, bỏ qua hành động công cụ của agent hoặc tạo hàng đợi rà soát mà không có thẩm quyền dừng.

Kiểm toán giả lập đạt khi người rà soát có thể truy vết một quyết định được lấy mẫu từ đầu đến cuối. Họ cần tái tạo được manifest phiên bản, xác minh truy cập và công bố, tìm ra các can thiệp của con người và kiểm tra lỗi kiểm soát. Đội ngũ cũng cần chứng minh cảnh báo tính toàn vẹn bằng chứng, hành vi rollback và thao tác xuất không yêu cầu tái dựng thủ công.

Với hệ thống agent, hãy đưa chi phí, độ trễ, mức dùng token, độ mới dữ liệu, kết quả chính sách và kết quả đánh giá vào góc nhìn kiểm toán. Không phải tất cả đều là yêu cầu pháp lý riêng. Chúng là tín hiệu vận hành giúp giải thích hành vi hệ thống, xác định drift và cho thấy kiểm soát còn hoạt động trước áp lực production hay không.

Van Data Team có thể mở rộng việc này thành danh mục workflow, bản đồ hợp đồng bằng chứng, dashboard khoảng trống kiểm soát, thiết kế rà soát của con người, báo cáo kiểm toán giả lập và kế hoạch bàn giao. Đội ngũ xây đường dừng và khôi phục cũng có thể dùng playbook vận hành agent production và chuyển cấp cho con người.

Kết luận: biến bằng chứng thành đầu ra của hệ thống vận hành

Cách ứng phó bền vững với lộ trình áp dụng theo giai đoạn là biến bằng chứng tuân thủ thành đầu ra bình thường của mọi lượt thực thi được quản trị.

Minh bạch áp dụng từ ngày 2/8/2026. Nghĩa vụ nhà cung cấp GPAI đã áp dụng từ ngày 2/8/2025. Nghĩa vụ rủi ro cao hiện đến qua các giai đoạn Annex III và Annex I muộn hơn. Lịch này cho đội ngũ thời gian xây kiểm soát mạnh hơn, nhưng chỉ khi triển khai bắt đầu trước lúc bằng chứng trở nên cấp thiết.

Tuân thủ EU AI Act trở thành vận hành khi đội ngũ có thể truy vết một quyết định, giải thích cơ sở đã phê duyệt, xác minh phiên bản dữ liệu và hệ thống, cho thấy thẩm quyền con người và chứng minh điều gì xảy ra sau thất bại.

Van Data Team có thể biến mục tiêu đó thành phạm vi triển khai gồm hợp đồng bằng chứng, instrument pipeline, cổng chính sách, workflow rà soát, dashboard kiểm toán và runbook khôi phục. Hãy bắt đầu với workflow có hệ quả cao nhất, sau đó làm cho bằng chứng của workflow đó luôn sẵn có, truy vấn được và có người chịu trách nhiệm.