# Khi agent làm sai, tòa án tìm người chịu trách nhiệm. Hợp đồng đẩy phần rủi ro đó cho khách hàng

> Từ chatbot của Air Canada đến vụ kiện Workday, thông điệp đã rõ: không ai được đổ lỗi cho AI. Phần lớn rủi ro vì thế dồn vào điểm duyệt và log, mà người xây chúng thường là FDE.

Bản gốc: https://fdetimes.net/vi/phan-tich/agent-gay-loi-ai-chiu-trach-nhiem-hop-dong-va-vai-tro-fde/

Air Canada từng thử một lập luận mà nhiều doanh nghiệp dùng AI hẳn đã nghĩ tới: chatbot của hãng là một thực thể pháp lý riêng. Tháng 2/2024, một tribunal ở British Columbia bác lập luận đó và buộc hãng chịu trách nhiệm về thông tin sai mà chatbot đưa cho khách.

Lý lẽ của tribunal rất đơn giản. Theo bản phân tích của McCarthy Tétrault, tribunal cho rằng thông tin đến từ một trang tĩnh hay từ chatbot cũng không khác gì nhau, và Air Canada phải chịu trách nhiệm cho mọi thông tin trên website của mình.

Nếu bạn là FDE, phán quyết này chạm thẳng vào việc hằng ngày. Bạn là người nối agent vào hệ thống thật của khách hàng, đặt ngưỡng, quyết định hành động nào cần người duyệt. Luật và hợp đồng đang dịch chuyển theo hướng biến những quyết định kỹ thuật ấy thành bằng chứng khi có tranh chấp.

## Tòa án không cho AI làm bình phong

Hãng luật Torkin Manes rút ra nguyên tắc chung từ vụ Moffatt v. Air Canada: doanh nghiệp vẫn chịu trách nhiệm nếu thông tin sai đến tay người tiêu dùng qua bất kỳ công cụ AI nào. Agent không phải người đứng ra gánh lỗi; bên triển khai mới là người đó.

Hệ quả kỹ thuật khá rõ. Nếu chatbot bị đối xử như một trang trên website, thì câu trả lời của nó cần được kiểm soát như nội dung chính thức: có bộ eval đối chiếu với chính sách gốc, có cách phát hiện khi câu trả lời lệch. Những việc đó thường nằm trong backlog của một FDE.

Ở Mỹ, trách nhiệm còn có thể lan tới nhà cung cấp. Trong vụ Mobley v. Workday, tòa liên bang ở California từ chối yêu cầu bãi đơn kiện và cho rằng Workday có thể bị truy trách nhiệm theo thuyết đại diện (agency), vì khách hàng được cho là đã ủy thác chức năng tuyển dụng cho nó.

Duane Morris tóm bài học cho nhà cung cấp: vendor dùng AI để sàng lọc ứng viên có thể phải chịu trách nhiệm về khiếu nại phân biệt đối xử. Nói cách khác, giao một việc cho phần mềm không khiến trách nhiệm pháp lý gắn với việc đó biến mất.

## Hợp đồng đang kéo theo hướng ngược lại

Đọc án lệ, bạn có thể nghĩ nhà cung cấp sẽ gánh nhiều hơn. Nhưng mẫu hợp đồng quen thuộc lại chia rủi ro theo hướng khác.

Mayer Brown mô tả logic của điều khoản SaaS truyền thống: nhà cung cấp lo nền tảng, còn người dùng chịu trách nhiệm cho mọi hành động thực hiện trên nền tảng đó.

Đi kèm thường là câu từ chối bảo đảm quen thuộc rằng dịch vụ được cung cấp nguyên trạng, kèm mọi lỗi. Theo hãng, logic này đang bị căng ra khi agent được bán như một dịch vụ.

Hãng luật Bristows nói thẳng hơn: theo hợp đồng thông thường, khách hàng gánh rủi ro khi agent hành xử bất ngờ hoặc sai. Tệ hơn, khách hàng rất khó chứng minh có vi phạm hợp đồng khi agent gây lỗi, và còn phải chứng minh quan hệ nhân quả.

Ghép hai mảnh lại thì thấy một khoảng trống. Tòa án nói bên triển khai không thể đổ lỗi cho AI, còn hợp đồng để bên triển khai tự gánh hành động của agent. Khi có sự cố, câu hỏi then chốt sẽ là khâu giám sát của con người có thật sự tồn tại và hoạt động hay không.

