Những rủi ro AI doanh nghiệp cần nhận diện và kiểm soát

Vì vậy, quản lý rủi ro AI hiệu quả không đồng nghĩa với cố gắng làm cho mô hình “không bao giờ sai”. Mục tiêu thực tế hơn là xác định AI có thể gây thiệt hại ở đâu, hậu quả nghiêm trọng đến mức nào, kiểm soát nào phải được đặt trước khi triển khai và khi nào bắt buộc phải có con người can thiệp.

NIST AI Risk Management Framework xem AI đáng tin cậy là hệ thống cần đồng thời đáp ứng các đặc tính như hợp lệ và đáng tin cậy, an toàn, bảo mật và khả năng phục hồi, có trách nhiệm và minh bạch, có khả năng giải thích, bảo vệ quyền riêng tư và kiểm soát thiên kiến gây hại. Điều đó cho thấy rủi ro AI là một bài toán quản trị đa chiều, không chỉ là vấn đề độ chính xác của thuật toán.

Rủi ro dữ liệu có thể làm AI sai ngay từ đầu

Dữ liệu là một trong những điểm phát sinh rủi ro sớm nhất. Một mô hình tốt vẫn có thể tạo kết quả không phù hợp nếu dữ liệu huấn luyện, dữ liệu truy xuất hoặc dữ liệu người dùng cung cấp không đại diện cho tình huống thực tế.

Có ba nhóm vấn đề doanh nghiệp cần tách biệt.

Chất lượng và tính đại diện của dữ liệu

Dữ liệu thiếu, lỗi thời hoặc lệch về một nhóm đối tượng có thể khiến mô hình hoạt động tốt trong môi trường thử nghiệm nhưng kém hiệu quả khi đưa vào vận hành.

Ví dụ, một hệ thống hỗ trợ tuyển dụng được xây dựng chủ yếu từ dữ liệu lịch sử của một nhóm nhân sự nhất định có thể học lại các mẫu lựa chọn trước đây. Nếu mẫu lịch sử chứa thiên kiến, việc tăng lượng dữ liệu không tự động loại bỏ thiên kiến đó.

Đây là lý do EU AI Act yêu cầu đối với các hệ thống AI rủi ro cao sử dụng dữ liệu huấn luyện, xác thực và kiểm thử phải có hoạt động quản trị dữ liệu phù hợp với mục đích sử dụng. Các yêu cầu bao gồm xem xét nguồn gốc dữ liệu, quy trình thu thập, tính đại diện và những thiên kiến có khả năng ảnh hưởng đến kết quả.

Dữ liệu nhạy cảm bị đưa vào AI ngoài kiểm soát

Một rủi ro khác xảy ra khi nhân viên nhập thông tin khách hàng, dữ liệu tài chính, tài liệu pháp lý, mã nguồn hoặc bí mật kinh doanh vào công cụ AI mà chưa xác định dữ liệu sẽ được xử lý và lưu giữ thế nào.

Rủi ro này khác với việc AI trả lời sai. Dù đầu ra hoàn toàn chính xác, doanh nghiệp vẫn có thể gặp sự cố nếu dữ liệu nhạy cảm đã đi qua một dịch vụ hoặc môi trường không được phép.

OWASP xếp Sensitive Information Disclosure vào nhóm rủi ro quan trọng của ứng dụng GenAI và cảnh báo rằng dữ liệu cá nhân, tài chính, hồ sơ sức khỏe, thông tin kinh doanh bí mật hoặc thông tin xác thực có thể bị lộ thông qua tương tác với LLM.

Doanh nghiệp vì thế cần phân loại dữ liệu trước khi phân loại công cụ AI. Một chatbot dùng cho nội dung marketing công khai và một trợ lý AI truy cập hồ sơ khách hàng không thể sử dụng cùng một mức kiểm soát.

Data poisoning làm sai dữ liệu mà AI tin tưởng

Đối với hệ thống sử dụng fine-tuning, RAG, embeddings hoặc nguồn dữ liệu bên ngoài, dữ liệu còn có thể bị cố ý thao túng.

Data poisoning xảy ra khi dữ liệu huấn luyện hoặc dữ liệu mà hệ thống sử dụng để tạo câu trả lời bị cài nội dung sai lệch, thiên kiến hoặc backdoor. OWASP lưu ý việc thao túng dữ liệu pre-training, fine-tuning hoặc embedding có thể làm suy giảm hiệu năng, tạo đầu ra thiên lệch hoặc phát sinh lỗ hổng bảo mật.

