Luật DLCN Part 4: Khi Luật quy định Code – Phân tích Dự thảo Nghị định

Trong các phần trước, mình đã đặt câu hỏi về việc làm sao chúng ta có thể “unlearn” (quên) dữ liệu đã nạp vào một Neural Network, thì bản Dự thảo Nghị định hướng dẫn Luật Bảo vệ Dữ liệu Cá nhân vừa được tung ra đã cho mình câu trả lời. Và thú thật, câu trả lời này mang đậm màu sắc hành chính hóa một vấn đề vốn dĩ thuần túy kỹ thuật.

Đọc qua toàn bộ Dự thảo, cảm giác chung của mình là: Sự bất tương thích lớn giữa tư duy quản lý bằng giấy phép và thực tế vận hành của thế giới số.

Dưới đây là các điểm nghẽn chí mạng mà dân làm tech, đặc biệt là các Startup AI và Blockchain, cần phải nhìn thẳng vào mặt sự thật.

1. “Án tử” cho AI: Retrain or Die?

Trong bài trước, mình đã phân tích rằng LLM không giống như một file Excel để bạn muốn xóa dòng nào thì xóa. Nhưng Điều 10 của Dự thảo dường như bỏ qua thực tế này.

Cơ quan soạn thảo đưa ra một yêu cầu nghe rất “đúng quy trình” nhưng sai kỹ thuật: Nếu phát hiện vi phạm, bạn có thể bị yêu cầu huấn luyện lại thuật toán (retrain) (điểm c khoản 6 Điều 10).

Hãy dừng lại một chút. Với một model cỡ GPT-OSS-120b mà chúng ta hay bàn tới, chi phí training tính bằng triệu đô và hàng tháng trời compute. Việc yêu cầu retrain chỉ vì một vi phạm dữ liệu cục bộ (local data violation) về mặt kinh tế không khác gì yêu cầu đập bỏ cả tòa nhà vì một viên gạch bị lỗi.

Nghiêm trọng hơn, Dự thảo có quy định về việc “hủy thuật toán” nếu vi phạm nghiêm trọng. Đây là một rủi ro pháp lý quá lớn cho bất kỳ ai muốn build core AI tại Việt Nam. Tài sản trí tuệ của bạn có thể bị xóa sổ theo mệnh lệnh hành chính.

2. Giấy phép con cho Data Processing

Đây là phần mình thấy lo ngại nhất cho anh em làm Outsourcing hoặc SaaS. Dự thảo đã biến hoạt động “Xử lý dữ liệu” từ một hành vi dân sự thành một Ngành nghề kinh doanh có điều kiện.

Theo Điều 22 và Điều 23, để cung cấp dịch vụ xử lý dữ liệu (được định nghĩa siêu rộng: từ phân tích dữ liệu, điện toán đám mây, đến API vị trí), bạn cần:

• Xin Giấy chứng nhận đủ điều kiện từ Bộ Công an.
• Phải có tối thiểu 03 nhân sự có bằng đại học và 2 năm kinh nghiệm về luật/an ninh mạng/CNTT.

Hãy tưởng tượng bạn viết một con bot đơn giản để clean data từ Excel sang JSON cho khách hàng. Bùm! Bạn trở thành “nhà cung cấp dịch vụ xử lý dữ liệu”. Bạn có đủ tiền thuê 3 ông nhân sự cứng chỉ để duy trì cái license này không? Nếu không, bạn đang hoạt động chui.

Ai làm về document intelligent cũng đều biết tesseract là một OCR engine, nhưng liệu nó được xếp vào hàng AI theo điểm h khoản 1 Điều 22 không? Hay là tesseract 4.0 (LSTM) thì mới là AI còn tesseract 3.0 thì là thuần nhận dạng pattern? Nếu bạn cung cấp dịch vụ API OCR sử dụng AI làm backend, và user dùng nó để OCR CV có chứa dữ liệu nhạy cảm, thì liệu vai trò của bạn như thế nào? Tương tự như vậy, nếu người dùng sử dụng general AI platform để tạo ra các dịch vụ dự doán hành vi người dùng (điểm e khoản 1) thì sao?

3. Blockchain: PII buộc phải off-chain

Anh em Web3 hay nói về Immutability (Tính bất biến) như một tôn chỉ. Nhưng luật pháp thì cần Reversibility (Khả năng đảo ngược/sửa đổi).

Điều 11 của Dự thảo đã giải quyết mâu thuẫn này bằng một cú chốt hạ: Cấm lưu trữ trực tiếp dữ liệu cá nhân trên Blockchain. Bạn chỉ được phép lưu trữ khi dữ liệu đã được khử nhận dạng (de-identified) hoặc chỉ lưu mã băm (hash).

