Sapan Pandya, Kỹ sư phần mềm cấp cao và Hội viên cao cấp IEEE – Loạt bài phỏng vấn

Sapan Pandya là Kỹ sư phần mềm cấp cao và Hội viên cao cấp IEEE, hiện sinh sống tại New Jersey, với hơn 10 năm kinh nghiệm về các hệ thống giao dịch phân tán có khả năng chống chịu. Công việc của ông bao quát tính toàn vẹn giao dịch, tích hợp phần mềm với thiết bị vật lý, xử lý sự cố trong môi trường vận hành thực tế và xác thực triển khai trong các môi trường chịu sự quản lý. Ông có bằng thạc sĩ Khoa học máy tính của Stevens Institute of Technology, đồng thời tham gia phản biện học thuật và nghiên cứu kỹ thuật.

Nghiên cứu của Pandya tìm hiểu về an ninh mạng cho kiosk, AI biên và kỹ thuật độ tin cậy có AI hỗ trợ; kinh nghiệm vận hành thực tế cũng định hình trọng tâm của ông về bằng chứng, kết quả giao dịch và trách nhiệm trong hoạt động. Trong cuộc phỏng vấn này, ông trao đổi về tính lũy đẳng, các bản ghi giao dịch mâu thuẫn, sự bất định trong hệ thống khôi phục và những biện pháp kiểm soát cần có trước khi các tác nhân AI có thể hoạt động trên hạ tầng trọng yếu. Ông phân biệt kinh nghiệm kỹ thuật thực tiễn với nghiên cứu được thực hiện thông qua phân tích tài liệu và thử nghiệm có kiểm soát hoặc thử nghiệm tổng hợp.

Sự nghiệp của ông tập trung vào độ tin cậy của phần mềm và các hệ thống giao dịch phân tán. Kinh nghiệm đó đã định hình cách ông hiểu về độ tin cậy như thế nào, và những thách thức nào đã ảnh hưởng đến quan điểm của ông về việc sử dụng AI để quản lý các hệ thống phức tạp?

Quan điểm của tôi đã chuyển từ việc đặt câu hỏi một thành phần có hoạt động hay không sang việc xác định giao dịch của khách hàng đã hoàn tất và có thể được đối soát hay chưa.

Ở giai đoạn đầu sự nghiệp, phần lớn sự chú ý của tôi tập trung vào cách ứng dụng vận hành: xác thực dữ liệu đầu vào, xử lý phản hồi và bảo đảm giao diện tuân theo quy trình dự kiến. Khi trách nhiệm mở rộng sang tích hợp hệ thống, xử lý sự cố trong môi trường vận hành thực tế và xác thực triển khai, tôi phải nhìn xa hơn từng thành phần riêng lẻ.

Một dịch vụ có thể hoàn tất công việc trong khi dịch vụ khác vẫn đang chờ xác nhận. Phần mềm có thể ghi nhận một thao tác thành công, nhưng thiết bị vật lý lại không thực hiện được kết quả như mong đợi. Việc từng thành phần vượt qua kiểm thử, tự nó, không chứng minh rằng toàn bộ quá trình tương tác sẽ vận hành chính xác.

Trải nghiệm đó khiến tôi đặc biệt quan tâm đến ranh giới giữa các hệ thống. Mỗi thành phần biết những gì? Nó đang giả định điều gì? Điều gì xảy ra khi những giả định đó không còn đúng?

Trải nghiệm ấy cũng định hình cách tôi nhìn nhận AI. AI có thể giúp các kỹ sư tập hợp bằng chứng, nhận ra quy luật và điều tra sự cố nhanh hơn, qua đó mang lại giá trị thực sự. Nhưng lời giải thích về điều có lẽ đã xảy ra không giống với bản ghi đã được xác minh về điều thực sự xảy ra.

Tôi muốn AI giảm công sức điều tra sự cố mà không hạ thấp tiêu chuẩn bằng chứng cần thiết để xử lý sự cố đó.

