Chỉ cần chụp căn cước và quét khuôn mặt, khách hàng có thể mở tài khoản ngân hàng trong 5 phút qua eKYC (electronic Know Your Customer). Câu hỏi người vận hành phải trả lời mỗi ngày: nếu người trước camera không phải “người thật” thì sao? Kẻ gian đã thử mọi cách, từ tấm ảnh in vài nghìn đồng đến deepfake dựng công phu. Từ kinh nghiệm triển khai cho các ngân hàng và tổ chức tài chính, bài viết đi theo mạch: kiểu tấn công → rủi ro → cách phòng thủ → hàm ý khi ra quyết định.

1. Hai cách để lừa một hệ thống nhận diện

Kẻ gian có hai cách để lừa hệ thống eKYC.

• Tấn công trình diễn (presentation attack): đưa khuôn mặt hoặc giấy tờ giả ra trước camera thật và hy vọng hệ thống không phân biệt được.

• Tấn công tiêm chèn (injection attack): không diễn trước camera mà can thiệp vào bên trong, đánh tráo dữ liệu camera gửi về hệ thống.

Hai kiểu này khác nhau về bản chất nên cần hai lớp phòng thủ riêng – điểm đầu tiên CIO/CISO cần tách bạch khi đánh giá giải pháp.

Hình ảnh 1: Hai phương thức tấn công eKYC: trình diễn (Presentation Attack) và tiêm chèn (Injection Attack)

1.1. Tấn công trình diễn: màn kịch trước ống kính
Đây là kiểu tấn công phổ biến nhất vì rào cản thấp. Phần lớn ca chúng tôi gặp là ảnh in và video phát lại trên màn hình khác; mức cao hơn là mặt nạ silicon hoặc hình chiếu lên đầu ma-nơ-canh. Với giấy tờ, các hình thức tấn công phổ biến là chụp lại màn hình, dán đè ảnh chân dung, chỉnh sửa kỹ thuật số để thay tên, đổi số.

Rủi ro: camera, ứng dụng, đường truyền đều thật - chỉ “diễn viên” là giả. Hệ thống chỉ so khớp khuôn mặt với ảnh căn cước sẽ bị qua mặt, vì ảnh in của khách hàng đương nhiên giống khách hàng.

Hình ảnh 2: Giả mạo khuôn mặt cơ bản: ảnh in, mặt nạ 2D, chụp lại từ màn hình

Cách phòng thủ: lớp đầu tiên là mô hình AI phân tích kết cấu bề mặt (vân giấy in, điểm ảnh màn hình) và dựng lại cấu trúc 3D (sống mũi, hốc mắt, gò má) để phân biệt khối mặt thật với mặt phẳng.

Hình ảnh 3: Mặt nạ 3D bằng latex, silicone hoặc ghép khối từ ảnh chụp

Lớp thứ hai là các phương thức liveness bổ sung như:

• Sử dụng màn hình chớp sáng và hệ thống đo cách ánh sáng phản chiếu trên mặt. Da thật tạo bóng đổ theo hình khối (má sáng, hốc mắt tối), còn ảnh in hay màn hình phản xạ phẳng, đều.

• Kết hợp liveness chủ động (quay đầu, chớp mắt) hoặc bị động (phân tích cấu trúc điểm ảnh trên khuôn mặt).

Chọn phương thức nào là đánh đổi giữa mức chống giả mạo và tỷ lệ khách hàng bỏ dở - cần tinh chỉnh theo từng phân khúc, không có cấu hình đúng cho mọi trường hợp.

Với giấy tờ, hệ thống kiểm tra bố cục, các đặc trưng điểm ảnh, phát hiện dấu vết dán đè, chỉnh sửa và kết hợp với các lớp quy tắc logic và kiểm tra chéo để phát hiện các ca làm giả trên phôi thật mà mô hình phân tích hình ảnh đơn thuần dễ bỏ sót.

Hàm ý cho quyết định: đừng chỉ hỏi độ chính xác so khớp khuôn mặt. Hãy yêu cầu bằng chứng PAD (chống giả mạo trình diễn) từ kiểm thử độc lập theo ISO/IEC 30107-3 và trên mẫu tấn công thực tế tại Việt Nam.

