Tóm tắt: Shadow AI là việc nhân viên dùng dịch vụ AI công ty không quản lý cho công việc. Cùng với code do AI sinh mà không ai kiểm tra, đây là nhóm rủi ro không cần kẻ tấn công ra tay. IPA khuyến nghị cung cấp dịch vụ được phép, quy định dữ liệu được nhập, và kiểm tra kết quả AI.
Bài 5/6 của loạt bài "Tấn công mạng bằng AI tại Nhật Bản". Bản đồ tổng thể ở bài 1: khái niệm và 3 nhóm rủi ro.
Mục lục
- Vì sao cách dùng AI trong nội bộ lại là rủi ro an ninh mạng?
- Shadow AI là gì và gây rò rỉ như thế nào?
- Vì sao cấm dùng AI không giải quyết được shadow AI?
- Code do AI sinh mang những rủi ro nào?
- Quy trình nào giữ được tốc độ của AI mà vẫn kiểm soát được?
- Nên hỏi bên phát triển phần mềm điều gì về việc họ dùng AI?
- Những gì quy định nội bộ không giải quyết được?
1. Vì sao cách dùng AI trong nội bộ lại là rủi ro an ninh mạng?
Cách dùng AI trong nội bộ là rủi ro an ninh mạng vì dữ liệu có thể rời công ty và lỗi có thể vào sản phẩm mà không có cuộc tấn công nào. IPA đã đưa nhóm rủi ro này vào chính mô tả của mối đe doạ hạng 3 khối tổ chức trong "情報セキュリティ10大脅威 2026".
Theo tài liệu giải thích của IPA, mục 「AIの利用をめぐるサイバーリスク」 gồm cả các vấn đề ngoài ý muốn do hiểu chưa đủ về AI: xâm phạm quyền của người khác, rò rỉ thông tin, và vấn đề phát sinh do tin kết quả AI mà không kiểm chứng. IPA viết rằng AI là công cụ hữu ích, nhưng dùng khi chưa hiểu đủ có thể dẫn tới xâm phạm quyền và rò rỉ thông tin.
Nhóm rủi ro này khác hai nhóm còn lại ở một điểm. Với phishing hay prompt injection, công ty phòng thủ trước người bên ngoài. Ở đây, người tạo ra rủi ro là nhân viên đang cố làm việc nhanh hơn.
2. Shadow AI là gì và gây rò rỉ như thế nào?
Shadow AI là việc nhân viên dùng dịch vụ AI mà công ty không cấp phép hoặc không biết tới cho công việc, thường bằng tài khoản cá nhân. Thuật ngữ này dựa trên shadow IT, tức phần mềm và dịch vụ dùng trong công ty ngoài sự quản lý của bộ phận IT.
Rò rỉ xảy ra theo đường rất đơn giản. Nhân viên dán biên bản họp, mã nguồn, dữ liệu khách hàng vào ô chat để nhờ tóm tắt hoặc sửa. Từ lúc đó, dữ liệu nằm ở nơi công ty không kiểm soát. Tuỳ cài đặt của dịch vụ, dữ liệu có thể được lưu lại hoặc dùng để huấn luyện mô hình.
Về mức độ phổ biến, IPA dẫn một khảo sát của một công ty AI của Mỹ:
- 77% người dùng sao chép và dán dữ liệu vào AI tạo sinh làm prompt khi làm việc.
- 82% trong số đó làm việc này bằng tài khoản không do tổ chức quản lý.
IPA nêu thêm một điểm ít được chú ý: bản thân việc công ty không nhận biết được nhân viên đang dùng AI bằng tài khoản cá nhân đã là rủi ro. Công ty không bảo vệ được thứ mình không biết là tồn tại.
| Dịch vụ AI công ty cấp phép | Shadow AI | |
|---|---|---|
| Tài khoản | Do công ty quản lý, thu hồi được khi nhân viên nghỉ | Cá nhân, công ty không thấy |
| Cài đặt dùng dữ liệu để huấn luyện | Công ty quyết định, kiểm tra được | Tuỳ từng người, thường để mặc định |
| Lịch sử sử dụng | Có log | Không có |
| Điều khoản dịch vụ | Đã được rà soát | Chưa ai đọc |
3. Vì sao cấm dùng AI không giải quyết được shadow AI?
Cấm dùng AI không giải quyết được shadow AI vì lệnh cấm không làm mất nhu cầu, chỉ làm việc sử dụng trở nên vô hình. Nhân viên có hạn chót vẫn sẽ dùng công cụ giúp họ kịp việc, trên điện thoại hoặc máy cá nhân.
IPA đi theo hướng này trong phần biện pháp dành cho lãnh đạo. Mục đầu tiên là xem xét việc đưa dịch vụ AI vào sử dụng để tránh shadow AI, sau đó mới tới các quy định. Các biện pháp IPA liệt kê:
- Chọn và cung cấp dịch vụ AI được phép. Kiểm tra điều khoản khi ký hợp đồng.
- Soạn quy định sử dụng. Hạn chế dùng tài khoản cá nhân cho công việc, nêu rõ cách xử lý khi vi phạm.
- Tắt việc dùng dữ liệu nhập vào để huấn luyện. IPA gọi là thiết lập opt-out triệt để khi dùng dịch vụ ngoài.
- Nắm tình hình sử dụng. Quản lý tài sản IT, dùng log truyền thông để biết dịch vụ AI nào đang được truy cập.
- Đào tạo. Không nhập thông tin mật một cách dễ dãi, hiểu rằng AI có thể trả lời sai, tránh phụ thuộc quá mức.
Quy định hiệu quả nhất là quy định cụ thể. "Không nhập thông tin mật" quá mơ hồ. Nên liệt kê theo loại: dữ liệu cá nhân của khách hàng, số liệu tài chính chưa công bố, mã nguồn, bản vẽ thiết kế, nội dung hợp đồng.
4. Code do AI sinh mang những rủi ro nào?
Code do AI sinh mang 4 rủi ro an ninh chính, và phần lớn phát sinh khi công cụ AI được dùng mà thiếu kiểm tra của người có chuyên môn.
| Rủi ro | Việc xảy ra | Nguồn |
|---|---|---|
| Lỗ hổng trong code | AI sinh code chạy được nhưng thiếu kiểm tra đầu vào, phân quyền, xử lý lỗi | IPA: code do AI sinh có trường hợp chứa lỗ hổng |
| Thư viện không tồn tại | AI đề xuất tên package không có thật. Kẻ tấn công đăng ký sẵn package độc hại với tên đó và chờ lập trình viên cài | IPA dẫn báo cáo của Koi Security về các cuộc tấn công chuỗi cung ứng lợi dụng điểm này |
| Công cụ lập trình bị cài lệnh | Chỉ thị độc hại giấu trong file của dự án khiến công cụ AI chạy lệnh với quyền của lập trình viên | IPA: lỗ hổng được phát hiện ở trình soạn code Cursor |
| Mã nguồn và bí mật rời công ty | Lập trình viên dán code, khoá API, cấu hình vào dịch vụ AI không được cấp phép | Chính là shadow AI ở mục 2 |
Rủi ro thứ hai đáng chú ý vì nó biến một điểm yếu của AI thành đường tấn công chuỗi cung ứng. AI đôi khi tạo ra thông tin không có thật và trình bày như sự thật, hiện tượng gọi là hallucination. Với văn bản, hậu quả là một câu sai. Với code, hậu quả là một dòng lệnh cài phần mềm của kẻ tấn công vào hệ thống.
Hallucination không chỉ là vấn đề của lập trình viên. IPA nêu một vụ ở bang Texas, Mỹ: phiên điều trần tháng 01/2025 phát hiện một bản ý kiến pháp lý nộp năm trước đó trích dẫn các án lệ không tồn tại. Luật sư soạn bản đó bằng AI tạo sinh và cho biết không rõ AI có thể tạo ra nội dung như vậy.
AI cũng có mặt còn lại. Gói Project YATA-Shield của chính phủ Nhật, công bố ngày 18/05/2026, có hạng mục cảnh báo nhà cung cấp phần mềm dùng cả AI hiệu năng cao để phát hiện và xử lý lỗ hổng sớm hơn trong toàn bộ vòng đời phát triển phần mềm. Câu hỏi không phải có dùng AI trong phát triển phần mềm hay không. Câu hỏi là ai kiểm tra kết quả, và việc kiểm tra đó có để lại bằng chứng không.
5. Quy trình nào giữ được tốc độ của AI mà vẫn kiểm soát được?
Quy trình giữ được tốc độ của AI mà vẫn kiểm soát được là quy trình coi mọi thứ AI sinh ra là bản nháp cần người chịu trách nhiệm xác nhận. Năm quy tắc dưới đây áp dụng cho đội phát triển phần mềm.
- Mọi thay đổi đều qua review của người. Code do AI sinh đi cùng đường với code người viết: pull request, người review có tên, lý do thay đổi.
- Kiểm thử là điều kiện, không phải việc làm thêm. AI sinh code nhanh nên lỗi cũng vào nhanh. Kiểm thử tự động là thứ giữ nhịp.
- Thư viện mới phải được kiểm tra trước khi cài. Package có tồn tại không, ai duy trì, có bao nhiêu người dùng. Không cài theo đề xuất của AI mà không tra lại.
- Bí mật không vào prompt. Khoá API, mật khẩu, dữ liệu thật của khách hàng không được dán vào công cụ AI.
- Prompt và chỉ dẫn cho AI cũng được quản lý phiên bản. Prompt quyết định kết quả, nên thay đổi prompt cần được ghi lại như thay đổi code.
Quy tắc 5 là việc VAON đang làm ở các dự án nội bộ. Đội VAON lưu prompt sinh 要件定義書 (tài liệu định nghĩa yêu cầu) dưới dạng file trong kho mã nguồn. Mỗi thay đổi đi qua pull request, có lý do và nhật ký thay đổi. Trước khi chấp nhận, đội so sánh kết quả mới với kết quả cũ trên một bộ đầu vào mẫu cố định. Cách làm này hiện mới áp dụng cho dự án nội bộ của VAON.
Quy tắc 1 và 2 áp dụng cho mọi dự án của VAON. Mọi dự án đều lưu hồ sơ review và kiểm thử, và khách hàng xem được hồ sơ đó. Trong năm 2026, "code do AI viết thì ai kiểm tra" là một trong ba câu khách hàng hỏi VAON nhiều nhất. Hồ sơ này là câu trả lời.
6. Nên hỏi bên phát triển phần mềm điều gì về việc họ dùng AI?
Bên thuê phát triển phần mềm nên hỏi vendor 5 câu về việc dùng AI, vì nhiều đội phát triển hiện nay dùng AI ở mức nào đó. Câu trả lời "chúng tôi không dùng AI" cần được kiểm tra lại cũng kỹ như câu trả lời "AI làm hết".
- Đội của anh chị dùng công cụ AI nào, bằng tài khoản công ty hay cá nhân?
- Mã nguồn và dữ liệu của chúng tôi có được nhập vào công cụ đó không? Cài đặt về việc dùng dữ liệu để huấn luyện ra sao?
- Code do AI sinh được ai review? Có hồ sơ review mà chúng tôi xem được không?
- Thư viện mới được kiểm tra thế nào trước khi đưa vào dự án?
- Dữ liệu thật của chúng tôi có được dùng trong môi trường phát triển và kiểm thử không?
Với câu 3, VAON trả lời được bằng hồ sơ review và kiểm thử của từng dự án. Các câu còn lại phụ thuộc vào thoả thuận của từng dự án, và nên được ghi vào hợp đồng hoặc tài liệu khởi động. Khách hàng có quy định riêng về công cụ AI thì nên nêu ngay từ đầu.
7. Những gì quy định nội bộ không giải quyết được?
Quy định nội bộ về AI có 3 giới hạn, và biết trước giúp công ty không kỳ vọng sai.
- Quy định không nhìn thấy thiết bị cá nhân. Nhân viên dùng AI trên điện thoại riêng nằm ngoài mọi log. Phần này chỉ giải quyết được bằng việc cung cấp công cụ được phép đủ tốt, và bằng đào tạo.
- Review không bắt được mọi lỗi. Người review cũng bỏ sót, nhất là khi lượng code tăng nhanh nhờ AI. Review cần đi cùng kiểm thử tự động và công cụ quét lỗ hổng.
- Quy định cũ nhanh. Công cụ AI thêm tính năng mới hằng tháng, ví dụ khả năng tự chạy lệnh hoặc tự đọc web. Quy định viết cho chatbot không phủ được AI agent. Nên rà lại định kỳ.
Bạn muốn biết đội phát triển của mình đang dùng AI ở đâu và ai đang kiểm tra kết quả? VAON cùng bạn rà soát quy trình, từ quy định nhập dữ liệu tới hồ sơ review. Đăng ký tư vấn miễn phí
Bài tiếp theo: Danh sách kiểm tra 30 ngày và câu hỏi nên gửi cho vendor
Tài liệu tham khảo (kiểm tra ngày 10/10/2026)
- IPA, 情報セキュリティ10大脅威 2026, tài liệu giải thích khối tổ chức: https://www.ipa.go.jp/security/10threats/10threats2026.html
- 国家サイバー統括室 và 13 cơ quan, AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について ～Project YATA-Shield～ (18/05/2026): https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Package.pdf