Vì thế Bristows khuyên khách hàng không nhận một mình trách nhiệm giám sát khi việc đó không phù hợp hoặc không khả thi về kỹ thuật, và đòi nhà cung cấp đưa ra điểm duyệt cho các hành động rủi ro cao. Điểm duyệt ấy không tự xuất hiện; ai đó phải cấu hình nó trong hệ thống của khách hàng.

## Ở châu Âu, hồ sơ phiên bản trở thành chứng cứ

Chỉ thị trách nhiệm sản phẩm mới của EU mở rộng khái niệm "sản phẩm" sang phần mềm và dịch vụ số. Baker McKenzie xác nhận phạm vi này bao gồm cả ứng dụng và hệ thống AI.

Hai cơ chế đi kèm khiến chuyện ghi log trở nên sống còn. Tòa có thể buộc các bên công bố bằng chứng liên quan, và theo HLC, nếu bên bị kiện không cung cấp tài liệu kỹ thuật thì sản phẩm bị coi là có lỗi. Nhà sản xuất cũng chịu trách nhiệm nếu lỗi đến từ bản cập nhật phần mềm nằm trong tầm kiểm soát của họ.

Đặt hai cơ chế đó vào một agent cụ thể, bạn cần trả lời được: lúc thiệt hại xảy ra, model nào, prompt nào, cấu hình nào đang chạy, và bản cập nhật gần nhất là gì. Không trả lời được thì không những không tự bào chữa được, mà còn có nguy cơ bị coi là có lỗi chỉ vì thiếu hồ sơ.

Bảng dưới đây xếp các nguồn trên theo cùng một câu hỏi: ai chịu, vì sao, và kỹ sư triển khai cần để lại dấu vết gì.

| Bối cảnh | Ai bị quy trách nhiệm | Căn cứ | Việc FDE nên để lại dấu vết |
|---|---|---|---|
| Moffatt v. Air Canada, British Columbia | Doanh nghiệp triển khai chatbot | Chịu trách nhiệm mọi thông tin trên website; chatbot không phải thực thể riêng | Bộ eval đối chiếu câu trả lời với chính sách gốc |
| Mobley v. Workday, California | Có thể cả nhà cung cấp AI | Thuyết đại diện: khách hàng ủy thác chức năng tuyển dụng | Tài liệu rõ agent quyết định gì, ở bước nào |
| Hợp đồng SaaS truyền thống | Chủ yếu là người dùng, tức khách hàng | Nhà cung cấp lo nền tảng, dịch vụ cung cấp nguyên trạng | Luồng giám sát thật, có log ai duyệt gì |
| Khuyến nghị của Bristows | Khách hàng không nên gánh một mình phần giám sát | Khách hàng nên đòi nhà cung cấp có điểm duyệt cho hành động rủi ro cao | Điểm duyệt được cấu hình và kiểm thử |
| Chỉ thị trách nhiệm sản phẩm của EU | Nhà sản xuất phần mềm, kể cả hệ thống AI | Thiếu tài liệu kỹ thuật thì sản phẩm bị coi là có lỗi; lỗi do bản cập nhật trong tầm kiểm soát | Phiên bản, cấu hình và lịch sử cập nhật của agent |

## Điểm duyệt là việc của FDE

Thử hình dung một agent xử lý yêu cầu hoàn tiền cho một công ty thương mại điện tử. Hợp đồng đặt phần giám sát lên khách hàng. Nhưng khi vận hành thật, đội hỗ trợ quá tải, nên mọi khoản hoàn tiền đều được tự động duyệt.

Trên giấy, rủi ro đã nằm ở phía khách hàng. Nếu agent hoàn sai hàng loạt, hệ thống không chứng minh được khâu giám sát nào, và theo lập luận của Bristows, khách hàng cũng khó đổ ngược lỗi cho nhà cung cấp. Hai bên sẽ tranh cãi về một khâu kiểm soát chưa từng được xây.

Giờ thử cấu hình khác. Agent tự xử lý khoản nhỏ, dừng lại chờ người duyệt khi vượt một ngưỡng do khách hàng chọn, và mọi lần duyệt đều được ghi lại cùng phiên bản agent đang chạy. Đó đúng là kiểu điểm duyệt cho hành động rủi ro cao mà Bristows khuyên khách hàng đòi hỏi.

**Điểm mấu chốt:** Guardrail bạn cấu hình cho agent có thể trở thành bằng chứng khi xảy ra tranh chấp về trách nhiệm.

## Ba cái bẫy nên tránh

