Tự vận hành LLM không tự bảo vệ dữ liệu doanh nghiệp

Tự vận hành LLM thực sự bảo vệ điều gì?

Tự vận hành loại một bên khỏi luồng dữ liệu của bạn: nhà cung cấp mô hình. Prompt, tài liệu được truy xuất và đầu ra do mô hình tạo ra đều nằm trong phạm vi hạ tầng bạn kiểm soát. Không có bên xử lý thứ ba, không chuyển dữ liệu xuyên biên giới và không phải phó thác mọi thứ cho một cam kết trong hợp đồng.

Đó là một lợi ích thực sự, nhưng khá giới hạn. Cách này chỉ xử lý đúng nhóm rủi ro phát sinh bên ngoài mạng của bạn. Mọi con đường khác khiến dữ liệu doanh nghiệp rò rỉ khỏi hệ thống LLM vẫn không thay đổi, bất kể GPU đặt ở đâu.

Dưới đây là bảng đánh giá thẳng thắn.

Sáu hàng được cải thiện. Ba hàng không thay đổi. Hai hàng thực sự tệ hơn. Nếu lý do bạn tự vận hành là một yêu cầu tuân thủ liên quan đến việc xử lý dữ liệu bởi bên thứ ba, phần đầu chính là câu trả lời. Nếu lý do chỉ là cảm giác mơ hồ rằng dữ liệu sẽ an toàn hơn khi nằm trên phần cứng của mình, hãy đọc tiếp.

LLM tự vận hành và API doanh nghiệp: điều khoản dữ liệu thực sự nói gì trong 2026?

Phần lớn so sánh giữa tự vận hành và API vẫn đang phản biện các điều khoản chat dành cho người dùng cá nhân từ năm 2023. Nhưng phía API đã thay đổi.

Theo mặc định, Anthropic xóa dữ liệu đầu vào và đầu ra của API sau bảy ngày và không dùng chúng để huấn luyện. Khách hàng có thể chọn thời hạn 30 ngày nếu cần dấu vết kiểm toán, trong khi Zero Data Retention được cung cấp cho các tài khoản doanh nghiệp đủ điều kiện. OpenAI cũng công bố lập trường tương tự; vào ngày 19 tháng 8 năm 2026, công ty đã giới thiệu thử nghiệm Private Safety Processing, phương án duy trì Zero Data Retention trên các mô hình frontier trong khi vẫn phát hiện các mẫu lạm dụng giữa những tương tác có liên quan. Theo cơ chế này, nội dung khách hàng vẫn nằm trên hạ tầng do khách hàng kiểm soát.

Có một điểm cần biết trước khi bạn xây dựng lập luận tuân thủ dựa trên ZDR: cam kết này phụ thuộc vào từng mô hình, không áp dụng chung cho toàn bộ nhà cung cấp. Anthropic cho biết với các mô hình frontier thuộc phạm vi áp dụng, khách hàng thương mại dùng ZDR tính đến ngày 9 tháng 6 năm 2026 vẫn chịu thời hạn lưu giữ và quy trình xem xét giới hạn cho mục đích an toàn. Bài học không phải là một nhà cung cấp nào đó bất cẩn — mà là ZDR là thuộc tính của từng mô hình và từng endpoint, có thể thay đổi khi mô hình mới ra mắt. Nếu DPIA của bạn ghi tên một cam kết thay vì một mô hình cụ thể, cam kết đó có thể lỗi thời mà không ai báo cho bạn.

Đó là lập luận mạnh nhất cho việc tự vận hành mà không liên quan đến hacker: mô hình do bạn vận hành sẽ không tự thương lượng lại điều khoản với bạn.

Hãy đọc lại hàng cuối hai lần. Đó là toàn bộ sự đánh đổi.

GDPR hoặc EU AI Act có bắt buộc bạn tự vận hành LLM không?

Không. Cả hai quy định đều không bắt buộc suy luận cục bộ. Điều tự vận hành mang lại là loại bỏ hai phần tốn kém nhất trong hồ sơ tuân thủ.

• Nghĩa vụ đối với bên xử lý theo Điều 28. Khi dùng API được lưu trữ, nhà cung cấp trở thành bên xử lý dữ liệu; bạn cần hợp đồng bằng văn bản, quyền kiểm soát bên xử lý phụ, quyền kiểm toán và thông báo sự cố. Nếu chạy mô hình trên phần cứng do bạn vận hành, mối quan hệ đó hoàn toàn không có bên xử lý.
• Phân tích chuyển dữ liệu theo Chương V. Định tuyến dữ liệu cá nhân của EU đến endpoint đặt tại Mỹ là một hoạt động chuyển dữ liệu xuyên biên giới, cần SCC hoặc Data Privacy Framework, kèm rủi ro Schrems II còn lại mà DPO phải ghi nhận hằng năm. Tự vận hành trong khu vực của mình sẽ loại bỏ việc chuyển dữ liệu thay vì chỉ tìm cách biện minh cho nó.

