Một AI PoC có thể được hoàn thành trong vài tuần. Doanh nghiệp đưa vào một số tài liệu mẫu, kết nối một mô hình AI, xây giao diện đơn giản và nhanh chóng có một demo có thể đọc tài liệu, trả lời câu hỏi, phân loại yêu cầu hoặc tạo báo cáo.
Trong buổi trình diễn, kết quả có thể rất thuyết phục. AI hiểu phần lớn câu hỏi, phản hồi nhanh và thực hiện những công việc trước đây cần con người xử lý. Sau demo, đội dự án đi đến một kết luận tưởng như rất tự nhiên: “AI đã làm được, bước tiếp theo chỉ là triển khai.”
Nhưng đây thường là lúc phần khó thực sự bắt đầu.
Khi chuyển từ vài chục dữ liệu mẫu sang dữ liệu thật, từ một nhóm thử nghiệm sang người dùng thật, từ việc AI chỉ tạo output sang việc Agent được kết nối với CRM, ERP hoặc hệ thống nội bộ, hàng loạt vấn đề mới xuất hiện. Dữ liệu không còn sạch như trong demo. Permission khác nhau giữa người dùng. API có thể lỗi. Một số trường hợp không nằm trong tài liệu. Hai nguồn dữ liệu có thể mâu thuẫn. Và một câu trả lời sai trong production có hậu quả rất khác một câu trả lời sai trong PoC.
Vì vậy, một PoC thành công chưa chứng minh rằng hệ thống đã sẵn sàng cho production. Nó chỉ chứng minh một số giả thuyết quan trọng đã có tín hiệu tích cực.
Câu hỏi tiếp theo phải là: Chúng ta đã chứng minh điều gì, và còn điều gì chưa được chứng minh?
PoC và Production đang trả lời hai câu hỏi khác nhau
Mục tiêu của PoC là giảm uncertainty.
Doanh nghiệp có thể muốn kiểm tra liệu AI có đọc được loại tài liệu đang sử dụng hay không, có thể phân loại email đủ tốt không, có thể tìm đúng thông tin trong knowledge base hay không hoặc có thể hỗ trợ một phần workflow cụ thể hay không.
PoC vì vậy có thể sử dụng phạm vi nhỏ, dữ liệu được lựa chọn và một số bước thủ công phía sau. Điều đó không có gì sai. Nếu phải xây toàn bộ hệ thống production chỉ để kiểm tra một giả thuyết, PoC sẽ mất đi ý nghĩa của nó.
Vấn đề xuất hiện khi doanh nghiệp sử dụng tiêu chuẩn của PoC để kết luận về production.
Một demo trả lời câu hỏi:
“AI có khả năng thực hiện task này không?”
Production phải trả lời một câu hỏi rộng hơn:
“Hệ thống có thể thực hiện task này ổn định, an toàn và tạo ra giá trị trong workflow thực tế hay không?”
Khoảng cách giữa hai câu hỏi này chính là chủ đề trung tâm của Từ AI Agent đến vận hành thực tế: Vì sao doanh nghiệp cần cách tiếp cận FDE?. Model chỉ là một phần. Production còn liên quan đến workflow, data, integration, permission, exception handling, monitoring và KPI.
PoC thường được thử với những dữ liệu “đẹp” hơn thực tế
Để kiểm tra nhanh một ý tưởng, đội dự án thường chọn một tập dữ liệu tương đối tốt. Một số tài liệu tiêu biểu được chuẩn bị, vài chục câu hỏi được tạo và những use case chính được thử nghiệm.
Nhưng dữ liệu production hiếm khi gọn gàng như vậy.
Một tài liệu có thể bị thiếu trang. Một file khác sử dụng template cũ. Email chứa nhiều yêu cầu cùng lúc. Khách hàng viết tắt hoặc sử dụng cách diễn đạt không có trong dữ liệu mẫu. Một record trong CRM chưa được cập nhật. Hai tài liệu chứa thông tin khác nhau. Một trường hợp ngoại lệ chỉ xuất hiện vài lần mỗi tháng nhưng lại có hậu quả lớn nếu xử lý sai.
Nếu PoC chỉ được kiểm tra trên happy path, tỷ lệ thành công có thể rất cao nhưng chưa phản ánh môi trường vận hành.
Vì vậy, một PoC tốt không nên chỉ hỏi “AI xử lý được bao nhiêu case?” mà còn phải chủ động tìm những trường hợp khiến hệ thống thất bại.
Edge case không phải thứ nên tránh trong PoC. Nó là một trong những dữ liệu giá trị nhất mà PoC có thể tạo ra.
Một demo thường được “giúp đỡ” nhiều hơn chúng ta nghĩ
Giả sử doanh nghiệp đang thử nghiệm một Agent hỗ trợ Sales. Trước demo, đội dự án xuất dữ liệu khách hàng từ CRM, chọn các email liên quan, chuẩn bị proposal cũ rồi đưa tất cả vào một thư mục để Agent sử dụng.
Agent tổng hợp context rất tốt.
Nhưng trong production, ai sẽ thực hiện phần chuẩn bị đó?
Nếu mỗi lần Sales muốn sử dụng Agent lại phải tự tìm customer ID, tải dữ liệu CRM, chọn email và upload tài liệu, doanh nghiệp chưa tự động hóa được workflow. Họ chỉ chuyển một phần công việc từ “đọc tài liệu” sang “chuẩn bị dữ liệu cho AI”.
Đây là một câu hỏi rất hữu ích khi review PoC:
Trong demo hiện tại, con người đang thực hiện thủ công những bước nào mà production sẽ phải tự động thực hiện?
Danh sách này thường tiết lộ phần lớn khoảng cách còn lại.
Nếu AI cần một file Excel được làm sạch thủ công, production cần data pipeline hoặc preprocessing. Nếu người demo tự chọn đúng tài liệu, production cần retrieval logic. Nếu người vận hành copy customer ID vào prompt, production cần CRM integration. Nếu người demo kiểm tra output trước khi trình bày, production cần một cơ chế Human-in-the-loop.
PoC càng phụ thuộc vào thao tác “hậu trường”, khoảng cách đến production càng lớn.
AI trả lời đúng chưa có nghĩa workflow đã chạy đúng
Đây là một khác biệt quan trọng.
Giả sử AI đọc một email và xác định chính xác rằng khách hàng muốn thay đổi địa chỉ giao hàng. Nếu mục tiêu của PoC chỉ là hiểu intent, đây có thể được xem là thành công.
Nhưng workflow thực tế còn nhiều bước. Hệ thống phải xác định khách hàng, tìm đơn hàng, kiểm tra trạng thái, xác định đơn còn được phép thay đổi hay không, kiểm tra địa chỉ mới, cập nhật hệ thống và gửi xác nhận.
AI có thể hiểu đúng email nhưng API update thất bại. Agent có thể tìm đúng order nhưng chọn nhầm record của cùng khách hàng. Business rule có thể chưa bao phủ một trạng thái đặc biệt. Hệ thống có thể cập nhật thành công nhưng không ghi log.
Trong production, task accuracy và workflow success không phải cùng một khái niệm.
Một PoC chỉ đánh giá output của model có thể bỏ qua phần lớn những điểm failure sẽ xuất hiện khi giải pháp được đưa vào business process thật.
Integration thường là nơi demo bắt đầu gặp thực tế
Khi AI chỉ đọc một file và trả lời câu hỏi, kiến trúc tương đối đơn giản. Khi Agent cần tham gia vào workflow, nó phải kết nối với thế giới bên ngoài.
CRM, ERP, database, email, calendar, file storage, knowledge base, ticketing system và các hệ thống nội bộ đều có API, authentication, data model và giới hạn khác nhau.
Một integration tưởng như đơn giản có thể phát sinh hàng loạt câu hỏi. API có cho phép lấy đúng dữ liệu cần thiết không? Rate limit là bao nhiêu? Có sandbox không? Customer ID giữa hai hệ thống có giống nhau không? Hệ thống legacy có API hay chỉ có UI? Quyền truy cập của từng user có được phản ánh khi Agent truy xuất dữ liệu không?
Đây là lý do trong bài AI Agent, RPA, API hay Workflow Automation: Doanh nghiệp nên dùng gì cho từng bài toán?, AI Agent không được xem là công nghệ thay thế cho integration.
Agent có thể quyết định cần lấy dữ liệu nào. Nhưng việc lấy dữ liệu một cách ổn định vẫn cần một integration layer đủ tốt.
Nếu PoC bỏ qua hoàn toàn integration, nó mới chỉ kiểm chứng phần “AI”, chưa kiểm chứng solution.
Dữ liệu production không chỉ cần tồn tại, mà còn phải có thể sử dụng
Một doanh nghiệp có thể nói: “Chúng tôi có dữ liệu này trong CRM.” Nhưng điều đó chưa có nghĩa Agent có thể sử dụng nó ngay.
Dữ liệu có thể thiếu, không được cập nhật thường xuyên hoặc được nhập theo cách khác nhau giữa các team. Một trường quan trọng có thể tồn tại nhưng phần lớn record để trống. Một số thông tin lại nằm trong note tự do thay vì trường có cấu trúc.
Khi Agent kết hợp nhiều hệ thống, một vấn đề khác xuất hiện: source of truth.
Nếu CRM nói khách hàng đang ở trạng thái A nhưng hệ thống vận hành nói B, Agent nên tin nguồn nào? Nếu một file nội bộ mới hơn database nhưng không có timestamp đáng tin cậy, hệ thống xử lý ra sao?
AI không tự giải quyết data governance.
Ngược lại, AI có thể khiến vấn đề khó phát hiện hơn nếu nó tổng hợp những dữ liệu mâu thuẫn thành một câu trả lời trôi chảy.
Vì vậy, production readiness phải bao gồm cả câu hỏi về data quality, ownership và source of truth, chứ không chỉ model quality.
Permission thường bị đơn giản hóa trong PoC
Trong demo, Agent có thể sử dụng một service account với quyền truy cập rộng để đội dự án phát triển nhanh hơn. Nhưng production không thể mặc định rằng mọi người đều được nhìn thấy cùng một dữ liệu.
Sales A có được xem dữ liệu khách hàng của Sales B không? Manager có được truy cập dữ liệu chi tiết của tất cả nhân viên không? Agent có được đọc hợp đồng chứa thông tin nhạy cảm không? Khi người dùng hỏi một câu vượt quá quyền của họ, hệ thống phải phản ứng thế nào?
Câu hỏi còn phức tạp hơn khi Agent có quyền hành động.
Quyền đọc CRM không đồng nghĩa quyền sửa CRM. Quyền tạo draft email không đồng nghĩa quyền gửi email. Quyền chuẩn bị refund không đồng nghĩa quyền phê duyệt refund.
Bài Human-in-the-loop: Vì sao AI Agent vẫn cần con người? đã đề cập đến cách phân chia quyền theo Read → Suggest → Prepare → Approve → Execute. Đây là một trong những framework cần được đưa vào khi chuyển từ PoC sang production.
Một PoC có thể chứng minh Agent biết làm gì. Production phải xác định Agent được phép làm gì.
“AI không biết” cần được thiết kế như một trạng thái hợp lệ
Một trong những khác biệt lớn giữa demo và production là cách xử lý uncertainty.
Trong demo, nếu AI trả lời sai một câu, đội dự án có thể chỉnh prompt, bổ sung tài liệu rồi thử lại. Trong production, hệ thống cần biết phải làm gì ngay tại thời điểm đó.
Nếu không tìm thấy dữ liệu thì sao? Nếu hai nguồn mâu thuẫn? Nếu yêu cầu nằm ngoài policy? Nếu confidence không đủ? Nếu Agent không xác định được customer record chính xác?
Một thiết kế nguy hiểm là buộc Agent luôn phải tạo ra câu trả lời hoặc hành động.
Một thiết kế tốt hơn cho phép trạng thái:
“Không đủ thông tin để tiếp tục.”
Từ đó, workflow có thể yêu cầu thêm dữ liệu, chuyển cho con người hoặc dừng hành động.
Trong môi trường doanh nghiệp, một Agent biết dừng đúng lúc thường an toàn hơn một Agent luôn cố hoàn thành nhiệm vụ.
Human-in-the-loop không nên được bổ sung ở phút cuối
Một pattern phổ biến là đội dự án xây Agent trước, sau đó gần production mới hỏi: “Chúng ta có cần người approve không?”
Thứ tự này nên được đảo lại.
Ngay khi mapping workflow, đội dự án cần xác định bước nào có thể tự động, bước nào cần approval và bước nào bắt buộc phải do con người quyết định.
Giả sử Agent hỗ trợ Sales follow-up. AI có thể tự động đọc meeting note và tạo summary. Nó có thể tự tạo task trong CRM nếu action item rõ ràng. Nhưng email chứa báo giá hoặc điều khoản thương mại có thể cần Sales review trước khi gửi.
Với Customer Service, Agent có thể tự phân loại yêu cầu và tìm policy, nhưng những case liên quan đến ngoại lệ hoặc giá trị tài chính lớn có thể phải escalation.
Human-in-the-loop vì vậy là một phần của workflow architecture, không phải “safety button” được thêm vào sau khi Agent đã hoàn thành.
Nếu không có failure path, hệ thống chưa sẵn sàng cho production
Hãy hình dung một workflow hoạt động tốt trong 95% trường hợp. Con số này nghe có vẻ cao.
Nhưng nếu hệ thống xử lý 10.000 transaction mỗi tháng, 5% còn lại tương đương 500 case cần được xử lý theo một cách nào đó.
Điều gì xảy ra với 500 case đó?
Chúng được retry? Chuyển vào queue? Gửi cảnh báo? Chuyển cho nhân viên nào? Context đã xử lý có được giữ lại không? Nếu một action đã thực hiện một phần rồi mới thất bại thì rollback thế nào?
Một production system phải được thiết kế cho cả success path và failure path.
Điều này cũng thay đổi cách đánh giá AI. Một Agent có accuracy thấp hơn một chút nhưng phát hiện uncertainty tốt và escalation đúng có thể phù hợp với production hơn một Agent có average accuracy cao nhưng tự tin thực hiện hành động sai ở những case quan trọng.
Logging và audit không tạo ra demo đẹp, nhưng production cần chúng
Khi Agent đưa ra một kết quả không đúng, đội vận hành cần có khả năng trả lời: hệ thống nhận input gì, lấy dữ liệu từ đâu, tool nào được gọi, business rule nào được áp dụng, output nào được tạo, ai approve và action nào đã được thực hiện.
Nếu không có những thông tin này, việc điều tra lỗi sẽ rất khó.
Logging cũng cần cho improvement. Nếu doanh nghiệp biết Agent thường thất bại ở loại tài liệu nào, tool nào thường timeout hoặc loại request nào liên tục escalation, đội dự án có thể ưu tiên cải thiện đúng nơi.
Một PoC có thể không cần hệ thống observability hoàn chỉnh. Nhưng trước production, khả năng theo dõi workflow cần trở thành một phần của architecture.
AI Agent không nên là một black box mà chỉ biết input và output.
Một PoC tốt phải có KPI trước khi bắt đầu
Một PoC có thể tạo ra output rất ấn tượng nhưng vẫn thất bại về mặt kinh doanh nếu không giải quyết được bottleneck đủ lớn.
Giả sử AI có thể tóm tắt một loại tài liệu với chất lượng tốt. Nếu nhân viên trước đây chỉ mất hai phút để đọc tài liệu đó và mỗi tháng chỉ có 50 tài liệu, lợi ích có thể không đủ lớn để justify một hệ thống production.
Ngược lại, một automation không quá “AI” nhưng giảm được năm phút cho một task diễn ra 20.000 lần mỗi tháng có thể tạo ra business case rõ hơn.
Vì vậy, trước PoC cần xác định baseline: hiện tại workflow mất bao lâu, volume bao nhiêu, bao nhiêu thao tác thủ công, error hoặc rework rate là bao nhiêu và bottleneck nằm ở đâu.
Sau PoC, doanh nghiệp đo lại những chỉ số tương tự.
Điều này giúp chuyển cuộc thảo luận từ “AI có vẻ hoạt động tốt” sang “workflow đã cải thiện bao nhiêu?”
Nếu doanh nghiệp vẫn đang ở bước tìm use case, bài 7 dấu hiệu một quy trình có tiềm năng ứng dụng AI Agent có thể được sử dụng như bước sàng lọc trước khi chọn PoC.
Đừng cố đưa toàn bộ workflow vào PoC đầu tiên
Một phản ứng khác khi nhận ra production phức tạp là cố giải quyết tất cả ngay trong PoC: nhiều phòng ban, nhiều hệ thống, nhiều loại dữ liệu và nhiều loại Agent.
Điều này dễ khiến PoC trở thành một dự án phần mềm lớn trước khi business hypothesis cơ bản được chứng minh.
Một PoC tốt nên đủ nhỏ để học nhanh nhưng đủ thật để kết quả có ý nghĩa.
Thay vì “AI Agent tự động hóa toàn bộ Customer Service”, có thể chọn một loại request có volume đủ lớn. Thay vì “AI Agent hỗ trợ toàn bộ Sales”, có thể bắt đầu từ meeting preparation. Thay vì “AI tự động hóa Back Office”, có thể chọn một loại hồ sơ cụ thể.
Điểm quan trọng là phạm vi phải đủ hẹp để kiểm soát, nhưng vẫn chạm vào workflow thật, dữ liệu thật và người dùng thật ở mức phù hợp.
Nếu PoC chỉ hoạt động trên một dataset hoàn toàn tách khỏi operation, doanh nghiệp sẽ học rất ít về production.
PoC nên tạo ra danh sách những điều chưa biết
Một cách đánh giá PoC hữu ích là không chỉ ghi lại những gì đã thành công, mà còn liệt kê những uncertainty còn lại.
Ví dụ, PoC đã chứng minh AI có thể trích xuất các trường quan trọng từ 85% loại tài liệu phổ biến. Nhưng chưa biết hiệu quả với template cũ. Chưa kiểm tra permission với nhiều nhóm người dùng. Chưa kết nối API production. Chưa biết chi phí ở volume thực tế. Chưa thiết kế exception handling.
Danh sách này không làm PoC trông kém thành công hơn. Ngược lại, nó giúp doanh nghiệp biết chính xác bước tiếp theo là gì.
PoC có giá trị không phải vì nó chứng minh “mọi thứ đều ổn”.
PoC có giá trị vì nó giúp biến những điều chưa biết thành những điều đã biết hoặc những câu hỏi cụ thể hơn.
Từ PoC đến Production không phải một cú nhảy
Một cách nhìn thực tế hơn là chia quá trình thành nhiều lớp trưởng thành.
Ở giai đoạn đầu, Prototype kiểm tra khả năng kỹ thuật. Sau đó, PoC kiểm tra một business hypothesis với dữ liệu gần thực tế hơn. Tiếp theo, Pilot đưa solution vào một phạm vi người dùng hoặc workflow giới hạn để quan sát hành vi trong operation. Chỉ sau khi các vấn đề về integration, permission, failure handling và measurement đủ rõ, hệ thống mới được mở rộng sang Production.
Có thể hình dung:
Prototype → PoC → Pilot → Controlled Production → Scale.
Không phải dự án nào cũng cần đặt tên chính xác cho từng giai đoạn, nhưng tư duy phía sau rất quan trọng: mức đầu tư và mức quyền của Agent tăng dần cùng với lượng bằng chứng doanh nghiệp thu được.
Điều này an toàn hơn việc đi từ một demo thành công thẳng tới rollout toàn tổ chức.
Khi nào nên dừng một AI PoC?
Không phải PoC nào cũng nên được production hóa.
Nếu PoC cho thấy chất lượng không đủ cho workflow, integration quá phức tạp so với business value, dữ liệu chưa sẵn sàng hoặc một giải pháp đơn giản hơn có thể giải quyết vấn đề tốt hơn, dừng dự án có thể là quyết định đúng.
Đây cũng là tinh thần của bài 10 trường hợp doanh nghiệp không nên vội sử dụng AI Agent.
PoC không chỉ tồn tại để chứng minh một ý tưởng đúng. Nó cũng tồn tại để giúp doanh nghiệp phát hiện một ý tưởng không đáng tiếp tục đầu tư trước khi chi phí trở nên lớn hơn.
Một PoC giúp doanh nghiệp quyết định “không làm” với bằng chứng rõ ràng vẫn có giá trị.
FDE giúp giữ PoC gần với production ngay từ đầu
Một trong những vai trò quan trọng của FDE là tránh để PoC trở thành một demo tách rời khỏi workflow.
Điều đó không có nghĩa PoC phải xây toàn bộ production architecture ngay lập tức. FDE cần phân biệt rõ phần nào có thể giả lập để học nhanh và phần nào phải được kiểm chứng sớm vì có khả năng trở thành blocker.
Ví dụ, UI có thể chưa cần hoàn chỉnh. Monitoring có thể chưa cần ở quy mô production. Nhưng nếu use case phụ thuộc vào một hệ thống legacy rất khó integration, khả năng truy cập hệ thống đó nên được kiểm tra sớm.
Tương tự, nếu Agent cần sử dụng dữ liệu nhạy cảm, permission model không nên bị bỏ qua đến cuối dự án. Nếu business value phụ thuộc vào việc xử lý hàng chục nghìn transaction, performance và cost ở volume lớn cần được ước tính sớm hơn.
FDE vì vậy giúp đội dự án liên tục đặt câu hỏi:
“Nếu PoC này thành công, điều gì có thể ngăn nó trở thành production?”
Những blocker quan trọng nhất được đưa vào quá trình thử nghiệm sớm thay vì chỉ xuất hiện sau khi demo đã hoàn thành.
Một checklist đơn giản trước khi gọi PoC là “sẵn sàng để đi tiếp”
Trước khi quyết định đầu tư vào giai đoạn tiếp theo, doanh nghiệp nên có câu trả lời tương đối rõ cho một số vấn đề cốt lõi.
Business problem đã đủ cụ thể chưa? Baseline và KPI có tồn tại không? AI đã được thử trên dữ liệu đủ đại diện chưa? Các edge case quan trọng đã được nhận diện chưa? Production data sẽ được lấy từ đâu? Integration chính có khả thi không? Source of truth đã rõ chưa? Agent được phép đọc và thực hiện những hành động nào? Trường hợp nào cần Human-in-the-loop? Failure path và escalation sẽ hoạt động ra sao? Có thể theo dõi và truy nguyên hành động của hệ thống không? Chi phí vận hành có phù hợp với business value dự kiến không?
Doanh nghiệp chưa cần hoàn thiện tất cả ở mức production ngay sau PoC. Nhưng nếu phần lớn câu hỏi này vẫn chưa được đặt ra, việc nói rằng giải pháp “chỉ còn bước triển khai” có thể quá sớm.
Một AI PoC thành công nên làm cho quyết định tiếp theo dễ hơn
Mục tiêu cuối cùng của PoC không phải tạo ra một buổi demo ấn tượng.
Một PoC tốt phải giúp doanh nghiệp ra quyết định tốt hơn: tiếp tục hay dừng, cần cải thiện phần nào, integration nào phải làm trước, mức automation nào phù hợp, rủi ro nào cần kiểm soát và business case có đủ mạnh để đầu tư tiếp hay không.
Nếu sau PoC câu trả lời duy nhất là “AI làm được”, doanh nghiệp vẫn còn thiếu nhiều thông tin.
Một kết quả hữu ích hơn là:
AI làm được task X với phạm vi Y. Với dữ liệu hiện tại, những case A và B hoạt động tốt; case C cần Human-in-the-loop. Integration với hệ thống D khả thi, nhưng hệ thống E cần xử lý thêm. Nếu đưa vào workflow, KPI cần kiểm chứng là F và G. Vì vậy, bước tiếp theo nên là một pilot giới hạn ở nhóm H.
Đó là lúc PoC bắt đầu trở thành một phần của quá trình đưa AI vào vận hành, thay vì chỉ là một màn trình diễn công nghệ.
Đã có PoC nhưng chưa biết làm gì tiếp theo?
Nếu doanh nghiệp đã có một AI demo hoặc PoC hoạt động tốt nhưng vẫn chưa rõ cách kết nối với dữ liệu thật, hệ thống thật, permission, Human-in-the-loop và KPI để tiến tới production, việc tiếp tục thêm tính năng cho demo chưa chắc là bước ưu tiên.
Synora có thể cùng doanh nghiệp review PoC từ góc nhìn FDE: xác định những giả thuyết đã được kiểm chứng, những khoảng trống còn lại và các blocker cần giải quyết trước khi chuyển sang Pilot hoặc Production.
Mục tiêu không phải production hóa mọi PoC. Mục tiêu là xác định PoC nào thực sự đáng để tiếp tục và cần làm gì để đưa nó vào workflow thật.
Review khoảng cách từ PoC đến Production
Đã có AI PoC? Bắt đầu bằng việc xác định những gì đã được chứng minh, những gì còn chưa chắc chắn và blocker nào cần giải quyết trước khi triển khai thực tế.
Bắt đầu review- Trích xuất đúng 92% trường thông tin trên 50 hợp đồng mẫu
- Độ chính xác với bản scan chất lượng thấp
- Chi phí khi xử lý 2.000 hợp đồng mỗi tháng
- Chưa được phê duyệt đưa dữ liệu khách hàng lên cloud