Vào ngày cuối tháng, kế toán phải mở tất cả hóa đơn phát sinh trong tháng đó để kiểm tra: mã hóa đơn có đúng không, ngày tháng có khớp không, tỷ giá có cập nhật không, cài đặt VAT có hợp lý không, ngôn ngữ có khớp với quốc gia của khách hàng không, nội dung dòng hàng có đúng quy ước không.
Nếu bỏ sót, có thể sẽ không phát hiện ra cho đến khi đã gửi cho khách hàng, và phải đính chính sau đó.
Nhưng việc đơn giản là "giao hết công việc kiểm tra này cho AI" cũng không phải là lựa chọn an toàn. Một khi hóa đơn đã phát hành thì rất khó thu hồi, và nếu AI tự động sửa sai só tiền hay tỷ giá mà không ai kiểm tra rồi gửi thẳng cho khách hàng, hậu quả sẽ không thể cứu vãn.
Điểm mấu chốt ở đây là một cơ chế kết nối AI Agent với hệ thống nghiệp vụ hiện có một cách an toàn, và chỉ trong phạm vi cần thiết.
Tại Bunbu, chúng tôi đã xây dựng điều này bằng một giao thức có tên MCP (Model Context Protocol). Bài viết này dùng chính quy trình rà soát hóa đơn thực tế làm ví dụ để giải thích MCP là gì, và cần thiết kế những gì khi tích hợp AI vào một hệ thống nghiệp vụ nội bộ.
I. MCP (Model Context Protocol) là gì
MCP là một giao thức chuẩn để kết nối mô hình AI (AI Agent như Claude) với các hệ thống và nguồn dữ liệu bên ngoài.
Trước đây, khi tích hợp AI vào hệ thống nghiệp vụ, người ta thường dùng một trong các cách sau:
- Tự xây API riêng cho từng trường hợp, rồi giải thích cách dùng cho AI qua prompt
- Xây batch job hoặc script riêng dành cho AI
- Cho AI truy cập trực tiếp vào database
Cả ba cách này đều dễ khiến cách tích hợp khác nhau giữa từng hệ thống, và ranh giới quyền hạn của AI trở nên mờ nhạt.
MCP tiếp cận theo hướng khác: tách riêng "điểm kết nối giữa AI Agent và hệ thống nghiệp vụ" thành một Server, và công khai nó dưới dạng các Tool rõ ràng.
MCP Server, nói cách khác, giống như "quầy API nghiệp vụ dành riêng cho AI Agent". AI chỉ có thể gọi những Tool (hàm) mà server công khai — không gì khác. Những gì AI làm được và không làm được được định nghĩa rõ ràng trong code.
II. Vấn đề Bunbu gặp phải
Tại Bunbu, chúng tôi quản lý hóa đơn cho khách hàng qua CRM nội bộ. Cuối tháng, có quy trình rà soát hóa đơn phát sinh trong tháng, tạo PDF và gửi cho khách hàng.
Quy trình rà soát này tuân theo những quy tắc như:
- Mã hóa đơn có được đánh theo quy tắc riêng của từng dự án (tên viết tắt dự án + năm tháng...) không?
- Ngày phát hành và hạn thanh toán có khớp với thông lệ giao dịch không?
- Tỷ giá có lệch so với tỷ giá hiện tại trong hệ thống không?
- Cài đặt VAT có phù hợp với quốc gia và hợp đồng của khách hàng không?
- Ngôn ngữ hóa đơn có khớp với quốc gia của khách hàng không?
- Nội dung dòng hàng (Item) có đúng quy ước đặt tên nội bộ (ví dụ ghi rõ tháng áp dụng) không?
- Trong số các dự án đang active, có dự án nào chưa có hóa đơn tháng này không?
Từng điểm riêng lẻ thì đơn giản, nhưng số lượng hóa đơn càng nhiều thì càng dễ bỏ sót. Đồng thời, không phải tất cả đều nên tự động sửa.
Chẳng hạn, tỷ giá liên quan đến quyết định kinh doanh về việc dùng tỷ giá tại thời điểm nào. Nội dung dòng hàng cũng vậy, cách ghi đúng thay đổi tùy theo tình hình dự án. Nếu AI tự ý sửa lại sao cho "có vẻ hợp lý", điều đó lại rất nguy hiểm.
Nói cách khác, điều cần thiết là một cơ chế tự động hoá những gì có thể khẳng định chắc chắn là đúng về mặt máy móc, và luôn để con người quyết định những gì cần phán đoán.
III. Cách giải quyết bằng MCP Server
Tại Bunbu, chúng tôi đã hiện thực hoá quy trình rà soát hóa đơn này dưới dạng MCP Server. AI Agent (Claude) truy cập dữ liệu hóa đơn trên CRM bằng cách gọi các Tool mà server này công khai.
1. Chia nghiệp vụ thành các Tool
Các Tool đã triển khai, ví dụ:
- list_month_invoices — lấy danh sách hóa đơn của tháng được chỉ định, và các dự án active chưa có hóa đơn
- check_invoice — kiểm tra 1 hóa đơn theo quy tắc và trả về danh sách vấn đề (Issue)
- fix_invoice — chỉ tự động sửa những Issue chắc chắn về mặt máy móc
- update_invoice_currency_rate / update_invoice_item_name — áp dụng giá trị sau khi con người đã quyết định
- create_invoice_pdf — tạo và đóng dấu PDF cho hóa đơn đã rà soát xong (không gửi đi)
AI Agent kết hợp các Tool này để thực hiện một chuỗi quy trình: liệt kê hóa đơn trong tháng, kiểm tra từng cái, sửa những gì sửa được, và xác nhận với con người những gì cần phán đoán.
2. Tính an toàn được đảm bảo bằng code, không phải bằng quy tắc vận hành
Điểm quan trọng nhất trong thiết kế server này là giới hạn hành vi của AI bằng chính code của server, thay vì bằng chỉ thị prompt.
Cụ thể, chúng tôi đã xây dựng các ràng buộc sau ở phía server:
- Chỉ hóa đơn ở trạng thái draft mới có thể sửa hoặc tạo lại PDF. Hóa đơn đã gửi cho khách hàng (unpaid / paid) không bao giờ bị thay đổi nội dung hay tạo lại PDF
- Các Tool thay đổi dữ liệu chỉ có thể gọi bởi vai trò có quyền (admin); vai trò chỉ xem/kiểm tra (accountant) không thực hiện được
- Mọi thay đổi đều được ghi lại trong nhật ký kiểm toán, cho biết ai là người thực hiện
- Không bao giờ tự động sửa tỷ giá. Nếu phát hiện lệch, Tool chỉ hiển thị "tỷ giá hiện tại" và "tỷ giá hệ thống tính được" — con người luôn phải chỉ định dùng tỷ giá nào
- Nếu thiếu thông tin cần thiết — ví dụ dự án chưa có tên viết tắt — AI không đoán mã hóa đơn. Nó phát cảnh báo và yêu cầu con người thiết lập lại
Chỉ yêu cầu AI "xin đừng làm X" trong prompt là chưa đủ — sớm muộn, một đầu vào hay cách diễn giải bất ngờ nào đó cũng sẽ vượt ranh giới đó. Ranh giới cần được đảm bảo bằng code, bằng cách giới hạn chính những Tool có thể gọi, chứ không phải bằng prompt.
3. Bước cuối cùng — "gửi cho khách hàng" — cố tình không tự động hoá
Chúng tôi đã tự động hoá đến tận bước tạo PDF, nhưng việc gửi PDF đó qua email cho khách hàng thì cố tình đặt ngoài phạm vi của AI Agent.
Hành động cuối cùng trong quy trình xuất hóa đơn — thứ liên quan trực tiếp đến mối quan hệ với khách hàng — luôn do con người thực hiện sau khi đã xác nhận cuối cùng. Đây không hẳn là giới hạn kỹ thuật, mà là một quyết định nghiệp vụ có chủ đích.
IV. Những điểm thiết kế then chốt
Qua dự án này, chúng tôi rút ra 3 điều quan trọng khi đưa AI Agent vào một quy trình nghiệp vụ nội bộ.
1. "Có thể tự động hoá" và "nên tự động hoá" là hai chuyện khác nhau
Về mặt kỹ thuật, có thể tự động sửa tỷ giá, thậm chí tự động gửi hóa đơn. Nhưng điều đó không có nghĩa là nên làm như vậy. Ranh giới giữa tự động hoá và quyết định của con người không phải thứ để hỏi AI, mà là quyết định thiết kế phải do con người hiểu rõ nghiệp vụ đưa ra.
2. Tính an toàn đến từ hệ thống, không phải từ prompt
Dù viết chỉ thị cho AI Agent cẩn thận đến đâu, đó vẫn chỉ là một "lời đề nghị". Bằng cách triển khai ràng buộc trong code của server — không phải trạng thái draft thì không được sửa, không đủ quyền thì không thực hiện được — tính an toàn được đảm bảo bất kể AI hành xử như thế nào.
3. Chia nhỏ thành các Tool có phạm vi quyền rõ ràng
Thay vì xây 1 Tool lớn "xử lý hóa đơn", chúng tôi chia thành các đơn vị: liệt kê, kiểm tra, sửa, tạo PDF — và định nghĩa riêng quyền hạn cần thiết và phạm vi áp dụng (ví dụ chỉ draft) cho từng Tool. Nhờ đó, luôn rõ ràng AI có thể làm gì, đến đâu.
V. Lời nhắn từ Bunbu
MCP cung cấp một cách chuẩn để kết nối AI Agent với hệ thống nghiệp vụ hiện có. Điều quan trọng là bản thân MCP không tự động đảm bảo an toàn.
Quyết định công khai Tool nào, mỗi Tool cần ràng buộc gì, ranh giới để con người quyết định nằm ở đâu — công việc thiết kế này vẫn thuộc về những kỹ sư hiểu rõ cả nghiệp vụ lẫn hệ thống, như từ trước đến nay.
Tại Bunbu, chúng tôi hỗ trợ thiết kế và triển khai MCP Server như thế này cho các hệ thống nghiệp vụ, CRM, ERP hiện có của khách hàng.
Nắm rõ hiện trạng hệ thống → xác định có thể giao bao nhiêu cho AI → thiết kế phạm vi có thể tự động hoá an toàn dưới dạng Tool → đưa dần vào nghiệp vụ theo từng giai đoạn
Thay vì "giao hết cho AI", việc xây dựng một cơ chế để con người và AI có thể hợp tác an toàn — đó chính là cách tiếp cận của Bunbu đối với việc tích hợp hệ thống nghiệp vụ trong thời đại AI.
Từ ý tưởng đến hệ thống vận hành ổn định — BUNBU đồng hành cùng quý công ty qua mọi giai đoạn: lập kế hoạch, phân tích yêu cầu, phát triển, kiểm thử và vận hành. Hãy liên hệ để được tư vấn miễn phí.