Điều này không loại bỏ hồ sơ hoạt động xử lý dữ liệu, DPIA, cơ sở pháp lý của bạn và — kể từ 2 tháng 8 năm 2026 — các nghĩa vụ minh bạch theo Điều 50 của EU AI Act, bao gồm việc thông báo cho người dùng rằng họ đang tương tác với một hệ thống AI và đánh dấu nội dung do AI tạo ra ở dạng máy có thể đọc. Các nghĩa vụ dành cho hệ thống rủi ro cao đã được Digital Omnibus package lùi đến tháng 12 năm 2027, giúp có thêm thời gian lập tài liệu nhưng không thay đổi bên chịu trách nhiệm.

Cách hiểu thực tế là: tự vận hành giúp lập luận tuân thủ ngắn gọn hơn, chứ không cho phép bạn bỏ qua việc lập luận đó. Những đội ngũ coi việc mua GPU là hạng mục tuân thủ thường lại trượt kiểm toán vì ghi nhật ký và kiểm soát truy cập.

Rủi ro bạn phải tiếp nhận ngay khi tự vận hành

Đây là phần thường bị bỏ qua trong thông điệp về quyền riêng tư. Cách phổ biến nhất để chạy mô hình cục bộ không có xác thực, và một tỷ lệ lớn hệ thống đã cài đặt đang nằm trên internet công cộng.

SentinelLABS và Censys đã dành khoảng 300 ngày lập bản đồ internet và phát hiện khoảng 175.000 máy chủ Ollama lộ ra ngoài duy nhất tại 130 quốc gia, trong đó gần một nửa được cấu hình để gọi công cụ — tức có thể thực thi mã và truy cập các hệ thống khác. Đến tháng 5 năm 2026, trong bối cảnh một lỗ hổng nghiêm trọng, Cyera ước tính số máy chủ bị lộ là khoảng 300.000. Hãy thận trọng với con số chính xác; quy mô tổng thể thì không còn phải tranh luận.

Những hệ thống này không lộ ra vì người vận hành là những người cẩu thả. Chúng lộ ra vì cấu hình mặc định không phù hợp với cách công cụ được sử dụng: không có xác thực ngay từ đầu, và rất nhiều người đổi cấu hình để lắng nghe trên mọi giao diện ngay khi cần truy cập mô hình từ một máy khác.

Rồi một lỗi xuất hiện trên nền đó. CVE-2026-7482, có biệt danh Bleeding Llama, là lỗi đọc ngoài giới hạn heap được chấm CVSS 9.1, cho phép kẻ tấn công không cần xác thực lấy bộ nhớ tiến trình chỉ bằng ba lệnh gọi API. Các nhà nghiên cứu Cyera công bố lỗ hổng đã liệt kê những gì có thể bị lấy đi: prompt, chỉ dẫn hệ thống, biến môi trường và khóa API. Tất cả đều chính là những loại dữ liệu bạn tự vận hành để bảo vệ.

Lớp gateway cũng gặp vấn đề tương tự. Một vụ xâm nhập chuỗi cung ứng vào tháng 3 năm 2026 trong một thư viện gateway AI được sử dụng rộng rãi (CVE-2026-33634, CVSS 9.4) cho thấy chỉ một dependency bị cài mã độc cũng có thể làm lộ toàn bộ thông tin xác thực của các nhà cung cấp AI mà một tổ chức đang sử dụng. Ở phía API, một khóa bị đánh cắp chỉ tạo ra phạm vi ảnh hưởng của một nhà cung cấp. Trong hệ thống tự vận hành, gateway thường giữ tất cả các khóa đó.

Tóm lại một cách không dễ chịu: tự vận hành LLM để bảo vệ dữ liệu doanh nghiệp chỉ hiệu quả nếu đội ngũ của bạn vận hành hạ tầng suy luận theo tiêu chuẩn áp dụng cho cơ sở dữ liệu. Phần lớn đội ngũ đưa ra quyết định vì lý do quyền riêng tư chưa từng phải làm việc đó.

Chi phí tự vận hành LLM trong 2026

Năng lực không còn là trở ngại chính. Các mô hình open-weight hiện trải dài từ máy tính xách tay đến cả rack máy chủ, và quy tắc chọn cấu hình khá đơn giản: trọng số phải vừa trong bộ nhớ tốc độ cao, khoảng 2 byte cho mỗi tham số ở FP16, một nửa mức đó ở INT8 và một phần tư ở 4-bit — cộng thêm khoảng trống cho bộ nhớ đệm KV, vốn tăng theo độ dài ngữ cảnh và mức độ đồng thời.

