Connect with us

Sự Thay Đổi Kiến Trúc Cần Thiết Để Quản Lý Các Đại Lý AI

Lãnh đạo tư tưởng

Sự Thay Đổi Kiến Trúc Cần Thiết Để Quản Lý Các Đại Lý AI

mm
A photorealistic widescreen image of a technician viewed from behind, seated at a dark command center with multiple monitors. A large glass wall in front of him displays a complex, glowing architectural blueprint made of blue and green light. The hologram features intricate pathways, interconnected nodes, and two small silhouettes of figures standing together, representing a human and an AI

AI không còn chỉ là một rô-bốt trò chuyện tạo ra văn bản. Trong môi trường doanh nghiệp, các đại lý AI đang thực hiện các hành động như thu thập dữ liệu nhạy cảm, kích hoạt các quy trình làm việc, gọi các công cụ và ghi nhật ký hoạt động trên các hệ thống. Tự chủ thay đổi hoàn toàn cuộc thảo luận về quản lý; các kiểm soát và thủ tục ban đầu được thiết kế cho người dùng và ứng dụng truyền thống không được xây dựng để quản lý phần mềm có thể thực hiện các hành động đa bước tại thời gian chạy.

Rủi ro không phải là lý thuyết. Các khoảng trống nhỏ trong khả năng hiển thị, kiểm soát truy cập và khả năng kiểm toán có thể tăng lên nhanh chóng, biến thành sự cố thời gian chạy khó phát hiện và thậm chí khó hơn để đảo ngược.

Để theo kịp thời đại mới này, việc quản lý các đại lý AI không thể được thực hiện bằng cách thêm nhiều tài liệu chính sách. Nó yêu cầu quản lý bằng thiết kế: một cách tiếp cận kiến trúc trong đó các kiểm soát được nhúng vào mặt phẳng kiểm soát và được thực thi liên tục tại thời gian chạy. Nếu các đại lý sẽ hành động như các đồng nghiệp kỹ thuật số, họ phải kế thừa các rào cản doanh nghiệp giống như con người, cộng với sự giám sát thời gian chạy mạnh mẽ hơn.

Tại sao quản lý bị hỏng trong kỷ nguyên hội tụ

Kiến trúc doanh nghiệp đã bước vào kỷ nguyên hội tụ. Dữ liệu và khối lượng công việc hiện đang trải rộng trên nhiều đám mây, trung tâm dữ liệu riêng và môi trường biên.

Có các tổ chức chạy nền tảng của họ trong các hệ thống song song vì họ có nhiều quy trình để quản lý đồng thời. Điều này bao gồm các hệ thống danh tính riêng biệt, đường ống ghi nhật ký, danh mục và quy trình được phê duyệt. Kết quả là những gì một số người gọi là “nền tảng Frankenstein”, nơi chi phí tích hợp tăng lên với mỗi công cụ hoặc môi trường đám mây mới. Trên thực tế, sự phân mảnh này đang xuất hiện trong thực tế hàng ngày.

Theo một khảo sát gần đây, 47% người được hỏi cho biết các yêu cầu truy cập và quy trình phức tạp, và 44% cho biết khả năng hiển thị hạn chế vào nơi dữ liệu cư trú là những rào cản đối với việc sử dụng dữ liệu hiệu quả.

Đây chính là nơi các đại lý lộ ra các mối nối giữa các hệ thống.

Để trả lời một câu hỏi kinh doanh, một đại lý có thể phải kéo dữ liệu từ một hệ thống ERP trên cơ sở, một hệ thống CRM trên đám mây, dữ liệu hoạt động trên đám mây khác và tài liệu trong một bộ phận hợp tác. Nếu tổ chức thực thi chính sách khác nhau ở mỗi nơi, đại lý sẽ либо thất bại hoặc, tệ hơn, thành công theo những cách bạn không thể giải thích hoặc kiểm soát.

Đây là lúc các nhà lãnh đạo doanh nghiệp phải chú ý. Các đại lý đang buộc một tiêu chuẩn cao hơn đòi hỏi sự nhất quán trên các môi trường và trách nhiệm giải trình tại thời gian chạy.

Quản lý, vì lý do này, đang được kéo vào trọng tâm bởi các cơ quan quản lý và an ninh. Một ví dụ về điều này là Khung quản lý rủi ro AI của NIST, nhấn mạnh quản lý rủi ro trên toàn bộ vòng đời AI, không chỉ tại thời điểm xây dựng. Đây là một lời nhắc nhở rằng tuân thủ và niềm tin là trách nhiệm vận hành, không phải là danh sách kiểm tra một lần.

