title: "LLM Gateway & Governance: Quản trị các lời gọi AI API trong doanh nghiệp"
series: "Software Architecture Masterclass"
part: "Phần 5 — AI-Augmented & Future-Proofing"
order: 39
audience: "Solutions Architect & Technical Lead"
reading_time: "13 phút"
tags: ["llm-gateway", "ai-governance", "cost-management", "pii-filtering", "rate-limiting", "vendor-abstraction"]

LLM Gateway & Governance: Quản trị các lời gọi AI API trong doanh nghiệp

Sáu tháng sau khi công ty "cho phép dùng AI", một CTO nhận được hóa đơn từ ba nhà cung cấp LLM khác nhau, cộng lại vượt ngân sách dự kiến gần bốn lần — và không ai trong công ty giải thích nổi khoản nào đến từ team nào, feature nào, hay thậm chí có bao nhiêu API key đang tồn tại. Khi rà soát, người ta phát hiện một service backend gửi thẳng nội dung email khách hàng (bao gồm số điện thoại, địa chỉ) vào prompt của một model bên thứ ba, không qua bất kỳ lớp lọc nào — vì developer viết feature đó chỉ đơn giản npm install SDK của nhà cung cấp và gọi thẳng, đúng như tài liệu hướng dẫn.

Đây không phải một câu chuyện hiếm. Nó là hệ quả tất yếu của cách hầu hết tổ chức áp dụng AI: từng team, từng developer, tự quyết định gọi LLM API theo cách riêng, không có lớp trung gian nào đứng giữa ứng dụng và nhà cung cấp mô hình. Bài này không nói về cách viết prompt hay cách chọn model tốt nhất — nó nói về việc thiếu một lớp quản trị tập trung cho AI API đã âm thầm trở thành lỗ hổng vận hành, tài chính, và bảo mật lớn ngang hàng với việc không có API Gateway trong một hệ thống microservices.

The Problem

Khi một tổ chức bắt đầu tích hợp LLM (Large Language Model — mô hình ngôn ngữ lớn) vào sản phẩm, con đường ít trở ngại nhất luôn là: mỗi team tự đăng ký một API key với nhà cung cấp (OpenAI, Anthropic, Google, hay bất kỳ ai), nhúng key đó vào biến môi trường của service mình, và gọi thẳng SDK trong code. Không cần chờ phê duyệt hạ tầng, không cần đợi một platform team dựng lớp trung gian — feature ra mắt nhanh hơn, và trong ngắn hạn, mọi thứ có vẻ ổn.

Vấn đề bắt đầu tích lũy ngay khi tổ chức có nhiều hơn một team làm AI. Team Support dùng model A để tóm tắt ticket. Team Sales dùng model B để soạn email. Team Product dùng cả model A lẫn C để thử nghiệm feature mới. Mỗi team có key riêng, hợp đồng riêng, và không ai — kể cả CFO lẫn CTO — có một bức tranh tổng thể về tổng chi phí AI của công ty tại bất kỳ thời điểm nào. Chi phí LLM API tính theo token (đơn vị văn bản nhỏ mà model xử lý) và có thể tăng phi tuyến khi một feature bất ngờ được dùng nhiều hơn dự kiến — nhưng không ai theo dõi được điều đó cho tới khi hóa đơn cuối tháng về.

Nghiêm trọng hơn chi phí là hai vấn đề song song: thực hành không nhất quán và rủi ro rò rỉ dữ liệu. Không có chuẩn chung, mỗi developer tự quyết định model nào dùng cho việc gì, retry logic ra sao khi API lỗi, có giới hạn tốc độ (rate limit) hay không. Một team có thể vô tình gọi API theo vòng lặp không kiểm soát, dẫn tới hóa đơn bất ngờ hoặc bị nhà cung cấp khóa tài khoản. Và vì không có lớp nào kiểm tra nội dung trước khi rời khỏi biên giới hệ thống, dữ liệu nhạy cảm — số thẻ tín dụng một phần, thông tin định danh cá nhân (PII — Personally Identifiable Information), bí mật kinh doanh trong tài liệu nội bộ — hoàn toàn có thể bị dán thẳng vào prompt gửi cho một nhà cung cấp bên ngoài, chỉ vì developer viết feature đó không có lý do gì để nghĩ tới việc lọc dữ liệu trước khi gửi.