Biện pháp kiểm soát vì thế phải bao gồm provenance của dữ liệu, quyền sửa dữ liệu, quy trình duyệt nguồn và khả năng phát hiện thay đổi bất thường, thay vì chỉ kiểm tra mô hình ở thời điểm triển khai.

Sai lệch AI có thể biến dữ liệu lịch sử thành quyết định không công bằng

Bias không chỉ xuất phát từ một thuật toán “thiên vị”. Nó có thể hình thành ở nhiều lớp: cách lấy mẫu dữ liệu, nhãn dữ liệu, biến đầu vào, mục tiêu tối ưu hóa, cách đặt ngưỡng hoặc bối cảnh triển khai thực tế.

Một hệ thống có thể đạt độ chính xác tổng thể cao nhưng vẫn tạo tỷ lệ sai khác nhau đáng kể giữa các nhóm người dùng. Vì vậy, một KPI trung bình thường chưa đủ để chứng minh AI đang vận hành công bằng.

Doanh nghiệp cần kiểm tra ít nhất ba câu hỏi:

·         Những nhóm đối tượng nào chịu ảnh hưởng bởi quyết định của AI

·         Sai số có phân bố tương đương giữa các nhóm quan trọng hay không

·         Hậu quả của false positive và false negative có giống nhau hay không

Rủi ro đặc biệt lớn khi AI được dùng trong tuyển dụng, chấm điểm, phân bổ nguồn lực, định giá, phát hiện gian lận hoặc những quyết định có ảnh hưởng trực tiếp đến cá nhân.

NIST đưa tiêu chí “fair with harmful bias managed” vào các đặc tính của AI đáng tin cậy. EU AI Act cũng đặt chất lượng dữ liệu và giảm nguy cơ kết quả phân biệt đối xử vào nhóm kiểm soát quan trọng đối với hệ thống rủi ro cao.

Điểm cần tránh là coi fairness như một bài kiểm tra thực hiện một lần. Khi dữ liệu người dùng, hành vi thị trường hoặc quy trình kinh doanh thay đổi, phân bố đầu vào cũng thay đổi. Một mô hình từng vượt kiểm thử fairness vẫn có thể phát sinh bias sau khi vận hành.

Vì vậy, kiểm soát sai lệch phải bao gồm cả kiểm thử trước triển khai và giám sát sau triển khai.

AI có thể tạo câu trả lời thuyết phục nhưng sai

Với Generative AI, một rủi ro đáng chú ý là mô hình có thể tạo thông tin không chính xác dưới hình thức rất tự tin và mạch lạc.

Điều này nguy hiểm khi người dùng nhầm khả năng diễn đạt với độ tin cậy của nội dung.

Rủi ro tăng mạnh nếu đầu ra AI được dùng trực tiếp để:

·         Tư vấn khách hàng

·         Tạo báo cáo quản trị

·         Phân tích hợp đồng

·         Viết hoặc chạy mã

·         Đề xuất thay đổi cấu hình hệ thống

·         Hỗ trợ quyết định tài chính hoặc pháp lý

OWASP xem misinformation là một rủi ro cốt lõi của ứng dụng LLM. Vấn đề trở nên nghiêm trọng hơn khi tổ chức hoặc người dùng quá phụ thuộc vào đầu ra mà không có cơ chế xác minh độc lập.

Kiểm soát phù hợp không phải lúc nào cũng là “thêm human review”. Doanh nghiệp nên phân biệt đầu ra theo mức độ hậu quả.

Nội dung ít rủi ro có thể được kiểm tra bằng sampling. Đầu ra có ảnh hưởng lớn cần đối chiếu với nguồn được phê duyệt, validation rule hoặc chuyên gia có thẩm quyền. Các hành động không thể đảo ngược không nên chỉ dựa trên một phản hồi xác suất của mô hình.

Rủi ro bảo mật AI vượt ra ngoài bảo mật phần mềm truyền thống

Ứng dụng AI vẫn chịu các rủi ro quen thuộc như kiểm soát truy cập yếu, lộ credential hoặc dependency bị xâm nhập. Nhưng LLM còn tạo ra một số bề mặt tấn công mới.

OWASP GenAI LLM Top 10 2026 tiếp tục coi các vấn đề như prompt injection, sensitive information disclosure, supply-chain vulnerabilities, data/model poisoning và excessive agency là những rủi ro quan trọng đối với hệ thống GenAI.

