title: "AI Platform Engineering: Xây dựng cổng nội bộ (Internal Developer Portal) có tích hợp AI"
series: "AI-Native Solutions Architect: Từ Coder đến Kiến trúc sư AI"
season: "Season 3 — AI Agents & Platform Engineering"
order: 27
audience: "Software Engineer hướng tới Solutions Architect"
reading_time: "13 phút"
tags:

• platform-engineering
• internal-developer-portal
• ai-governance
• llm-gateway
• finops
• solutions-architecture

AI Platform Engineering: Xây dựng cổng nội bộ (Internal Developer Portal) có tích hợp AI

Tháng trước bạn review chi phí AI của công ty và phát hiện ra một điều khó chịu: team Sales Ops đang gọi thẳng OpenAI API bằng key cá nhân của một bạn intern, team Data đang dùng Bedrock qua một IAM role không ai nhớ ai tạo, team Product thì trả tiền Claude Pro cho từng người để "tự động hóa" report bằng cách copy-paste vào chat. Ba team, ba cách tính phí, ba mô hình bảo mật, và không ai — kể cả bạn, kiến trúc sư — biết tổng chi phí AI thực tế của công ty là bao nhiêu cho tới khi hóa đơn thẻ tín dụng về.

Đây không phải vấn đề của một team cẩu thả. Đây là hệ quả tất yếu của giai đoạn "mỗi đội tự bơi" với AI — giai đoạn mà gần như công ty nào cũng đi qua trong 1-2 năm đầu áp dụng AI. Vấn đề không nằm ở việc thiếu công cụ (ngược lại, thừa công cụ), mà ở việc thiếu một lớp trừu tượng chung để tất cả các đội gọi tới năng lực AI theo cùng một cách. Không có lớp đó, mọi nỗ lực quản lý chi phí, bảo mật, và compliance đều là chữa cháy sau khi sự cố đã xảy ra.

Bài này nói về vai trò của Platform Engineering trong kỷ nguyên AI: xây một Internal Developer Portal (IDP) cung cấp năng lực AI như một dịch vụ dùng chung, để các đội feature-team không cần tự quyết định "dùng model nào, gọi provider nào, ai trả tiền" — họ chỉ cần tiêu thụ một API nội bộ đã được chuẩn hóa. Đây là công việc thật của Solutions Architect ở tầng platform, không phải lý thuyết.

Vấn đề

Hình dung một công ty tầm 150-300 kỹ sư, chia thành 15-20 feature team. Khi AI bắt đầu lan vào sản phẩm và quy trình nội bộ, kịch bản điển hình diễn ra như sau:

• Team A tích hợp GPT-4o vào tính năng auto-summarize ticket, gọi trực tiếp OpenAI API bằng key riêng của team, lưu trong .env của service.
• Team B xây chatbot nội bộ dùng Claude, quản lý key qua AWS Secrets Manager nhưng không có rate limit, không log lại prompt/response nào.
• Team C thử nghiệm RAG với Bedrock, key gắn với IAM role của account AWS riêng cho team đó, chi phí lẫn vào bill AWS chung không tách được.
• Team D dùng self-hosted Llama qua vLLM trên GPU instance tự thuê, không ai theo dõi utilization.

Sáu tháng sau, CTO hỏi ba câu đơn giản mà không ai trả lời được:

1. Tổng chi phí AI của công ty tháng này là bao nhiêu, chia theo team/use-case?
2. Dữ liệu khách hàng có bị gửi ra ngoài qua các lời gọi AI không được kiểm soát này không?
3. Nếu ngày mai OpenAI tăng giá gấp đôi, chúng ta có thể chuyển sang provider khác trong bao lâu?

Không có câu nào trả lời được vì mỗi team đã tự khóa mình vào một cách tích hợp riêng. Đây chính là bài toán kinh điển của Platform Engineering — không phải AI tạo ra vấn đề mới, mà AI khuếch đại một vấn đề cũ (thiếu chuẩn hóa hạ tầng dùng chung) với tốc độ nhanh hơn, vì rào cản để một dev tự gọi thẳng một LLM API gần như bằng không: chỉ cần một API key và vài dòng code.