Cái bẫy phổ biến nhất là giám sát chỉ có trên giấy: hợp đồng và tài liệu thiết kế ghi "con người rà soát", nhưng trong vận hành thật không ai mở hàng đợi duyệt. Hãy kiểm tra bằng dữ liệu, chẳng hạn bao nhiêu phần trăm hành động vượt ngưỡng thực sự có người bấm duyệt tuần trước.

Cái bẫy kế tiếp là ngưỡng chưa từng được kiểm thử. Một ngưỡng escalation viết trong config nhưng không có test case nào chứng minh agent dừng lại đúng chỗ thì chưa phải kiểm soát. Hãy đưa vài tình huống vượt ngưỡng vào bộ eval và chạy lại sau mỗi lần cập nhật.

Cái bẫy cuối cùng là log thiếu ngữ cảnh. Log ghi "đã duyệt" mà không có ai duyệt, lúc nào, với phiên bản và cấu hình agent nào thì khó dùng khi tòa yêu cầu công bố tài liệu kỹ thuật.

Ở mỗi đợt triển khai, nên hỏi sớm trong buổi discovery: hợp đồng giả định giám sát ở đâu, và hành động nào của agent có thể gây thiệt hại cho khách hàng cuối, ứng viên hay người mua?

## Kỹ năng này nên được nêu rõ trong CV

Nhiều kỹ sư viết một dòng CV kiểu "Triển khai agent AI xử lý hoàn tiền cho khách hàng thương mại điện tử". Dòng đó chỉ nói agent làm được gì, mà bỏ qua phần khó nhất của việc triển khai.

Một dòng mạnh hơn sẽ nêu cụ thể hành động nào phải chờ duyệt, ngưỡng được thống nhất với ai, log lưu những gì, và eval nào kiểm tra độ chính xác so với nguồn chính thức.

Khi đọc mô tả công việc FDE, hãy để ý các từ như governance, human review, approval workflow hay audit trail, và chuẩn bị sẵn một ví dụ cụ thể về phần việc đó từ dự án của bạn. Trong phỏng vấn, nếu được hỏi về một lần triển khai, hãy kể cả lý do bạn đặt điểm dừng ở đó.

Kỹ sư phần mềm có thể coi điều khoản trách nhiệm là việc của luật sư. FDE thì không được như vậy: điểm duyệt viết trong hợp đồng chỉ bảo vệ được ai đó khi nó thực sự chạy trong hệ thống của khách hàng.

**Thử ngay tuần này:**

- Chọn một agent bạn đang triển khai và liệt kê mọi hành động nó có thể làm mà không cần người duyệt; đánh dấu hành động nào rủi ro cao và nên có điểm duyệt.
- Xin đọc phần trách nhiệm và giám sát trong hợp đồng của khách hàng hiện tại, rồi đối chiếu xem hệ thống đang chạy có thật sự đáp ứng điều khoản đó không.
- Viết lại một dòng trong CV theo cách mô tả guardrail bạn đã xây: hành động nào phải dừng chờ duyệt, ở ngưỡng nào, và được ghi log ra sao.

## Nguồn

- [BC Tribunal Confirms Companies Remain Liable For AI Chatbot-Created Information (Torkin Manes, Mondaq)](https://www.mondaq.com/canada/new-technology/1432798/bc-tribunal-confirms-companies-remain-liable-for-ai-chatbot-created-information)

- [Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot (McCarthy Tétrault TechLex)](https://www.mccarthy.ca/en/insights/blogs/techlex/moffatt-v-air-canada-misrepresentation-ai-chatbot)

- [California Federal Court Denies Motion To Dismiss Artificial Intelligence Employment Discrimination Lawsuit (Duane Morris)](https://blogs.duanemorris.com/classactiondefense/2024/07/16/california-federal-court-denies-motion-to-dismiss-artificial-intelligence-employment-discrimination-lawsuit/)

- [Spotlight on Agentic AI | Liability (Bristows)](https://inquisitiveminds.bristows.com/post/102njsw/spotlight-on-agentic-ai-liability)

- [Contracting for Agentic AI Solutions: Shifting the Model from SaaS to Services (Mayer Brown)](https://www.mayerbrown.com/en/insights/publications/2026/02/contracting-for-agentic-ai-solutions-shifting-the-model-from-saas-to-services)

- [EU introduces comprehensive digital-era Product Liability Directive (HLC)](https://hlc.com/en/publications/eu-introduces-comprehensive-digitalera-product-liability-directive)

- [EU Product Liability Reform (Baker McKenzie, Product Risk Radar)](https://www.bakermckenzie.com/en/insight/publications/resources/product-risk-radar-articles/eu-product-liability-reform)