Prompt injection có thể làm thay đổi hành vi của AI

Prompt injection xảy ra khi nội dung do người dùng hoặc nguồn bên ngoài cung cấp khiến mô hình bỏ qua hoặc làm sai lệch chỉ dẫn ban đầu.

Đáng chú ý, cuộc tấn công không nhất thiết phải nằm trong prompt người dùng nhập trực tiếp. Chỉ dẫn độc hại có thể được giấu trong website, tài liệu hoặc dữ liệu mà AI đọc.

Tùy quyền của hệ thống, prompt injection có thể dẫn tới lộ thông tin, thao túng đầu ra, truy cập chức năng trái phép hoặc kích hoạt hành động ngoài ý muốn.

Vì vậy, doanh nghiệp không nên xem prompt là một security boundary đáng tin cậy. Các quyền quan trọng vẫn cần được kiểm soát ở tầng ứng dụng và hạ tầng.

Excessive agency biến một câu trả lời sai thành một hành động sai

Rủi ro tăng mạnh khi AI không chỉ tư vấn mà còn được cấp quyền gửi email, sửa dữ liệu, chạy mã, tạo giao dịch hoặc điều khiển các dịch vụ khác.

OWASP mô tả excessive agency thường bắt nguồn từ ba yếu tố: quá nhiều chức năng, quá nhiều quyền hoặc quá nhiều quyền tự chủ. Khi đó, hallucination hoặc prompt injection không còn dừng ở một câu trả lời sai mà có thể trở thành hành động gây thiệt hại trực tiếp.

Nguyên tắc kiểm soát nên là least privilege cho AI:

·         Chỉ cấp công cụ cần cho nhiệm vụ

·         Chỉ cấp quyền dữ liệu cần thiết

·         Tách quyền đọc khỏi quyền ghi hoặc xóa

·         Yêu cầu phê duyệt với hành động có hậu quả lớn

·         Ghi log toàn bộ tool call quan trọng

·         Cho phép dừng hoặc thu hồi quyền nhanh chóng

AI càng có nhiều quyền hành động, yêu cầu kiểm soát càng phải cao.

Rủi ro trách nhiệm xuất hiện khi không biết ai chịu trách nhiệm cho quyết định của AI

Một vấn đề phổ biến trong triển khai AI là trách nhiệm bị phân tán.

Nhà cung cấp tạo mô hình. Đội công nghệ tích hợp mô hình. Một phòng ban lựa chọn use case. Nhân viên sử dụng đầu ra. Cuối cùng, một khách hàng hoặc bên thứ ba chịu hậu quả.

Nếu không xác định trước trách nhiệm, khi xảy ra sự cố rất dễ xuất hiện tình trạng mỗi bên cho rằng lỗi thuộc về hệ thống hoặc nhà cung cấp khác.

NIST coi accountability và transparency là những đặc tính nền tảng của AI đáng tin cậy. ISO/IEC 42001:2023 cũng tiếp cận rủi ro AI ở cấp hệ thống quản lý, yêu cầu tổ chức thiết lập, triển khai, duy trì và liên tục cải tiến cách quản lý AI thay vì chỉ kiểm soát từng mô hình riêng lẻ.

Doanh nghiệp nên xác định tối thiểu:

·         Ai là owner của use case

·         Ai chịu trách nhiệm phê duyệt triển khai

·         Ai theo dõi hiệu năng và sự cố

·         Ai quyết định dừng hệ thống

·         Ai xử lý khiếu nại hoặc hậu quả đối với người bị ảnh hưởng

·         Nhà cung cấp chịu trách nhiệm cho thành phần nào

·         Bằng chứng và log nào phải được giữ để truy vết quyết định

Human-in-the-loop chỉ có ý nghĩa khi người được giao kiểm tra có đủ thông tin, chuyên môn, quyền hạn và thời gian để thực sự bác bỏ quyết định của AI.

Một bước “Approve” mang tính hình thức không tạo ra accountability thực chất.

Không phải mọi ứng dụng AI đều có cùng mức rủi ro

Sai lầm thường gặp là áp dụng một bộ kiểm soát duy nhất cho tất cả AI.

Một trợ lý viết lại email nội bộ có mức hậu quả khác với hệ thống đề xuất tín dụng hoặc AI agent có quyền sửa cơ sở dữ liệu sản xuất.

Doanh nghiệp có thể đánh giá rủi ro dựa trên bốn biến chính:

1.    Mức độ nhạy cảm của dữ liệu