Từ chính sách đến nền tảng

Quản lý bằng thiết kế có nghĩa là quản lý đi cùng với khối lượng công việc chứ không phải được thực hiện lại trong mỗi silo. Trong thực tế, điều này phụ thuộc vào ba khối xây dựng:

  • Mặt phẳng kiểm soát thống nhất

Một nơi để định nghĩa và thực thi danh tính, truy cập, chính sách, danh mục và quyền được hưởng trên các đám mây và trung tâm dữ liệu.

Mục tiêu là viết chính sách một lần và thực thi chúng ở bất kỳ nơi nào dữ liệu và mô hình chạy, chứ không phải xây dựng lại các hệ thống kiểm soát hệ thống theo hệ thống. Điều này ngăn chặn sự trôi dạt hành vi của đại lý, nơi cùng một đại lý hành động an toàn trong một môi trường nhưng nguy hiểm trong môi trường khác.

Một thử nghiệm thực tế là đơn giản: nếu một người dùng không thể truy cập một cột, hãy xác minh rằng một đại lý hành động thay mặt cho họ cũng không thể truy cập nó. Điều này nên chỉ ra liệu các chính sách viết có được thực thi trên toàn bộ mặt phẳng hay không.

  • Vải dữ liệu dựa trên các tiêu chuẩn mở

Các đại lý cần ngữ cảnh để hoạt động. Khi ngữ cảnh đó được phân散 trên các cấu trúc thuộc sở hữu của các đội khác nhau, vải dữ liệu giúp tiêu chuẩn hóa các từ vựng và mẫu truy cập, vì vậy các đại lý không cần phải học một tập hợp các quy tắc mới cho mỗi tập dữ liệu.

Các định dạng bảng mở như Apache Iceberg hỗ trợ điều này bằng cách cho phép nhiều động cơ chia sẻ cùng một dữ liệu được quản lý mà không cần sao chép nó vào một silo mới. Điều này rất quan trọng vì sự sao chép dữ liệu là nơi quản lý thường thất bại. Một khi các đội bắt đầu sao chép “chỉ những gì đại lý cần”, bạn đã tạo ra một môi trường mới, ít được quản lý hơn.

Nếu các đại lý có thể hoạt động trên các tập dữ liệu mà không giới thiệu các khoảng trống quyền mới, quản lý đang hoạt động như dự định.

  • Quan sát thời gian thực và nguồn gốc

Các đại lý chỉ có thể được quản lý nếu bạn có thể xem những gì họ đang làm tại thời gian chạy.

Khả năng quan sát ở đây không chỉ là “tốt để có”, mà là nền tảng cho các kiểm soát thời gian chạy và phản hồi sự cố.

Cụ thể, cần phải có bằng chứng cuối cùng về các hành động của đại lý. Các đại lý nên có thể chứng minh các hành động, chẳng hạn như dữ liệu nào được truy cập và công cụ nào được gọi, và từ đó, nguồn gốc có thể kết nối các đầu ra trở lại các đầu vào. Điều này cho phép các đội kiểm toán các quyết định và giải quyết các sự cố, nếu cần, do đó chứng minh sự tuân thủ chung.

Xử lý các đại lý như “đồng nghiệp kỹ thuật số”

Một trong những mô hình tinh thần hữu ích nhất là xử lý các đại lý như các đồng nghiệp kỹ thuật số.

Đây là một so sánh phân tích điều này: giống như nhân viên có thẻ truy cập cho phép họ vào một số tòa nhà và phòng, nhưng không phải tất cả, quản lý cho phép các đại lý có quyền truy cập với các hạn chế. Một bổ sung quan trọng là các đại lý phải nhận thức được tình huống về những gì họ được phép tiết lộ.

Hãy xem xét một đại lý hỗ trợ. Nó có thể cần truy cập các trường hợp hỗ trợ trước để giải quyết một vấn đề, nhưng nó không thể tiết lộ chi tiết riêng tư của khách hàng khác trong khi làm như vậy. Nói cách khác, đại lý có thể sử dụng kiến thức hạn chế để lý luận, nhưng vẫn cần thực thi các ranh giới tiết lộ. Điều này không phải là một “vấn đề viết lời nhắc” mà chúng tôi đã biết cách điều hướng trước đây; thay vào đó, nó là một vấn đề về danh tính và thực thi thời gian chạy.