Ông từng nhấn mạnh rằng mã nguồn đúng về mặt kỹ thuật không phải lúc nào cũng bảo đảm kết quả giao dịch chính xác. Ông có thể nêu một ví dụ cụ thể về trường hợp giao dịch có vẻ thất bại do hết thời gian chờ nhưng thực tế đã hoàn tất không? Điều gì có thể xảy ra khi hệ thống tự động thử lại thao tác, và các kỹ sư nên ngăn giao dịch bị tính trùng như thế nào?

Hãy xem xét một khoản thanh toán giả định trị giá 50 USD. Ứng dụng gửi yêu cầu, dịch vụ thanh toán ghi nhận giao dịch thành công, nhưng phản hồi bị thất lạc trước khi đến được ứng dụng.

Khách hàng thấy thông báo hết thời gian chờ, dù khoản thanh toán đã được thực hiện. Nếu ứng dụng gửi một yêu cầu thanh toán mới, khách hàng có thể bị tính tiền lần nữa.

Thông báo hết thời gian chờ cho biết phản hồi đã không đến kịp lúc. Nó không cho biết giao dịch thực tế có thành công hay không.

Một biện pháp bảo vệ phổ biến là tính lũy đẳng: cho phép lặp lại cùng một yêu cầu logic mà không tạo thêm tác động tài chính. Ứng dụng giữ nguyên mã định danh thao tác qua các lần thử lại, còn dịch vụ nhận diện yêu cầu đó là yêu cầu ban đầu chứ không phải một giao dịch mua mới.

Điều quan trọng không chỉ là gắn mã định danh vào yêu cầu. Dịch vụ phải thực thi quy tắc định danh đó và lưu đủ thông tin để phân biệt thao tác đã hoàn tất với thao tác vẫn đang được xử lý. Mã định danh không thể bảo vệ một hành động ở hệ thống phía sau nếu hành động đó bỏ qua mã này.

Khi kết quả vẫn chưa rõ, quy trình khôi phục nên kiểm tra giao dịch hiện có và đối soát các bản ghi liên quan, thay vì lập tức tạo một giao dịch thay thế.

Tôi cũng sẽ giới hạn số lần thử lại và xác định cách xử lý khi cơ chế khôi phục tự động không thể xác định kết quả. Khách hàng cần thấy trạng thái chờ xử lý rõ ràng và có cách giải quyết vấn đề, chứ không phải bị tính tiền nhiều lần hoặc phải nhìn màn hình xử lý mãi không kết thúc.

Trong các hệ thống phân tán, cơ sở dữ liệu, dịch vụ phụ trợ và kiosk vật lý có thể báo cáo thông tin mâu thuẫn về cùng một giao dịch. Ông đã từng gặp dạng bất nhất này trong môi trường vận hành thực tế chưa, và sự việc được điều tra, giải quyết như thế nào? AI có thể đóng vai trò gì, nếu có, trong việc đối soát những bản ghi mâu thuẫn này?

Đúng vậy, điều tra sự bất nhất về trạng thái giao dịch là một phần trong công việc vận hành thực tế của tôi. Để giải thích cách suy luận mà không bàn về một sự cố tại nơi làm việc, tôi sẽ dùng một ví dụ giả định.

Hãy xem xét một quầy thanh toán tự phục vụ thông thường. Dịch vụ thanh toán ghi nhận giao dịch mua hàng thành công, máy in báo đã nhận lệnh in hóa đơn, rồi màn hình hiển thị lỗi. Những thông tin này có thể phản ánh các giai đoạn khác nhau của quá trình giao dịch, chứ không chứng minh rằng toàn bộ giao dịch mua hàng đã thất bại.

Trước tiên, tôi sẽ dựng lại trình tự sự việc dựa trên mã giao dịch và các bản ghi liên quan của dịch vụ và thiết bị. Sau đó, tôi sẽ xác định từng thông tin chứng minh được điều gì. Việc máy in nhận lệnh không nhất thiết chứng minh rằng hóa đơn đã được in ra và giao cho khách hàng. Việc một yêu cầu được tiếp nhận cũng không nhất thiết chứng minh rằng tác động tài chính của yêu cầu đó đã được ghi nhận.

