Từ AI prototype đến production: phần khó không còn nằm ở prompt

AI đã làm cho việc tạo prototype nhanh hơn rất nhiều.

Một founder có thể mô tả ý tưởng bằng vài đoạn prompt, dùng Lovable hoặc v0 để tạo frontend, nối một model API và trong một cuối tuần đã có một bản demo đủ thuyết phục để cho người khác xem. Một engineering team cũng có thể tạo agent xử lý tài liệu, thao tác trên browser hoặc thực hiện nhiều bước workflow chỉ trong vài ngày.

Nhưng tốc độ tạo prototype dễ tạo ra một ảo giác nguy hiểm: nếu demo đã chạy, phần còn lại chỉ là “deploy lên production”.

Những hướng dẫn production AI xuất hiện gần đây lại đang chỉ về kết luận ngược lại. OpenAI, Anthropic và các chương trình enterprise AI đang ngày càng nói ít hơn về prompt đơn lẻ và nhiều hơn về policy, evaluation, permission, approved actions, escalation, auditability và human approval.

Nói cách khác, phần khó của AI productionization không phải là làm cho AI có thể thực hiện một hành động. Phần khó là quyết định khi nào hệ thống được phép thực hiện hành động đó, làm sao biết nó làm đúng và chuyện gì xảy ra khi nó không chắc chắn.

Demo trả lời đúng không đồng nghĩa với hệ thống đáng tin

Hãy tưởng tượng một agent đọc email và tạo draft reply.

Trong demo, nó có thể hoạt động rất ấn tượng. Agent đọc một email, hiểu nội dung rồi tạo câu trả lời hợp lý trong vài giây.

Nhưng ngay khi đưa vào môi trường doanh nghiệp, hàng loạt câu hỏi khác xuất hiện. Agent được phép gửi email hay chỉ tạo draft? Nếu người gửi là khách hàng VIP thì sao? Nếu email có yêu cầu thay đổi thông tin thanh toán? Nếu nội dung chứa prompt injection? Nếu agent không chắc ai là người cần approve? Hệ thống lưu lại decision nào để audit sau này?

Không câu hỏi nào trong số đó được giải quyết chỉ bằng việc viết prompt tốt hơn.

Một prototype thường chứng minh rằng happy path tồn tại. Production system phải chứng minh rằng cả happy path lẫn những trường hợp bất thường đều được kiểm soát ở mức chấp nhận được.

Đây chính là khoảng cách mà nhiều AI product hiện nay phải vượt qua.

Production AI đang hình thành một vocabulary rất khác

Trong tuần vừa qua, OpenAI giới thiệu Presence theo hướng tập hợp các thành phần cần thiết để agent có thể hoạt động trong production, từ policy và SOP tới guardrail, approved actions, simulation, evaluation và escalation. Anthropic cũng tiếp tục mở rộng hướng dẫn về production agent với computer use cùng các capability phục vụ việc đưa agent vào workflow doanh nghiệp. Song song đó, chương trình về enterprise-ready AI agents của Cornell nhấn mạnh state machine, human approval gate, auditability và risk controls.

Các implementation cụ thể có thể khác nhau, nhưng vocabulary đang hội tụ.

Một production AI system ngày càng cần trả lời được ít nhất năm nhóm câu hỏi.

Thứ nhất là permission: AI được đọc gì, được thay đổi gì và được thực hiện hành động nào?

Thứ hai là evaluation: làm sao biết output đủ tốt trước khi ship và sau mỗi lần model, prompt hoặc dữ liệu thay đổi?

Thứ ba là observability: khi agent đưa ra quyết định sai, team có nhìn thấy trace đủ để hiểu nguyên nhân hay không?

Thứ tư là human control: hành động nào có thể tự động hoàn toàn và hành động nào cần con người approve?

Cuối cùng là failure handling: hệ thống làm gì khi tool lỗi, API timeout, model không chắc chắn hoặc state trở nên không nhất quán?

Đó mới là những câu hỏi production.

Human approval không phải dấu hiệu hệ thống AI yếu

Một trong những xu hướng đáng chú ý nhất của production AI là việc human approval được xem như một thành phần kiến trúc thay vì một biện pháp tạm thời.

Trong giai đoạn hype đầu tiên, một hệ thống càng autonomous thường càng được xem là tiên tiến. Nhưng khi agent bắt đầu tác động tới tiền, dữ liệu khách hàng, tài khoản hoặc workflow quan trọng, autonomy tuyệt đối không phải lúc nào cũng là mục tiêu tốt nhất.

Một hệ thống có thể tự động xử lý 90% trường hợp thông thường và đưa 10% trường hợp có rủi ro cao cho con người review đôi khi tốt hơn rất nhiều so với một agent cố tự quyết định 100%.

Điều quan trọng là approval không nên được thêm ngẫu nhiên. Nó cần nằm đúng nơi trong workflow.

Ví dụ, AI có thể tự động phân loại ticket nhưng cần approval trước khi refund tiền. Nó có thể tạo draft contract nhưng không tự động gửi. Nó có thể đề xuất thay đổi database nhưng không được phép chạy migration production. Nó có thể thu thập và tóm tắt thông tin nhưng phải escalation khi confidence thấp.

Đây là product design, không chỉ là AI engineering.

Evaluation phải tồn tại trước khi production có thể cải thiện có kiểm soát

Một điểm khác thường bị bỏ qua ở prototype là evaluation.

Khi một developer thay đổi một function truyền thống, unit test và integration test có thể cho biết behavior cũ có bị phá hay không. Với AI, output không hoàn toàn deterministic, nên evaluation cần một cách tiếp cận khác.

