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 kiểm soát quản trị thành bằng chứng lúc chạy. Với đội ngũ kỹ thuật, MLOps và quản trị AI triển khai AI rủi ro cao hoặc AI mục đích chung, bằng chứng chỉ nằm trong slide sẽ là rủi ro khi kiểm toán yêu cầu chứng minh trực tiếp. 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. Đội ngũ cần tầng 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 đường đi của quyết định.

Điểm chuyển quản trị là ngày 2/8/2026, khi các nghĩa vụ minh bạch chủ yếu 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. Nghĩa vụ AI rủi ro cao hiện theo các 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ớ

• Minh bạch là mốc nghĩa vụ chính vào ngày 2/8/2026, không phải ngày thực thi phổ quát cho 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ụ độc lập theo Annex III chuyển sang ngày 2/12/2027, còn nghĩa vụ sản phẩm Annex I chuyển 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 khiến minh bạch trở thành nghĩa vụ production tức thời, trong khi nghĩa vụ rủi ro cao đến ở giai đoạn sau 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 hệ thống tương tác với con người phải làm rõ sự tương tác đó. Nhà cung cấp phù hợp cũng phải hỗ trợ nhận diện bằng máy đối với nội dung được tạo 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 tạo ra thời gian triển khai, không phải thời gian nhàn rỗi. Audit trail cần lịch sử vận hành. Người rà soát cần thực hành dùng kiểm soát dừng và ghi đè. Quy tắc giám sát cần sự cố thật và tín hiệu dương tính giả 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 muộn hơn như lý do để hoãn gắn đo lườ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 tạo hồi tố không thể tạo 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 mã định danh tương quan cho mọi request, workflow, lệnh gọi mô hình, lệnh gọi công cụ, phê duyệt và đầu ra.
• Lineage phiên bản: Ghi nhận mô hình, prompt, dataset, chỉ mục truy xuất, gói chính sách, mã điều phối và hợp đồng công cụ đã triển khai.
• Quản trị dữ liệu: Lưu provenance, quyết định lưu trú, 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 leo thang 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ữ theo kiểu chỉ thêm, đườ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 biến logging thành sao chép dữ liệu không kiểm soát. Hãy lưu tham chiếu hoặc biểu diễn được bảo vệ khi đầu vào đầy dữ liệu nhạy cảm. 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.

Lưu giữ không phải là hằng số kỹ thuật phổ quát. 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 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.

Phân phối 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 cần theo nhu cầu độ mới, khối lượng, khôi phục và truy vấn kiểm toán. Cùng 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ế không biến mô hình thành thẩm quyền lâm sàng cuối cùng. Nó làm cho ranh giới hệ thống có thể kiểm tra. 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ẫu kỹ thuật diễn đạt 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à:

định nghĩa chính sách -> kiểm thử triển khai -> thực thi runtime -> tạo bằng chứng -> rà soát của con người -> truy xuất kiểm toán -> cải tiến kiểm soát

Hợp đồng chính sách gọn có thể 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. Khi 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. Giám sát sau đó phát hiện hồ sơ thiếu, trôi chính sách, đánh giá thất bại và leo thang chưa được xử lý.

AI có thể giải thích cần dùng cùng đường bằng chứng. 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. Người rà soát chỉ có thể xác nhận kết quả 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 đè, leo thang 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 công cụ nào mặc định cung cấp 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 chi phí, độ trễ, ngân sách token, khả năng quan sát và đánh giá cùng nhau. Workflow có thể vượt kiểm thử chất lượng nhưng 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 công cụ, lần thử lại, đường dự phòng và kết quả leo thang. 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à chuyển tuyến 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à máy chủ MCP. 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ị.
• [ ] Gắn đo lường cho 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 đè, leo thang, dự phòng 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ư mới và giả định log cloud chung chung tạo ra 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 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. Đây không phải tất cả là yêu cầu pháp lý độc lập. 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à leo thang tới 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

Phản hồi bền vững trước lộ trình triển khai 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, gắn đo lường 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 bằng chứng của nó trở nên trực tiếp, có thể truy vấn và có chủ sở hữu.