Cách xử lý phụ thuộc vào giai đoạn xảy ra lỗi. Lặp lại toàn bộ giao dịch có thể không phù hợp nếu chỉ cần xử lý khâu in. Nếu bằng chứng hiện có chưa xác định được chuyện gì đã xảy ra, cần giữ hoạt động bị ảnh hưởng trong tầm kiểm soát trong khi chờ điều tra.

Việc khắc phục lâu dài cũng cần giải quyết nguyên nhân khiến sự không nhất quán có thể xảy ra, thay vì chỉ sửa một bản ghi.

AI có thể hỗ trợ đối chiếu các sự kiện và xác định thông tin còn thiếu. Tôi sẽ yêu cầu AI đưa ra những cách giải thích khác nhau cùng bằng chứng ủng hộ từng cách. AI nên giúp thu hẹp phạm vi điều tra, chứ không nên giải quyết các bản ghi mâu thuẫn bằng cách chọn lời giải thích nghe có vẻ thuyết phục nhất.

Khi các tác nhân AI chuyển từ chẩn đoán sự cố trong môi trường sản xuất sang đề xuất hoặc thực hiện hành động khôi phục, cần có những biện pháp bảo vệ nào trước khi một hệ thống AI được phép thử lại, đảo ngược hoặc sửa đổi giao dịch? Các biện pháp kiểm soát tất định như khóa chống xử lý lặp, nhật ký giao dịch và cơ chế đối soát có thể ngăn AI gây thêm lỗi như thế nào?

Tôi sẽ tách biệt việc đề xuất hành động với việc phê duyệt và thực hiện hành động đó.

Một tác nhân AI có thể đề xuất thử lại, nhưng cần có một cơ chế kiểm soát riêng để xác định liệu có được phép thử lại hay không. Cơ chế này cần kiểm tra trạng thái hiện tại của giao dịch, danh tính của thao tác, quyền hạn của tác nhân và các điều kiện để hành động đó an toàn.

Việc kiểm tra phải được thực hiện tại thời điểm hành động diễn ra, chứ không chỉ khi mô hình vừa xem xét sự cố. Trong lúc đó, một quy trình khác có thể đã hoàn tất giao dịch.

Các công cụ mà tác nhân có thể sử dụng cũng cần được giới hạn chặt chẽ. Quyền tra cứu trạng thái giao dịch khác với quyền hoàn tiền hoặc sửa đổi hồ sơ tài chính. Tác nhân không được phép tự mở rộng thẩm quyền chỉ vì giải pháp mà nó ưu tiên đòi hỏi quyền truy cập rộng hơn.

Cơ chế chống xử lý lặp hạn chế các tác động trùng lặp. Nhật ký lưu giữ lịch sử cần thiết để điều tra. Đối soát kiểm tra mức độ thống nhất giữa các bản ghi liên quan. Không biện pháp nào trong số này, khi đứng riêng, có thể xác định liệu hành động được đề xuất có phù hợp hay không.

Tôi cũng sẽ ghi lại bằng chứng đã sử dụng, đề xuất, quyết định phê duyệt và kết quả thực tế. Nhờ vậy, có thể xem xét lại biện pháp can thiệp sau đó.

Các biện pháp kiểm soát này cần được thực thi bằng phần mềm có thể kiểm thử, nằm ngoài mô hình. Hướng dẫn yêu cầu tác nhân thận trọng là điều hữu ích, nhưng không thể thay thế cơ chế phê duyệt.

Hãy xem xét tình huống một hệ thống giám sát AI phát hiện dấu hiệu giao dịch thất bại và đề xuất tự động đảo ngược giao dịch. Nếu giao dịch thực tế đã thành công nhưng thông báo xác nhận bị trễ, biện pháp can thiệp đó có thể gây ra vấn đề mới. Các nhóm kỹ thuật nên thiết kế hệ thống khôi phục do AI điều khiển như thế nào để nhận biết sự không chắc chắn và tránh thực hiện hành động khắc phục dựa trên thông tin chưa đầy đủ?

Hệ thống cần có trạng thái thực sự là “chưa rõ kết quả”. Nếu không, hệ thống có thể biến việc thiếu thông tin thành một kết luận sai rằng giao dịch đã thất bại.

