Review công cụ Legal AI: Phương pháp kiểm thử bằng bằng chứng

Một công cụ trả lời trôi chảy chưa chắc là công cụ phù hợp cho công việc pháp lý. Đánh giá cần dựa trên bộ tình huống có đáp án, nguồn kiểm chứng và tiêu chí chấp nhận, đồng thời phản ánh đúng dữ liệu và quy trình mà tổ chức sẽ sử dụng trong thực tế.

1. Benchmark phải kiểm tra khả năng áp dụng luật, không chỉ khả năng trả lời

Một câu trả lời có trích dẫn thật vẫn có thể sai nếu dùng nhầm phiên bản hoặc điều khoản không điều chỉnh sự kiện. Bộ kiểm thử cần tạo tình huống chốt ở nhiều thời điểm để kiểm tra các Điều 53–58 Luật số 64/2025/QH15; tình huống có quy định chung và riêng; tình huống thiếu dữ kiện; và câu hỏi mà nguồn không có đáp án. Tiêu chí phải chấm riêng việc xác định quy phạm, đối chiếu yếu tố pháp lý với dữ kiện và nêu ngoại lệ. Điểm diễn đạt hoặc tốc độ không được bù cho lỗi kết luận về hiệu lực.

2. Nghĩa vụ của hệ thống theo phân loại rủi ro

Điều 13 Luật Trí tuệ nhân tạo yêu cầu hệ thống rủi ro cao được đánh giá sự phù hợp trước khi sử dụng hoặc khi có thay đổi đáng kể; Điều 14 quy định quản trị dữ liệu kiểm thử, hồ sơ kỹ thuật, nhật ký, giám sát con người và giải trình. Điều 15 áp dụng nghĩa vụ minh bạch, giải trình cho hệ thống rủi ro trung bình. Vì vậy, bài review phải ghi phiên bản, cấu hình, nguồn dữ liệu, ngày thử và vai trò của công cụ trong quy trình. Không thể lấy kết quả của một tài khoản thử nghiệm rồi suy rộng cho mọi cấu hình và mọi use case.

3. Từ kết quả thử nghiệm đến trách nhiệm sử dụng

Khoản 3 Điều 28 cho phép cơ quan có thẩm quyền yêu cầu hồ sơ kỹ thuật, nhật ký, dữ liệu huấn luyện và thông tin cần thiết để xác định nguyên nhân sự cố hoặc phân định trách nhiệm. Điều 29 quy định trách nhiệm xử lý vi phạm và bồi thường, trong đó bên triển khai hệ thống rủi ro cao có thể phải bồi thường thiệt hại ngay cả khi đã quản lý đúng quy định, trừ trường hợp miễn trừ. Vì vậy, kết luận review phải nêu phạm vi an toàn, lỗi loại trừ, kiểm soát bắt buộc và quyền dừng hệ thống; nhãn “đạt benchmark” không phải là sự bảo đảm pháp lý vĩnh viễn.

4. Bộ kiểm thử phải đại diện cho công việc thật

Nên kết hợp câu hỏi đơn giản, câu hỏi nhiều văn bản, trường hợp có quy định chuyển tiếp, câu hỏi cố ý thiếu dữ kiện và tình huống không có câu trả lời trong nguồn. Công cụ tốt phải biết dừng, nêu giới hạn và yêu cầu bổ sung thông tin thay vì bịa câu trả lời.

Bộ dữ liệu kiểm thử cần được chuyên gia gắn đáp án và cập nhật theo phiên bản pháp luật. Tách riêng bộ dùng để tinh chỉnh prompt và bộ dùng để đánh giá cuối cùng để giảm thiên lệch.

5. Chấm cả chất lượng pháp lý và chất lượng vận hành

Nhóm pháp lý gồm độ đúng của kết luận, độ chính xác trích dẫn, tình trạng hiệu lực, khả năng nhận diện ngoại lệ và tỷ lệ bỏ sót. Nhóm vận hành gồm phân quyền, nhật ký, lưu giữ dữ liệu, tích hợp, tốc độ, khả năng xuất báo cáo và hỗ trợ người dùng.

Cần đo lỗi nghiêm trọng riêng. Một câu trả lời sai về hiệu lực hoặc bịa điều khoản có trọng số cao hơn lỗi trình bày. Điểm trung bình đẹp không được che giấu lỗi có thể dẫn đến quyết định sai.

6. Review công khai cần minh bạch phương pháp

Bài review nên nêu phiên bản công cụ, ngày thử, gói dịch vụ, phạm vi dữ liệu, số lượng tình huống và cách tính điểm. Nếu nhà cung cấp tài trợ hoặc cung cấp tài khoản, cần công bố mối quan hệ.

Kết luận nên chỉ rõ công cụ phù hợp với công việc nào, cần kiểm soát gì và không phù hợp với tình huống nào. Điều này hữu ích hơn một xếp hạng chung thiếu bối cảnh.

7. Phương pháp kiểm thử có thể lặp lại