Đây là một vấn đề kiến trúc, không phải vấn đề kỷ luật cá nhân. Không có tổ chức nào có thể trông cậy vào việc "nhắc từng developer cẩn thận" ở quy mô — ta cần một điểm kiểm soát tập trung, giống hệt lý do API Gateway (bài 20) ra đời để giải quyết vấn đề tương tự cho traffic nội bộ giữa client và microservices.

The Theory

LLM Gateway là một lớp proxy tập trung đứng giữa mọi ứng dụng nội bộ và mọi nhà cung cấp LLM bên ngoài. Thay vì mỗi service gọi thẳng SDK của OpenAI, Anthropic, hay Google, mọi lời gọi đều đi qua một điểm duy nhất — về bản chất là một API Gateway (bài 20) chuyên biệt hóa cho lưu lượng AI, mang đầy đủ các trách nhiệm mà một gateway thông thường đảm nhiệm, cộng thêm những trách nhiệm đặc thù của AI.

Bốn năng lực cốt lõi mà một LLM Gateway phải cung cấp:

1. Theo dõi chi phí tập trung (cost observability). Mọi request đi qua gateway đều được gắn nhãn theo team, project, hoặc feature gọi nó, và số token tiêu thụ (đầu vào lẫn đầu ra) được ghi log tại một nơi duy nhất. Điều này biến câu hỏi "tháng này chúng ta tiêu bao nhiêu cho AI, và ai tiêu nhiều nhất" từ một cuộc điều tra thủ công tốn hàng giờ thành một dashboard truy vấn tức thời. Nó cũng cho phép đặt ngân sách (budget) theo team và cảnh báo khi vượt ngưỡng, trước khi hóa đơn cuối tháng trở thành chuyện đã rồi.

2. Giới hạn tốc độ và kiểm soát lưu lượng (rate limiting & quota). Gateway có thể áp rate limit theo team, theo API key nội bộ, hoặc theo model, ngăn một lỗi lập trình (vòng lặp gọi API không kiểm soát) hay một traffic spike bất thường làm cạn ngân sách hoặc khiến tài khoản bị nhà cung cấp tạm khóa. Đây cũng là nơi tự nhiên để áp cơ chế retry với backoff nhất quán, thay vì mỗi team tự viết logic retry riêng — thường sai theo những cách khác nhau.

3. Lọc prompt và dữ liệu nhạy cảm (prompt/PII filtering). Trước khi bất kỳ payload nào rời khỏi biên giới hệ thống, gateway là điểm duy nhất có thể quét và redact (che/xóa) thông tin nhạy cảm — số điện thoại, email, số thẻ, mã định danh nội bộ — hoặc chặn hoàn toàn request nếu phát hiện dữ liệu vi phạm chính sách. Đây không phải lớp bảo vệ tuyệt đối (một filter dựa trên pattern-matching hay một model phụ để phát hiện PII đều có thể bỏ sót), nhưng nó là lớp phòng thủ tập trung duy nhất — thay vì trông cậy vào từng developer tự nhớ áp dụng filter trong code của mình.

4. Trừu tượng hóa nhà cung cấp (provider abstraction). Ứng dụng gọi một API nội bộ thống nhất; gateway chịu trách nhiệm dịch sang định dạng request/response cụ thể của từng nhà cung cấp phía sau. Điều này cho phép tổ chức chuyển model, thử nghiệm A/B giữa các nhà cung cấp, hay fallback sang provider dự phòng khi một nhà cung cấp gặp sự cố — mà không cần sửa code ở hàng chục service khác nhau. Nó cũng là điểm đòn bẩy đàm phán hợp đồng: khi toàn bộ lưu lượng AI của công ty đi qua một điểm, tổ chức có vị thế thương lượng giá tốt hơn nhiều so với việc mỗi team tự ký hợp đồng lẻ.