2.    Dữ liệu công khai khác với dữ liệu cá nhân, bí mật kinh doanh hoặc thông tin được quản lý đặc biệt

3.    Mức độ ảnh hưởng của đầu ra

4.    Một gợi ý có thể chỉnh sửa khác với quyết định trực tiếp ảnh hưởng đến quyền lợi của cá nhân

5.    Mức độ tự chủ của AI

6.    AI chỉ tạo nội dung khác với AI được phép gọi API hoặc thực hiện giao dịch

7.    Khả năng đảo ngược hậu quả

8.    Một bản nháp sai dễ sửa hơn một khoản thanh toán, quyết định tuyển dụng hoặc thao tác xóa dữ liệu

Mức kiểm soát cần tăng theo hậu quả tiềm tàng, không nhất thiết theo mức độ phức tạp của mô hình.

Đây cũng là logic của cách tiếp cận dựa trên rủi ro trong EU AI Act. Với hệ thống được phân loại là high-risk, quy định đặt ra các yêu cầu nghiêm ngặt về quản lý rủi ro, dữ liệu, logging, tài liệu, giám sát của con người, độ chính xác, robustness và cybersecurity.

Quản lý rủi ro AI phải diễn ra trong toàn bộ vòng đời

Kiểm tra AI ngay trước khi go-live là chưa đủ.

NIST AI RMF tổ chức quản trị rủi ro qua bốn chức năng Govern, Map, Measure và Manage. Govern tạo nền quản trị xuyên suốt; Map xác định bối cảnh và rủi ro; Measure đánh giá và theo dõi; Manage ưu tiên và xử lý rủi ro.

Trong thực tế, doanh nghiệp có thể chuyển nguyên tắc này thành một chu trình vận hành.

Govern: đặt người chịu trách nhiệm và luật sử dụng AI

Doanh nghiệp cần có danh mục các use case AI đang tồn tại, owner cụ thể, chính sách dữ liệu, tiêu chuẩn phê duyệt nhà cung cấp và cơ chế báo cáo sự cố.

Không có inventory, tổ chức khó quản lý những hệ thống AI mà chính mình không biết đang được sử dụng.

Map: hiểu AI được dùng ở đâu và ảnh hưởng đến ai

Trước khi triển khai, cần mô tả rõ mục đích, người dùng, dữ liệu đầu vào, các hệ thống được kết nối, nhóm người chịu ảnh hưởng và hậu quả nếu AI sai.

Cùng một mô hình có thể có mức rủi ro rất khác khi được đặt trong hai bối cảnh sử dụng khác nhau.

Measure: biến rủi ro thành tiêu chí có thể kiểm tra

Không nên chỉ ghi “mô hình phải chính xác” hoặc “AI phải công bằng”.

Cần xác định metric và ngưỡng phù hợp với use case, chẳng hạn:

·         Tỷ lệ lỗi tổng thể và theo từng nhóm đối tượng

·         Tỷ lệ hallucination trên bộ câu hỏi kiểm thử

·         Tỷ lệ truy xuất đúng nguồn

·         Tỷ lệ prompt injection vượt được guardrail

·         Số lần AI yêu cầu quyền ngoài phạm vi

·         Tỷ lệ quyết định cần human override

·         Số sự cố rò rỉ hoặc truy cập dữ liệu không phù hợp

Đối với hệ thống high-risk, EU AI Act cũng quy định việc kiểm thử phải sử dụng các metric và probabilistic threshold được xác định trước, phù hợp với mục đích dự kiến của hệ thống.

Manage: giảm rủi ro trước khi mở rộng AI

Kết quả đo lường phải dẫn đến hành động: giới hạn tính năng, bổ sung validation, giảm quyền truy cập, thay dữ liệu, tăng human oversight hoặc dừng triển khai.

Không phải rủi ro nào cũng cần loại bỏ hoàn toàn. Doanh nghiệp cần xác định mức residual risk có thể chấp nhận và ai có quyền chấp nhận mức rủi ro đó.

Quan trọng hơn, đánh giá phải lặp lại khi model, dữ liệu, prompt, công cụ tích hợp, phạm vi người dùng hoặc mục đích sử dụng thay đổi.

EU AI Act cũng mô tả quản lý rủi ro đối với hệ thống high-risk là một quy trình liên tục, lặp lại trong toàn bộ vòng đời và cần được xem xét, cập nhật thường xuyên.

Các lớp kiểm soát giúp giảm rủi ro AI trong doanh nghiệp