Chi phí là nơi trực giác thường sai. Giá thuê năng lực H100 dao động khoảng 1,49-6,98 USD mỗi GPU-giờ tùy nhà cung cấp, theo các khảo sát giá được công bố vào tháng 8 năm 2026. Nhưng mức giá niêm yết là con số ít đáng quan tâm nhất trong khoảng đó: ở mức sử dụng 40%, một card giá 3,99 USD sẽ tiêu tốn gần 10 USD cho mỗi giờ làm việc hữu ích. GPU nhàn rỗi là nguồn gây hối tiếc lớn nhất khi tự vận hành.

Ba khoản chi thường xuyên bị bỏ quên trong bài toán kinh doanh:

• Kỹ thuật. Dự trù từ nửa đến một kỹ sư toàn thời gian trong năm đầu tiên. Với phần lớn đội ngũ, khoản này lớn hơn chi phí GPU và không biến mất sau khi ra mắt — mô hình, runtime và CVE vẫn liên tục thay đổi.
• Mức sử dụng. API tính phí theo token không tốn chi phí khi không ai yêu cầu. GPU đặt trước vẫn tính phí lúc 3 giờ sáng.
• Dự phòng. Một GPU chỉ phù hợp để trình diễn. Môi trường sản xuất cần nút thứ hai hoặc một kế hoạch thực tế cho tình huống nút đầu tiên hỏng.

Với các mô hình open giá rẻ, lưu lượng lớn được phục vụ bởi nhà cung cấp suy luận phổ thông, thường không có điểm hòa vốn nào cả — giá theo token thấp hơn chi phí mà một card thuê có thể tạo ra. Tự vận hành có lợi về kinh tế khi dùng mô hình flagship, checkpoint được tinh chỉnh riêng và lưu lượng lớn ổn định. Cách này luôn thắng về quyền kiểm soát, bất kể lưu lượng bao nhiêu; đó là một lập luận khác và nên được trình bày độc lập.

Lỗ hổng kiến trúc tạo ra bất kể mô hình chạy ở đâu

Trên thực tế, dữ liệu doanh nghiệp không thoát ra qua nhà cung cấp mô hình. Nó thoát qua ba thứ do chính bạn xây dựng.

1. Chỉ mục truy xuất bị mất quyền

Sự cố nghiêm trọng phổ biến nhất trong một đợt triển khai AI nội bộ không phải là đánh cắp dữ liệu ra ngoài. Đó là khi nhân viên đặt câu hỏi cho chatbot và nhận được nội dung từ một tài liệu mà họ chưa bao giờ được phép mở. Điều này xảy ra khi pipeline RAG nạp một ổ đĩa dùng chung nhưng không đưa ACL theo từng tài liệu vào kho vector, cũng không kiểm tra lại quyền tại thời điểm truy vấn.

Tự vận hành khiến kiểu sự cố này dễ xảy ra hơn, không phải ít hơn. Câu nói “chúng ta không thể đưa dữ liệu đó lên cloud” vô tình đóng vai trò như một cổng phân loại dữ liệu. Bỏ cổng đó đi, phạm vi nạp dữ liệu sẽ mở rộng thành mọi thứ, thường ngay trong cùng một sprint.

2. Nhật ký prompt của chính bạn

Hệ thống tự vận hành thường ghi nhật ký rất rộng theo mặc định. Gateway, công cụ quan sát và giao diện chat đều thu thập toàn bộ prompt và nội dung hoàn tất; những dữ liệu này được đưa vào một cơ sở dữ liệu thường có mã hóa, thời hạn lưu giữ và kiểm soát truy cập yếu hơn chính sách của nhà cung cấp mà bạn đã thay thế. Bạn không loại bỏ việc lưu giữ dữ liệu. Bạn chỉ chuyển nó đến nơi không có DPA và không có lịch xóa.

3. Phạm vi công cụ của agent

Ngay khi mô hình có thể gọi công cụ, câu hỏi bảo mật không còn chỉ xoay quanh văn bản mà chuyển sang năng lực. Gần một nửa số máy chủ bị lộ có bật tính năng gọi công cụ. Hãy giới hạn từng công cụ theo danh tính của người yêu cầu, không phải danh tính của dịch vụ — một agent truy vấn cơ sở dữ liệu bằng tài khoản dịch vụ là một lỗ hổng leo thang đặc quyền chỉ chờ một prompt được viết đủ khéo.

Đây là các quyết định về kiến trúc, không phải hạ tầng, và chúng giống nhau dù suy luận chạy trong rack của bạn hay của người khác. Nếu muốn thiết kế đúng ngay từ đầu, đó là công việc nằm sau dịch vụ kỹ thuật tự động hóa AI và workflow của chúng tôi — gồm agent, pipeline truy xuất và mô hình phân quyền bên dưới.

