Buổi chiều Thứ Tư đó
Tuấn - junior developer trong team - đến chỗ tôi với vẻ mặt không quen. Không phải lo lắng, không phải hỏi kỹ thuật. Là một thứ gì đó khác, khó đặt tên hơn.
"Anh ơi, em có làm gì sai không?"
Tôi nhìn màn hình anh ấy chỉ sang. Một cửa sổ ChatGPT đang mở. Trong đó là toàn bộ đoạn code của service xử lý đơn hàng cho một khách hàng thương mại điện tử lớn - tên biến đặt theo domain business của họ, comment bằng tiếng Anh đủ để ai cũng hiểu đây là hệ thống của ai, và ở dưới cùng của đoạn code, một connection string đến cơ sở dữ liệu production với thông tin đăng nhập đầy đủ.
Tuấn paste vào để hỏi ChatGPT giúp debug một lỗi timeout.
ChatGPT đã trả lời, rất hữu ích, lỗi timeout được fix. Nhưng câu hỏi thật sự, theo tôi, là câu hỏi khác.
"Em đã làm xong với cái cửa sổ đó chưa?" tôi hỏi.
"Rồi anh."
"Em có xóa conversation đó đi chưa?"
Tuấn nhìn tôi, chưa hiểu tại sao đó lại là việc quan trọng.
Đó là lúc tôi biết mình phải viết bài này.
Không phải tội lỗi - là khoảng trống trong nhận thức
Tôi không phán xét Tuấn. Thực ra trong lần đầu tôi dùng AI coding tools, tôi cũng đã paste code khách hàng vào. Bản năng debug là bản năng rất tự nhiên - gặp lỗi, tìm người giỏi hơn để hỏi. ChatGPT, Claude, Gemini đang là "người giỏi nhất phòng" trong mắt nhiều developer.
Vấn đề là AI không ký NDA với khách hàng của bạn. Nhưng bạn thì có.
Và đây không phải lo lắng lý thuyết. Theo báo cáo GitGuardian 2026, trong năm 2025 có gần 29 triệu bí mật bị lộ trên GitHub public - tăng 34% so với năm trước. Đặc biệt hơn: các commit có sự hỗ trợ của AI coding tools lộ bí mật ở tỷ lệ cao gấp đôi bình thường. 77% nhân viên từng paste thông tin công ty vào AI tools, và 82% trong số đó dùng tài khoản cá nhân - tức là ngoài tầm kiểm soát của bộ phận bảo mật.
Đây là vấn đề của cả ngành, không phải của Tuấn.
Ba vùng rủi ro một developer cần hiểu rõ
Vùng 1: Bảo mật mã nguồn - thứ biến mất không ai thấy
Khi bạn paste code vào một AI tool, điều gì xảy ra với dữ liệu đó?
Câu trả lời phụ thuộc vào từng công cụ, từng plan, và chính sách của nhà cung cấp - và thay đổi theo thời gian. ChatGPT có thể dùng conversation của bạn để huấn luyện model nếu bạn không tắt tính năng đó. GitHub Copilot Business và Enterprise có chính sách rõ hơn, không dùng code để train model, nhưng vẫn có thể gửi đoạn code đến server để xử lý.
Điều quan trọng nhất: code của khách hàng không phải của bạn để chia sẻ.
Dù bạn có xóa conversation ngay sau đó, bạn không biết dữ liệu đó đã đi đến đâu trong vài giây vừa rồi. Đây không phải hoang tưởng - đây là cách mọi SaaS tool hoạt động.
Quy tắc thực tế:
- Không bao giờ paste code có chứa thông tin nhận dạng khách hàng (tên biến, comment, domain)
- Không bao giờ paste connection string, API key, token - dù là test hay production
- Nếu cần AI giúp debug, trừu tượng hóa đoạn code trước: đổi tên biến, xóa context nhạy cảm
Vùng 2: Bản quyền code - một vụ kiện bạn nên biết tên
Năm 2022, một nhóm developer kiện GitHub, Microsoft, và OpenAI vì cho rằng GitHub Copilot được huấn luyện trên hàng triệu repository mã nguồn mở mà không tuân thủ các điều khoản license. Đến đầu 2026, vụ kiện - Doe v. GitHub - vẫn đang trong quá trình điều tra và chưa có phán quyết cuối.
Đây là vụ kiện đặt ra câu hỏi mà chưa có câu trả lời chính thức: Code do AI generate, ai sở hữu nó?
Theo Luật Sở hữu trí tuệ Việt Nam sửa đổi 2025: AI không được coi là chủ thể quyền SHTT. Sản phẩm AI tạo ra nếu không có đóng góp sáng tạo thực chất của con người sẽ không được bảo hộ.
Dịch ra tiếng không legalese: code AI viết ra cho bạn có thể không được bảo hộ bản quyền, và trong một số trường hợp có thể bị coi là "derived work" từ training data - tức là code của người khác.
Rủi ro thực tế là gì? Với project nội bộ, nhỏ - tạm thời không lo nhiều. Với sản phẩm thương mại, phần mềm đem đi bán, hoặc code có yếu tố bản quyền nhạy cảm - bạn cần biết công cụ AI mình đang dùng có cơ chế gì để tránh tái tạo code có bản quyền. GitHub Copilot có tính năng "duplication detection" - bật nó lên nếu bạn chưa làm.
Quy tắc thực tế:
- Review kỹ output AI trước khi commit vào codebase thương mại
- Với dự án có yêu cầu IP rõ ràng: document lại bạn đã dùng tool gì, prompt gì
- Dùng các AI tool có chính sách IP rõ ràng và đã được verify (GitHub Copilot Enterprise, Amazon CodeWhisperer Professional)
Vùng 3: Dữ liệu người dùng - ranh giới bạn không được thấy nhưng nó ở đó
Đây là vùng rủi ro nghiêm trọng nhất và ít người nghĩ đến nhất.
Hãy tưởng tượng bạn đang debug một module xử lý đơn hàng. Bạn lấy một order thật từ production database - với tên khách hàng, địa chỉ giao hàng, số điện thoại - để reproduce lỗi. Rồi paste đoạn code cùng sample data đó vào AI tool.
Bạn vừa đưa dữ liệu cá nhân của người dùng ra ngoài biên giới hệ thống của mình. Không có sự đồng ý của họ. Không biết dữ liệu đó sẽ được xử lý như thế nào.
Ở Việt Nam, Luật Bảo vệ dữ liệu cá nhân có hiệu lực từ 1/1/2026. Điều này có nghĩa là việc chia sẻ dữ liệu cá nhân với bên thứ ba (kể cả AI tool) mà không có cơ sở pháp lý phù hợp là vi phạm pháp luật - không phải vi phạm đạo đức suông nữa.
Quy tắc thực tế:
- Không bao giờ dùng dữ liệu production thật để debug với AI - dùng fixture, mock data, hoặc dữ liệu đã anonymize
- Nếu cần reproduce lỗi có dữ liệu thật: làm trong môi trường staging đã được kiểm soát
- Với hệ thống có dữ liệu nhạy cảm (y tế, tài chính, trẻ em): cân nhắc kỹ trước khi cho phép AI tool kết nối vào codebase
Chính sách tôi đang áp dụng ở team
Sau cuộc trò chuyện với Tuấn, tôi ngồi lại và viết một tài liệu ngắn - không phải policy dài 20 trang không ai đọc, mà là 3 câu hỏi mỗi developer phải tự hỏi trước khi paste bất kỳ thứ gì vào AI tool:
1. Thứ này có thuộc về khách hàng hoặc người dùng không?
Nếu có → đừng paste nguyên xi. Trừu tượng hóa trước.
2. Thứ này có phải là bí mật của tổ chức không?
API key, connection string, business logic độc quyền, kiến trúc hệ thống của client - đây là bí mật. Không đi ra ngoài.
3. Công cụ này có chính sách data retention và training rõ ràng không?
Nếu bạn không biết câu trả lời - đó là dấu hiệu cần đọc Terms of Service trước khi dùng.
Ba câu hỏi này không mất quá 10 giây. Nhưng có thể tránh cho bạn một cuộc trò chuyện rất khó chịu với khách hàng sau này.
Gửi các bạn trẻ đang đọc bài này
Tôi biết các bạn đang học cách dùng AI để làm việc nhanh hơn. Đó là điều tốt - thực ra rất tốt. AI sẽ là một trong những công cụ quan trọng nhất trong sự nghiệp của các bạn.
Nhưng có một điều các bạn cần học song song, và không có AI tool nào dạy được: ranh giới giữa thông tin của mình và thông tin của người khác.
Tuấn không cố ý gây hại. Anh ấy chỉ đang làm những gì tự nhiên nhất với một developer - tìm cách sửa bug nhanh. Cái thiếu không phải là ý định tốt, mà là một framework để biết ranh giới ở đâu.
Xây dựng framework đó sớm. Nó sẽ bảo vệ bạn, bảo vệ khách hàng của bạn, và phân biệt bạn với đa số developer chỉ nghĩ đến tốc độ.
Triết lý
Tôi "believe in basic". Và một trong những "basic" nhất trong nghề là: dữ liệu người khác giao cho bạn là niềm tin, không phải nguyên liệu để bạn xử lý tùy thích.
AI thay đổi tốc độ làm việc. Nhưng nó không thay đổi câu hỏi cốt lõi: dữ liệu này có phải của mình để dùng không?
Trước khi có AI, câu hỏi đó áp dụng cho việc bạn commit gì lên repo, bạn gửi gì qua email, bạn nói gì trong cuộc họp với vendor. Bây giờ, nó mở rộng ra thêm một chiều nữa: bạn paste gì vào AI tool.
Câu hỏi không thay đổi. Chiều áp dụng thay đổi.
Team của bạn đang xử lý điều này như thế nào?
Công ty bạn đã có policy rõ ràng về việc dùng AI tools với code và dữ liệu khách hàng chưa? Hay hiện tại vẫn đang để mỗi người tự quyết? Rất tò mò muốn nghe cách các team đang navigate vùng xám này 👇
/Son Do - believe in basic
#1percentbetter #AIEthics #DeveloperMindset #DataPrivacy #SoftwareEngineering