Không có một guardrail đơn lẻ có thể xử lý toàn bộ rủi ro AI. Kiểm soát hiệu quả thường cần nhiều lớp độc lập.

Ở lớp dữ liệu

·         Phân loại dữ liệu trước khi cho phép đưa vào AI

·         Giới hạn nguồn dữ liệu được phép sử dụng

·         Kiểm soát provenance, retention và quyền truy cập

·         Kiểm tra chất lượng và tính đại diện của dữ liệu

·         Tách dữ liệu sản xuất khỏi môi trường thử nghiệm khi cần thiết

Ở lớp mô hình và ứng dụng

·         Kiểm thử độ chính xác theo use case

·         Kiểm thử hallucination và failure case

·         Red-team prompt injection

·         Validation đầu ra trước khi truyền sang hệ thống khác

·         Giới hạn tool và quyền mà AI có thể gọi

Ở lớp con người

·         Định nghĩa rõ trường hợp bắt buộc human review

·         Huấn luyện người dùng về giới hạn của AI

·         Không để nhân viên mặc định tin đầu ra vì văn phong có vẻ thuyết phục

·         Trao quyền thực sự cho người giám sát để từ chối hoặc dừng hệ thống

Ở lớp quản trị

·         Có AI inventory và owner

·         Phân loại mức rủi ro theo use case

·         Lưu tài liệu về mục đích, dữ liệu và giới hạn hệ thống

·         Ghi log các quyết định và hành động quan trọng

·         Có quy trình incident response và tiêu chí dừng AI

ISO/IEC 42001 cung cấp một khung hệ thống quản lý để tổ chức cấu trúc hóa các hoạt động này, trong khi NIST AI RMF cung cấp mô hình quản trị rủi ro linh hoạt hơn. Hai cách tiếp cận có thể bổ trợ nhau thay vì loại trừ nhau.

Rủi ro pháp lý cần được đánh giá theo thị trường và trường hợp sử dụng

Rủi ro AI không chỉ phụ thuộc công nghệ mà còn phụ thuộc doanh nghiệp hoạt động ở đâu và AI được dùng vào mục đích gì.

Ví dụ, EU AI Act áp dụng cách tiếp cận dựa trên mức rủi ro và đặt yêu cầu khác nhau đối với từng nhóm hệ thống. Tính đến tháng 9/2026, các nghĩa vụ minh bạch theo Điều 50 đã bắt đầu áp dụng từ ngày 2/8/2026, trong khi nhiều nghĩa vụ đối với hệ thống high-risk dự kiến áp dụng từ ngày 2/12/2027.

Điều đó có hai ý nghĩa thực tế.

Thứ nhất, doanh nghiệp không nên đợi đến khi một hệ thống bị xác định là “AI rủi ro cao” mới xây governance. Inventory, logging, data governance và accountability cần được xây từ trước.

Thứ hai, compliance không đồng nghĩa với AI hoàn toàn an toàn. Quy định pháp lý đặt ra mức yêu cầu tối thiểu hoặc cụ thể cho từng trường hợp, trong khi doanh nghiệp vẫn phải tự đánh giá rủi ro vận hành, bảo mật và uy tín của mình.

Rủi ro AI không bắt đầu và kết thúc ở việc mô hình có trả lời đúng hay không. Dữ liệu kém có thể tạo quyết định lệch; dữ liệu nhạy cảm có thể bị lộ; prompt injection có thể thay đổi hành vi; quyền quá lớn có thể biến một đầu ra sai thành hành động sai; còn thiếu accountability khiến doanh nghiệp không thể kiểm soát hậu quả khi sự cố xảy ra.

Cách tiếp cận bền vững là quản lý use case AI như một hệ thống socio-technical gồm dữ liệu, mô hình, ứng dụng, người sử dụng, quyền truy cập và quy trình quản trị.

Doanh nghiệp nên bắt đầu từ câu hỏi: nếu AI này sai, bị thao túng hoặc được sử dụng ngoài dự kiến thì điều gì có thể xảy ra? Từ hậu quả đó mới xác định metric, quyền hạn, human oversight và kiểm soát phù hợp.

Mục tiêu cuối cùng không phải loại bỏ mọi rủi ro AI. Mục tiêu là bảo đảm tổ chức biết rủi ro nằm ở đâu, đo được mức độ của nó, có người chịu trách nhiệm và có khả năng can thiệp trước khi rủi ro vượt khỏi mức chấp nhận.