Thông báo xác nhận bị trễ là lý do để điều tra, chứ không phải lý do để tự động đảo ngược giao dịch. Đảo ngược cũng là một thao tác tài chính khác, kéo theo những hệ quả riêng. Thao tác này cần có căn cứ được xác lập độc lập và được phê duyệt phù hợp.

Tôi sẽ chia cách ứng phó thành hai hướng. Hướng điều tra có thể tra cứu trạng thái, thu thập các sự kiện còn thiếu, đối chiếu bản ghi và thông báo cho nhóm chịu trách nhiệm. Hướng thực hiện hành động tài chính vẫn phải bị chặn cho đến khi đáp ứng đủ các điều kiện.

Cách này ngăn điểm tin cậy của AI thay thế cho bằng chứng về giao dịch. Mô hình có thể rất tự tin vào một lời giải thích được xây dựng từ thông tin chưa đầy đủ.

Cũng cần xác định rõ thời điểm phải chuyển cấp xử lý. Để giao dịch ở trạng thái chờ vô thời hạn không phải là kết quả thỏa đáng đối với khách hàng. Cần có người chịu trách nhiệm xử lý vụ việc chưa được giải quyết và được cung cấp đủ bối cảnh để xác định bước tiếp theo an toàn.

Vì vậy, quy trình khôi phục cần có khả năng vừa nói rằng “Tôi chưa thể đưa ra căn cứ hợp lý để thay đổi giao dịch này”, vừa cho biết “Đây là những việc cần làm để giải quyết vấn đề”.

Nhận biết sự không chắc chắn chỉ hữu ích khi hệ thống có cách thiết thực để xử lý tình trạng đó.

Một trong những câu hỏi lớn nhất xoay quanh AI tự chủ là xác định khi nào vẫn cần có sự phê duyệt của con người. Theo ông, AI nên được phép tự thực hiện những biện pháp khôi phục nào trong môi trường vận hành, và những biện pháp nào luôn cần có sự chấp thuận của con người? Các tổ chức nên thiết lập những ranh giới này ra sao khi có liên quan đến giao dịch tài chính, việc tuân thủ quy định hoặc niềm tin của khách hàng?

Tôi sẽ xác định ranh giới dựa trên hậu quả nếu xảy ra sai sót, chứ không dựa vào việc một hành động có được gắn nhãn là «AI» hay không.

Điều tra chỉ đọc là một khởi điểm hợp lý, miễn là tác nhân chỉ có thể truy cập thông tin được phép. Tác nhân có thể thu thập hồ sơ chẩn đoán, nhóm các cảnh báo có liên quan và chuẩn bị bản tóm tắt sự cố mà không được phép thay đổi giao dịch gốc.

Một số quy trình khôi phục được xác định trước cũng có thể phù hợp để tự động hóa, nếu các điều kiện của chúng được xác minh độc lập và tác động được giới hạn.

Tôi sẽ yêu cầu con người phê duyệt khi biện pháp can thiệp được đề xuất nằm ngoài quy trình đã được phê duyệt, khi hồ sơ mâu thuẫn và kết quả tài chính vẫn chưa được xác định, hoặc khi hành động đó sẽ thay đổi các biện pháp kiểm soát bảo mật hay quyền hạn của chính tác nhân. Tác nhân không nên tự phê duyệt những quyết định đó.

Điều đó không có nghĩa là mọi hoạt động tài chính thường lệ đều cần một người phê duyệt. Quy trình xử lý dựa trên các quy tắc đã thiết lập khác với việc cho phép một mô hình tự nghĩ ra cách điều chỉnh khi xảy ra sự cố.

Việc con người xem xét cũng phải có ý nghĩa thực chất. Màn hình phê duyệt cần hiển thị bằng chứng hỗ trợ, những điểm còn chưa chắc chắn, tác động dự kiến và các phương án thay thế. Yêu cầu ai đó phê duyệt một đoạn giải thích đầy vẻ tự tin nhưng không có ngữ cảnh như vậy hầu như chẳng tăng thêm mức độ bảo vệ nào.

Các ranh giới này cần được thống nhất trước khi triển khai. Khi hệ thống gặp sự cố, đó không phải là lúc thích hợp để quyết định nên trao cho hệ thống tự động bao nhiêu quyền hạn.