Về mặt kiến trúc hệ thống, điều này ép chúng ta phải quay về mô hình Hybrid: Data để off-chain (cơ sở dữ liệu truyền thống) và chỉ đẩy Proof/Hash lên On-chain.

• Tin tốt: Nó hợp pháp hóa mô hình Zero-Knowledge Proof.
• Tin xấu: Những dự án định lưu full profile người dùng on-chain để minh bạch hóa coi như vi phạm luật ngay từ khâu thiết kế (privacy by design).

4. Cái bẫy “Sandbox” cho Startup

Dự thảo có vẻ thấu hiểu nỗi khổ doanh nghiệp nhỏ khi đưa ra Điều 42: Doanh nghiệp siêu nhỏ, Startup được miễn lập “Bộ phận bảo vệ dữ liệu”.

Nghe rất bùi tai, nhưng hãy đọc kỹ phần trừ trường hợp: Bạn sẽ MẤT quyền miễn trừ này nếu bạn xử lý “Dữ liệu nhạy cảm”.

Vậy “Dữ liệu nhạy cảm” gồm những gì?

• Thông tin tài khoản ngân hàng.
• Dữ liệu vị trí (Location data).

Thử hỏi có Startup công nghệ nào thời nay (E-commerce, Delivery, Fintech, Booking) mà không đụng vào Vị trí hay Thanh toán?

=> Kết luận: Cái “Sandbox” này dường như vô nghĩa với Tech Startup. Ngay từ ngày đầu, bạn đã phải gánh full trách nhiệm tuân thủ như một tập đoàn lớn.

5. Tin tốt cho doanh nghiệp “bình thường”

Sau khi ném đá tơi bời các quy định về AI và License, mình phải dành một lời khen cho khoản 3 Điều 18. Đây chính là điểm sáng duy nhất giúp giải cứu 99% doanh nghiệp Việt Nam khỏi vũng lầy pháp lý mà Nghị định 13/2023 vô tình tạo ra.

Dưới thời Nghị định 13, về mặt kỹ thuật, mỗi lần bạn quẹt thẻ Visa trả tiền server (qua Stripe/PayPal) hay gửi địa chỉ khách hàng cho FedEx/DHL để ship hàng đi Mỹ, bạn đang thực hiện một hành vi “Chuyển dữ liệu ra nước ngoài”. Theo quy định cũ, bạn phải lập hồ sơ đánh giá tác động (TIA) cho… từng giao dịch hoặc từng đối tác đó. Điều này biến mọi hoạt động thương mại bình thường trở thành hành vi vi phạm pháp luật tiềm tàng (technically illegal).

Dự thảo mới đã sửa sai bằng cách miễn trừ lập hồ sơ TIA cho các trường hợp:

• Thực hiện hợp đồng (thanh toán, logistics, vận chuyển).
• Quản lý nhân sự nội bộ (HR) theo quy chế lao động.

Tin tốt: Vẫn còn may mắn là tại khoản 3 Điều 18, bạn không cần đánh giá tác động chuyển dữ liệu xuyên biên giới nếu việc xử lý dữ liệu là để thực hiện nghĩa vụ theo hợp đồng, hay để quản lý nhân sự

Ví dụ: Khi bạn gửi data khách hàng cho Viettel Post để ship hàng từ Hà Nội vào Sài Gòn, hành động này về mặt pháp lý không phải là “Chuyển dữ liệu ra nước ngoài”, kể cả khi data này được route qua các IaaS/PaaS provider nước ngoài như AWS.

Tin xấu: Đừng vội mừng. Miễn lập hồ sơ chuyển đi không có nghĩa là bạn được miễn làm Hồ sơ đánh giá tác động xử lý dữ liệu cá nhân (DPIA).

Trước khi dữ liệu đó rời khỏi Việt Nam, bạn đã “thu thập” nó. Bạn vẫn PHẢI lập “Hồ sơ đánh giá tác động xử lý dữ liệu” (Mẫu 02a/04). Trong hồ sơ nội bộ này, bạn buộc phải liệt kê rõ: “Tôi có chia sẻ tên, sđt khách hàng cho bên vận chuyển A, bên thanh toán B”.

Túm lại: Dự thảo này là một mũi tên trúng hai đích. Nó cởi trói cho các hoạt động thương mại truyền thống để dòng tiền và hàng hóa lưu thông, nhưng lại siết chặt gọng kìm lên các công ty công nghệ thuần túy bằng các yêu cầu về kiến trúc hệ thống và giấy phép.

6. Nhân sự DPO: hết kiêm nhiệm?

Nếu bạn đang điều hành một doanh nghiệp truyền thống – ví dụ một chuỗi F&B hay một công ty vận tải – và nghĩ rằng “Bảo vệ dữ liệu” là việc của mấy ông IT, thì Dự thảo mới sẽ khiến bạn giật mình khi nhìn vào bảng lương (payroll).

