Governing AI Agents: khoá 1,5 giờ dạy đúng phần nền, nhưng chưa đủ cho production

Khoá học này chỉ dài khoảng 1,5 giờ và được xếp vào mức cho người mới. Nhưng một bài ở giữa đề cương đặt ra câu hỏi mà các bản demo agent thường né: agent này là ai?

Governing AI Agents là short course của DeepLearning.AI, làm cùng Databricks, do Amber Roberts, Staff Technical Marketing Manager tại Databricks, giảng dạy. Trang giới thiệu khoá nêu lý do ngắn gọn: khi agent tự truy cập lượng dữ liệu lớn hơn và nhạy cảm hơn, quản trị trở thành điều bắt buộc.

Với FDE, đó là chuyện của ngày đầu tiên agent chạm dữ liệu thật ở khách hàng. Đánh giá ngắn gọn: nên học nếu bạn chưa từng đưa agent lên production, nhưng hãy coi đây là nửa đầu của kỹ năng. Nửa còn lại nằm ngoài khoá.

Một buổi tối, ba lab và một việc đáng làm kỹ

Khoá xoay quanh bốn trụ cột: quản lý vòng đời, quản lý rủi ro, bảo mật và khả năng quan sát. Đề cương có 11 mục, gồm video, 3 lab và một bài quiz có chấm điểm; phần thực hành áp dụng quản trị cho một agent phân tích dữ liệu, giới hạn quyền của nó với dữ liệu nhạy cảm.

Yêu cầu đầu vào chỉ là Python cơ bản, nên kỹ sư phần mềm đang muốn chuyển sang FDE theo được ngay. Trang khoá, cập nhật ngày 17/7/2026, ghi rằng khoá miễn phí có thời hạn trong giai đoạn beta của nền tảng; tình trạng này có thể đã thay đổi, nên hãy kiểm tra lại trước khi đăng ký.

Bạn không cần học thuộc tên bốn trụ cột. Giá trị nằm ở ba ý dưới đây, và ở việc bạn mang chúng về công việc thế nào.

Ý đầu tiên: agent cần danh tính riêng trong hệ thống quyền

Lesson 4 nói về việc cho agent một danh tính. Thử hình dung một agent phân tích nhân sự, giống loại agent mà Lab 3 dùng, chạy bằng một service account chung có quyền đọc hồ sơ của 200 nhân viên.

Một quản lý có 12 người dưới quyền hỏi agent về lương của nhóm mình. Về mặt hệ thống, agent vẫn có thể đọc thêm 188 hồ sơ mà người hỏi không được phép xem. Không cần lỗi mô hình nào để rò rỉ xảy ra: chỉ cần một câu hỏi diễn đạt khác đi là đủ.

Một bài blog của Databricks về Unity Catalog cho thấy ý này trông ra sao ở production, với một quy tắc rõ ràng: nếu bạn không truy cập được một bảng trong Unity Catalog thì agent hành động thay bạn cũng không truy cập được.

Áp quy tắc đó vào ví dụ trên, agent không còn đọc được 188 hồ sơ thừa kia nữa.

Việc cần làm đầu tiên ở khách hàng: hỏi xem agent sẽ chạy bằng tài khoản nào. Nếu câu trả lời là một tài khoản dùng chung, hãy tính khoảng cách quyền như ví dụ trên và đặt con số đó lên bàn họp.

Ý thứ hai: trace còn là bằng chứng

Khoá định nghĩa khả năng quan sát là theo dõi input, output và quyết định của agent, để minh bạch và để debug. Đây là phần kỹ sư dễ tiếp nhận nhất, vì nó giống công việc logging quen thuộc.

Databricks đi thêm một bước trong một bài viết về MLflow tracing: khi trace ghi cả dấu vết quyền đã cho phép từng hành động, nó trở thành hồ sơ audit chứ không chỉ là công cụ debug.

Sự khác biệt lộ ra khi có người hỏi: vì sao tuần trước agent trả dữ liệu này cho người kia?

Trace chỉ có input và output cho bạn biết chuyện gì đã xảy ra. Trace có thêm danh tính và quyền còn cho biết ai được phép làm việc đó. Khi thiết kế logging cho khách hàng, hãy viết sẵn câu hỏi của người làm audit rồi kiểm tra xem một trace có trả lời nổi không.

Ý thứ ba: quản trị không phải cổng kiểm duyệt trước ngày go-live

Khoá trình bày quản trị trên cả vòng đời, từ việc định nghĩa kiểm soát truy cập đến giám sát hành vi khi chạy. Cách nhìn này đáng giữ vì nó không để quản trị thành một bước duyệt cuối cùng; ngay tên Lab 3 cũng gộp đánh giá và deployment vào một bài thực hành.

Ở khách hàng, hãy gắn với mỗi giai đoạn một người chịu trách nhiệm và một bằng chứng: ai duyệt quyền trước khi chạy, ai xem hành vi sau khi chạy, và cả hai xem ở đâu. Một bảng như thế thường làm lộ ra những việc chưa có ai chịu trách nhiệm, và đó mới là rủi ro cần xử lý trước.

Bỏ gì, học thêm gì

Nếu đã vận hành agent thật, bạn có thể lướt các video khái niệm rồi chuyển sang Lab 3, nhưng trước hết hãy kiểm tra xem lab này có cần kết quả của các lab trước không.

Vì người dạy và đối tác đều là Databricks, hãy tách nguyên tắc khỏi sản phẩm: quyền theo người dùng và trace có thể audit là thứ bạn mang đi được, còn tên công cụ thì tuỳ stack của khách hàng.

Khoảng trống đáng lấp nằm ở phần sau khoá. Bài blog về Unity Catalog mô tả mỗi lời gọi của agent được đối chiếu với policy trước khi chạy và được ghi log sau đó.

Bài này còn nói đến việc đăng ký MCP server bên ngoài như GitHub, Jira hay Slack vào Unity Catalog và quản trị chúng như mọi securable khác, một chủ đề khoá dường như không đi vào.

Thứ tự hợp lý: học khoá trước, đọc bài blog Unity Catalog ngay sau đó, rồi đọc bài về MLflow trace. Sau đó, hãy tự làm lại trên một agent của bạn với một công cụ bên ngoài, vì có vẻ đây là chỗ khoá dừng lại, còn công việc thật mới bắt đầu.

Về nghề nghiệp, đừng biến khoá này thành một dòng trên CV. Dòng có giá trị là thứ bạn đã làm được, chẳng hạn một dự án cá nhân nơi agent chạy theo quyền người dùng và mỗi hành động truy ngược được qua trace.

Khi mô tả công việc FDE nhắc đến access control, audit hay observability, hãy hỏi lại trong buổi phỏng vấn: agent ở đó đã chạm dữ liệu thật chưa, và ai đang giữ quyền của nó?

Khoá dạy bạn đặt đúng câu hỏi trong 1,5 giờ. Lần tới khi khách hàng hỏi agent đã đọc gì và ai cho phép, bạn nên có sẵn một trace để mở ra thay vì một lời hứa.