Ông có nhiều kinh nghiệm về các hệ thống phụ trợ có khả năng chịu lỗi, công cụ giám sát và khả năng quan sát hệ thống, cũng như tích hợp giữa các dịch vụ phần mềm với phần cứng vật lý. Tác nhân AI cần những loại dữ liệu đo lường từ môi trường vận hành và bằng chứng nào để chẩn đoán sự cố một cách đáng tin cậy? Các nhóm kỹ thuật có thể phân biệt những đề xuất hữu ích do AI tạo ra với các kết luận nghe có vẻ hợp lý nhưng sai, có nguy cơ khiến sự cố trở nên nghiêm trọng hơn, bằng cách nào?

Tôi sẽ bắt đầu với những bằng chứng kết nối hoạt động của khách hàng xuyên suốt các hệ thống liên quan: mã định danh giao dịch, sự kiện dịch vụ, thay đổi trạng thái được lưu bền vững, phản hồi từ thiết bị và lỗi liên lạc.

Phiên bản phần mềm và các thay đổi cấu hình cũng rất quan trọng. Một sự cố bắt đầu sau khi phát hành phiên bản mới là manh mối hữu ích cho người điều tra, nhưng chỉ riêng thời điểm xảy ra không chứng minh được quan hệ nhân quả.

Tác nhân cũng cần hiểu những giới hạn của bằng chứng. Nhật ký có thể không đầy đủ, hồ sơ có thể đến muộn và đồng hồ có thể không đồng bộ. Không nhận được xác nhận không đồng nghĩa với bằng chứng rằng thao tác đã không diễn ra.

Một chẩn đoán hữu ích cần phân biệt giữa quan sát và diễn giải. «Máy khách ghi nhận lỗi hết thời gian chờ» là một quan sát. «Hệ thống phụ trợ không khả dụng» là một lời giải thích cần có thêm bằng chứng hỗ trợ.

Tôi kỳ vọng một đề xuất sẽ chỉ rõ những hồ sơ làm căn cứ, giải thích điều gì vẫn chưa rõ và nêu cụ thể cần thực hiện thêm bước kiểm tra nào để xác nhận hoặc bác bỏ kết luận.

Sau đó, các kỹ sư nên đối chiếu những đề xuất có ảnh hưởng đáng kể với hồ sơ gốc, thay vì chỉ dựa vào bản tóm tắt của tác nhân. Điều này đặc biệt quan trọng khi bản tóm tắt cô đọng một lịch sử sự kiện dài hoặc mâu thuẫn.

Tiêu chuẩn tôi đặt ra rất đơn giản: một kỹ sư khác có thể lần theo bằng chứng và đi đến một kết luận có cơ sở hay không? Nếu lời giải thích không vượt qua được phép kiểm tra đó, thì chưa nên dùng nó để thúc đẩy thay đổi trong môi trường vận hành.

Trong nghiên cứu đã công bố của ông về khả năng chống chịu trước mã độc tống tiền tại các ki-ốt xổ số và cá cược, ông đã đánh giá một khuôn khổ bảo mật có AI hỗ trợ bằng cách sử dụng một môi trường mô phỏng 500 ki-ốt. Những phát hiện quan trọng nhất là gì, và độc giả cần lưu ý những hạn chế nào khi diễn giải các kết quả này? Cần tiến hành thêm những bước xác thực nào trước khi áp dụng kiến trúc được đề xuất vào môi trường vận hành thực tế?

Tôi muốn xem xét khả năng chống chịu không chỉ ở khâu phát hiện, mà còn ở cách môi trường thiết bị đầu cuối có thể hạn chế một cuộc tấn công, nhận diện cuộc tấn công đó và khôi phục hoạt động trong khi vẫn bảo toàn bằng chứng về những gì đã xảy ra.

Khung bảo mật có khả năng chống chịu hình thành từ sự kết hợp giữa các biện pháp kiểm soát phòng ngừa, khả năng phát hiện bất thường có AI hỗ trợ và các cơ chế ứng phó, khôi phục được xác định rõ. Thành phần AI tập trung vào việc phát hiện hành vi đáng ngờ. Đây không phải là một thử nghiệm cho phép tác nhân dựa trên mô hình ngôn ngữ tự ý thay đổi các giao dịch tài chính.

