Benchmark Legal AI: 8 tiêu chí pháp lý cần kiểm thử trước khi mua

Một buổi trình diễn tốt chỉ cho thấy công cụ hoạt động trong tình huống do nhà cung cấp lựa chọn. Trước khi mua hoặc mở rộng phạm vi, tổ chức cần một benchmark độc lập dựa trên công việc thật, dữ liệu được kiểm soát và tiêu chí đạt hoặc không đạt được thống nhất trước.

1. Tám tiêu chí phải gắn với nghĩa vụ pháp luật

Độ đúng của kết luận và hiệu lực phải bám các Điều 53–58 Luật số 64/2025/QH15. Quản trị dữ liệu, nhật ký và giám sát phải được đối chiếu với Điều 14 Luật Trí tuệ nhân tạo. Khả năng minh bạch và cảnh báo phải kiểm tra theo Điều 11; xử lý sự cố theo Điều 12; bảo vệ dữ liệu cá nhân theo các Điều 3, 21, 23, 30 và 37 Luật số 91/2025/QH15. Khi mỗi tiêu chí được nối với một nghĩa vụ cụ thể, tổ chức có thể xác định lỗi nào chỉ làm giảm tiện ích và lỗi nào có thể dẫn tới không tuân thủ hoặc thiệt hại.

2. Thiết kế lỗi loại trừ trước khi chạy pilot

Điều 7 Luật Trí tuệ nhân tạo cấm dùng AI cho hành vi trái luật, xử lý dữ liệu trái pháp luật, vô hiệu hóa giám sát con người và che giấu thông tin bắt buộc. Vì vậy, benchmark nên quy định lỗi loại trừ như bịa số hiệu hoặc điều khoản; tiết lộ dữ liệu của nhóm khác; bỏ qua yêu cầu dừng; không cho người có thẩm quyền can thiệp; hoặc dùng dữ liệu kiểm thử cho mục đích khác. Nếu xuất hiện lỗi loại trừ, pilot phải dừng để phân tích nguyên nhân thay vì tiếp tục tính điểm trung bình.

3. Quyết định mua và nghĩa vụ sau khi mua

Điều 10 yêu cầu phân loại trước khi đưa hệ thống vào sử dụng và phân loại lại khi tích hợp hoặc thay đổi chức năng làm tăng rủi ro. Điều 35 quy định thời hạn chuyển tiếp cho hệ thống đã hoạt động trước ngày Luật có hiệu lực. Sau khi mua, thay đổi mô hình, dữ liệu, prompt hệ thống hoặc phạm vi người dùng có thể làm kết quả benchmark cũ không còn đại diện. Hợp đồng cần cho phép kiểm thử lại, nhận thông báo thay đổi, truy cập nhật ký cần thiết, xuất và xóa dữ liệu, hỗ trợ sự cố và chấm dứt khi hệ thống không duy trì mức phù hợp đã cam kết.

4. Thiết kế bộ tình huống đại diện

Bộ kiểm thử nên bao gồm câu hỏi tra cứu đơn giản, tình huống phải kết hợp nhiều văn bản, văn bản đã bị sửa đổi, quy định chuyển tiếp, dữ kiện thiếu và câu hỏi không có đáp án trong nguồn. Cần có cả trường hợp dễ lẫn giữa quy định chung và quy định chuyên ngành.

Mỗi tình huống phải có đáp án hoặc tiêu chí đánh giá do chuyên gia phê duyệt. Một phần dữ liệu nên được giữ kín để tránh việc tối ưu prompt chỉ nhằm vượt qua các câu hỏi đã biết trước.

5. Tám tiêu chí cần chấm riêng

Tám nhóm tiêu chí gồm: độ đúng của kết luận; độ chính xác của trích dẫn; khả năng xác định hiệu lực; khả năng nhận diện ngoại lệ và chuyển tiếp; tỷ lệ bỏ sót; khả năng từ chối khi thiếu căn cứ; bảo mật và quản trị dữ liệu; khả năng tích hợp, lưu nhật ký và xuất kết quả.

Lỗi nghiêm trọng phải được thống kê riêng thay vì hòa vào điểm trung bình. Một trích dẫn bịa hoặc kết luận sai về hiệu lực có thể làm mất giá trị của nhiều câu trả lời đúng về hình thức.

6. Đánh giá tổng chi phí và khả năng vận hành

Chi phí thực tế không chỉ là phí thuê bao. Cần tính thời gian tích hợp, làm sạch dữ liệu, thiết kế phân quyền, đào tạo, kiểm thử, chuyên gia sửa kết quả, lưu trữ, hỗ trợ và chi phí chuyển đổi khi chấm dứt dịch vụ.

Pilot nên chạy song song với quy trình cũ trong phạm vi kiểm soát. Chỉ mở rộng khi công cụ đạt ngưỡng chất lượng, người dùng hiểu giới hạn, dữ liệu được bảo vệ và tổ chức có cơ chế dừng hoặc chuyển cấp khi phát hiện lỗi.

7. Thiết kế dữ liệu kiểm thử và đáp án chuẩn

Tình huống nên được lấy từ công việc thực nhưng phải loại bỏ hoặc ẩn danh dữ liệu không được phép sử dụng. Mỗi câu có mô tả, nguồn, đáp án, mức độ khó và loại lỗi có thể phát sinh. Bộ kiểm thử cần cân bằng giữa câu có đáp án rõ, câu yêu cầu tổng hợp nhiều nguồn, câu có ngoại lệ và câu mà hệ thống phải từ chối vì thiếu căn cứ.

