Khi một chatbot trả lời sai, ngân hàng có một vấn đề chất lượng. Khi một AI agent có thể khóa thẻ, thay đổi hạn mức, lập lệnh hoặc gửi khuyến nghị đầu tư sai, ngân hàng có một vấn đề kiểm soát.

Đây là khác biệt quan trọng giữa AI cung cấp thông tin và AI thực hiện hành động. Cuộc thảo luận vì vậy không nên bắt đầu bằng câu hỏi “model nào thông minh nhất?”. Nó nên bắt đầu bằng câu hỏi: AI được phép làm gì, trong điều kiện nào, ai chịu trách nhiệm và hệ thống nào có quyền ghi nhận hành động cuối cùng?

Từ giao diện hội thoại đến một chủ thể thực thi

Ứng dụng ngân hàng truyền thống yêu cầu khách hàng tự tìm chức năng, nhập thông tin và xác nhận. Giao diện hội thoại rút ngắn hành trình: khách hàng chỉ cần nói mục đích. Nhưng khi hệ thống chuyển từ giải thích sang thực hiện, mỗi câu hội thoại có thể trở thành một yêu cầu nghiệp vụ.

Ví dụ, “hãy giúp tôi thanh toán thẻ đúng hạn” có thể dẫn đến việc kiểm tra số dư, chọn tài khoản, xác định ngày, lập lệnh và gửi xác nhận. Đây không còn là một câu trả lời ngôn ngữ. Nó là chuỗi quyết định liên quan đến quyền truy cập, chính sách, dữ liệu, giao dịch và bằng chứng kiểm toán.

Vì vậy, ngân hàng cần tách rõ hai lớp:

  • Lớp AI: hiểu ý định, thu thập ngữ cảnh, đề xuất bước tiếp theo và giải thích.
  • Lớp quyết định xác định: kiểm tra quyền, hạn mức, điều kiện sản phẩm, quy tắc rủi ro, phê duyệt và ghi sổ.

AI có thể đề xuất. Hệ thống có kiểm soát mới được cam kết hành động.

Năm ranh giới cần thiết kế trước khi pilot

1. Ranh giới về phạm vi

Một agent không nên bắt đầu với quyền “hỗ trợ mọi nhu cầu”. Phạm vi ban đầu cần hẹp và có thể mô tả bằng danh sách hành động cụ thể: tra cứu, chuẩn bị hồ sơ, tạo nháp, hoặc thực hiện một giao dịch có điều kiện.

Với mỗi hành động, cần định nghĩa rõ dữ liệu được đọc, hệ thống được gọi, số lần thử lại, giới hạn tiền và tình huống phải chuyển sang con người.

2. Ranh giới về quyền quyết định

Không phải mọi hành động đều cần mức phê duyệt giống nhau. Có thể chia thành bốn mức:

  1. AI chỉ cung cấp thông tin.
  2. AI đề xuất, con người quyết định.
  3. AI thực hiện trong giới hạn và khách hàng xác nhận.
  4. AI tự động thực hiện theo ủy quyền đã được thiết lập.

Một use case nên được xếp mức trước khi lựa chọn công nghệ. Nếu nhóm dự án chưa thống nhất mức quyền, họ chưa sẵn sàng đánh giá giải pháp.

3. Ranh giới về dữ liệu

Agent cần biết đúng ngữ cảnh nhưng không nên nhìn thấy nhiều hơn mức cần thiết. Thiết kế phải trả lời: dữ liệu nào được dùng để hiểu ý định, dữ liệu nào được đưa vào model, dữ liệu nào không được rời khỏi hệ thống ngân hàng, và dữ liệu hội thoại được lưu bao lâu.

Luật Bảo vệ dữ liệu cá nhân đã có hiệu lực từ ngày 01/01/2026. Với ngân hàng, việc “có dữ liệu” không đồng nghĩa với việc có thể dùng dữ liệu đó cho mọi mục đích AI.

4. Ranh giới về ngoại lệ

Demo thường trình bày hành trình thuận lợi. Vận hành thật được quyết định bởi ngoại lệ: dữ liệu mâu thuẫn, khách hàng dễ bị tổn thương, nghi ngờ gian lận, giao dịch thất bại một phần, hoặc yêu cầu vượt quá ủy quyền.

