Vin Sharma, Đồng sáng lập kiêm CEO của Vijil – Loạt bài phỏng vấn

Vin Sharma là Đồng sáng lập kiêm CEO của Vijil, với hơn 30 năm kinh nghiệm trong các lĩnh vực an ninh mạng, mã nguồn mở, điện toán đám mây và hạ tầng AI. Trước khi thành lập công ty, ông phụ trách công việc kỹ thuật học sâu tại AWS cho Amazon SageMaker và Amazon Bedrock, phát triển hạ tầng trung tâm dữ liệu tại Intel, đồng thời đảm nhiệm các vai trò về sản phẩm và kỹ thuật tại Hewlett-Packard. Sự nghiệp của ông bắt đầu với việc kiểm thử đội đỏ tự động cho các hệ thống UNIX đáng tin cậy; nền tảng đó định hình trọng tâm của ông trong việc giúp các tác tử AI dành cho doanh nghiệp hoạt động đáng tin cậy, bảo mật và an toàn.

Vijil cung cấp hạ tầng tạo dựng niềm tin cho các tác tử AI dành cho doanh nghiệp, giúp các tổ chức đánh giá hành vi, thực thi các biện pháp kiểm soát và tăng cường khả năng chống chịu trong suốt vòng đời của tác tử. Cách tiếp cận của công ty kết hợp kiểm thử, bảo mật và phản hồi liên tục để điều chỉnh hành vi của tác tử phù hợp với mục đích và chính sách mà tổ chức đề ra. Trong cuộc phỏng vấn này, Sharma trao đổi về cách xác định và đo lường niềm tin, lý do việc kiểm thử tác tử khác với bảo mật phần mềm thông thường, cũng như cơ chế giám sát mà doanh nghiệp cần khi các tác tử ngày càng có quyền tự chủ.

Ông đã làm việc hơn 30 năm tại các công ty như AWS, Intel và Hewlett-Packard trước khi thành lập Vijil. Điều gì cuối cùng đã thuyết phục ông rằng niềm tin và bảo mật AI là một vấn đề chưa được giải quyết đủ lớn để xây dựng hẳn một công ty nhằm giải quyết?

Trước khi gia nhập một công ty khởi nghiệp về bảo mật cách đây 30 năm, tôi đang học cao học về AI và học máy. Kể từ đó, tôi đã làm việc trong các nhóm sản phẩm xây dựng bảo mật cấp quân sự cho hệ điều hành dựa trên Unix và Linux, máy chủ web an toàn cho ngân hàng trực tuyến, môi trường thực thi tin cậy cho điện toán đám mây, tích hợp mã hóa vào các nền tảng phân tích dữ liệu, và gần đây nhất là quay trở lại điểm xuất phát với việc xây dựng các dịch vụ AI/ML sẵn sàng cho doanh nghiệp tại AWS. Hành trình ấy khiến tôi tin chắc rằng việc xây dựng niềm tin vào một hệ thống trí tuệ khó hơn việc tạo ra chính hệ thống thông minh đó. Trong khi ngành AI dường như nhìn chung đều tập trung nâng cao năng lực của các tác tử, tôi tin rằng chúng ta cần đầu tư nguồn lực tương đương vào việc xây dựng các cơ chế giám sát và kiểm soát có khả năng mở rộng ngay trong các tác tử. Nếu thiếu những chỉ số và cơ chế được thiết kế phù hợp với nhu cầu của từng tổ chức, làn sóng ứng dụng ban đầu đầy hứng khởi sẽ mắc cạn trên những bãi cạn của rủi ro và ROI, bởi doanh nghiệp sẽ không thể chứng minh rằng các tác tử đang hoạt động vì lợi ích tốt nhất của mình.

Vijil được xây dựng dựa trên nhận định rằng nhiều tác tử AI không bao giờ được đưa vào môi trường sản xuất vì doanh nghiệp không thể xác minh đầy đủ độ tin cậy, tính bảo mật và mức độ an toàn của chúng. Khi các công ty chuyển từ nguyên mẫu AI sang triển khai trong môi trường sản xuất, ông nhận thấy những khoảng trống lớn nhất về niềm tin đang xuất hiện ở đâu?

Trở ngại đối với việc triển khai ngày càng nhiều tác tử có mức độ tự chủ cao hơn là liệu các tổ chức có thể xác định hành vi mong muốn của tác tử và xác minh rằng chúng đang hành xử đúng như dự định hay không. Không chỉ vậy, họ còn phải thực hiện được điều đó ở quy mô và tốc độ mà các tác tử vận hành. Vì vậy, việc cần có một cách để các tác tử đo lường và điều chỉnh hành vi của những tác tử khác là điều hợp lý. Hai khoảng trống lớn nhất là xác định cần đo lường điều gì (thế nào là tốt đối với tác tử) và biết cần điều chỉnh điều gì (cần tinh chỉnh những thành phần nào của hệ thống tác tử để khơi gợi hành vi mà bên ủy quyền mong muốn: mô hình và các tham số của mô hình, lời nhắc hệ thống, chỉ dẫn của người dùng, khung điều phối tác tử hay đồ thị của các hệ thống đa tác tử).