Đánh giá sử dụng một môi trường mô phỏng đại diện cho 500 ki-ốt trong 72 giờ, với các mô phỏng hành vi của những cuộc tấn công bằng mã độc tống tiền, chứ không phải triển khai trên 500 thiết bị đầu cuối vật lý.

So với mốc đối chiếu chỉ sử dụng phần mềm diệt vi-rút trong nghiên cứu, thời gian phát hiện trung bình giảm từ 52 phút xuống còn 31 phút, còn thời gian khôi phục trung bình giảm từ 120 phút xuống còn 56 phút.

Đó là kết quả của khung tổng hợp trong các điều kiện thử nghiệm. Không nên quy những kết quả này chỉ cho AI hoặc xem chúng là sự bảo đảm về hiệu năng trong môi trường vận hành thực tế. Một phát hiện đáng chú ý là chỉ riêng việc phát hiện sớm hơn không mang lại mức cải thiện tương tự về khả năng khôi phục. Thiết kế quy trình ngăn chặn và khôi phục cũng đóng vai trò quan trọng.

Các hạn chế của nghiên cứu rất đáng lưu ý. Khối lượng công việc mô phỏng, điều kiện mạng, hành vi tấn công và các biện pháp phòng thủ cơ sở không đại diện cho mọi môi trường vận hành. Các thiết bị và ứng dụng khác nhau sẽ cần được kiểm định lại.

Trước khi đưa vào sản xuất, tôi muốn thử nghiệm trên phần cứng đại diện, đánh giá bảo mật độc lập, tiến hành các đợt đánh giá kéo dài hơn, đồng thời đo lường cẩn thận cảnh báo sai và chi phí xử lý.

Tôi cũng sẽ kiểm thử quy trình khôi phục với các hoạt động giao dịch hợp lệ. Khôi phục một ảnh phần mềm hoạt động được là chưa đủ nếu quy trình làm mất thông tin cần thiết để hạch toán các giao dịch đã hoàn tất.

Nghiên cứu này tạo cơ sở cho những thử nghiệm tiếp theo. Chứng minh được hành vi an toàn trong môi trường vận hành thực tế là một bước riêng biệt.

Góc nhìn của ông kết hợp nhiều năm làm kỹ thuật trong môi trường sản xuất với nghiên cứu học thuật về độ tin cậy của phần mềm và bảo mật ứng dụng AI. Ông có thể phân biệt những cơ chế bảo đảm độ tin cậy mà bản thân đã triển khai hoặc vận hành trong các hệ thống sản xuất thực tế với những phương pháp ông đã nghiên cứu hoặc thử nghiệm trong môi trường mô phỏng không? Theo ông, những năng lực khôi phục ứng dụng AI nào đã khả thi trong thực tế hiện nay, và những năng lực nào phần lớn vẫn còn mang tính thử nghiệm?

Công việc trong môi trường sản xuất của tôi bao gồm phát triển và tích hợp phần mềm, xác thực giao dịch, khắc phục sự cố, kiểm thử và xác nhận bản phát hành.

Các nghiên cứu đã công bố là một phần riêng trong công việc của tôi; mỗi nghiên cứu cần được xem xét dựa trên phương pháp và những hạn chế đã nêu.

Bài nghiên cứu về mã độc tống tiền đánh giá một khung bảo mật được đề xuất trong môi trường kiểm thử tổng hợp. Bài nghiên cứu về AI biên của tôi phân tích tài liệu về trí tuệ nhân tạo trên thiết bị và khả năng ứng dụng công nghệ này vào các thiết bị đầu cuối giao dịch. Bài viết của tôi trên IEEE FeedForward xem xét một kiến trúc bảo đảm độ tin cậy có AI hỗ trợ thông qua mô phỏng có kiểm soát, bao gồm giám sát, leo thang xử lý và cơ chế dự phòng.

Không nên xem bất kỳ ấn phẩm nào trong số đó là bằng chứng cho thấy tôi đã triển khai một tác tử AI tự chủ có quyền kiểm soát các giao dịch tài chính trực tiếp.