Điều gì thay đổi vào năm 2026: các đại lý di chuyển từ thí nghiệm sang sản xuất

Năm 2026 là năm khi các thí nghiệm kết thúc và các đại lý chiếm vị trí sản xuất.

Sự thay đổi này buộc các doanh nghiệp phải hoạt động ở hai tốc độ. Một là tốc độ đổi mới, nơi các đội kiểm tra các mô hình, công cụ và quy trình làm việc của đại lý mới để có được lợi thế cạnh tranh. Và cái còn lại là tốc độ an toàn, nơi các hệ thống phải đáp ứng các yêu cầu về tuân thủ và vận hành, có thể bao gồm các kiểm soát truy cập nghiêm ngặt và điểm mù.

Nếu không có quản lý kiến trúc được thiết lập, hai tốc độ này sẽ xung đột.

Nếu các đội triển khai các đại lý này trước khi chúng được quản lý, sẽ có một bản vá các kiểm soát một lần và các sự cố vận hành. Và nếu điều ngược lại xảy ra, bạn sẽ có một chế độ thất bại trong đó bảo mật chặn mọi thứ, và đổi mới di chuyển sang IT bóng tối, làm suy yếu quản lý.

Mục tiêu không phải là chọn một tốc độ. Đó là xây dựng một kiến trúc hỗ trợ cả hai.

Danh sách kiểm tra thực tế để quản lý các đại lý tại thời gian chạy

  • Nếu bạn đang xây dựng hoặc mở rộng các đại lý, điều quan trọng là phải tự hỏi mình các câu hỏi sau để tiết lộ liệu quản lý có thực sự là kiến trúc hay không: Bạn có thể giải thích, từ đầu đến cuối, dữ liệu nào một đại lý đã truy cập để tạo ra một câu trả lời hoặc thực hiện một hành động?
  • Các quyết định truy cập có nhất quán trên các môi trường hybrid hay không, hay chúng khác nhau theo từng nền tảng?
  • Bạn có telemetry cho các hành động của đại lý, bao gồm cả cuộc gọi công cụ, kiểm tra chính sách và nâng cấp cho con người?
  • Bạn có thể giảm tốc, tạm dừng hoặc cách ly một đại lý tại thời gian chạy nếu nó hành động không mong muốn?
  • Bạn có kế hoạch giám sát sau triển khai phù hợp với các nghĩa vụ quản lý và khẩu vị rủi ro của bạn?

Nếu bạn không thể trả lời những điều này, hãy xử lý việc triển khai đại lý của bạn như một sự cố sản xuất đang chờ xảy ra.

Sự thay đổi quản lý cần phải là kiến trúc, hoặc nó không tồn tại

Các đại lý sẽ trở thành một phần bổ sung tiêu chuẩn cho các hoạt động doanh nghiệp. Câu hỏi là liệu họ sẽ trở thành một phần đáng tin cậy của các hoạt động doanh nghiệp.

Nếu các đại lý không được quản lý ít nhất cũng tự tin như con người và phần mềm quan trọng của nhiệm vụ, các hậu quả sẽ là thực sự. Chúng tôi sẽ thấy những hậu quả đó trong rò rỉ dữ liệu, thất bại tuân thủ, ngừng hoạt động vận hành và mất niềm tin vào các chương trình AI.

Các nhà lãnh đạo cần ngừng xử lý quản lý đại lý như một bài tập ghi chép. Khi các khả năng của nền tảng mở rộng, quản lý đại lý nên là một trong những người đó thực hiện giám sát các vai trò khác. Điều này có nghĩa là nhúng các kiểm soát vào mặt phẳng kiểm soát, làm cho các hành động có thể quan sát được và các quyết định có thể kiểm toán. Và sau đó mở rộng.

Đó là cách bạn nhận được các đại lý di chuyển nhanh mà không phá vỡ doanh nghiệp.

Sergio Gago là CTO của Cloudera, mang lại hơn 20 năm kinh nghiệm trong lĩnh vực AI/ML, tính toán lượng tử và kiến trúc dựa trên dữ liệu. Trước đây là Giám đốc Điều hành của AI/ML & Quantum tại Moody’s Analytics, ông cũng từng giữ vị trí CTO tại Rakuten, Qapacity và Zinio. Sergio là một người ủng hộ mạnh mẽ cho cơ sở hạ tầng dữ liệu đáng tin cậy, tin rằng AI sẽ phát triển thành hệ điều hành của doanh nghiệp vào năm 2030.