Cách xác định trách nhiệm của nhiều chủ thể công nghệ

Vì vậy, cách phân chia hợp lý là gắn trách nhiệm với vai trò thực tế, quyền kiểm soát, phần đóng góp và quyết định mà mỗi chủ thể có khả năng tác động. NIST AI RMF cũng tiếp cận theo vòng đời, trong đó các nhóm chủ thể khác nhau đảm nhiệm các công việc từ thiết kế, phát triển, kiểm thử, triển khai đến vận hành và giám sát.

Trách nhiệm được xác định theo vai trò và điểm kiểm soát

Nguyên tắc cốt lõi là không mặc định một chủ thể phải chịu toàn bộ trách nhiệm chỉ vì họ là nhà cung cấp hoặc chủ sở hữu công nghệ.

Có thể phân tích theo bốn câu hỏi:

1.    Chủ thể đã làm gì đối với công nghệ?

2.    Chủ thể kiểm soát phần nào của hệ thống hoặc quy trình?

3.    Chủ thể có quyền quyết định đối với rủi ro đang xảy ra hay không?

4.    Chủ thể có nghĩa vụ kiểm tra, cảnh báo hoặc khắc phục vấn đề đó hay không?

Từ đó, trách nhiệm thường được phân bổ theo chuỗi:

Thiết kế → phát triển → kiểm thử → tích hợp → triển khai → vận hành → giám sát

Một chủ thể có thể chịu trách nhiệm chính ở một giai đoạn nhưng chỉ có trách nhiệm hỗ trợ ở giai đoạn khác. NIST mô tả rõ sự tham gia của các nhóm như nhà thiết kế, nhà phát triển, bên tích hợp, người triển khai, người vận hành, chuyên gia đánh giá và kiểm toán trong các giai đoạn khác nhau của vòng đời hệ thống.

Điều này cũng có nghĩa trách nhiệm có thể chồng lên nhau nhưng nhiệm vụ không nên bị bỏ trống. Nếu nhiều bên cùng có quyền kiểm soát một rủi ro, cần xác định ai là người ra quyết định cuối cùng, ai có nghĩa vụ thực hiện và ai phải cung cấp thông tin hoặc hỗ trợ.

Nhà phát triển, nhà cung cấp và bên tích hợp chịu trách nhiệm về phần mình kiểm soát

Chủ thể phát triển công nghệ thường kiểm soát các yếu tố kỹ thuật như kiến trúc, mã nguồn, mô hình, thuật toán, cấu hình hoặc quy trình kiểm thử. Trách nhiệm của họ vì thế tập trung vào việc hệ thống được thiết kế và phát triển phù hợp với mục đích đã xác định, có giới hạn được nhận diện và có cơ chế kiểm tra cần thiết.

Bên cung cấp dữ liệu có trách nhiệm khác. Nếu dữ liệu đầu vào có vấn đề, chẳng hạn thiếu tính đại diện hoặc không phù hợp với mục đích sử dụng, trách nhiệm có thể nằm ở khâu dữ liệu thay vì toàn bộ thuộc về nhà phát triển công nghệ.

Bên tích hợp lại kiểm soát một điểm khác: cách các thành phần được kết nối với hệ thống thực tế. Một thành phần riêng lẻ có thể hoạt động đúng nhưng khi tích hợp với hệ thống khác lại tạo ra rủi ro mới. Vì vậy, trách nhiệm kiểm tra khả năng tương thích, cấu hình và điều kiện triển khai không thể tự động chuyển hết cho nhà phát triển ban đầu.

NIST cũng phân biệt các nhiệm vụ xây dựng mô hình với kiểm thử, xác minh và xác nhận; đồng thời xem việc tách biệt một số chức năng đánh giá khỏi nhóm xây dựng hệ thống là một thực hành hữu ích.

Bên triển khai và vận hành chịu trách nhiệm về cách công nghệ được sử dụng

Một công nghệ không tồn tại trong môi trường trừu tượng. Khi được đưa vào hoạt động, bên triển khai thường quyết định những vấn đề mà nhà phát triển không thể kiểm soát hoàn toàn: mục đích sử dụng cụ thể, người sử dụng, dữ liệu thực tế, quy trình nghiệp vụ, mức độ giám sát của con người và cách xử lý khi hệ thống hoạt động bất thường.

Do đó, trách nhiệm của bên triển khai và vận hành thường bao gồm:

·         Sử dụng công nghệ đúng mục đích và điều kiện đã xác định

·         Kiểm soát dữ liệu đầu vào thuộc phạm vi mình quản lý

·         Bố trí người có đủ năng lực để giám sát khi cần

·         Theo dõi hoạt động và kết quả của hệ thống

·         Phát hiện, ghi nhận và thông báo sự cố

·         Dừng hoặc điều chỉnh việc sử dụng khi xuất hiện rủi ro đáng kể

NIST xác định triển khai và vận hành là những giai đoạn có các chủ thể riêng, trong đó người triển khai, người vận hành và người sử dụng có trách nhiệm đối với bối cảnh sử dụng và tác động phát sinh trong thực tế.

Đối với hệ thống AI có rủi ro cao, EU AI Act còn quy định cụ thể nghĩa vụ của bên triển khai, như bảo đảm sử dụng theo hướng dẫn, bố trí giám sát của con người, theo dõi hoạt động và xử lý hoặc báo cáo khi nhận thấy rủi ro.