Hình ảnh 4: Giả mạo “nghiệp dư” – giấy tờ chụp lại từ màn hình – bị hệ thống phát hiện và chặn.

Hình ảnh 5: Giả mạo “chuyên nghiệp” – chỉnh sửa trên phôi CCCD thật – chỉ bị phát hiện nhờ kết hợp nhiều lớp kiểm tra.

1.2. Tấn công tiêm chèn: đánh tráo từ bên trong

Kiểu tấn công tiêm chèn diễn ra giống chiêu trong phim trộm két bằng hình thức can thiệp camera an ninh để màn hình bảo vệ chỉ thấy hành lang yên tĩnh. Trong eKYC có hai con đường.

Thứ nhất, giả làm camera: cài camera ảo (phần mềm tự nhận là camera) để ứng dụng nhận video dựng sẵn; biến thể là camera ảo trên máy giả lập hoặc capture card gắn ngoài “bơm” tín hiệu như ống kính thật. Kênh web dễ bị tấn công kiểu này hơn hẳn app, vì trình duyệt không cho kiểm soát sâu xuống phần cứng để xác minh camera vật lý.

Hình ảnh 6: Tấn công tiêm chèn bằng camera ảo.

Thứ hai, bỏ qua camera: dữ liệu giả được đưa thẳng vào tầng xử lý, camera không cần bật. Kẻ gian thường dùng thiết bị đã root/jailbreak để hooking vào ứng dụng, sửa dữ liệu ngay trong bộ nhớ, hoặc dịch ngược API để tự gửi dữ liệu giả về máy chủ.

Hình ảnh 7: Tấn công tiêm chèn bằng việc bypass hệ thống camera.

Nội dung tiêm vào có ba mức tinh vi tăng dần: video thật của nạn nhân; face swap hoặc deepfake thời gian thực cử động theo yêu cầu hệ thống; và khuôn mặt do AI sinh hoàn toàn để tạo danh tính ma.

Rủi ro: tiêm chèn không đánh lừa AI mà đi vòng qua AI. Video người thật được tiêm vào vẫn “sạch” dưới mọi phép phân tích hình ảnh - vấn đề là nó không đến từ camera.

Cách phòng thủ: chống tiêm chèn là việc của lớp bảo mật trên thiết bị, không phải của AI. SDK cần phát hiện camera ảo, giả lập, root/jailbreak, chống hooking và giám sát toàn vẹn dữ liệu từ lúc mở camera đến máy chủ; kèm chính sách dừng hỗ trợ hệ điều hành quá cũ, khuyến khích cập nhật ứng dụng.

Hàm ý cho quyết định: chọn kênh app hay web là quyết định rủi ro, không chỉ là trải nghiệm. Nếu bắt buộc mở web, cần bù bằng hạn mức giao dịch thấp hơn, giám sát hậu kiểm hoặc xác thực bổ sung.

Vây, CIO/CISO nên hỏi gì khi đánh giá một giải pháp eKYC?

Năm câu hỏi phân biệt giải pháp vận hành được với một bản demo tốt:

1. Chống giả mạo trình diễn: Đã kiểm thử PAD độc lập theo ISO/IEC 30107-3 chưa, ở cấp độ nào, với loại tấn công nào?

2. Chống tiêm chèn: Có phát hiện camera ảo, giả lập, root/jailbreak, hooking không? Kênh web được bảo vệ ra sao?

3. Giấy tờ: Có đối soát logic giữa các trường và phát hiện chỉnh sửa trên phôi thật không?

4. Vận hành: Có thể hậu kiểm để phát hiện các trường hợp chặn nhầm và bỏ lọt trên dữ liệu thực tế không? Có thể điều chỉnh ngưỡng của mô hình linh hoạt?

5. Cập nhật và kiểm toán: Mất bao lâu để cập nhật mô hình và SDK trước kiểu tấn công mới? Có đủ log để điều tra và kiểm toán không?

Takeaway cho CIO/CISO

• Không có lớp phòng thủ đơn lẻ nào là đủ. Phòng thủ hiệu quả là sự kết hợp nhiều lớp: AI phân tích hình ảnh, bảo mật thiết bị, và quy tắc nghiệp vụ đối soát ở giữa.

