FDE là điểm gặp giữa năng lực của AI và công việc có trách nhiệm trong tổ chức.
Gần đây, người ta nói rất nhiều về AI. Mô hình mới nào mạnh hơn, agent nào làm được nhiều việc hơn, doanh nghiệp nào đã bắt đầu dùng. Những câu hỏi ấy không sai. Nhưng khi đi vào một tổ chức thật, tôi thường gặp một câu hỏi khó hơn nhiều: AI sẽ đứng ở đâu trong công việc hằng ngày của chúng ta?
Không phải ở bản demo. Không phải ở một buổi trình diễn mà mọi dữ liệu đều sạch và mọi câu hỏi đều được chuẩn bị trước. Tôi muốn nói đến nơi có hồ sơ thiếu, có quy trình vòng vèo, có khách hàng nóng ruột, có nhân viên phải xử lý ngoại lệ, và có người lãnh đạo phải chịu trách nhiệm khi một quyết định gây hậu quả.
Forward Deployed Engineer, hay FDE, xuất hiện ở chính chỗ đó. Tôi không xem đây chỉ là một tên gọi mới trong ngành công nghệ. Nó là dấu hiệu cho thấy AI đang đi từ câu chuyện về năng lực mô hình sang câu chuyện về năng lực tổ chức.
Điều doanh nghiệp thiếu thường không phải là một model mạnh hơn
Một mô hình có thể viết, tóm tắt, phân loại, tìm kiếm, thậm chí lập kế hoạch khá ấn tượng. Nhưng một tổ chức chỉ bắt đầu có giá trị khi họ biết dùng năng lực ấy vào đúng việc, với đúng dữ liệu, trong đúng ranh giới.
Tôi gọi phần còn thiếu này là Structure Gap. Đó là khoảng cách giữa điều model có thể làm và điều tổ chức có thể tin cậy giao cho nó làm.
Khoảng cách ấy thường lộ ra qua ba câu hỏi rất đời thường. AI tham gia vào bước nào trong workflow? Đến mức nào thì cần người phê duyệt? Và nếu đội triển khai rời đi, ai sẽ hiểu, sửa, quyết định thay đổi hoặc dừng hệ thống?
Nghe qua, đây có vẻ là các câu hỏi quản trị. Thực ra, chúng là các câu hỏi kỹ thuật, vận hành và con người cùng lúc. Không trả lời được chúng, doanh nghiệp có thể có một chatbot hay một prototype rất đẹp, nhưng chưa có một hệ thống.
Khảo sát năm 2025 của McKinsey cho thấy 88% người trả lời nói tổ chức của họ đã dùng AI thường xuyên ở ít nhất một chức năng. Tuy nhiên, chỉ khoảng một phần ba cho biết doanh nghiệp đã bắt đầu mở rộng AI ở quy mô toàn tổ chức. Với agentic AI, 23% đang mở rộng ở đâu đó, còn 39% vẫn thử nghiệm.
Các con số này không nói rằng mọi doanh nghiệp đều phải tuyển FDE. Nhưng chúng cho ta thấy một chuyện khá rõ: dùng thử và vận hành bền vững là hai nấc rất khác nhau. McKinsey cũng đặt việc thiết kế lại workflow vào trung tâm của câu chuyện tạo giá trị.
Công nghệ luôn đi nhanh hơn khả năng hấp thụ của tổ chức
Đi qua nhiều làn sóng công nghệ, từ phần mềm, Internet, mobile, cloud, dữ liệu đến AI, tôi thấy một điều ít thay đổi: công nghệ mới luôn tạo cảm giác rằng mọi việc sẽ được giải quyết nhanh hơn khả năng thực tế của tổ chức.
Nhưng hệ thống tốt hiếm khi bắt đầu bằng một lời hứa lớn. Nó bắt đầu bằng việc có người chịu ngồi với người vận hành, nghe họ kể về những ngoại lệ mà tài liệu quy trình không ghi. Có những bước không nên tự động hóa, không phải vì AI kém thông minh, mà vì cái giá của một quyết định sai là quá lớn. Có những bước có thể tự động hóa ngay, không cần biến chúng thành một dự án AI hào nhoáng.
Tôi từng thấy nhiều dự án công nghệ thành công không phải vì họ chọn được công cụ hoàn hảo. Họ thành công vì biết rõ công cụ được dùng để giải quyết vấn đề nào, ai có quyền nói nó đang sai, và ngày mai ai sẽ tiếp tục chăm nó.
FDE không chỉ là kỹ sư, cũng không chỉ là tư vấn
FDE làm việc ở giữa hai thế giới vốn thường nói hai thứ tiếng khác nhau. Một bên là người hiểu hạ tầng, dữ liệu, API, evaluation và độ tin cậy. Bên kia là người hiểu khách hàng, doanh thu, rủi ro, quy trình và những áp lực của ngày làm việc thật.
Vì vậy, một FDE phải đi từ việc hiểu bài toán đến thiết kế giải pháp, từ triển khai đến quan sát việc sử dụng, rồi đưa bài học trở lại sản phẩm và cách làm chung. Câu hỏi họ phải theo đuổi không phải là “đã giao xong chưa?”, mà là “khách hàng có thực sự vận hành được chưa?”.
Tôi cho rằng đó là điểm phân biệt quan trọng. Bàn giao một phần mềm không đồng nghĩa với bàn giao một năng lực. Một năng lực chỉ được bàn giao khi người ở lại biết hệ thống để làm gì, biết những giới hạn của nó, biết nhìn vào đâu khi có sự cố, và có đủ quyền để can thiệp.
Đọc tín hiệu thị trường cho đúng
Sự xuất hiện của FDE không phải là một cơn sốt chức danh thuần túy. Nó phản ánh nhu cầu rất thật của các tổ chức đang cố đi qua khoảng cách từ thử nghiệm đến vận hành. Nhưng chúng ta cũng không nên biến nó thành một câu chuyện tuyển dụng màu hồng.
AWS công bố đầu tư 1 tỷ USD vào tổ chức FDE của họ. Điểm đáng chú ý trong thông báo của AWS không chỉ là con số đầu tư. Họ nói về việc khách hàng cần có hệ thống, runbook, tài liệu kiến trúc và những người nội bộ có thể tự vận hành sau dự án.
Đó là một tín hiệu đáng suy nghĩ. Giá trị của AI không dừng ở việc có một model tốt hơn. Giá trị nằm ở khả năng biến model thành một phần có ích của công việc, rồi để tổ chức tiếp tục đi được khi chuyên gia bên ngoài không còn ngồi cạnh họ.
Tuy vậy, một khoản đầu tư của một hãng công nghệ không thể đại diện cho cả thị trường. Đọc nó như một chỉ dấu về nơi nút thắt đang dịch chuyển thì hữu ích hơn. Nút thắt ấy là triển khai, tích hợp, kiểm soát và chuyển giao năng lực.
Ba năng lực làm nên bản lĩnh của FDE
Nghề này không cho phép chúng ta đứng mãi trong một vùng an toàn.
Kỹ thuật là điều kiện đầu tiên. FDE phải hiểu hệ thống, dữ liệu, cách tích hợp, cách đo chất lượng và cách xử lý khi mọi thứ không đi đúng như mong muốn. Không có nền tảng kỹ thuật, lời hứa với khách hàng rất dễ biến thành nợ kỹ thuật.
Nhưng kỹ thuật không đủ. FDE cần hiểu nghiệp vụ đủ sâu để nhận ra vấn đề thực sự có đáng giải không. Một workflow có thể gây bực bội cho nhiều người, nhưng không phải workflow nào cũng cần LLM. Có lúc một form rõ hơn, một rule đơn giản hơn hoặc một API được nối đúng chỗ đã giải quyết được phần lớn vấn đề.
Và sau cùng là phán đoán. Tôi gọi đó là FDE Judgment. Biết khi nào cho AI đề xuất, khi nào bắt AI dừng, khi nào để phần mềm tất định xử lý, và khi nào mời con người trở lại bàn. Đây không phải dấu hiệu của sự do dự. Đây là sự trưởng thành nghề nghiệp.
World Economic Forum nói đến nhu cầu tăng của kỹ năng AI và dữ liệu, nhưng đồng thời nhấn mạnh leadership, resilience và flexibility. Điều đó hợp lý. Khi công nghệ đi nhanh, người biết giữ được phán đoán thường có giá trị không kém người biết chạy nhanh.
Trước khi viết code, hãy đi một vòng qua công việc thật
Một FDE tốt không bắt đầu bằng việc mở máy và viết code. Họ bắt đầu bằng việc quan sát, hỏi và kiểm tra giả định.
Sau đó mới đến việc chọn workflow có tác động đủ rõ, xây một phiên bản có thể đánh giá, đưa vào sử dụng với kiểm soát, theo dõi giá trị và rủi ro, rồi cải tiến hoặc bàn giao. Vòng lặp này nghe đơn giản, nhưng nó buộc đội dự án trả lời những câu hỏi mà prototype thường né tránh.
Dữ liệu nào được phép dùng? Khi nào con người phải quyết định? Ta sẽ dựa vào bằng chứng nào để nói hệ thống hoạt động đúng? Khi nhóm triển khai rời đi, khách hàng có thể tự vận hành không?
Đây là chỗ evaluation trở nên quan trọng. Nó không phải chỉ là bảng điểm cho model. Nó là cách để một tổ chức biết lúc nào nên tin, lúc nào nên kiểm tra và lúc nào phải thay đổi quy trình.
Đạo đức AI bắt đầu từ chỗ ai được quyền quyết định
Trong Đạo đức AI: Nguyên tắc và Thực hành, tôi đã viết: “Bạn không thể thuê ngoài trách nhiệm giải trình.” (Chương 1, tr. 36.)
Open Library record https://openlibrary.org/books/OL62486007M/Câu này đặc biệt đúng với FDE. Khách hàng có thể mua phần mềm, thuê cloud, thuê đội tư vấn hoặc thuê một nhà cung cấp triển khai. Nhưng nếu AI từ chối một khách hàng, đánh giá một nhân sự, ưu tiên một hồ sơ hoặc đưa ra một khuyến nghị gây hại, tổ chức không thể nói rằng trách nhiệm thuộc về thuật toán hay bên thứ ba.
FDE không có nhiệm vụ nhận trách nhiệm thay khách hàng. Nhiệm vụ của họ là giúp khách hàng nhìn thấy trách nhiệm ấy từ đầu và thiết kế nó vào hệ thống.
Trong công việc của một FDE, nguyên tắc này có thể bắt đầu rất cụ thể. Ngay từ đầu, phải biết mục đích nào đang theo đuổi, dữ liệu nào được dùng, ai là người sở hữu quyết định và chỗ nào không được tự động hóa. Khi đưa hệ thống vào vận hành, cần có quyền truy cập tối thiểu, cơ chế chuyển cho người phù hợp khi AI không chắc chắn, log đủ để nhìn lại, và điều kiện dừng khi có sự cố. Sau đó, điều quan trọng là tiếp tục đo lỗi, lắng nghe phản hồi và sửa sai.
NIST AI RMF là một khung tham chiếu tốt để tổ chức suy nghĩ về quản trị rủi ro. Nhưng không khung nào làm thay công việc này. Mọi nguyên tắc chỉ trở nên có nghĩa khi được chuyển thành vai trò, quyết định và dấu vết có thể kiểm tra.
Hãy để số liệu làm công việc khiêm tốn của nó
Tôi thích có nguồn dưới mỗi con số, không phải để làm bài viết có vẻ hàn lâm hơn, mà để người đọc biết nên tin điều gì ở mức nào. McKinsey là khảo sát tự báo cáo, hữu ích để nhìn xu hướng, không phải bằng chứng về quan hệ nhân quả. AWS cho thấy góc nhìn và định hướng đầu tư của AWS, không đại diện cho cả thị trường. WEF gợi mở dịch chuyển kỹ năng dài hạn, không thể thay thế yêu cầu của từng vị trí tuyển dụng.
Sự tỉnh táo đó rất cần cho FDE. Nghề này làm việc ở nơi nhiều kỳ vọng gặp nhiều rủi ro. Càng nhiều số liệu, càng phải biết số liệu đang nói điều gì và đang im lặng về điều gì.
Khi rời dự án, bạn để lại điều gì?
Nếu chỉ nhìn FDE như người làm cho AI chạy được, chúng ta sẽ bỏ lỡ phần quan trọng nhất của nghề này.
FDE giúp tổ chức học cách quyết định, kiểm soát và sở hữu tương lai AI của mình. Đó là công việc đòi hỏi sự tò mò để hiểu hiện trường, năng lực kỹ thuật để hệ thống chạy ổn định, và sự can đảm để nói rằng có những việc AI chưa nên làm.
Khi dự án kết thúc, điều đáng ở lại không phải là một dashboard lấp lánh hay một demo được vỗ tay. Điều đáng ở lại là một tổ chức hiểu hệ thống của mình, có quyền điều chỉnh nó, biết sửa khi nó sai và không đánh mất quyền quyết định trước công nghệ.
Với tôi, đó mới là phần đáng theo đuổi của con đường FDE.