Đáp án chuẩn không nhất thiết là một đoạn văn duy nhất. Với vấn đề có nhiều cách hiểu hợp lý, chuyên gia có thể xây dựng tiêu chí gồm các điểm bắt buộc, nguồn tối thiểu, giả định và câu hỏi cần nêu. Cách chấm này đánh giá khả năng lập luận có kiểm soát thay vì buộc công cụ lặp lại đúng một câu trả lời. Bộ dữ liệu phải được cập nhật khi pháp luật thay đổi.

8. Chấm điểm, ngưỡng đạt và lỗi loại trừ

Trước khi chạy thử, tổ chức cần xác định ngưỡng tối thiểu cho từng tiêu chí. Độ chính xác trích dẫn và khả năng xác định hiệu lực thường không nên được bù bằng tốc độ hoặc giao diện. Một số lỗi có thể là lỗi loại trừ, chẳng hạn tạo điều khoản không tồn tại, tiết lộ dữ liệu kiểm thử hoặc không cho phép người dùng xóa và xuất dữ liệu theo yêu cầu hợp đồng.

Điểm số phải đi kèm khoảng tin cậy và kích thước mẫu. Nếu chỉ có vài câu hỏi, chênh lệch nhỏ giữa hai công cụ không có nhiều ý nghĩa. Báo cáo nên công bố số tình huống, cách lấy mẫu, trọng số và tỷ lệ lỗi nghiêm trọng. Khi thay đổi prompt hoặc cấu hình, cần chạy lại cùng bộ kiểm thử để biết cải thiện có bền vững hay chỉ xuất hiện ở một số trường hợp.

9. Quyết định sau pilot

Sau pilot, tổ chức có thể chọn mua, yêu cầu khắc phục, giới hạn use case hoặc dừng. Quyết định cần dựa trên chất lượng sau kiểm tra, rủi ro dữ liệu, khả năng tích hợp, năng lực hỗ trợ và tổng chi phí. Nếu công cụ chỉ đạt ở một số nhiệm vụ, phạm vi hợp đồng và quyền truy cập phải phản ánh đúng giới hạn đó thay vì mở cho toàn bộ tổ chức.

Khi triển khai, benchmark trở thành bộ kiểm thử hồi quy. Công cụ cần được kiểm tra lại sau thay đổi lớn về mô hình, dữ liệu hoặc tính năng. Người dùng phải có kênh báo lỗi và cơ chế dừng. Kết quả pilot không phải bảo đảm vĩnh viễn; nó là điểm khởi đầu cho giám sát liên tục và quyết định dựa trên bằng chứng.

10. Nền tảng hỗ trợ như thế nào?

– Tạo benchmark từ hồ sơ và câu hỏi đại diện cho công việc thật.

– Chấm riêng kết luận, trích dẫn, hiệu lực, bỏ sót và khả năng từ chối.

– Kiểm thử phân quyền, lưu dữ liệu, nhật ký, xuất dữ liệu và tích hợp.

– So sánh tổng chi phí sở hữu và hiệu quả sau khi chuyên gia kiểm tra.

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

Câu hỏi 1. Nên chạy pilot trong bao lâu trước khi mua Legal AI?

Không có một thời hạn chung phù hợp cho mọi tổ chức. Pilot phải đủ để bao phủ quy trình thật, loại văn bản, nhóm người dùng, tình huống thiếu dữ kiện và lỗi loại trừ; chỉ kết thúc khi thu đủ bằng chứng theo tiêu chí đạt hoặc không đạt đã định trước.

Câu hỏi 2. Hợp đồng mua Legal AI cần quy định những quyền kiểm soát nào?

Nên có quyền kiểm thử lại, nhận thông báo thay đổi, truy cập hoặc xuất nhật ký cần thiết, kiểm soát nhà thầu phụ, xuất và xóa dữ liệu, hỗ trợ sự cố, yêu cầu khắc phục và chấm dứt khi hệ thống không duy trì mức phù hợp đã cam kết.

Câu hỏi 3. Khi nào phải benchmark lại công cụ?

Cần đánh giá lại khi thay đổi mô hình, nguồn dữ liệu, prompt hệ thống, chức năng, nhóm người dùng, phạm vi tích hợp hoặc mục đích sử dụng; đặc biệt khi thay đổi có thể làm tăng rủi ro hoặc khiến kết quả cũ không còn đại diện.

12. Căn cứ pháp lý tham khảo

1. Luật Trí tuệ nhân tạo số 134/2025/QH15 và Nghị định số 142/2026/NĐ-CP.

2. Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định số 356/2025/NĐ-CP.

3. Luật Ban hành văn bản quy phạm pháp luật số 64/2025/QH15, được sửa đổi, bổ sung bởi Luật số 87/2025/QH15.

13. Kết luận

Benchmark Legal AI là bước thẩm định pháp lý và vận hành, không chỉ là so sánh tính năng. Quyết định mua nên dựa trên lỗi nghiêm trọng, khả năng truy xuất, nghĩa vụ dữ liệu, cơ chế giám sát và quyền kiểm soát sau khi hợp đồng được ký.