• Ba điều nên mang vào phòng họp: thứ nhất, đánh giá eKYC theo những kiểu tấn công hệ thống chống được, không theo con số “chính xác bao nhiêu phần trăm”; thứ hai, coi kênh triển khai và phương thức liveness là quyết định rủi ro, có đánh đổi trực tiếp với trải nghiệm và tỷ lệ chuyển đổi; thứ ba, chọn đối tác có năng lực cập nhật liên tục, vì deepfake và giấy tờ giả bằng AI đang tiến hóa nhanh hơn bất kỳ phiên bản sản phẩm nào. Kẻ gian không bao giờ đi qua cửa chính - câu hỏi đúng là hệ thống của bạn đã khóa những cửa nào.
  Tác giả: Phạm Hoàng Tùng – Product Manager – Trung tâm sản phẩm AI Vision - FPT Smart Cloud - Tập đoàn FPT

Many IT leaders are being asked to defend AI results they can’t explain, leading to some disappointment over vendor and platform choices.

A vast majority of CIOs now regret major AI purchases their organizations have made, with many also being asked to defend AI outputs they can’t explain.

Three-quarters of CIOs say they have remorse over at least one major AI vendor or platform selection made in the past 18 months, with some of that disappointment driven by unexpected AI results, according to a survey commissioned by AI orchestration provider Dataiku.

Twenty-nine percent of CIOs say they’ve been asked to justify AI outcomes they could not fully interpret. Those numbers are concerning, says Kurt Muehmel, head of AI strategy at Dataiku.

“Reading that statistic, it makes me a little bit nervous being a member of society where corporations are increasingly running on these systems,” he says. “In the excitement to deploy this technology, which is understandable given the potential for it, we’re a step or two ahead of the governance frameworks.”

AI adoption is moving much more quickly than many other technologies, including machine learning in the last decade, Muehmel notes. With machine learning, there was a gradual building of capabilities, he says, and organizations collectively learned what works and what doesn’t.

“With AI, with agents especially right now, things have gone so quickly that we don’t have yet those full governance and agent ops capabilities in the way that we need,” he adds. “Those best practices aren’t well defined yet in the industry.”

The cost of switching

CIO regrets, meanwhile, seem to be tied to switching costs, Muehmel says. In some cases, companies that are launching agents are tying deployments to specific AI vendors, he adds.

“Imagine an agent, all the instructions, all the orchestration of how that is supposed to work,” he says. “If you too tightly couple that with one of your providers and then you realize that someone else came out with a better model or there’s a better framework, extracting that logic from that underlying system becomes super costly.”

The survey also suggests that CIOs feel heavy pressure to make AI work. Six in 10 say their CEOs have questioned their AI vendor or platform decisions in the past year, and 71% say it’s likely their AI budgets will be cut or frozen if targets aren’t met by mid-2026.

Some IT leaders say the survey’s results hit home. Early in his company’s adoption of AI, Tomas Kazragis, VP of engineering at email and SMS marketing technology provider Omnisend, was asked to explain outputs he couldn’t fully explain.

Like many other IT leaders, Kazragis was caught up in the AI hype and pushed too hard for results, he says. “There was a great deal of movement, but it was difficult to explain what outcomes we were actually aiming for,” he adds. “Basically, we asked people to move — and they did — without a clearly defined objective or measurable result.”

Kazragis still feels pressure to generate positive AI results, he says. “Competitors and professional networks are all buzzing about how AI will change the world,” he adds. “If you’re not in, you’re out. But when you observe all of this critically and keep a clear head, you quickly see the conversation is equal parts snake oil and genuine innovation.”

Moving too fast for regrets

It’s important for IT leaders to remain level-headed and not pressure themselves into following every AI trend blindly, Kazragis says. Still, he doesn’t have any remorse over any AI vendor or product decisions Omnisend has made.

“With the pace of innovation so rapid, we’ve replaced quite a few AI tools — but it’s not something to regret,” he says. “It’s the natural cost of working with innovative solutions, where the risk of replacement is inherently high.”

Lior Gavish, cofounder and CTO at AI observability vendor Monte Carlo, also doesn’t feel any regret over AI tools deployed.

“Some AI technologies proved highly successful, while others less so,” he says. “But experimentation and failures are essential in such a rapidly evolving space.”