Về vị trí kiến trúc, LLM Gateway thường được triển khai như một service độc lập (có thể dựa trên các dự án mã nguồn mở làm nền, hoặc xây riêng), đứng sau cùng một lớp xác thực nội bộ mà mọi service khác đi qua — tương tự cách mọi traffic phải qua API Gateway trước khi chạm service mesh nội bộ (bài 20).

The Trade-off

Đây là phần không được phép mơ hồ: dựng một LLM Gateway là đặt cược một điểm tập trung mới lên vai của một hệ thống, đổi lấy khả năng quản trị mà hỗn loạn phi tập trung không bao giờ có.

Được gì:

Tầm nhìn tài chính đầy đủ theo thời gian thực. Tổ chức biết chính xác team nào, feature nào, đang tiêu bao nhiêu cho AI tại bất kỳ thời điểm nào — thay vì phát hiện qua hóa đơn cuối tháng. Đây là điều kiện tiên quyết để ra quyết định đầu tư AI có cơ sở, thay vì cảm tính.
Một chính sách bảo mật/PII áp dụng nhất quán cho toàn tổ chức. Thay vì mỗi developer tự quyết định (hoặc quên quyết định) có lọc dữ liệu nhạy cảm hay không, chính sách được thực thi tại một điểm duy nhất, review được, audit được, và cập nhật một lần là có hiệu lực toàn hệ thống.
Đàm phán và chuyển đổi nhà cung cấp trở nên khả thi. Khi toàn bộ lưu lượng đi qua một điểm trừu tượng hóa, tổ chức không bị khóa chặt (vendor lock-in) vào một nhà cung cấp duy nhất, và có thể tận dụng cạnh tranh giá giữa các nhà cung cấp mà không phải sửa code ứng dụng.
Rate limiting bảo vệ ngân sách khỏi lỗi lập trình. Một vòng lặp gọi API vô tình, hay một traffic spike bất thường, bị chặn ở gateway trước khi biến thành hóa đơn bất ngờ hoặc tài khoản bị khóa bởi nhà cung cấp.

Mất gì — và đây là phần không được phép né tránh:

Một điểm nghẽn (bottleneck) và một điểm lỗi trọng yếu (critical dependency) mới. Nếu LLM Gateway sập, mọi tính năng AI trong toàn công ty sập theo cùng lúc — dù nguyên nhân gốc chỉ nằm ở một team. Đây chính xác là cái giá mà mọi lớp tập trung hóa phải trả (cùng logic với API Gateway ở bài 20): tập trung hóa quản trị luôn đồng nghĩa tập trung hóa rủi ro vận hành.
Độ trễ tăng thêm ở mọi lời gọi. Mỗi request giờ đi qua thêm một hop mạng, cộng thêm chi phí xử lý cho việc quét PII, ghi log, kiểm tra rate limit — trước khi chạm tới nhà cung cấp thực sự. Với các luồng tương tác thời gian thực (chat trực tiếp với người dùng), độ trễ cộng dồn này có thể ảnh hưởng cảm nhận trải nghiệm, đặc biệt nếu gateway không được thiết kế để streaming response hiệu quả.
Mất tự chủ của team, và ma sát khi cần tính năng đặc thù. Một team muốn thử nghiệm nhanh một tính năng model-provider mới, hay cần một tham số cấu hình đặc biệt mà gateway chưa hỗ trợ, giờ phải xin platform team bổ sung — thay vì tự do gọi thẳng SDK và triển khai trong một buổi chiều. Tốc độ thử nghiệm (velocity) của từng team cá nhân giảm để đổi lấy quản trị toàn tổ chức.
Chi phí xây dựng và vận hành ban đầu không nhỏ. Một platform team phải đầu tư xây gateway, duy trì nó, theo kịp API thay đổi của nhiều nhà cung cấp khác nhau (mỗi nhà cung cấp có định dạng request/response, cơ chế streaming, và giới hạn riêng), và xử lý các trường hợp biên (model mới ra mắt, tham số mới, tính năng multimodal mới) — đây là một khoản đầu tư hạ tầng dài hạn, không phải một cấu hình một lần rồi quên.
Lọc PII không bao giờ hoàn hảo, và có thể tạo cảm giác an toàn giả. Một bộ lọc dựa trên pattern hay một model phụ để phát hiện dữ liệu nhạy cảm đều có tỷ lệ bỏ sót — nó giảm rủi ro, không loại bỏ rủi ro. Nếu tổ chức coi việc có gateway là "đã giải quyết xong vấn đề PII" và ngừng review thực hành ở tầng ứng dụng, lớp lọc trở thành một tấm khiên có lỗ hổng mà không ai còn kiểm tra.