Team cần xác định những scenario thực tế, một tập dữ liệu đại diện và tiêu chí đánh giá đủ rõ để biết phiên bản mới tốt hơn hay tệ hơn phiên bản trước. Đối với một support agent, đó có thể là mức chính xác của classification, tỷ lệ hallucination, mức tuân thủ policy hoặc số trường hợp cần escalation. Đối với document extraction, đó có thể là field accuracy và error rate trên những document khó.

Nếu không có baseline, việc nâng model hoặc chỉnh prompt rất dễ biến thành “version này có vẻ tốt hơn”.

Trong production, “có vẻ” hiếm khi là tiêu chuẩn đủ tốt.

Observability quan trọng hơn khi AI có khả năng hành động

Một chatbot chỉ tạo text và một agent có khả năng gọi API khác nhau rất nhiều về risk profile.

Khi hệ thống chỉ trả lời, một hallucination có thể gây trải nghiệm xấu. Khi hệ thống có thể thay đổi record, gửi email, tạo refund hoặc thao tác trên browser, cùng một hallucination có thể trở thành operational incident.

Vì vậy, hệ thống cần biết agent đã nhận input nào, sử dụng instruction nào, gọi tool nào, nhận response gì và tại sao cuối cùng chọn action đó. Không nhất thiết phải log mọi dữ liệu nhạy cảm; trên thực tế privacy và security có thể yêu cầu masking hoặc redaction. Nhưng phải có đủ observability để điều tra failure.

Nếu không, team sẽ gặp một trong những tình huống khó chịu nhất trong production engineering: biết rằng hệ thống đã làm sai nhưng không biết tại sao.

Security cũng thay đổi khi AI có tool access

Prototype thường bắt đầu bằng một API key duy nhất có khá nhiều quyền. Cách này đủ nhanh cho demo nhưng nguy hiểm khi hệ thống bắt đầu có user thật.

Production cần permission boundary rõ hơn. Agent nên có đúng quyền nó cần, không phải tất cả quyền developer có. User A không được khiến agent đọc dữ liệu User B. Một tool phục vụ lookup không nên mặc nhiên có quyền update. Credential cần được quản lý như production secret thay vì nằm trong environment local hoặc một config dễ lộ.

Ngoài ra, prompt injection làm cho security model của AI khác đáng kể so với ứng dụng truyền thống. Khi model xử lý nội dung bên ngoài rồi đồng thời có khả năng gọi tool, nội dung mà agent đọc có thể cố gắng thay đổi behavior của chính agent.

Do đó, việc phân tách dữ liệu, instruction và action permission trở nên quan trọng hơn nhiều.

Từ “AI feature” sang “operating system”

Một production AI capability vì vậy hiếm khi chỉ gồm model API.

Nó là một hệ thống gồm model, data, tool, workflow, permission, evaluation, monitoring và human operation.

Đây cũng là lý do nhiều doanh nghiệp có thể tự tạo một prototype khá nhanh nhưng vẫn cần engineering support để đưa nó vào vận hành. Phần khó không nằm ở việc gọi API của OpenAI hay Anthropic. Phần khó là ghép AI vào một system đã có user, business rule và consequence thật.

Đó là một loại engineering rất gần với backend và SaaS production work truyền thống.

Một AI Production Readiness Review nên kiểm tra những gì?

Trước khi đưa prototype cho real users, thay vì chỉ hỏi “model trả lời có hay không?”, team nên review ít nhất năm lớp.

Architecture cần xem state nằm ở đâu, tool interaction diễn ra thế nào và system boundary có rõ không. Security cần xem permission, secrets, data access và action scope. Evaluation cần có một baseline đủ thực tế để phát hiện regression. Observability cần đủ để debug behavior và đo system health. Cuối cùng là operations: ai chịu trách nhiệm khi agent không chắc, khi nào human approval xảy ra và rollback như thế nào.

Đây cũng chính là cách Mikel Studio tiếp cận dịch vụ AI Prototype to Production: không phải làm prototype đẹp hơn, mà bổ sung những nền tảng cần thiết để hệ thống có thể được triển khai ổn định và sử dụng một cách có trách nhiệm. Mục tiêu là một sản phẩm có thể vận hành và tiếp tục cải thiện, thay vì một demo có thêm nhiều tính năng nhưng chưa sẵn sàng cho người dùng thật.

Prototype càng dễ tạo, production engineering càng quan trọng

AI coding tools sẽ tiếp tục khiến việc tạo application trở nên nhanh hơn. Điều đó không làm production engineering biến mất. Nó thay đổi vị trí giá trị.

Khi giao diện và happy path có thể được tạo trong vài giờ, giá trị sẽ dịch chuyển sang những việc khó tự động hóa hơn: architecture, judgement, data model, permission, evaluation, observability và operational design.

Một prototype tốt trả lời câu hỏi:

“Ý tưởng này có thể hoạt động không?”

Một production system phải trả lời thêm:

“Nó có hoạt động đủ đáng tin khi người dùng thật, dữ liệu thật và hậu quả thật xuất hiện hay không?”

Đó là một tiêu chuẩn hoàn toàn khác.

Nguồn tham khảo

• OpenAI — Introducing OpenAI Presence
• Anthropic — Claude for Enterprise
• eCornell — Building Enterprise-Ready AI Agents: From Prototypes to Production

Bước tiếp theo

Bạn đã có AI prototype nhưng chưa chắc nó sẵn sàng cho real users? Mikel Studio có thể thực hiện một Production Readiness Review tập trung vào architecture, permission, evaluation, observability và các rủi ro cần xử lý trước khi launch.