Monte Carlo quickly learned that one key to successful deployment is connecting AI tools to the data they need, he adds. “We regretted the times we didn’t do it,” he adds.

Gavish does feel pressure to drive AI forward, he acknowledges. “The pressure to meet AI targets is coming from the rapidly evolving market,” he adds. “Our customers expect it, and our competitors will beat us if we don’t.”

Still, he sees the pressure evolving over time, if not lessening. After FOMO drove early adoption, organizations will shift from experimentation to accountability, he says.

“Enterprises are moving past pilots and asking harder questions about reliability, governance, and measurable ROI,” he adds. “The pace of adoption will continue, but the focus is turning from speed to trust and operational rigor, which is ultimately a healthier phase of the cycle.”

CIOs often get blamed for the consequences of the FOMO coming from above, adds Maya Mikhailov, CEO at fintech AI agent vendor SAVVI AI. Many AI decisions have been forced on tech teams by executives, she says.

“There is a massive disconnect between the AI demos and promises being sold to the C-suite and boards, and the reality on the ground about the enterprise’s data readiness for AI success,” she adds. “Unfortunately, the CIO bears the brunt of this disconnect because they are the tech guy who was supposed to make these choices work, even with legacy systems and broken processes.”

Companies should adopt AI based on specific needs and an understanding of their complexity compared to their value, Mikhailov adds.

“‘We need to buy ChatGPT and figure out what to do with it later’ is not a business strategy, but it’s unfortunately one that the CIO is now responsible for,” she says.

Bối Cảnh

Tình huống dưới đây là minh họa tổng hợp, không phải một vụ việc cụ thể.

Một buổi họp phê duyệt ngân sách AI đầu quý. Hai đề xuất nằm cạnh nhau trong cùng danh mục: một chatbot nội bộ (xây trên mô hình ngôn ngữ lớn, giúp nhân viên tra cứu chính sách nghỉ phép) và một mô hình tham gia quyết định cho vay đối với khách hàng.

Cả hai đi qua cùng một checklist, cùng bộ câu hỏi rủi ro, cùng tốc độ duyệt. Người phê duyệt không xuề xòa. Quy trình chưa bao giờ được thiết kế để phân biệt hai loại đề xuất này.

Chatbot chạy êm, ít ai nhắc đến. Mô hình cho vay tích lũy dần một khuynh hướng từ chối lệch ở một nhóm khách hàng và bị phát hiện muộn, khi việc khắc phục đã tốn kém hơn nhiều so với việc rà soát kỹ từ vòng duyệt đầu tiên.

Hai đề xuất khác nhau ở đâu và khác theo trục nào? Trong quy trình hiện tại, câu trả lời bị gói gọn trong một nhãn: “AI”.

Thế giới đã có nhiều cách trả lời câu hỏi này

Bốn khung quốc tế đã trả lời từng phần câu hỏi “hệ thống AI nào cần kiểm soát chặt hơn”. EU AI Act (hiệu lực từ 1/8/2024) hỏi: hệ thống dùng trong lĩnh vực nào, và lĩnh vực đó thuộc diện cấm, rủi ro cao hay chỉ cần minh bạch? NIST AI RMF (Mỹ, 2023) hỏi: tổ chức quản trị rủi ro theo quy trình nào — Govern, Map, Measure, Manage? MIT AI Risk Repository hỏi: hệ thống có thể vướng loại rủi ro nào trong bảy lĩnh vực tác động? ISO/IEC 42001 (2023) hỏi: rủi ro cho tổ chức và tác động ra bên ngoài đã được đánh giá riêng chưa (theo ISO/IEC 42005:2025)?

Bốn khung này cho CIO biết cần xem xét điều gì. Chúng không giúp so sánh hai đề xuất cạnh nhau trong một buổi họp ngân sách. Muốn vậy, CIO cần thay một checklist bằng ba quyết định tách biệt, mỗi quyết định có một khung tham chiếu riêng.

Ba quyết định, ba khung tham chiếu