Nói ngắn gọn: mô hình phi tập trung cho từng team tốc độ và tự chủ tối đa trong ngắn hạn, nhưng đặt cược rằng kỷ luật cá nhân sẽ thay thế được quản trị hệ thống — một cược gần như luôn thua khi tổ chức lớn dần. LLM Gateway trả giá bằng một điểm phụ thuộc mới, độ trễ, và ma sát vận hành, để đổi lấy khả năng nhìn thấy, kiểm soát, và giới hạn thiệt hại của việc gọi AI ở quy mô toàn công ty.

The Architecture Diagram

Sơ đồ dưới đây minh họa topology của một LLM Gateway: nhiều team gọi vào một điểm duy nhất, đi qua các lớp quản trị (xác thực nội bộ, lọc PII, rate limiting, logging chi phí), trước khi được định tuyến tới nhà cung cấp LLM phù hợp phía sau.

flowchart LR
    subgraph TEAMS["Các team / ứng dụng nội bộ"]
        direction TB
        T1["Team Support<br/>(tóm tắt ticket)"]
        T2["Team Sales<br/>(soạn email)"]
        T3["Team Product<br/>(feature AI mới)"]
        T4["Backend service<br/>(xử lý dữ liệu KH)"]
    end

    subgraph GW["LLM Gateway"]
        direction TB
        AUTH["Xác thực nội bộ<br/>(service identity, không dùng<br/>key nhà cung cấp trực tiếp)"]
        PII["Lớp lọc Prompt / PII<br/>(redact số ĐT, email, PII)"]
        RATE["Rate Limiting & Quota<br/>(theo team, theo model)"]
        COST["Cost Logging & Attribution<br/>(gắn nhãn team/feature,<br/>đếm token, dashboard chi phí)"]
        ROUTE["Router / Provider Abstraction<br/>(chọn model, fallback,<br/>A/B giữa nhà cung cấp)"]

        AUTH --> PII --> RATE --> COST --> ROUTE
    end

    subgraph PROVIDERS["Nhà cung cấp LLM (bên ngoài)"]
        direction TB
        P1["Provider A<br/>(model tổng quát)"]
        P2["Provider B<br/>(model chuyên biệt)"]
        P3["Provider C<br/>(dự phòng / fallback)"]
    end

    T1 -->|"request qua<br/>internal API"| AUTH
    T2 -->|"request qua<br/>internal API"| AUTH
    T3 -->|"request qua<br/>internal API"| AUTH
    T4 -->|"request qua<br/>internal API"| AUTH

    PII -.->|"⚠ chặn nếu phát hiện<br/>PII chưa được che"| BLOCK(["Request bị từ chối<br/>+ log cảnh báo"])

    ROUTE --> P1
    ROUTE --> P2
    ROUTE -.->|"fallback khi<br/>Provider A lỗi"| P3

    COST --> DASH[("Dashboard chi phí<br/>theo team/feature")]

