Giao diện chat & tích hợp AI nội bộ vào quy trình

Có mô hình chạy on-premise mới là một nửa. Nửa còn lại — cũng là nửa quyết định AI có thực sự được dùng hay không — là giao diện và tích hợp. Thực tế có hai lối vào: (1) giao diện chat cho nhân viên hỏi trực tiếp (phổ biến nhất là Open WebUI), và (2) API tương thích OpenAI để nối AI vào helpdesk, CRM và phần mềm nội bộ sẵn có. Bài 6/8 này hướng dẫn dựng cả hai, kèm xác thực SSO/RBAC và vài kịch bản tích hợp thực tế — tất cả vẫn nằm trong ranh giới hạ tầng của bạn.

Giao diện chat cho nhân viên — Open WebUI

Với đa số nhân viên, "AI nội bộ" chính là ô chat họ gõ câu hỏi vào. Open WebUI là giao diện mã nguồn mở phổ biến nhất cho mục đích này: trải nghiệm gần giống ChatGPT nhưng chạy hoàn toàn trên máy chủ của bạn, kết nối trực tiếp tới lớp serving (Ollama, vLLM…) đã dựng ở bài Serving.

Những gì nhân viên nhận được ngay khi triển khai:

• Lịch sử hội thoại: mỗi người có luồng chat riêng, lưu lại để tra cứu — vẫn nằm trong hạ tầng nội bộ.
• Chọn mô hình: chuyển giữa các model đang phục vụ (ví dụ một model nhanh cho hỏi đáp ngắn, một model lớn hơn cho tác vụ khó).
• Chia sẻ & cộng tác: chia sẻ một hội thoại hữu ích cho đồng nghiệp, tạo prompt mẫu dùng chung cho cả nhóm.
• Đính kèm & hỏi-đáp tài liệu: khi bật RAG, người dùng có thể tải tài liệu lên và hỏi nội dung bên trong.

Open WebUI thường được triển khai bằng Docker và đặt sau một reverse proxy nội bộ. Vì nó nói chuyện với backend qua chuẩn API tương thích OpenAI, bạn có thể trỏ nó vào bất kỳ lớp serving nào — đây cũng chính là cầu nối sang phần tích hợp API bên dưới.

Tích hợp qua API — endpoint tương thích OpenAI

Chat UI phục vụ con người; API phục vụ phần mềm. Điểm mấu chốt khiến việc tích hợp AI nội bộ trở nên dễ dàng là hầu hết các công cụ serving mã nguồn mở đều phơi ra endpoint tương thích với API của OpenAI — cùng đường dẫn (/v1/chat/completions), cùng định dạng request/response. Nghĩa là bất kỳ đoạn code nào vốn gọi OpenAI đều có thể chuyển sang gọi AI nội bộ của bạn chỉ bằng cách đổi base URL và API key, gần như không sửa logic.

Vài kịch bản nhúng thường gặp:

• Helpdesk / ticketing: khi một ticket mới được tạo, gọi API để gợi ý phân loại, tóm tắt hoặc soạn nháp câu trả lời cho nhân viên hỗ trợ.
• CRM: nút "tóm tắt lịch sử khách hàng" hoặc "soạn email theo dõi" ngay trong màn hình hồ sơ khách.
• Phần mềm nội bộ: thêm một widget chat vào ERP/portal, gọi API kèm ngữ cảnh của người dùng và (qua RAG) tài liệu phòng ban.
• Tự động hóa nền: job định kỳ tóm tắt báo cáo, trích xuất dữ liệu từ văn bản, phân loại nội dung — không cần con người ngồi chat.

Vì endpoint theo chuẩn OpenAI, các SDK và thư viện chính thống (Python, Node.js…) đều dùng lại được — chỉ cần cấu hình lại điểm kết nối. Đó là lý do tích hợp AI nội bộ thường nhanh hơn nhiều so với hình dung ban đầu.

Xác thực & phân quyền

Khi AI nội bộ có nhiều người dùng và chạm vào tài liệu nhạy cảm, xác thực và phân quyền không còn là tùy chọn. Ba lớp cần đặt từ đầu:

• SSO (đăng nhập một lần): để nhân viên dùng chính tài khoản công ty (qua OIDC/SAML hoặc LDAP), không tạo mật khẩu riêng — vừa tiện, vừa dễ thu hồi khi ai đó nghỉ việc.
• RBAC (phân quyền theo vai trò): quy định ai được thấy/hỏi gì — model nào, tài liệu nào, tính năng nào. Ví dụ: chỉ phòng nhân sự truy được trợ lý hỏi-đáp chính sách nội bộ.
• Giới hạn theo phòng ban: kết hợp RBAC với phân vùng dữ liệu ở lớp RAG — mỗi phòng ban chỉ truy xuất được kho tài liệu của mình, tránh rò rỉ chéo.

Open WebUI hỗ trợ nhiều người dùng, vai trò và tích hợp OAuth/OIDC; với tích hợp qua API, phân quyền thường được xử lý ở lớp cổng (gateway) trước khi request tới lớp serving. Việc chặn kết nối ra ngoài và các lớp phòng thủ khác được trình bày ở bài Hệ thống bảo mật AI nội bộ.

Vài kịch bản tích hợp thực tế

Tích hợp có giá trị khi gắn vào một công việc cụ thể. Ba kịch bản thường triển khai đầu tiên:

• Trợ lý tra cứu quy trình/chính sách: nhân viên hỏi "quy trình xin nghỉ phép thế nào?" và nhận câu trả lời kèm trích dẫn từ tài liệu nội bộ — thay cho việc lục sổ tay hay hỏi đồng nghiệp.
• Tóm tắt email/tài liệu: nút "tóm tắt" ngay trong hộp thư hoặc kho tài liệu, rút gọn văn bản dài thành các ý chính để đọc nhanh.
• Hỏi-đáp tài liệu phòng ban: mỗi phòng ban có một "góc hỏi-đáp" trên kho tài liệu riêng (hợp đồng, tài liệu kỹ thuật, hướng dẫn vận hành), phân quyền để không lẫn dữ liệu giữa các phòng.

Điểm chung: gần như kịch bản nào có ích cũng cần lớp RAG phía sau để AI trả lời dựa trên tài liệu thật của bạn thay vì "bịa". Chất lượng câu trả lời sau đó được đo và siết bằng eval/guardrails ở bài Đánh giá & tinh chỉnh.

# gọi thẳng endpoint OpenAI-compatible của AI nội bộ
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $INTERNAL_AI_KEY" \
  -d '{
    "model": "qwen2.5:7b",
    "messages": [{"role": "user", "content": "Tóm tắt quy trình xin nghỉ phép"}]
  }'

# chỉ đổi base URL + key — logic giữ nguyên
client = OpenAI(
  base_url="http://ai-noi-bo.local/v1", # endpoint on-premise
  api_key=INTERNAL_AI_KEY,
)
resp = client.chat.completions.create(
  model="qwen2.5:7b",
  messages=[{"role": "user", "content": user_question}],
)
# cắm resp vào helpdesk/CRM; thêm RAG ở tầng trước nếu cần trích dẫn

Góc nhìn Namtech

Namtech coi giao diện và tích hợp là bước "đưa AI vào tay người dùng thật". Chúng tôi thường bắt đầu bằng Open WebUI cho nhóm thử nghiệm để nhân viên làm quen, đồng thời phơi endpoint tương thích OpenAI để đội phát triển nội bộ nối AI vào phần mềm sẵn có mà không phải học API mới. SSO và RBAC được bật ngay từ đầu — vì với AI nội bộ, tiện dụng và kiểm soát truy cập phải đi cùng nhau. Nguyên tắc vẫn là bắt đầu từ một luồng rõ ràng, đo hiệu quả, rồi mới nhân rộng ra toàn tổ chức.

Câu hỏi thường gặp

Lưu ý: Bài viết mang tính hướng dẫn, cập nhật 02/07/2026; công cụ và mô hình thay đổi nhanh — hãy kiểm chứng phiên bản mới nhất khi triển khai.