Vượt qua suy nghĩ “AI là phép màu”: Vì sao hiểu cách các mô hình AI hoạt động phải là ưu tiên của toàn công ty

Giữa những cảnh báo về các tác tử AI hoạt động ngoài tầm kiểm soát, gần đây một nhà phát triển đã để một tác tử lập trình toàn quyền sử dụng một máy tính không có bản sao lưu từ xa. Tác tử này đã xóa 48.000 tệp trong chưa đầy hai phút.

Những sự cố như vậy là lời nhắc nhở rõ ràng rằng việc triển khai tác tử AI đi kèm rủi ro; chỉ thêm một người kiểm tra ở đâu đó trong một quy trình phức tạp rồi cho rằng hệ thống đã an toàn là chưa đủ. Một số quy trình không cần can thiệp, trong khi những quy trình khác đòi hỏi các bước kiểm tra chặt chẽ hơn nhiều. Rõ ràng, sửa một lỗi đánh máy và xóa hàng nghìn tệp không có cùng mức độ rủi ro, vì vậy việc giám sát cần tương xứng với những gì thực sự bị đe dọa.

Các tổ chức cần xác định tốt hơn những thời điểm mà phán đoán của con người thực sự quan trọng, đặc biệt khi hành động có tác động lớn hoặc khó đảo ngược. Và khi tác tử mắc lỗi, môi trường cần hạn chế phạm vi thiệt hại.

AI không mang tính tất định mà mang tính xác suất

Trước hết, mọi nhân viên tham gia trực tiếp hoặc gián tiếp vào quá trình phát triển phần mềm đều cần có kiến thức nền tảng về cách các mô hình AI xử lý thông tin. Đây không phải là nhiệm vụ nhỏ; việc này đòi hỏi cam kết đào tạo các nhóm, và về lâu dài cần trở thành mục tiêu của toàn công ty.

Khi mới bắt đầu tương tác với AI, người ta thường cảm thấy như đang chứng kiến phép màu. Bạn nhập một câu, và ngay sau đó đã có thể trò chuyện. Việc hiểu biết cơ bản về cách các mô hình và quá trình huấn luyện thực sự vận hành phía sau rất quan trọng để xây dựng chính sách AI trên toàn công ty về bảo mật và năng suất. Mạng nơ-ron, quá trình mã hóa token, các phân tích thống kê diễn ra phía sau, cũng như cách chúng tạo ra kết quả, sẽ là nội dung đào tạo thiết yếu cho tất cả nhân viên trong doanh nghiệp.

Các mô hình ngôn ngữ lớn sẽ không bao giờ tạo ra kết quả mang tính tất định. Kết quả đầu ra mang tính xác suất. Với phần mềm thông thường, khi bạn cung cấp dữ liệu đầu vào, bạn có thể dự đoán phần nào kết quả sẽ là A, B hoặc C. Nhưng với AI, kết quả có thể là F, một ký tự & hoặc mô tả về một con mèo đeo kính râm.

Khi một thứ mang tính xác suất, bạn không thể kiểm thử nó theo cách thông thường. Điều bạn cần là một phương pháp kiểm thử có khả năng điều chỉnh, suy luận, thấu hiểu và nhanh chóng truy xuất ngữ cảnh để phát hiện các yếu tố xác suất cũng như nhận diện những vấn đề mà chúng có thể gây ra. Tùy thuộc vào quy mô và mức độ rủi ro, việc kiểm thử này có thể do AI hoặc một người có chuyên môn phù hợp thực hiện. Đưa con người tham gia vào quy trình sẽ hữu ích nhất ngay từ đầu, để xác định rõ vấn đề cần giải quyết, rồi đánh giá lại ở cuối quy trình.

Vì các nhà phát triển là những người có điều kiện quan sát gần nhất các biến số và thông lệ phổ biến trong cách AI nội bộ của tổ chức đưa ra câu trả lời từ dữ liệu đầu vào, họ có thể đóng vai trò quan trọng trong việc định hình chương trình đào tạo về AI tại công ty và bảo đảm mọi người hiểu được sự khác biệt giữa tính tất định và tính xác suất trong AI, cũng như lý do sự khác biệt đó quan trọng. Mục tiêu là giảm suy nghĩ cho rằng dùng AI chẳng khác nào chứng kiến phép màu và có thể hài lòng với bất kỳ kết quả nào nhận được. Thay vào đó, các tổ chức nên nỗ lực làm sáng tỏ và trình bày các mô hình mà doanh nghiệp đang sử dụng, cách sử dụng chúng, những vấn đề có thể phát sinh, cách kiểm tra chúng và kết quả của quy trình đó.

Các rào chắn an toàn cần nằm trong hạ tầng, không phải trong mô hình

Sau khi làm sáng tỏ “phép màu” của AI và bắt đầu triển khai một dự án do AI dẫn dắt, điều thiết yếu là phải có chính sách kiểm toán minh bạch để bảo đảm mọi việc diễn ra đúng lộ trình dự kiến. Nhờ vậy, nếu dự án tạo ra kết quả “tệ” hoặc không đạt yêu cầu, người chịu trách nhiệm có thể kiểm tra các bước đã thực hiện và ngăn sự cố tái diễn. Chính sách này cũng có ích khi kết quả tốt hơn kỳ vọng, bởi khi đó các bước đã thực hiện có thể được lặp lại và chia sẻ với những dự án hoặc nhóm khác.