Vijil định nghĩa và đo lường “niềm tin” vào một tác tử AI như thế nào, và những tín hiệu hay chuẩn đánh giá nào quan trọng nhất khi xác định một tác tử đã sẵn sàng hoạt động trong môi trường doanh nghiệp hay chưa?

Chúng tôi định nghĩa niềm tin là lợi ích kỳ vọng từ việc giao phó nhiệm vụ cho một tác tử tự chủ, sau khi đã tính đến rủi ro tác tử phản bội ý định của chúng ta. Điều này có nghĩa là có thể tin cậy một tác tử nếu nó hành xử đúng trong điều kiện bình thường, nhiễu loạn và đối kháng; khi gặp lỗi, nó sẽ giảm thiểu phạm vi tác động. Sau đó, chúng ta có thể đo lường niềm tin dựa trên ba trụ cột: độ tin cậy, tính bảo mật và mức độ an toàn. Tác tử đáng tin cậy khi hoạt động như mong đợi trong nhiều điều kiện khác nhau; bảo mật khi hoạt động như mong đợi trong điều kiện đối kháng; và an toàn khi có thể giảm thiểu rủi ro kinh doanh, pháp lý và kỹ thuật.

Các tác tử AI có thể hành xử khó lường vì kết hợp mô hình, công cụ, nguồn dữ liệu, bộ nhớ và hệ thống bên ngoài. Việc kiểm thử một tác tử khác với kiểm thử bảo mật ứng dụng truyền thống hay đánh giá mô hình thông thường như thế nào?

Phần mềm truyền thống gặp lỗi theo những cách hiện nay đã được hiểu rõ: nói một cách khái quát, đó là không xử lý được dữ liệu đầu vào sai định dạng, các điểm yếu trong logic và thiết kế hệ thống, lỗi triển khai, lỗ hổng tiềm ẩn trước các cuộc tấn công và những tác dụng phụ ngoài ý muốn của đầu ra. Việc kiểm thử các lỗi này có thể dự đoán tương đối chính xác. Tác tử mở rộng đáng kể phạm vi có thể xảy ra lỗi, đến mức các phương pháp đánh giá mô hình, kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử bảo mật ứng dụng, kiểm thử xâm nhập và kiểm tra tuân thủ đều không thể bao quát phạm vi đó. Để kiểm thử bề mặt rủi ro mới của tác tử, chúng ta cần các chỉ số và cơ chế mới nhằm đánh giá hành vi của tác tử dựa trên mục đích do bên ủy quyền xác định, chân dung người dùng và chính sách của tổ chức, ngành nghề và khu vực nơi tác tử hoạt động.

Ông từng dẫn dắt các nỗ lực kỹ thuật học sâu cho Amazon SageMaker và Amazon Bedrock. Những bài học nào từ quá trình xây dựng hạ tầng AI tại AWS ảnh hưởng nhiều nhất đến cách ông tiếp cận vấn đề bảo mật và độ tin cậy của tác tử tại Vijil?

Bài học định hình tư duy của tôi nhiều nhất là việc phát hiện sớm các vấn đề về độ tin cậy, bảo mật và tuân thủ của dịch vụ trong chu kỳ phát triển hiệu quả hơn rất nhiều so với việc chỉ phát hiện ngay trước ngày ra mắt như cách làm truyền thống; tệ hơn nữa là phát hiện sau khi dịch vụ đã đi vào hoạt động, đồng nghĩa với việc phải thức dậy vì những cuộc gọi báo dịch vụ gặp sự cố.

Vijil không chỉ tập trung kiểm thử tác tử trước khi triển khai mà còn bảo vệ và liên tục cải thiện chúng trong môi trường vận hành thực tế. Những loại rủi ro nào chỉ bộc lộ khi tác tử bắt đầu tương tác với người dùng, dữ liệu và hệ thống doanh nghiệp thực?

Thế giới thực luôn có vô vàn khả năng khiến chúng ta bất ngờ. Và một tác tử bị bất ngờ là một tác tử dễ mắc lỗi. Không ai bận tâm nếu một tác tử mắc lỗi khi tạo meme. Nhưng một tác tử được thiết kế để hỗ trợ hoặc thay thế cố vấn tài chính, trợ lý pháp lý, luật sư, điều dưỡng, bác sĩ, bệnh nhân hoặc bất kỳ chuyên gia nào trong một ngành đòi hỏi phải chứng minh hành vi ủy thác đều không thể hoạt động nếu không xác định rõ các ngưỡng chấp nhận sai sót, giám sát chúng cẩn thận và nhanh chóng đưa hành vi của tác tử trở lại trạng thái phù hợp.

Khi doanh nghiệp triển khai các tác tử ngày càng tự chủ, có khả năng thực hiện hành động thay vì chỉ tạo câu trả lời, mô hình bảo mật cần thay đổi như thế nào? Những khái niệm truyền thống như quyền hạn, danh tính và kiểm soát truy cập có còn đủ hay không?