Cái công ty cần không phải là "cấm dùng AI" (sẽ khiến các đội né platform và làm chui), cũng không phải "để mỗi đội tự quyết" (đã thấy hậu quả ở trên). Cái cần là một điểm trung gian duy nhất — nơi mọi request AI đi qua, được log, được tính phí, được route tới đúng provider, và được self-service đăng ký mà không cần xin phép platform team cho từng việc nhỏ.

Kỹ thuật cốt lõi

Platform Engineering định nghĩa vai trò của mình qua một câu quen thuộc: xây "Golden Path" — con đường mặc định, dễ đi nhất, mà đồng thời cũng là con đường an toàn nhất và rẻ nhất. Với AI, Golden Path đó là một AI Gateway nội bộ đóng vai trò lớp trừu tượng giữa consumer (feature team) và provider (OpenAI, Anthropic, Bedrock, self-hosted model).

Nguyên lý thiết kế, không phải sản phẩm cụ thể:

flowchart LR
    subgraph Teams["Feature Teams"]
        T1[Team A - Ticket Summarizer]
        T2[Team B - Internal Chatbot]
        T3[Team C - RAG Search]
        T4[Team D - Agent Pipeline]
    end

    subgraph Gateway["AI Platform Gateway (nội bộ)"]
        AUTH[Auth & API Key Layer]
        ROUTE[Model Router]
        QUOTA[Quota / Rate Limit Engine]
        LOG[Logging & Audit]
        CACHE[Prompt/Response Cache]
    end

    subgraph Providers["LLM Providers"]
        P1[Anthropic Claude]
        P2[OpenAI]
        P3[AWS Bedrock]
        P4[Self-hosted vLLM]
    end

    subgraph Portal["Self-Service Portal"]
        REG[Đăng ký use-case mới]
        DASH[Dashboard chi phí/usage]
        POLICY[Policy Editor: quota, model whitelist]
    end

    T1 & T2 & T3 & T4 --> AUTH
    AUTH --> ROUTE
    ROUTE --> QUOTA
    QUOTA --> CACHE
    CACHE --> LOG
    LOG --> P1 & P2 & P3 & P4

    Portal -.đăng ký / xem usage.-> Gateway

Bốn thành phần cốt lõi:

1. Model Router: mỗi request từ team không chỉ định trực tiếp model=gpt-4o mà chỉ định một capability tag như summarization-fast hay reasoning-complex. Gateway tự quyết định route tới provider nào dựa trên policy (chi phí, độ trễ, độ sẵn sàng). Đây là điểm mấu chốt: đổi provider trở thành thay đổi cấu hình ở một chỗ, không phải đi sửa code của 20 team.

2. Quota & Cost Engine: mỗi team/use-case có một "ngân sách" (budget) tính theo token hoặc theo tiền, gateway từ chối hoặc cảnh báo khi vượt hạn mức, tương tự cách một API Gateway thường xử lý rate limiting nhưng áp cho chi phí thay vì chỉ số lượng request.

3. Logging & Audit tập trung: mọi prompt/response (hoặc ít nhất metadata + hash) được log lại ở một nơi, phục vụ cả debug, cả compliance (ai đã gửi dữ liệu gì ra ngoài), cả để feed vào hệ thống eval sau này (liên quan trực tiếp tới chủ đề Evaluation & Monitoring ở bài trước).

4. Self-Service Portal: đây là phần "Developer Portal" thật sự — thay vì team phải Slack platform team xin quota, họ vào một giao diện (có thể đơn giản là một trang nội bộ dựa trên Backstage, hoặc một CLI tool, hoặc thậm chí một file YAML submit qua PR), điền thông tin use-case, chọn model tier cần, hệ thống tự cấp API key nội bộ và quota mặc định theo policy đã duyệt trước.

Khác biệt quan trọng với một API Gateway thông thường: gateway AI này không chỉ route theo path/method mà route theo ngữ nghĩa của tác vụ (capability), và quota được tính theo đơn vị kinh tế thực (token, USD) chứ không chỉ số lượng request — vì chi phí một request AI có thể lệch nhau hàng trăm lần tùy độ dài context và model được chọn.