Việc hệ thống hóa quy trình này đặc biệt quan trọng với các công ty lớn, nơi mỗi nhóm có thể có hàng chục nhà phát triển, còn hàng trăm nhà phát triển cùng tác động đến mã nguồn trong suốt ngày làm việc. AI có thể thực hiện nhiều việc rất nhanh, và nếu có sự cố, cần có một hệ thống để xác định chính xác vấn đề xảy ra ở bước nào. Hãy xem các tác tử của OpenAI xâm nhập Hugging Face vào mùa hè này. OpenAI đang kiểm tra khả năng khai thác lỗ hổng phần mềm của các mô hình bằng một bộ tiêu chuẩn có tên ExploitGym. Để phục vụ cuộc kiểm tra, họ cố ý nới lỏng các cơ chế từ chối của mô hình đối với những tác vụ an ninh mạng mang tính tấn công. Lối thoát duy nhất khỏi môi trường hộp cát là thông qua một máy chủ proxy gói phần mềm. Các mô hình phát hiện ra một lỗ hổng chưa từng được biết đến trong máy chủ proxy đó, thoát ra ngoài và dành hơn hai ngày bên trong các hệ thống sản xuất của Hugging Face để tìm kiếm đáp án kiểm tra.

Các tiêu đề gọi đó là AI hoạt động ngoài tầm kiểm soát. Tôi cho rằng đây là một thiết lập mang tính tất định xoay quanh một hệ thống mang tính xác suất. OpenAI yêu cầu các mô hình tấn công hệ thống, rồi lại trông chờ chúng đi đúng lộ trình dự kiến. Người tạo ra bộ tiêu chuẩn cho biết trước đó các mô hình từng gian lận trong bài kiểm tra, nhưng luôn ở bên trong môi trường hộp cát. Lần này, một mô hình đã không ở lại trong đó. Các rào chắn an toàn thông thường giả định rằng hành vi sẽ tuân theo thông lệ, nhưng AI không nhất thiết phải làm vậy.

Đó là lý do an ninh AI phụ thuộc vào quyền truy cập và các biện pháp kiểm soát được thực thi bởi môi trường, chứ không phải vào việc mô hình cư xử đúng mực. Hãy giả định rằng tác tử sẽ thử mở mọi cánh cửa, và chỉ để ngỏ những cửa mà nó cần. Tác tử đã xóa 48.000 tệp dù được dặn chỉ làm việc trên các bản sao và không đụng đến bản gốc. Dù vậy, nó vẫn xóa các tệp gốc. Chỉ dẫn không phải là biện pháp kiểm soát.

Quản lý quyền của tác tử cũng giống như tiếp nhận một lập trình viên cấp dưới mới. Bạn sẽ không cấp cho họ quyền root trên môi trường production ngay ngày đầu tiên. Nếu bạn làm vậy và họ xóa cơ sở dữ liệu, bạn sẽ không cho rằng đó là vì họ là một hacker thiên tài. Trong các sự cố an ninh ở bất kỳ mức độ nào, điều tối quan trọng là xác định chính xác nguyên nhân gốc rễ. Đó là do mô hình? Do công ty tạo ra mô hình? Hay do công ty cấp quyền truy cập cho mô hình? Dù nguyên nhân là gì, cuối cùng vẫn có một con người chịu trách nhiệm.

Cuối cùng, một vấn đề then chốt cần giải quyết ngay lúc này là những gì diễn ra âm thầm trên máy tính xách tay của lập trình viên. Trước đây, quy trình làm việc dễ lần theo hơn. Lập trình viên viết mã, xem xét rồi đưa mã vào sử dụng, nên có thể truy ngược rõ ràng đến thời điểm xảy ra sự cố. Giờ đây, lập trình viên có thể đưa phiếu công việc cho một tác tử và bảo: “sửa cái này”. Nếu công việc đó diễn ra khuất tầm mắt, sẽ chẳng có gì để lần theo. Cần lưu lại đầy đủ mọi bước: tác tử nào đã chạy, nó sử dụng mô hình nào, được cung cấp những câu lệnh nào, đã gọi những công cụ nào và có những quyền gì vào thời điểm đó. Chạy các tác tử tập trung thay vì trên từng máy tính xách tay riêng lẻ là một cách để đạt được điều này. Điều quan trọng là phải có dấu vết đầy đủ.

Suy cho cùng, khi xảy ra sự cố, mọi công ty đều cần tự bảo vệ mình. Dấu vết đó cần lưu đủ thông tin để tiến hành phân tích nguyên nhân gốc rễ và xác định bước nào, cũng như đoạn mã nào, đã gây ra vấn đề.

AI đã làm thay đổi thế giới sâu sắc, và các quy trình kinh doanh cũng phải thay đổi theo. Để xác định các biện pháp bảo vệ phù hợp, cần hiểu rõ hơn về các quy trình AI, hoạt động kiểm thử, chu kỳ rà soát và chu kỳ kiểm toán, cả trong các nhóm phát triển lẫn trên toàn công ty.