Không. Khi trở thành những tác nhân trong tổ chức, các tác tử cần được cấp danh tính riêng có thể xác minh; cần được phân công vai trò để ràng buộc hành vi cũng như các thành phần chức năng của chúng (các công cụ có quyền truy cập tài nguyên), đồng thời áp dụng các chính sách kiểm soát truy cập bắt buộc; cần được giám sát liên tục để phát hiện sai lệch khỏi mục đích dự kiến và được định hướng để duy trì khả năng chống chịu trước các cuộc tấn công.

Vijil đã phát triển từ vòng gọi vốn Seed trị giá 6 triệu USD lên vòng Series A trị giá 17 triệu USD, đồng thời xây dựng đội ngũ sáng lập khoảng 20 người và đạt 1 triệu USD doanh thu định kỳ hằng năm đầu tiên. Những quyết định nào quan trọng nhất giúp ông chuyển từ một ý tưởng kỹ thuật ban đầu sang được thị trường đón nhận?

Ngay từ đầu, chúng tôi đã chọn xây dựng một lớp tin cậy tích hợp với nền tảng mà khách hàng lựa chọn, đồng thời dự đoán rằng các doanh nghiệp sẽ ngày càng muốn tùy chỉnh nhiều hơn, kiểm soát chi tiết hơn và giảm chi phí cho các hệ thống đa tác tử sử dụng mô hình mở. Chiến lược dài hạn xây dựng một lớp nền tảng thay vì một sản phẩm đơn lẻ mang lại cho chúng tôi lợi thế cạnh tranh, nhưng cũng tạo ra những thách thức: việc tìm được các doanh nghiệp sẵn sàng quản trị tác tử trên quy mô lớn không dễ như bán một dịch vụ chuyển đổi nguyên trạng.

Ông bắt đầu sự nghiệp vào năm 1995 với việc phát triển các bài kiểm thử đội đỏ tự động cho những hệ thống UNIX đáng tin cậy. Gần ba thập kỷ sau, các nguyên tắc kiểm thử đội đỏ đã thay đổi ra sao khi hệ thống được kiểm thử là một tác tử AI có khả năng suy luận, thích nghi và sử dụng công cụ bên ngoài?

Trước đây, kiểm thử đội đỏ có nghĩa là kiểm tra khả năng phòng thủ của một tổ chức trước một cuộc tấn công phối hợp. Các nguyên tắc chung vẫn còn nguyên giá trị. Chúng ta vẫn cần phối hợp các cuộc tấn công trong những điều kiện được kiểm soát để dò tìm điểm yếu của tổ chức đang được kiểm thử. Tuy nhiên, giai đoạn lịch sử mà các bài tập đội đỏ được soạn sẵn kịch bản để kiểm thử hệ thống phần mềm nay không còn phù hợp, bởi tác tử AI không giống phần mềm có tính quyết định—chúng được thiết kế để thích nghi với môi trường, nên không thể phát lại cùng một cuộc tấn công theo cách có thể dự đoán trước. Tôi cho rằng nên xem tác tử như các tập đoàn. Vì vậy, kiểm thử đội đỏ đối với tác tử nhất thiết phải thích ứng với mục đích của tác tử, dò tìm những sai lệch so với ý định của người dùng, cũng như đánh giá mức độ sẵn lòng và khả năng né tránh các chính sách trong môi trường hoạt động của nó.

Trong thời gian tới, ông có cho rằng kiểm thử độc lập và các tiêu chuẩn đo lường được về độ tin cậy của tác tử AI sẽ trở thành điều kiện tiên quyết để triển khai trong doanh nghiệp không? Ngành cần làm gì để mức độ bảo đảm đó trở thành thông lệ?

Hiện nay, các nhà phát triển đánh giá năng lực của tác tử, các đội đỏ kiểm tra khả năng chống lại tấn công chèn lời nhắc và bẻ khóa, còn các nhóm GRC mới bắt đầu kiểm tra mức độ tuân thủ quy định. Rất ít tổ chức thiết lập cơ chế xác minh hành vi chạy liên tục ở chế độ nền trong suốt vòng đời của tác tử, ngay cả khi mô hình, công cụ, tài nguyên, quy trình làm việc và môi trường mục tiêu thay đổi. Quan trọng hơn nữa, điểm khác biệt trong cách Vijil hỗ trợ doanh nghiệp là truy vết hành vi thực tế của tác tử trong môi trường vận hành trở lại đặc tả của nó, thông qua một vòng phản hồi liên tục cải thiện tác tử. Những tác tử trụ vững trước các cuộc tấn công là những tác tử biết thích nghi để duy trì khả năng chống chịu.

Cảm ơn ông đã dành thời gian cho buổi phỏng vấn tuyệt vời này. Độc giả muốn tìm hiểu thêm về cách kiểm thử, bảo vệ và liên tục cải thiện các tác tử AI dành cho doanh nghiệp có thể truy cập Vijil.