Tích hợp AI vào hệ thống doanh nghiệp: từ dữ liệu đến vận hành

Chọn một workflow và viết hợp đồng đầu ra trước khi chọn model

Tích hợp AI vào hệ thống doanh nghiệp nên bắt đầu từ một điểm chuyển giao cụ thể: phân loại email vào hàng đợi, trích xuất trường từ hợp đồng, tìm câu trả lời có dẫn nguồn hay chuẩn bị bản nháp cập nhật CRM. Hãy viết đầu vào, đầu ra, trường bắt buộc, điều kiện từ chối và người chịu trách nhiệm. Đây là hợp đồng để thiết kế API và eval.

Nếu quy trình hoàn toàn xác định, automation theo quy tắc có thể rẻ và ổn định hơn AI. AI phù hợp khi đầu vào không cấu trúc hoặc cần phán đoán trong ranh giới; quy tắc nghiệp vụ, hạn mức và hành động có hậu quả vẫn nên được kiểm soát bằng code xác định. Chọn model sau khi đã biết độ chính xác, độ trễ và chi phí cần đạt.

• ✓Một owner, một kết quả và một tập dữ liệu đại diện.
• ✓Schema đầu ra, validation và lý do từ chối rõ ràng.
• ✓Phân loại phần dùng AI, phần dùng rule và phần cần người quyết định.
• ✓Baseline về thời gian, lỗi, rework và chi phí hiện tại.

Tích hợp AI tốt không làm model biết mọi thứ. Nó cho model đúng ngữ cảnh, đúng công cụ và đúng quyền để hoàn thành một nhiệm vụ có thể kiểm tra.

Kiến trúc bảy lớp cho tích hợp AI có thể thay đổi

Một kiến trúc thực tế tách kênh yêu cầu, orchestration, dữ liệu hoặc retrieval, model, tool/API, policy và observability. Model không nên giữ credential hoặc gọi thẳng hệ thống production; một lớp dịch vụ kiểm tra schema, quyền, hạn mức và idempotency trước khi thực thi. OpenAPI giúp mô tả hợp đồng công cụ nhưng vẫn cần kiểm tra nghiệp vụ ở phía server.

Tách lớp giúp đổi model mà không viết lại CRM integration, đổi nguồn dữ liệu mà không phá giao diện và đánh giá từng thành phần khi kết quả sai. Với nhiệm vụ dài, queue và trạng thái rõ ràng tốt hơn giữ một request mở. Mọi hành động cần correlation ID để nối yêu cầu, dữ liệu truy xuất, model output, tool call và kết quả cuối.

• ✓Kênh vào và xác thực người dùng.
• ✓Orchestrator quản lý trạng thái, timeout và retry.
• ✓Retrieval có quyền, version và trích dẫn nguồn.
• ✓Model gateway kiểm soát model, prompt, giới hạn và chi phí.
• ✓Tool/API adapter xác thực schema và quyền nghiệp vụ.
• ✓Policy cùng human approval cho hành động quan trọng.
• ✓Log, metrics, trace, feedback và cảnh báo.

Quản lý dữ liệu và quyền truy cập theo từng yêu cầu

Retrieval phải giữ ranh giới quyền của hệ thống nguồn. Nhân viên không được thấy hợp đồng của phòng ban khác thì AI cũng không được truy xuất nội dung đó. Lưu document ID, phiên bản, nguồn và phạm vi quyền cùng mỗi đoạn dữ liệu để câu trả lời có thể kiểm tra và dữ liệu cũ có thể bị loại bỏ.

Chỉ gửi sang model dữ liệu tối thiểu cần cho nhiệm vụ. Bí mật, credential và trường nhạy cảm không nên xuất hiện trong prompt hoặc log nếu không cần. CISA và NCSC khuyến nghị secure-by-design xuyên suốt thiết kế, phát triển, triển khai và vận hành hệ thống AI; ranh giới dữ liệu và quyền cần được thiết kế trước khi kết nối production.

• ✓Kế thừa quyền từ nguồn thay vì tạo một kho dữ liệu mở cho mọi người.
• ✓Metadata về owner, version, hiệu lực và phạm vi sử dụng.
• ✓Che hoặc loại bỏ trường không cần thiết trước khi gọi model.
• ✓Retention, quyền xem log và quy trình thu hồi dữ liệu rõ ràng.

Xây eval và rollout từ quan sát đến tự động hóa

Test set cần chứa tình huống bình thường, dữ liệu thiếu, tài liệu mâu thuẫn, input độc hại và ngoại lệ nghiệp vụ. Đánh giá không chỉ câu trả lời mà cả retrieval, schema, tool selection và hành động cuối. NIST nhấn mạnh testing, evaluation, verification và validation trước triển khai và trong vận hành; OpenAI cũng khuyến nghị eval theo tiêu chí cụ thể để so sánh khi thay model hoặc prompt.

Rollout nên bắt đầu ở shadow mode, nơi AI xử lý nhưng chưa ảnh hưởng công việc. Sau đó chuyển sang đề xuất để người duyệt so sánh, rồi mới tự động hóa nhóm tình huống có rủi ro thấp. Giữ approval bắt buộc cho giao tiếp quan trọng, thay đổi dữ liệu, quyền truy cập, tài chính hoặc hành động khó đảo ngược.

• ✓Shadow: đo kết quả mà không tác động hệ thống nguồn.
• ✓Assist: tạo đề xuất, con người chỉnh và phê duyệt.
• ✓Bounded automation: tự chạy nhóm ổn định trong hạn mức.
• ✓Re-evaluate sau mỗi thay đổi model, prompt, data hoặc tool.

Checklist production và cách Friday Works bàn giao

Production cần rate limit, timeout, retry có kiểm soát, idempotency, circuit breaker, queue, fallback và kill switch. Dashboard theo dõi chất lượng, latency, chi phí, lỗi retrieval, tool failure và tỷ lệ human override. Runbook phải nêu ai nhận cảnh báo, cách tắt tính năng và cách xử lý tác vụ đang dở khi model hoặc API không sẵn sàng.

Friday Works bàn giao sơ đồ kiến trúc, hợp đồng API, data map, test set, báo cáo eval, cấu hình môi trường, dashboard và runbook theo phạm vi. Pilot tập trung thường 3–6 tuần sau giai đoạn xác nhận 1–2 tuần; hệ thống có nhiều nguồn dữ liệu hoặc hành động nhạy cảm được chia giai đoạn. Chỉ mở rộng khi bằng chứng production đạt ngưỡng đã thống nhất.

• ✓Sơ đồ dữ liệu, quyền, API và ownership.
• ✓Eval report cùng acceptance threshold và known limitations.
• ✓Monitoring, alert, budget limit, fallback và incident runbook.
• ✓Tài liệu bàn giao và cổng quyết định cho giai đoạn tiếp theo.