Mỗi lần kiểm thử cần ghi phiên bản công cụ, ngày thử, cấu hình, nguồn dữ liệu, prompt và điều kiện tài khoản. Nếu một biến thay đổi, kết quả có thể khác. Bộ tình huống nên được chạy theo quy trình thống nhất, hạn chế người kiểm thử điều chỉnh prompt nhiều lần cho đến khi nhận đáp án mong muốn. Khi có điều chỉnh, phải ghi lại số lần và lý do để phản ánh đúng công sức sử dụng thực tế.

Chấm điểm nên có ít nhất hai người với tiêu chí rõ. Bất đồng được thảo luận và lưu lý do, đặc biệt với câu hỏi cần phán đoán pháp lý. Một phần mẫu có thể được chấm mù để giảm thiên lệch thương hiệu. Đối với lỗi nghiêm trọng, cần đánh giá hậu quả tiềm năng chứ không chỉ đếm số lượng. Một lỗi về hiệu lực có thể quan trọng hơn nhiều lỗi diễn đạt.

8. Diễn giải kết quả theo use case

Không nên kết luận một công cụ tốt hoặc kém cho mọi công việc. Một sản phẩm có thể mạnh về tìm kiếm và trích xuất nhưng chưa phù hợp để tạo dự thảo; một sản phẩm khác có thể tích hợp tốt nhưng dữ liệu pháp luật chưa đủ mới. Báo cáo cần tách từng use case, nêu mức chất lượng, kiểm soát cần thiết và nhóm người dùng phù hợp.

Kết quả cũng phải phản ánh thời gian chuyên gia sửa. Nếu công cụ tạo bản nháp nhanh nhưng mất nhiều giờ kiểm tra và khắc phục, lợi ích vận hành có thể thấp hơn phương pháp cũ. Nên đo thời gian đến kết quả đã được phê duyệt, không chỉ thời gian đến câu trả lời đầu tiên. Đây là chỉ số gần với giá trị thực tế của Legal AI trong tổ chức.

9. Tránh những bài review dễ gây hiểu nhầm

Bài review dễ gây hiểu nhầm khi dùng quá ít câu hỏi, chỉ chọn tình huống đơn giản, không công bố gói dịch vụ hoặc không kiểm tra trích dẫn. Việc xếp hạng bằng một điểm tổng duy nhất cũng che khác biệt giữa các nhóm tính năng. Nếu nhà cung cấp tài trợ, cung cấp tài khoản hoặc hỗ trợ cấu hình, mối quan hệ đó phải được công bố để người đọc đánh giá tính độc lập.

Kết luận nên trình bày cả điểm mạnh, điểm yếu, giới hạn dữ liệu và điều kiện sử dụng an toàn. Không nên dùng ngôn ngữ như chính xác tuyệt đối hoặc thay thế luật sư nếu benchmark không chứng minh được. Một review có trách nhiệm giúp người đọc đặt câu hỏi và thiết kế pilot phù hợp, thay vì thúc đẩy quyết định mua dựa trên ấn tượng từ vài câu trả lời trôi chảy.

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

– Benchmark có đáp án và tình huống từ công việc thật.

– Chấm riêng trích dẫn, hiệu lực, bỏ sót và lỗi nghiêm trọng.

– Đánh giá bảo mật, phân quyền, nhật ký và điều khoản dữ liệu.

– Công khai phiên bản, ngày thử và giới hạn của bài review.

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

Câu hỏi 1. Một công cụ trích dẫn đúng văn bản có thể vẫn trả lời sai không?

Có. Văn bản có thể không còn hiệu lực tại thời điểm sự kiện, điều khoản có thể không điều chỉnh đúng chủ thể hoặc có ngoại lệ và chuyển tiếp. Vì vậy phải chấm riêng việc tìm nguồn và việc áp dụng quy phạm vào dữ kiện.

Câu hỏi 2. Lỗi nào nên được coi là lỗi loại trừ trong bài review?

Các lỗi như bịa điều khoản, tiết lộ dữ liệu của người khác, bỏ qua yêu cầu dừng, không cho con người can thiệp hoặc dùng dữ liệu sai mục đích nên làm dừng pilot để điều tra, thay vì được bù trừ bằng điểm tốc độ hoặc trình bày.

Câu hỏi 3. Có thể dùng một kết quả review cho mọi phiên bản công cụ không?

Không. Kết quả chỉ đại diện cho phiên bản, cấu hình, nguồn dữ liệu, thời điểm và use case đã thử. Khi mô hình, prompt hệ thống, dữ liệu hoặc phạm vi tích hợp thay đổi, cần đánh giá lại mức độ đại diện của benchmark.

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

Review công cụ Legal AI phải trả lời được công cụ phù hợp với công việc nào, trong điều kiện kiểm soát nào và phải dừng khi xuất hiện lỗi gì. Một bảng điểm chỉ có ý nghĩa khi người đọc tái lập được phiên bản, dữ liệu, phương pháp và căn cứ pháp lý của lần thử.