Quyết định 1 – Giá trị: AI Value Creators (Thomas, Zikopoulos, Soule - 2025) không phải một khung quản trị rủi ro, mà là sách hướng dẫn doanh nghiệp đưa AI vào hoạt động, do các tác giả thuộc IBM viết. Tác giả đề xuất nhìn danh mục AI qua hai câu hỏi. Một, chi tiền để tiết kiệm (cải tạo cái đang có, thay lao động thủ công bằng tự động hóa) hay để tăng trưởng (mở nguồn doanh thu, mô hình kinh doanh mới)? Hai, AI đóng góp bằng cách nào - tự động hóa (thực thi quy tắc đã biết), tối ưu hóa (điều chỉnh một biến số trong biên độ đã định, như thời điểm gửi thông điệp bán hàng), hay dự đoán (phán đoán nơi kết quả chưa biết, như ước lượng mặt hàng sắp cháy hàng)?

Ghép hai câu hỏi tạo thành một ma trận như ví dụ ở hình bên dưới. Sách khuyên bắt đầu ở ô an toàn nhất - tự động hóa, chi để tiết kiệm - nhưng cảnh báo nếu dừng mãi ở đó, giá trị tạo ra sẽ nhỏ, vì giá trị tăng dần khi dự án dịch từ tiết kiệm sang đổi mới/ tăng trưởng.

Hình 1 BFSI AI Acumen Curve

Quyết định 2 — Rủi ro và giám sát. Mô hình Quản trị AI của Singapore (IMDA, lần đầu công bố 2019) trả lời trực tiếp câu hỏi “hệ thống này cần bao nhiêu sự giám sát của con người” để tổ chức cân nhắc mức giám sát phù hợp. Công thức chỉ có một ma trận hai trục: xác suất xảy ra tổn hại × mức độ nghiêm trọng nếu xảy ra. Từ ma trận đó, xếp hệ thống vào một trong ba mức giám sát:

• Human-in-the-loop: con người ra quyết định cuối cùng, AI chỉ đề xuất.

• Human-over-the-loop: AI tự vận hành, con người giám sát và có thể can thiệp khi cần.

• Human-out-of-the-loop: AI tự quyết hoàn toàn, không cần con người can thiệp theo thời gian thực.

Ngân hàng DBS tại Singapore đã áp dụng ma trận này cho mô hình chống rửa tiền của họ. Thay vì để AI tự động chặn hoặc để con người duyệt từng giao dịch, DBS chọn mức human-over-the-loop: mô hình hỗ trợ sàng lọc các cảnh báo giám sát và đánh giá khả năng cảnh báo là false positive; nhân sự tập trung đánh giá các cảnh báo có mức độ tin cậy thấp hoặc mức rủi ro cao. Đây là một ví dụ tốt về việc sử dụng ngưỡng tin cậy, xếp hạng rủi ro và cơ chế leo thang để phân tích bổ sung đánh giá của con người, thay vì để AI tự động đưa ra quyết định cuối cùng về AML.

Quyết định 3 — Ưu tiên đầu tư. McKinsey sẽ trả lời câu hỏi còn lại: dự án này đáng đầu tư đến đâu và rủi ro có chặn mất khoản đầu tư đó không. McKinsey khuyến nghị mỗi lĩnh vực ưu tiên cần một business case dựa trên ba yếu tố: giá trị tiềm năng, khả năng triển khai và thời gian đầu tư, đồng thời nhấn mạnh rủi ro và kiểm soát phải được tích hợp ngay từ đầu, không phải lớp thẩm định thêm vào sau khi đã chọn xong lĩnh vực.

Cách làm này thể hiện rõ qua một case trong “From promising to productive” (2024): một ngân hàng toàn cầu bắt đầu với 23 lĩnh vực có thể áp dụng AI tạo sinh, thu hẹp còn 2 dựa trên đánh giá tác động kinh doanh (doanh thu, tiết kiệm chi phí, lợi thế cạnh tranh…) và khả năng triển khai kỹ thuật (dữ liệu đã sẵn sàng chưa, hạ tầng có chưa, đội ngũ có kỹ năng chưa…). Đến bước chọn giữa 2 lĩnh vực cuối — trung tâm chăm sóc khách hàng và nghiệp vụ định danh khách hàng doanh nghiệp (KYC) — ngân hàng thêm một lớp sàng lọc thứ ba: rủi ro. Vì dữ liệu KYC nhạy cảm hơn, ngân hàng chọn triển khai trung tâm chăm sóc khách hàng trước. Hai yếu tố giá trị và khả năng triển khai thu hẹp danh sách; và rủi ro quyết định thứ tự triển khai.