Thực hành

1. Manifest self-service — team đăng ký use-case mới

Thay vì một form web phức tạp ngay từ đầu, cách rẻ nhất để có self-service là một file manifest YAML mà team tự viết và submit qua Pull Request vào một repo trung tâm (ai-platform-registry). CI tự validate và, nếu pass policy, tự động provision API key + quota.

# registry/use-cases/ticket-summarizer.yaml
apiVersion: ai-platform/v1
kind: AICapabilityRequest
metadata:
  name: ticket-summarizer
  team: support-eng
  owner: nguyen.van.a@company.com
  cost_center: CC-1042
spec:
  description: >
    Tóm tắt nội dung ticket hỗ trợ khách hàng thành 2-3 câu
    hiển thị trong dashboard CSKH.
  capability: summarization-fast      # không chỉ định model cụ thể
  data_classification: internal        # internal | confidential | pii
  expected_volume:
    requests_per_day: 5000
    avg_input_tokens: 800
    avg_output_tokens: 150
  budget:
    monthly_usd_cap: 300
    alert_threshold_pct: 80
  environments:
    - staging
    - production
  fallback_policy: degrade_to_smaller_model  # thay vì fail cứng khi hết quota

Pipeline CI kiểm tra: data_classification có khớp với capability được phép hay không (ví dụ dữ liệu pii chỉ được route tới provider có DPA/hợp đồng xử lý dữ liệu phù hợp), monthly_usd_cap có nằm trong ngân sách còn lại của cost center hay không, rồi tự động tạo API key scoped theo name này và đăng ký quota vào gateway.

2. Policy routing tại gateway — map capability sang provider

Đây là "bảng giá trị" trung tâm mà platform team maintain, tách biệt hoàn toàn khỏi code của feature team:

# gateway/policies/capability-routing.yaml
capabilities:
  summarization-fast:
    primary: 
      provider: anthropic
      model: claude-haiku-4-5
    fallback:
      provider: bedrock
      model: amazon.titan-text-lite-v1
    max_latency_ms: 2000
    cache_ttl_seconds: 3600   # cache theo hash(prompt) để giảm chi phí

  reasoning-complex:
    primary:
      provider: anthropic
      model: claude-sonnet-4-5
    fallback:
      provider: openai
      model: gpt-4o
    max_latency_ms: 15000
    cache_ttl_seconds: 0       # không cache vì output cần tính thời điểm

  embedding-search:
    primary:
      provider: openai
      model: text-embedding-3-small
    fallback:
      provider: bedrock
      model: amazon.titan-embed-text-v2
    max_latency_ms: 500
    cache_ttl_seconds: 86400

Khi provider chính bị rate-limit, tăng giá đột ngột, hoặc có sự cố (đã bàn ở bài Disaster Recovery), platform team chỉ sửa file này và deploy lại gateway — không có feature team nào cần biết hay phải sửa code.

3. Quota enforcement — request/response thực tế qua gateway

Một request điển hình từ team consumer gửi tới gateway nội bộ (không phải gửi thẳng tới OpenAI/Anthropic):

POST /v1/ai/complete HTTP/1.1
Host: ai-gateway.internal.company.com
Authorization: Bearer aik_ticket-summarizer_7f3a...
Content-Type: application/json
X-Capability: summarization-fast
X-Request-Id: req_8823ac

{
  "input": "Khách hàng báo lỗi thanh toán VNPay không trừ tiền nhưng đơn không lên...",
  "max_output_tokens": 150
}

Response gateway trả về, kèm theo metadata phục vụ FinOps mà bản thân model provider không cung cấp:

{
  "output": "Khách hàng gặp lỗi thanh toán qua VNPay: giao dịch bị trừ tiền nhưng đơn hàng không được ghi nhận. Cần kiểm tra log webhook VNPay và đối soát giao dịch.",
  "usage": {
    "input_tokens": 210,
    "output_tokens": 48,
    "provider_used": "anthropic/claude-haiku-4-5",
    "estimated_cost_usd": 0.00087,
    "cache_hit": false
  },
  "quota": {
    "monthly_budget_usd": 300,
    "spent_this_month_usd": 214.32,
    "remaining_pct": 28.6
  }
}

Team ticket-summarizer không cần biết, cũng không cần quan tâm, hôm nay gateway đang route qua Claude Haiku hay Titan Lite — họ chỉ tiêu thụ một hợp đồng API ổn định.

4. Bảng so sánh: tập trung hóa qua platform vs. mỗi team tự làm

Bảng này nên được đưa thẳng vào slide trình bày với CTO/VP Engineering khi đề xuất đầu tư platform — dòng cuối cùng là dòng dễ bị bỏ qua nhất nhưng lại là dòng CFO sẽ hỏi trước tiên.

Cạm bẫy thường gặp

Xây platform trước khi có đủ use-case để chuẩn hóa. Nếu công ty mới có 2 team dùng AI với 2 use-case đơn giản, việc đầu tư 2-3 kỹ sư platform xây gateway, quota engine, self-service portal là lãng phí — chi phí xây và vận hành platform vượt xa giá trị nó tiết kiệm được. Ngưỡng hợp lý để bắt đầu nghĩ tới AI platform thường rơi vào khoảng 5-8 use-case AI độc lập trở lên, hoặc khi chi phí AI hàng tháng đã đủ lớn để CFO bắt đầu hỏi câu hỏi khó. Trước ngưỡng đó, một shared library nội bộ (một package npm/pip wrap sẵn SDK + logging cơ bản) đã đủ — chưa cần cả một portal.

Áp đặt chuẩn từ trên xuống mà không có sự đồng thuận của các team. Platform team dễ mắc lỗi thiết kế gateway theo nhu cầu của riêng mình rồi bắt buộc toàn công ty dùng, dẫn tới các feature team âm thầm tìm đường vòng (shadow AI usage) — chính xác vấn đề ban đầu platform được sinh ra để giải quyết. Cách thực tế hơn: đưa 2-3 team đầu tiên vào làm "design partner" khi xây gateway, launch ở dạng opt-in với incentive rõ ràng (ví dụ: dùng gateway thì không cần tự xin ngân sách AWS/OpenAI riêng, không cần tự lo logging/compliance), rồi mới dần biến nó thành mandatory path cho use-case mới sau khi đã chứng minh giá trị.

Quota cứng nhắc giết chết khả năng thử nghiệm. Nếu policy quota áp dụng y hệt cho môi trường production và sandbox thử nghiệm, các kỹ sư sẽ ngại thử ý tưởng mới vì sợ tốn quota của use-case đang chạy thật. Giải pháp thực dụng: tách riêng một "sandbox tier" với budget nhỏ, model rẻ mặc định, không cần qua quy trình đăng ký PR đầy đủ như production — giữ được tốc độ đổi mới trong khi vẫn kiểm soát được chi phí và bảo mật ở tầng production.

🧭 Góc nhìn Solutions Architect
Nếu ngày mai một feature team đề xuất một use-case AI mới, họ có cần biết tên provider hay SDK cụ thể nào không — hay chỉ cần khai báo capability và budget? Nếu OpenAI đổi giá gấp đôi qua đêm, bao nhiêu dòng code trong công ty phải sửa? Và nếu câu trả lời không phải là "chỉ một file cấu hình", platform của bạn chưa thực sự là một lớp trừu tượng — nó chỉ là một cái tên gọi khác cho tình trạng phân mảnh cũ.

🔗 Bài viết liên quan

• Bài 20: AI Integration Patterns — những LLM Agents — các pattern tích hợp AI ở tầng kiến trúc mà gateway này cần route tới.
• Bài 26: Evaluation & Monitoring — ảo giác — logging tập trung ở gateway là nguồn dữ liệu đầu vào trực tiếp cho hệ thống eval.

Bài trước: Evaluation & Monitoring · Bài tiếp theo: LLM Ops (LLMOps)