Điểm mấu chốt của sơ đồ nằm ở việc không có mũi tên nào đi thẳng từ khối "Teams" tới khối "Providers" — mọi con đường bắt buộc phải xuyên qua toàn bộ chuỗi bên trong Gateway. Team không biết (và không cần biết) nhà cung cấp cụ thể phía sau là ai; họ chỉ gọi một API nội bộ duy nhất, và mọi chính sách chi phí, bảo mật, rate limit được thực thi trước khi request rời khỏi biên giới công ty.

Implementation Guardrails

Không team nào được phép gọi trực tiếp LLM API bên ngoài với dữ liệu production, dưới bất kỳ lý do nào. Không có ngoại lệ "chỉ là một thử nghiệm nhỏ" hay "prototype tạm thời" — một API key nhà cung cấp cấp thẳng cho một team là một lỗ hổng quản trị đang chờ bị phát hiện muộn. Chính sách phải được thực thi ở tầng hạ tầng (không cấp quyền egress trực tiếp tới domain của nhà cung cấp), không chỉ dựa vào việc yêu cầu team tự giác tuân thủ.
Lớp lọc PII phải là deny-by-default cho các trường dữ liệu chưa được whitelist rõ ràng, không phải một bộ lọc "cố gắng bắt những gì biết trước". Với các luồng xử lý dữ liệu khách hàng nhạy cảm, mặc định là chặn hoặc redact, chỉ cho qua khi có xác nhận tường minh rằng trường dữ liệu đó an toàn để gửi ra ngoài — đảo ngược tư duy này (mặc định cho qua, chặn những gì phát hiện được) gần như chắc chắn sẽ để lọt dữ liệu mà bộ lọc chưa từng thấy trước đó.
Mọi request phải được gắn nhãn attribution (team, feature, môi trường) tại thời điểm gọi, không được suy luận ngược sau đó. Nếu việc gắn nhãn là tùy chọn hoặc để mặc định, phần lớn request sẽ không có nhãn, và dashboard chi phí trở thành vô dụng đúng vào lúc cần nó nhất — khi hóa đơn vượt ngân sách và không ai giải thích được vì sao.
Gateway phải có kế hoạch chịu lỗi riêng (fallback provider, circuit breaker, độ sẵn sàng cao) tương xứng với việc nó là điểm lỗi trọng yếu duy nhất cho mọi tính năng AI của công ty. Không được coi gateway là một service phụ trợ vận hành với tiêu chuẩn thấp hơn service nghiệp vụ chính — về mặt tác động khi sập, nó tương đương API Gateway hay identity provider (bài 33), và cần được đầu tư độ sẵn sàng (bài 26) tương xứng.

Architect's Verdict

LLM Gateway giờ cơ bản đã trở thành một thành phần hạ tầng mặc định, giống hệt vị trí mà API Gateway từng chiếm giữ khi microservices bắt đầu phổ biến — không phải một lựa chọn "nice to have" dành cho tổ chức có ngân sách dư dả, mà là điều kiện tối thiểu để AI được dùng ở quy mô doanh nghiệp mà không biến thành một sự cố quản trị, chi phí, và bảo mật đang chờ nổ. Thiếu nó không có nghĩa tổ chức "chưa cần" — nó có nghĩa rủi ro đang tích lũy âm thầm cho tới ngày một developer vô tình gửi dữ liệu khách hàng ra ngoài, hoặc CFO nhận một hóa đơn không ai giải thích nổi. Nếu ngân sách còn hạn chế, đừng đợi có đủ nguồn lực để xây một gateway hoàn chỉnh với mọi tính năng — bắt đầu bằng việc chặn mọi lời gọi trực tiếp và ép toàn bộ traffic qua một điểm duy nhất, dù ban đầu điểm đó chỉ làm mỗi việc logging và rate limiting; phần lọc PII và trừu tượng hóa nhà cung cấp có thể bồi đắp dần, nhưng việc có một điểm tập trung duy nhất phải là quyết định đầu tiên, không phải cuối cùng.

🔗 Bài viết liên quan: Integrating AI into Architecture · API Gateway & Service Mesh

Bài trước: Integrating AI into Architecture · Bài tiếp theo: AI Agent Architecture