Để ứng dụng trong thực tế, tôi sẽ ưu tiên những công cụ hỗ trợ mà kỹ sư có thể kiểm tra: bản tóm tắt sự cố có liên kết đến hồ sơ nguồn, các mối tương quan giữa nhiều cảnh báo và những bước kiểm tra chẩn đoán được đề xuất. Tuy nhiên, tính hữu ích của chúng vẫn cần được đo lường trong môi trường triển khai.

Thách thức lớn hơn là khôi phục trong các tình huống không xác định trước, khi mô hình lựa chọn và thực thi các thay đổi trong những điều kiện chưa được dự liệu. Việc này đòi hỏi mức độ bằng chứng cao hơn nhiều so với một đề xuất chẩn đoán hữu ích.

Tôi xem kinh nghiệm thực tế trong môi trường sản xuất và nghiên cứu của mình là hai phương diện bổ trợ cho nhau: một bên giúp xác định những vấn đề vận hành mà tôi hiểu rõ, còn bên kia khám phá các phương pháp vẫn cần được kiểm định trước khi có thể chứng minh giá trị.

Trong thời gian tới, khi các tác tử AI ngày càng có khả năng phát hiện bất thường, chẩn đoán lỗi và điều phối khôi phục trên các hệ thống phân tán, ông hình dung mối quan hệ giữa hệ thống tự chủ và kỹ sư con người sẽ thay đổi ra sao? Cần có những biện pháp bảo vệ kỹ thuật, bằng chứng vận hành và cơ chế trách nhiệm giải trình nào trước khi các tổ chức có thể tự tin trao cho AI quyền hạn lớn hơn đối với hạ tầng sản xuất trọng yếu?

Tôi cho rằng AI sẽ đảm nhận nhiều hơn công việc tổng hợp thông tin về sự cố. Thay vì mất quá nhiều thời gian tự thu thập dữ liệu, các kỹ sư có thể bắt đầu với một dòng thời gian hữu ích, các thành phần bị ảnh hưởng, những cách lý giải khác nhau và những bằng chứng còn thiếu.

Nhờ đó, con người sẽ có thêm thời gian đưa ra những quyết định đòi hỏi phải hiểu rõ các nghĩa vụ của hệ thống và hậu quả của việc thay đổi hệ thống.

Tôi sẽ mở rộng quyền thực thi từng bước. Ban đầu, một tác tử có thể hoạt động ở chế độ chạy ngầm, đưa ra khuyến nghị nhưng không tự hành động. Các nhóm có thể đối chiếu những khuyến nghị đó với kết quả đã được xem xét, đồng thời kiểm tra cách tác tử ứng phó khi thông tin bị thiếu, mâu thuẫn hoặc lỗi thời.

Quá trình đánh giá cần bao gồm các hành động can thiệp sai, sự cố bị bỏ sót, việc leo thang xử lý không cần thiết và khả năng khôi phục sau sai lầm do chính tác tử gây ra. Một khuyến nghị nhanh sẽ không có giá trị nếu khiến đội ứng phó đi sai hướng.

Việc trao quyền hạn lớn hơn cũng cần có điều kiện. Bản cập nhật mô hình hoặc thay đổi lớn trong hệ thống có thể làm mất hiệu lực của các thử nghiệm trước đó. Các nhóm cần có cách thu hẹp hoặc thu hồi quyền của tác tử khi hành vi của nó không còn đáp ứng tiêu chuẩn yêu cầu.

Tự động hóa được cải thiện không làm mất đi trách nhiệm của con người. Phải có người chịu trách nhiệm về các quy tắc vận hành, bằng chứng cần thiết cho mỗi thay đổi và quy trình điều tra sự cố.

Tôi hình dung các kỹ sư sẽ dành ít thời gian hơn cho việc thu thập thông tin, và dành nhiều thời gian hơn để xác định, kiểm thử và duy trì những điều kiện cần có để biện minh cho hành động tự động.

Cảm ơn ông về cuộc phỏng vấn tuyệt vời. Độc giả muốn theo dõi công việc của ông về độ tin cậy của giao dịch phân tán và khôi phục có hỗ trợ AI một cách có trách nhiệm có thể kết nối với Sapan Pandya.