Ba câu hỏi này độc lập với nhau. Chatbot nghỉ phép trong phần Bối cảnh có thể tạo giá trị thấp (tiết kiệm nhỏ), cần ít giám sát (human-out-of-the-loop, vì sai thì dễ sửa và ít người bị ảnh hưởng), và dễ triển khai (dữ liệu đã có sẵn). Mô hình cho vay có thể tạo giá trị cao (ảnh hưởng doanh thu tín dụng), nhưng cần giám sát chặt (human-in-the-loop, vì mức độ nghiêm trọng nếu từ chối sai một khách hàng đủ điều kiện là cao), và khả năng triển khai còn tùy vào chất lượng dữ liệu tín dụng hiện có. Một quy trình duyệt gộp chung ba câu hỏi này vào một checklist sẽ luôn bỏ sót ít nhất một trục.

Bảng Action Kit: hai đề xuất ở Bối cảnh sau khi tách ba quyết định

Thang chấm 1–5. Mức giám sát = xác suất sai × mức nghiêm trọng (≤6 out, 7–14 over, ≥15 in). Ưu tiên đầu tư = giá trị × khả năng triển khai (≤6 tạm gác, 7–10 thử nhỏ, 11–16 có điều kiện, ≥17 đầu tư ngay). Điểm và ngưỡng là giả định minh họa của tác giả; mỗi tổ chức tự đặt theo trọng số của mình.

Hai đề xuất từng đi chung một checklist. Tách ba quyết định, chúng ra hai kết luận khác nhau. Chatbot được duyệt nhanh vì sai thì dễ sửa và ít người bị ảnh hưởng. Mô hình cho vay đáng làm, với điểm đầu tư 15, nhưng phải chậm hơn và có người giám sát. Đó là điều một checklist chung ở đầu bài không phân biệt được.

Lời kết

Ba trục trên không có một công thức chung đúng cho mọi tổ chức. Một ngân hàng coi trọng tuân thủ quyền riêng tư sẽ chấm mức độ nghiêm trọng cao hơn cho bất kỳ hệ thống nào chạm đến dữ liệu khách hàng, bất kể xác suất sai thấp đến đâu. Một doanh nghiệp sản xuất ưu tiên tốc độ ra thị trường có thể chấp nhận khả năng triển khai thấp hơn miễn giá trị đủ lớn. Chiến lược, khẩu vị rủi ro và nghĩa vụ tuân thủ của từng ngành quyết định trọng số của ba trục, không phải công thức tự thân. Trước khi chấm điểm bất kỳ hệ thống nào, việc đầu tiên của CIO là thống nhất với ban điều hành và quản trị rủi ro về trọng số này.

Sau khi có trọng số, bốn bước sau sẽ giúp CIO có một bức tranh rõ ràng hơn trong việc hỗ trợ ra quyết định đầu tư vào hệ thống AI:

• Gắn nhãn trục AI Value Creators cho từng hệ thống trong danh mục: loại đóng góp và mục đích chi tiêu. Tính tỷ lệ phần trăm ngân sách theo từng ô.

• Chấm trục giám sát Singapore cho từng hệ thống: xác suất sai × mức độ nghiêm trọng, theo trọng số tổ chức đã thống nhất. Xếp vào in/over/out-of-the-loop.

• Chấm trục đầu tư McKinsey cho từng hệ thống: giá trị kinh doanh × khả năng triển khai × thời gian đầu tư. Xếp theo mức độ rủi ro: ưu tiên ngay, đầu tư có điều kiện, thử nghiệm nhỏ, hoặc tạm gác.

• Ghép ba kết quả lại thành một bảng giám sát cho từng hệ thống. Hệ thống cần in-the-loop nhưng đang chạy như out-of-the-loop: dừng để rà soát ngay, bất kể điểm McKinsey cao hay thấp - giám sát không mặc cả bằng giá trị kinh doanh. Hệ thống out-of-the-loop nhưng bị thẩm định nặng: nếu điểm McKinsey cũng thấp, cân nhắc dừng hẳn thay vì chỉ nới lỏng quy trình; nếu điểm cao, chuyển sang đường duyệt nhanh ngay.
  
  Tác giả: Trần Thị Bảo Thùy | AINEXT Advisory