Dưới thời Nghị định 13/2023, yêu cầu về nhân sự rất mở: Bạn chỉ cần “chỉ định” một bộ phận hoặc cá nhân phụ trách. Thông thường, Giám đốc HR hoặc IT Manager sẽ “gánh” thêm việc này. Chi phí tăng thêm gần như bằng 0.

Nhưng Dự thảo Nghị định (Điều 13) đã dựng lên một hàng rào kỹ thuật cho chính vị trí này:

• Bằng cấp: Phải tốt nghiệp Đại học/Cao đẳng.
• Kinh nghiệm: Phải có ít nhất 02 năm kinh nghiệm trong lĩnh vực Luật, CNTT, hoặc An ninh mạng…
• Chứng chỉ: Phải có chứng nhận đào tạo từ các tổ chức được cấp phép.

Điều này có nghĩa là gì với doanh nghiệp thường? Bạn không thể giao việc này cho một nhân viên Admin hay một bạn IT Support mới ra trường được nữa. Bạn có hai lựa chọn:

• Option A: Trả lương cao để tuyển một chuyên gia có 2 năm kinh nghiệm và chứng chỉ theo đúng quy định.
• Option B: Thuê ngoài (Outsource) dịch vụ DPO theo Điều 16. Nghĩa là bạn sẽ phải tốn thêm một khoản “phí bảo kê dữ liệu” hàng tháng cho các công ty luật hoặc công ty công nghệ.

Tại sao bạn không thể lờ đi? Vì chỉ cần bạn trả lương cho nhân viên qua tài khoản ngân hàng, bạn đã xử lý “Dữ liệu tài chính” (Dữ liệu nhạy cảm). Chỉ cần bạn lưu hồ sơ khám sức khỏe định kỳ, bạn đã dính “Dữ liệu sức khỏe”. Quy định này biến vị trí DPO từ một chức danh “cho có” trở thành một vị trí bắt buộc phải có chuyên môn (và tốn kém).

Tin an ủi duy nhất: Ban soạn thảo biết rằng hiện tại Việt Nam chưa đủ người, nên họ cho chúng ta một “ân huệ” tại Điều 43: Bạn có hạn chót đến ngày 01/01/2027 để chuẩn bị nhân sự này. Hãy bắt đầu budget từ bây giờ đi là vừa.

7. Từ Tesseract đến General AI: Ranh giới mờ nhạt của AI

Một trong những điểm thú vị (và đáng sợ) nhất của Dự thảo này nằm ở định nghĩa về “Dịch vụ xử lý dữ liệu”. Hãy cùng mổ xẻ một case study kinh điển mà ai làm về Document Intelligence cũng biết: Tesseract OCR.

Tesseract: Heuristic hay AI?

Theo điểm h, khoản 1, Điều 22, dịch vụ xử lý dữ liệu tự động dựa trên “trí tuệ nhân tạo” (Artificial Intelligence) là ngành nghề kinh doanh có điều kiện, phải xin giấy phép.

Điều này đặt ra một câu hỏi đậm chất kỹ thuật:

• Nếu tôi dùng Tesseract 3.0, vốn dựa trên các thuật toán nhận dạng mẫu (Pattern Matching/Heuristic) và mô hình thống kê (Gaussian Mixture Models), liệu đó có phải là AI? Có thể cãi là không.
• Nhưng nếu tôi dùng Tesseract 4.0 trở lên? Engine của nó đã chuyển sang LSTM (Long Short-Term Memory) – một dạng Recurrent Neural Network. Mà Neural Network thì đích thị là Deep Learning, là tập con cốt lõi của AI hiện đại.

Hệ quả pháp lý:

Dưới góc nhìn của nhà làm luật, họ sẽ không phân biệt đâu là Heuristic, đâu là Neural Net. Chỉ cần hệ thống của bạn “tự động” và “thông minh” hơn một câu lệnh if-else thông thường, bạn sẽ bị tóm vào rọ của Điều 22.

Điều trớ trêu của “Code is Law” ở đây là: Để an toàn về mặt pháp lý (không cần xin giấy phép AI), có khi bạn phải… hạ cấp (downgrade) công nghệ của mình về những năm 2000 để nó “bớt thông minh” đi.

Cái bẫy “Wrapper API” và Dữ liệu nhạy cảm

Giả sử bạn build một dịch vụ API OCR đơn giản (Wrapper quanh Tesseract) để anh em dev khác dùng.

Một ngày đẹp trời, người dùng (Client) gửi lên API của bạn một file PDF là CV xin việc.