Cách bảo mật một hệ thống LLM tự vận hành

Nếu tự vận hành, hãy coi máy chủ suy luận là hạ tầng sản xuất đang lưu trữ dữ liệu nhạy cảm — vì đó chính xác là những gì nó đang làm. Danh sách dưới đây được sắp xếp tương đối theo tần suất bị bỏ sót:

1. Không bao giờ bind máy chủ suy luận vào 0.0.0.0. Bind vào localhost hoặc giao diện riêng, rồi đặt reverse proxy ở phía trước. Kiểm tra từ bên ngoài, không chỉ từ chính máy chủ.
2. Yêu cầu xác thực trên mọi endpoint. Dùng khóa API hoặc OAuth gắn với kiểm soát truy cập dựa trên vai trò, không dùng một token chung được lưu trong trang wiki.
3. Quét hệ thống như cách kẻ tấn công quét. Xác nhận các cổng suy luận không thể truy cập từ internet công cộng, sau đó kiểm tra lại sau mỗi thay đổi hạ tầng.
4. Dùng runtime sản xuất cho môi trường sản xuất. Dùng vLLM, SGLang hoặc TensorRT-LLM để phục vụ lưu lượng; giữ các công cụ cục bộ thân thiện với nhà phát triển trên máy của họ.
5. Vá lớp phục vụ theo lịch bảo mật. Runtime suy luận hiện là bề mặt CVE đang bị khai thác tích cực, không còn là dependency phục vụ sở thích cá nhân.
6. Xác thực artifact của mô hình. Tải trọng số từ các nhà phát hành đáng tin cậy và kiểm tra checksum. File mô hình bị tạo malformed từng là một vector tấn công có hiệu quả.
7. Cô lập secret của gateway. Lưu khóa nhà cung cấp trong secret manager và phân quyền theo từng dịch vụ, để một dependency bị xâm nhập không thể làm lộ toàn bộ chuỗi khóa.
8. Duy trì ACL trong quá trình truy xuất. Lọc tại thời điểm truy vấn theo quyền thực tế của người yêu cầu và lập chỉ mục lại khi quyền thay đổi.
9. Đặt chính sách lưu giữ cho nhật ký prompt và mã hóa chúng. Sau đó xóa theo lịch và chứng minh rằng việc xóa đã được thực hiện.
10. Ghi nhật ký yêu cầu suy luận để kiểm toán — người dùng, thời điểm, mô hình và các công cụ được gọi. Bạn cần dữ liệu này để ứng phó sự cố và ngày càng cần nó cho cơ quan quản lý.
11. Giới hạn tốc độ và giám sát hành vi lạm dụng. Lưu lượng token bất thường từ một danh tính là tín hiệu sớm nhất của cả việc sử dụng sai mục đích lẫn sự cố xâm nhập.

Khi nào nên tự vận hành, khi nào nên dùng API và cách kết hợp cả hai

Mô hình hiệu quả nhất không hẳn là phải chọn một trong hai. Hãy phân loại dữ liệu rồi định tuyến lưu lượng — phần lớn tổ chức có ba tầng và chỉ một tầng thực sự cần phần cứng chuyên dụng.

Hãy tự vận hành khi có ít nhất một điều sau: cơ quan quản lý hoặc hợp đồng khách hàng yêu cầu nơi lưu trữ dữ liệu; DPIA của bạn không thể tiếp nhận một bên xử lý thứ ba; bạn cần một checkpoint được tinh chỉnh mà không nhà cung cấp nào lưu trữ; hoặc lưu lượng ổn định đủ lớn để GPU đặt trước rẻ hơn giá theo token ở mức sử dụng thực tế.

Hãy tiếp tục dùng API khi lưu lượng biến động theo đợt, khi đội ngũ không có lịch trực hạ tầng, hoặc khi câu trả lời thành thật cho câu hỏi “ai sẽ vá máy chủ suy luận lúc 2 giờ sáng?” là không ai cả. Một mô hình được lưu trữ với điều khoản doanh nghiệp và kiến trúc chặt chẽ sẽ bảo vệ dữ liệu doanh nghiệp tốt hơn một mô hình tự vận hành nhưng để mở một cổng. Đây không phải là một quyết định sít sao.

Nếu bạn đang cân nhắc và muốn được rà soát kiến trúc trước khi mua phần cứng — từ phân loại dữ liệu, định tuyến, quyền truy xuất đến chính hệ thống triển khai — hãy cho chúng tôi biết bạn đang xây dựng gì để chúng tôi lập phạm vi công việc.