Agent phải biết khi nào dừng. Điều kiện dừng quan trọng không kém điều kiện bắt đầu.

5. Ranh giới về trách nhiệm

Không thể đặt trách nhiệm vào “AI”. Cần một business owner cho outcome, một owner cho model hoặc dịch vụ AI, một owner cho rule/policy engine và một đơn vị giám sát rủi ro. Khi sự cố xảy ra, cơ chế khắc phục phải xác định ai có quyền dừng hệ thống, đảo giao dịch và thông báo khách hàng.

Thông tư 53/2026/TT-NHNN thay đổi câu hỏi phê duyệt như thế nào?

Thông tư 53/2026/TT-NHNN về an toàn, quản lý rủi ro và điều kiện triển khai AI trong ngành Ngân hàng được ban hành ngày 30/09/2026 và có hiệu lực từ 15/11/2026. Điều này khiến governance không còn là phần bổ sung sau pilot.

Investment committee cần yêu cầu hồ sơ use case trả lời tối thiểu:

  • AI hỗ trợ hay ra quyết định trong hoạt động nghiệp vụ nào?
  • Mức rủi ro của hệ thống là gì và căn cứ phân loại?
  • Khách hàng có biết mình đang tương tác với AI không?
  • Quyết định nào có thể được yêu cầu con người rà soát?
  • Có log nào để tái hiện input, phiên bản, rule và hành động?
  • Nhà cung cấp được dùng dữ liệu vào mục đích gì?
  • Điều kiện dừng, khôi phục và chuyển đổi nhà cung cấp là gì?

Nếu các câu hỏi này chỉ xuất hiện ở giai đoạn compliance review cuối cùng, chi phí thiết kế lại sẽ rất cao.

Một cách bắt đầu phù hợp cho ngân hàng Việt Nam

Thay vì chọn use case nổi bật nhất, hãy chọn use case có ba đặc điểm: tần suất đủ cao, outcome đo được và ranh giới kiểm soát rõ.

Ví dụ tốt có thể là hỗ trợ nhân viên chuẩn bị hồ sơ, phân loại yêu cầu dịch vụ hoặc tạo nháp câu trả lời. Những use case này tạo dữ liệu học tập về độ chính xác, khả năng tích hợp, hành vi người dùng và vận hành sự cố trước khi ngân hàng trao quyền hành động rộng hơn.

Pilot nên có bốn nhóm chỉ số:

  • Chất lượng: độ chính xác, tỷ lệ phải sửa, loại lỗi.
  • Kết quả: thời gian xử lý, tỷ lệ hoàn tất, chi phí trên giao dịch.
  • Kiểm soát: tỷ lệ escalation đúng, sự cố, vi phạm quyền truy cập.
  • Adoption: mức sử dụng, tỷ lệ bỏ qua đề xuất, lý do không tin tưởng.

Chỉ số năng suất mà không có chỉ số kiểm soát sẽ khuyến khích hệ thống hành động nhanh hơn trước khi tổ chức hiểu rủi ro.

Câu hỏi dành cho Ban điều hành

Trước khi duyệt agentic AI, hãy yêu cầu nhóm dự án mô phỏng một tình huống thất bại. AI hiểu sai ý định. Một hệ thống downstream phản hồi chậm. Khách hàng đổi ý giữa chừng. Giao dịch đã được tạo nhưng chưa ghi sổ. Ai phát hiện, ai dừng, ai giải thích và ai khôi phục?

Nếu câu trả lời chỉ là “model sẽ được huấn luyện tốt hơn”, thiết kế vẫn chưa đủ trưởng thành.

Model tạo ra sự thông minh. Ranh giới kiểm soát tạo ra khả năng vận hành trong ngân hàng.

Nguồn tham khảo

Disclosure: Bài viết thể hiện quan điểm cá nhân của tác giả và không đại diện cho bất kỳ tổ chức nào mà tác giả đang hoặc sẽ làm việc.

LDT

Lê Duy Tú
Banking · Digital Product · Wealth Management