• Về mặt dữ liệu: Trong CV đó có trường “Dân tộc” hoặc “Tôn giáo”. Bùm! Đây là Dữ liệu nhạy cảm theo Điều 4.
• Về mặt vai trò: Bạn đang cung cấp dịch vụ cho phép người khác xử lý dữ liệu nhạy cảm thông qua hệ thống của mình. Theo khoản 1 Điều 22, bạn chính là “Tổ chức kinh doanh dịch vụ xử lý dữ liệu cá nhân”³.

Bạn – một solo dev viết cái API 5$/tháng – bỗng dưng phải gánh trách nhiệm của một tổ chức có giấy phép, phải có 3 nhân sự trình độ đại học và 2 năm kinh nghiệm. Nếu không, bạn đang kinh doanh trái phép.

General AI Platform và Dự đoán hành vi

Mở rộng ra hơn nữa, điểm e, khoản 1, Điều 22 quy định dịch vụ “phân tích và khai thác dữ liệu… dự đoán hành vi người dùng” cũng phải xin giấy phép.

Nếu bạn cung cấp một General AI Platform (như một dịch vụ AutoML hoặc Churn Prediction API) cho phép khách hàng tự định nghĩa bài toán:

• Khách hàng nộp dữ liệu lịch sử mua hàng.
• Hệ thống của bạn dự đoán ai sắp rời bỏ dịch vụ (Churn).

=> Hành động này chính xác là “dự đoán hành vi người dùng”.

Dù bạn chỉ cung cấp cái “xẻng” (công cụ), nhưng luật đang quy định người bán xẻng cũng phải chịu trách nhiệm như người đào vàng. Ranh giới giữa “Software Vendor” (bán phần mềm) và “Data Processing Service” (dịch vụ xử lý) đã bị xóa nhòa, đẩy rủi ro pháp lý về phía người làm công nghệ (Builder) cao hơn bao giờ hết.

Tổng kết sơ bộ

Nhìn lại toàn bộ bức tranh của Dự thảo Nghị định này, chúng ta thấy một sự phân hóa rõ rệt trong tư duy quản lý.

Một mặt, Ban soạn thảo đã có những bước lùi chiến thuật rất đáng ghi nhận để cứu vãn nền kinh tế thực. Việc miễn trừ hồ sơ TIA cho các hoạt động logistic, thanh toán và nhân sự tại Điều 18 là một “van xả áp” cần thiết. Nó đảm bảo dòng chảy của hàng hóa và tiền tệ không bị tắc nghẽn bởi thủ tục hành chính. Đây là một điểm cộng lớn so với Nghị định 13/2023.

Tuy nhiên, với nền kinh tế số và giới công nghệ, Dự thảo này vẫn còn là một gáo nước lạnh.

1. Gánh nặng định danh lên sự sáng tạo: Chúng ta đang sống trong thời đại mà một dev có thể viết ra một con bot OCR bằng Tesseract 4.0 hay một tool check email trong một buổi chiều. Nhưng Dự thảo này, với định nghĩa quá rộng về “Dịch vụ xử lý dữ liệu” và “AI” (Điều 22), đang đe dọa biến những công cụ tiện ích đó thành hoạt động kinh doanh có điều kiện. Bạn buộc phải có giấy phép và 3 nhân sự trình độ cao chỉ để vận hành một đoạn script Python.
2. Sự đứt gãy về nhân sự: Yêu cầu DPO phải có chứng chỉ nội địa và không công nhận các chứng chỉ quốc tế (CIPP/E, CISM…) là một sự lãng phí nguồn lực xã hội khổng lồ. Nó biến Tuân thủ (Compliance) từ một hoạt động bảo vệ người dùng thành một ngành kinh doanh khóa học và cấp chứng chỉ.
3. Cái bẫy của sự “Bình thường”: Ngay cả những doanh nghiệp không làm tech cũng không thoát nạn. Chiến lược dùng dịch vụ nội địa (domestic only) giúp bạn tránh được hồ sơ chuyển vùng, nhưng việc xử lý dữ liệu nhạy cảm (tài chính, vị trí) trong khâu vận hành hàng ngày vẫn buộc bạn phải thuê những DPO “có chứng chỉ” .

Túm lại:

Dự thảo Nghị định đang cố gắng dùng các công cụ hành chính của thế kỷ 20 (Giấy phép, Chứng chỉ, Hồ sơ giấy) để quản lý những công nghệ của thế kỷ 21 (AI, Blockchain, Cloud).

Nếu không có sự điều chỉnh, các Startup và Solo Developer – động lực đổi mới sáng tạo thực sự – sẽ buộc phải lựa chọn: Hoặc hoạt động trong vùng xám, hoặc mang “Code” của họ sang một định chế pháp lý khác cởi mở hơn.

Khi Luật cố gắng viết lại Code, thường thì Code sẽ bị lỗi. Nhưng lần này, cái bị lỗi có thể là cả một hệ sinh thái khởi nghiệp.