Trách nhiệm có thể thay đổi khi một chủ thể thay đổi công nghệ hoặc mục đích sử dụng

Một điểm dễ bị bỏ qua là vai trò pháp lý hoặc trách nhiệm của một chủ thể có thể thay đổi theo hành động của chính họ.

Ví dụ, trong EU AI Act, một nhà phân phối, nhà nhập khẩu, bên triển khai hoặc bên thứ ba trong một số trường hợp có thể bị xem là nhà cung cấp hệ thống AI rủi ro cao. Điều này có thể xảy ra khi họ đưa hệ thống ra thị trường dưới tên hoặc nhãn hiệu của mình, thực hiện thay đổi đáng kể đối với hệ thống hoặc thay đổi mục đích sử dụng khiến hệ thống trở thành hệ thống AI rủi ro cao.

Điểm quan trọng ở đây không phải là áp dụng quy định của EU cho mọi công nghệ, mà là nhận diện một nguyên tắc rộng hơn: trách nhiệm phải được đánh giá theo hành vi và mức độ kiểm soát thực tế, không chỉ theo tên gọi của các bên trong hợp đồng.

Vì vậy, khi phân tích một trường hợp cụ thể, cần kiểm tra cả:

·         Vai trò được ghi nhận ban đầu

·         Quyền kiểm soát thực tế

·         Các thay đổi mà chủ thể đã thực hiện

·         Mục đích sử dụng cuối cùng

·         Quyền quyết định đối với dữ liệu, cấu hình và vận hành

·         Nghĩa vụ theo hợp đồng và quy định pháp luật áp dụng

Khi nhiều bên cùng góp phần tạo ra một rủi ro, không nên mặc định trách nhiệm thuộc về một bên duy nhất

Một sự cố công nghệ có thể hình thành từ nhiều mắt xích. Chẳng hạn, nhà phát triển tạo ra một giới hạn kỹ thuật, bên tích hợp cấu hình hệ thống sai, bên triển khai đưa hệ thống vào một bối cảnh ngoài dự kiến và người vận hành không thực hiện quy trình giám sát.

Trong trường hợp này, cần truy ngược chuỗi nguyên nhân và quyền kiểm soát thay vì chỉ tìm một “chủ thể chịu trách nhiệm”.

Có thể sử dụng ma trận sau:

NIST nhấn mạnh rằng các chủ thể trong vòng đời thường không có đầy đủ khả năng quan sát hoặc kiểm soát các giai đoạn khác. Chính sự phụ thuộc lẫn nhau này có thể khiến quyết định ở một giai đoạn ảnh hưởng đến rủi ro ở giai đoạn khác.

Do đó, phân chia trách nhiệm không đồng nghĩa với chia đều trách nhiệm. Mỗi bên cần chịu phần trách nhiệm tương ứng với khả năng tác động và kiểm soát của mình; đồng thời phải có cơ chế phối hợp khi rủi ro nằm ở điểm giao giữa nhiều bên.

Cách lập ma trận trách nhiệm để tránh khoảng trống hoặc đùn đẩy

Một cơ chế thực tế là lập ma trận trách nhiệm theo vòng đời công nghệ. Với mỗi hoạt động, cần xác định ít nhất bốn yếu tố: ai thực hiện, ai chịu trách nhiệm cuối cùng, ai phải được tham vấn và ai cần được thông báo.

Ví dụ:

NIST AI RMF yêu cầu vai trò, trách nhiệm và tuyến thông tin liên lạc liên quan đến quản trị rủi ro được xác định rõ; đồng thời nhấn mạnh trách nhiệm của lãnh đạo đối với các quyết định về rủi ro trong phát triển và triển khai AI.

Một ma trận tốt phải trả lời được câu hỏi “nếu xảy ra vấn đề ở bước này, ai có quyền hành động và ai có nghĩa vụ hành động?” Nếu không xác định được câu trả lời, đó là dấu hiệu còn khoảng trống trách nhiệm.

Về mặt quản trị, các thỏa thuận giữa các bên cũng nên quy định rõ quyền tiếp cận thông tin, dữ liệu, khả năng kỹ thuật và hỗ trợ cần thiết để mỗi bên thực hiện nghĩa vụ của mình. EU AI Act là một ví dụ cho cách tiếp cận này khi yêu cầu trong một số quan hệ chuỗi giá trị phải xác định bằng văn bản các thông tin, năng lực, quyền tiếp cận kỹ thuật và hỗ trợ cần thiết.

Trách nhiệm của nhiều chủ thể công nghệ vì vậy nên được xác định theo vai trò thực tế quyền kiểm soát mức độ đóng góp quyền quyết định nghĩa vụ giám sát và khắc phục. Không nên dùng một tiêu chí duy nhất như quyền sở hữu, tên gọi “nhà cung cấp” hay vị trí trong hợp đồng để quy toàn bộ trách nhiệm cho một bên.

Cách tiếp cận an toàn hơn là lập bản đồ trách nhiệm xuyên suốt vòng đời công nghệ, xác định rõ người thực hiện, người chịu trách nhiệm cuối cùng, quyền kiểm soát và cơ chế phối hợp ở từng điểm. Đây cũng là cách giảm hai rủi ro đối lập: một bên phải gánh trách nhiệm vượt quá khả năng kiểm soát, trong khi một rủi ro khác lại không có chủ thể chịu trách nhiệm rõ ràng.