Yuri Gubin, CTO tại DataArt – Loạt Phỏng Vấn

Yuri Gubin, CTO tại DataArt là một giám đốc công nghệ và kiến trúc sư phần mềm dày dặn kinh nghiệm, đã làm việc hơn 18 năm tại DataArt, tiến triển qua các vai trò bao gồm kiến trúc phần mềm, kiến trúc giải pháp, công nghệ đám mây, đổi mới và lãnh đạo cấp cao trước khi trở thành Giám đốc Công nghệ vào tháng 3 năm 2026. Công việc của ông tập trung vào việc giải quyết các thách thức công nghệ phức tạp trong các ngành như dịch vụ tài chính, chăm sóc sức khỏe, du lịch và IoT, với chuyên môn đặc biệt trong điện toán đám mây, AI, nền tảng dữ liệu và kiến trúc phần mềm doanh nghiệp. Trước khi trở thành CTO, Gubin đã phục vụ hơn năm năm với vai trò Giám đốc Đổi mới tại DataArt và là thành viên của Ban Đối tác công ty kể từ năm 2021. Ông cũng là thành viên chuyên nghiệp của Forbes Technology Council, tham gia các nhóm chuyên gia AI và Điện toán Đám mây, và là Cố vấn Công nghệ cho Girls Who Code, nơi ông tư vấn về kiến trúc, bảo vệ dữ liệu, quản trị nền tảng và chính sách công nghệ. Hiện tại DataArt liệt kê ông là Giám đốc Công nghệ, làm việc tại New York.

DataArt là một công ty toàn cầu về kỹ thuật phần mềm và chuyển đổi dữ liệu và AI, được thành lập tại New York vào năm 1997. Công ty đã mở rộng lên hơn 6.000 chuyên gia công nghệ hoạt động tại hơn 20 quốc gia và hợp tác với hơn 400 khách hàng, cung cấp dịch vụ trong các lĩnh vực bao gồm trí tuệ nhân tạo và học máy, dữ liệu và phân tích, chuyển đổi đám mây, phát triển phần mềm tùy chỉnh, an ninh mạng và hiện đại hoá hệ thống cũ. DataArt hoạt động trên các ngành như dịch vụ tài chính, chăm sóc sức khỏe và khoa học đời sống, du lịch, truyền thông và giải trí, và bán lẻ, đồng thời duy trì các quan hệ đối tác công nghệ với các nền tảng như AWS, Google Cloud, Microsoft Azure, Snowflake và Databricks. Năm 2025, công ty công bố khoản đầu tư $100 triệu trong ba năm cho khả năng dữ liệu và AI, và năm 2026 đã ra mắt Artisyn, một mô hình vận hành có AI hỗ trợ, được thiết kế để tích hợp các tác nhân AI, các bộ tăng tốc tái sử dụng, quản trị, bảo mật và tuân thủ vào phát triển phần mềm doanh nghiệp.

Bạn đã dành gần hai thập kỷ tại DataArt, tiến triển từ kiến trúc sư phần mềm và kiến trúc sư giải pháp đến Giám đốc Đổi mới và hiện là CTO. Hành trình đó đã hình thành cách bạn phân biệt công nghệ thực sự mang tính chuyển đổi so với các chu kỳ quảng cáo, và nó đã ảnh hưởng như thế nào đến \”lạc quan hoài nghi\” của bạn đối với AI hiện nay?

Chúng tôi đã chứng kiến nhiều làn sóng khác nhau trong những năm qua, bao gồm sự lên ngôi của điện toán đám mây và di động, các thế hệ AI khác nhau, tự động hoá, DevOps và SRE, và tôi đã lập trình, kiến trúc và tư vấn cho khách hàng của chúng tôi về nhiều chủ đề này trong suốt thời gian đó. Điều tôi nhận ra là, vâng, bạn có thể làm hầu hết mọi thứ với công nghệ, và công nghệ rất mạnh mẽ, nhưng thách thức nằm ở chi tiết và bạn cần biết mình đang làm gì để nó có ý nghĩa và hoạt động.

Tôi đã thấy môi trường đám mây ngày càng tốn kém, các mô hình AI không hoạt động như bạn mong đợi, và những nỗ lực tự động hoá chu kỳ phát hành được thực hiện kém. Tôi đã chứng kiến tác động của cả quyết định tốt và quyết định xấu, vì vậy bất cứ khi nào có điều gì mới xuất hiện và bạn đọc tất cả các thông báo, lời hứa và quảng cáo, tôi luôn quay lại giả thiết ban đầu: hầu hết mọi thứ đều có thể với công nghệ, nhưng bạn cần biết mình đang làm gì.

Bạn nắm bắt tốt một công nghệ thông qua R&D và, quan trọng hơn, thông qua các dự án thực tế, vì đó là cách bạn học được những gì có thể, những gì không, và nơi có thể xảy ra sai sót. Bạn rút ra những bài học từ mỗi dự án, trò chuyện với đồng nghiệp, các kiến trúc sư và nhà phân tích khác, và cố gắng hiểu liệu có những mẫu hình nào và bạn có thể tạo ra một hệ thống nào đó xung quanh chúng không. Cuối cùng, điều đó trở thành hướng dẫn, và sau đó bạn xem liệu những quyết định mà bạn cho là tốt thực sự mang lại kết quả tốt hay không.

Đó là nguồn gốc của lạc quan hoài nghi. Dù công nghệ hứa hẹn gì, bạn vẫn cần biết mình đang làm gì, và kiến thức đó đến từ kinh nghiệm, hợp tác, và nỗ lực liên tục để học hỏi, cải thiện và tạo ra một hệ thống nào đó phía sau những lời quảng cáo.

AI doanh nghiệp dường như đang chuyển từ giai đoạn khuyến khích thử nghiệm sang việc quyết định những thử nghiệm nào thực sự xứng đáng được mở rộng. Những tín hiệu nào cho bạn biết một trường hợp sử dụng AI đã sẵn sàng cho triển khai rộng hơn, và những dấu hiệu cảnh báo nào cho thấy một công ty đang mở rộng quá sớm?

Tôi sử dụng hai phương pháp để hiểu liệu chúng ta có thể mở rộng một thứ gì đó hay cần làm gì khác: đường cong chấp nhận và đường cong học hỏi.

Để hiểu một trường hợp sử dụng AI có hiệu quả hay không, bạn cần cho nó một thời gian và hiểu giá trị mà nó mang lại cũng như hành trình của người dùng trông như thế nào, vì khi đó bạn có thể nhìn thấy những thăng trầm thay vì chỉ hiệu ứng ‘wow’ ngay lập tức trong một đội hoặc quy trình cụ thể. Bạn cần xem những gì xảy ra với cùng những người dùng sau vài tuần. Họ vẫn còn sử dụng nó không? Họ vẫn hài lòng với trường hợp sử dụng đó, với tự động hoá hoặc kỹ năng AI mà họ đã tạo ra, hay đó chỉ là một hiện tượng ngắn ngủi không nên được mở rộng?

Một số điều này chỉ có thể được xác nhận theo thời gian. Sẽ luôn luôn có những người tiên phong đầu tiên, thường là những người có kỹ năng kỹ thuật cao và rất tò mò, sau đó bạn cần thử nghiệm với các phân khúc khác, với những người theo sau những người áp dụng sớm và sau đó là đa số sớm. Khi nó tự chứng minh được ở đó, vâng, bạn có thể bắt đầu mở rộng và mở rộng trường hợp sử dụng đó sang các phòng ban khác.

Mỗi lần phát hành mô hình lớn có thể tạo áp lực trong một tổ chức để ngay lập tức cung cấp cho nhân viên quyền truy cập vào các khả năng mới nhất. Các nhà lãnh đạo công nghệ nên đánh giá như thế nào để xác định liệu một mô hình mới có mang lại cải tiến đáng kể hay chỉ đơn giản là tạo ra một làn sóng thử nghiệm và chi phí mới?

Một lần nữa, tôi đưa ra sự lạc quan hoài nghi của mình. Giả sử bạn đã có một mô hình và hàng ngàn người đang sử dụng AI hàng ngày, với các mô hình và công cụ khác nhau đã có sẵn. Khi một mô hình mới ra mắt, vì sự thổi phồng và tính tò mò tự nhiên, bạn có thể mong đợi mọi người sẽ muốn thử nghiệm nó, điều này là tốt, nhưng việc thử nghiệm đó không nhất thiết phải được hướng dẫn hoặc nhắm tới bất kỳ kết quả cụ thể nào, và đôi khi bạn thậm chí không thể đo lường sự khác biệt.

Ở quy mô lớn, điều này quan trọng. Không chỉ một hoặc hai người đang khám phá để xem mô hình mới hoạt động như thế nào so với mô hình cũ. Có thể hàng ngàn người dành thời gian thử nghiệm, trong khi đối với một trường hợp sử dụng cụ thể, kết quả có thể không đáng kể. Đồng thời, nếu có điều gì đó hoạt động rất tốt, những kiến thức về những gì hiệu quả trong tổ chức của bạn có thể không được giải thích rõ ràng hoặc hiển thị cho mọi người.

Đó là lý do tại sao nhóm đầu tiên đánh giá một mô hình mới không nên là toàn bộ nhân viên trong tổ chức. Nó nên là một nhóm R&D làm việc chặt chẽ với các đội liên quan, cũng như bộ phận pháp lý và bảo mật. Chúng tôi đánh giá mô hình một cách toàn diện, thực hiện đánh giá nhanh, sau đó đưa nó tới khán giả rộng hơn kèm theo một số nhận xét và hướng dẫn về bảo mật, tuân thủ và công nghệ. Khi các mô hình mới và các bản cập nhật lớn liên tục xuất hiện, bạn cần có mô hình và tư duy này sẵn sàng. Thực tế, đây không phải là một hoạt động một lần duy nhất.

DataArt đã tạo ra một đội “AI SWAT” đa chức năng bao gồm công nghệ, pháp lý, tuân thủ, InfoSec và các đội khác. Nhóm này hoạt động như thế nào trong thực tế, và những loại rủi ro hoặc câu hỏi nào cần được giải quyết trước khi một công cụ AI mới được phê duyệt để sử dụng rộng rãi?

Kể từ khi thành lập, tôi nghĩ chúng tôi đã đặt các mục tiêu khác nhau cho nhóm này khoảng mỗi bốn hoặc năm tháng một lần. Chúng tôi thay đổi ưu tiên, mục tiêu và đôi khi cả sứ mệnh, và nhiều mục tiêu này liên quan đến AI. Có thể là nâng cao kỹ năng cho lực lượng lao động, chiến lược ra thị trường và các khả năng mới, quan hệ đối tác, hoặc mở rộng việc áp dụng AI rộng rãi hơn trong tổ chức và trên toàn bộ ADLC.

Các chủ đề cụ thể thay đổi theo thời gian, và tôi cho rằng điều này là lành mạnh vì bạn luôn cần xem lại chiến lược của mình, xác thực các giả định và hiểu liệu bạn có cần điều chỉnh hướng đi và chủ đề tiếp theo cho đội ngũ là gì.

Nhóm này bao gồm đại diện từ các phòng ban khác nhau, và một trong những mục đích của nó đơn giản là giữ mọi người được thông báo. Khi có thông báo, câu hỏi hoặc cơ hội mới, ai đó có thể đưa chủ đề đó lên một trong các cuộc họp định kỳ của chúng tôi. Ngay cả khi nó trông giống như một câu hỏi công nghệ chỉ liên quan đến một nhóm hẹp, ngày nay những chủ đề này có thể ảnh hưởng đến nhiều bộ phận trong tổ chức.

Đó là lý do, khi chúng tôi đánh giá một đối tác, công cụ hoặc chương trình tăng tốc mới, chúng tôi thảo luận công khai để mọi người hiểu hướng đi và có cơ hội đặt câu hỏi hoặc giám sát. Đối với một công cụ AI mới, công nghệ không thể đánh giá nó một cách riêng lẻ. Bộ phận bảo mật, pháp lý và tuân thủ cũng cần hiểu cách nó xử lý dữ liệu công ty hoặc khách hàng, những ràng buộc nào áp dụng và liệu nó có thể được sử dụng an toàn ở quy mô lớn hay không.

Đôi khi đội AI SWAT cũng làm việc trên các chương trình cụ thể, chẳng hạn như nâng cao kỹ năng, nơi chúng tôi đặt mục tiêu, lập lộ trình và quyết định cách các nhóm khác nhau sẽ được đưa vào. Đó thực sự là cách hoạt động: giữ mọi người được thông báo, hợp tác trên các chương trình cụ thể, và cung cấp cho ban lãnh đạo cái nhìn về những gì đang diễn ra với AI trong toàn công ty.

Bạn đang thấy những thái độ rất khác nhau đối với phát triển phần mềm hỗ trợ AI, với một số tổ chức đang tích cực mở rộng phát triển có tính năng tự động trong khi những tổ chức khác vẫn cấm mã do AI tạo ra. Điều gì giải thích sự chia rẽ này, và cần thay đổi gì trước khi các doanh nghiệp chú trọng rủi ro hơn cảm thấy thoải mái khi AI đóng vai trò lớn hơn trong kỹ thuật phần mềm?

Có lẽ yếu tố tạo ra sự khác biệt giữa những người nói không và những người nói có là mức độ chấp nhận rủi ro và thái độ của họ đối với sự mơ hồ và không chắc chắn. Điều giúp cả hai loại tổ chức là giáo dục liên tục, thử nghiệm và đánh giá. Ngay cả trong số nhiều tổ chức mà chúng tôi làm việc, những người áp dụng AI và tích hợp nó ở mọi nơi, vẫn còn những thách thức trong việc đo lường kết quả và tác động. Thành thật mà nói, câu hỏi về cách bạn đo lường tác động của AI và cách bạn đánh giá hiệu suất của một đội ngũ đôi khi xuất hiện một cách bất ngờ, như thể không ai thực sự nghĩ tới trước đây.

Khi bạn bắt đầu đánh giá một sáng kiến AI một cách toàn diện hơn, bạn sẽ hiểu được tác động và giá trị thực sự mà nó mang lại, từ đó đưa ra các quyết định tốt hơn về nơi công nghệ này có ý nghĩa. Đối với các công ty từ chối AI, vẫn cần có một quy trình liên tục để xem xét những gì công nghệ có thể làm và hiện trạng của nó. Bạn không muốn một quyết định được đưa ra ba năm trước vẫn còn là chính sách công ty chỉ vì không ai xem xét lại các giả định đằng sau nó.

AI có tính năng tự động hoá ngày càng làm cho các đội nhóm riêng lẻ dễ dàng tạo ra các tác nhân của riêng mình, có khả năng dẫn đến việc có nhiều tác nhân thực hiện các nhiệm vụ gần như giống nhau. Thì lúc nào việc thử nghiệm trở thành sự lan rộng của các tác nhân, và cần loại lớp quản trị nào để quản lý quyền sở hữu, quyền truy cập, trùng lặp và quản lý vòng đời?

Khi chúng ta thấy một kịch bản điển hình mà giấy phép AI được cấp cho mọi nhà phát triển và việc thử nghiệm trở nên không có hướng dẫn, mọi người bắt đầu tự tạo ra các sản phẩm của mình và làm việc theo cách riêng. Thông thường, điều này dẫn đến các đội ngũ kém hiệu suất, không đạt được kỳ vọng, chất lượng tụt hậu và chi phí tăng lên. Kết luận là nó không đáp ứng được những gì mọi người mong đợi, chất lượng kém và chi phí cao. Để giảm thiểu, cần có một nỗ lực chung của cả đội, là một phần của nỗ lực rộng hơn của phòng ban hoặc tổ chức, và đó là nơi quản trị xuất hiện.

Ở cấp độ dự án, bạn có thể thống nhất cơ sở kiến thức và ngữ cảnh, cũng như các trường hợp sử dụng mà bạn bắt đầu áp dụng AI. Sau đó, bạn tạo ra các kỹ năng và tác nhân là một phần của quy trình phát triển và mọi người có thể tái sử dụng, giúp tích lũy kiến thức và các thực tiễn tốt nhất thay vì phải tạo lại mỗi lần. Nỗ lực ở cấp độ dự án này sau đó nên được điều phối bởi một hội đồng kiến trúc doanh nghiệp, một nhóm công nghệ, CTO, hoặc một đội chịu trách nhiệm về việc áp dụng AI. Bạn muốn tái sử dụng các tác nhân hoạt động tốt, đảm bảo quy trình vững chắc và để chúng hoạt động trên toàn tổ chức thay vì trở thành hỗn loạn và ồn ào.

Vì vậy, tôi cho rằng cần có một nỗ lực đồng bộ ở cấp độ dự án, có thể là cấp độ chương trình, và sau đó ở các cấp độ phòng ban và tổ chức.

Việc tiêu thụ token và chi phí suy luận có thể trông khá nhỏ trong giai đoạn thí điểm nhưng trở nên đáng kể khi các hệ thống AI được triển khai trên hàng ngàn nhân viên hoặc các tác nhân tự động. Doanh nghiệp nên suy nghĩ như thế nào về quản lý chi phí AI, và bạn có mong đợi một hình thức tương tự FinOps sẽ xuất hiện riêng cho các khối lượng công việc AI không?

Tôi sẽ bắt đầu bằng cách nói rằng một kịch bản gần như lý tưởng là khi chi phí AI tăng lên, đạt đến mức ổn định, rồi sau đó giảm nhẹ theo thời gian. Điều này cho bạn biết rằng bạn có thể dự báo, kiểm soát chi phí, hiểu rõ những gì bạn thực sự chi cho AI và thấy kết quả của các quyết định bạn đưa ra. Các tình huống xấu là khi chi phí liên tục lên xuống vì thường nghĩa là có điều gì đó không bền vững, hoặc khi chi phí tăng rồi giảm hoàn toàn vì việc áp dụng có thể không diễn ra, có thứ gì đó không hoạt động, hoặc mọi người đang dùng một công cụ khác và bạn không nhận ra.

Vì vậy FinOps là một khái niệm, và AI FinOps cũng là một khái niệm. Một số kỹ thuật rất chuyên sâu, trong khi những kỹ thuật khác lại khá đơn giản. Nó có thể chỉ là việc chọn mô hình ưu tiên để bạn không luôn phải dựa vào mô hình đắt nhất, và từng quyết định nhỏ dần dần giúp tiết kiệm chi phí. Đồng thời, biết cách tiết kiệm và kiểm soát chi phí chỉ là một nửa của phương trình. FinOps, theo tôi, là một lĩnh vực và phương pháp luận cũng liên quan đến các nhà lãnh đạo sản phẩm và kinh doanh vì bạn cần xác định những gì mình đang đo lường khi đánh giá các nỗ lực AI.

Vì vậy, tôi nghĩ AI FinOps là một chủ đề tốt để đội ngũ tương đương AI SWAT thảo luận: mức chi tiêu, mức thu hồi, cách kiểm soát và những cơ hội nào tồn tại.

Nhiều công ty đang bị yêu cầu chứng minh ROI từ AI mặc dù họ chưa bao giờ thiết lập một chuẩn cơ sở đáng tin cậy về năng suất của các đội ngũ trước khi AI được giới thiệu. Các tổ chức thực sự nên đo lường gì nếu muốn xác định AI có tạo ra giá trị kinh doanh có ý nghĩa hay không?

Bất kể quan điểm của bạn về AI hay vị trí hiện tại của bạn, có thể bạn đã đang sử dụng các tác nhân khắp nơi hoặc có thể bạn đang nghĩ rằng vào năm tới sẽ bắt đầu sử dụng AI, việc thiết lập một chuẩn cơ sở hiện nay là điều không thể thiếu.

Có một số loại chỉ số. Một số là chủ quan, có thể chỉ là phản hồi từ các nhà phát triển hoặc nhân viên của bạn vì bạn đang làm việc với con người và việc hiểu họ cảm nhận giá trị của AI là quan trọng. Các chỉ số khách quan hơn có thể bắt đầu từ các chỉ số cơ học hoặc tổng hợp, mặc dù tôi khuyên mọi người không nên gắn bó quá chặt chẽ với chúng. Tôi nói đến các yếu tố như commit mã nguồn hoặc story point. Những chỉ số này cho thấy công việc đã diễn ra, nhưng chúng không thực sự phản ánh giá trị hay tác động.

Điều quan trọng hơn là các chỉ số giải thích tốc độ hoặc mức độ hoàn thành công việc. Hãy nghĩ đến các chỉ số DORA như lead time hoặc MTTR, tốc độ khôi phục sau một sự cố, tốc độ sửa lỗi trong môi trường production, hoặc cách những chỉ số này thay đổi theo thời gian. Một con số tại một thời điểm không cho bạn thấy xu hướng. Một trong những kiến trúc sư của chúng tôi vừa đề cập rằng, trong phát triển phần mềm, một chỉ số tốt cũng có thể là độ tin cậy của các ước lượng khi việc áp dụng AI ngày càng tăng, vì điều đó phản ánh tính bền vững của những nỗ lực và mức độ năng suất thực sự của các đội nhóm. Bạn cũng cần theo dõi chi phí vì nếu chỉ nói về lợi ích mà không hiểu chi phí để đạt được chúng, bạn sẽ không có bức tranh đầy đủ.

Ngoài lĩnh vực phát triển phần mềm, tôi nghĩ về nó theo cách tương tự. Trong mỗi quy trình hoặc luồng công việc, luôn có một đơn vị công việc và một định nghĩa về hoàn thành. Dù bạn đang xử lý yêu cầu bồi hoàn, xem xét tài liệu hay xử lý yêu cầu khách hàng, hãy xác định những gì bạn đang cung cấp và sau đó đo lường thời gian đã mất trước khi có AI, tốc độ và chất lượng hiện tại, cũng như chi phí. Điều đó cung cấp cho bạn một điểm khởi đầu tốt cho cả mức chuẩn cơ bản và khung chỉ số.

DataArt đã tích hợp AI xuyên suốt vòng đời giao hàng phần mềm thông qua các sáng kiến như Artisyn. Khi AI tiếp quản nhiều hơn các nhiệm vụ triển khai, kiểm thử và quy trình làm việc, những phần nào của kỹ thuật phần mềm trở nên có giá trị hơn đối với con người, và những kỹ năng nào có nguy cơ trở nên kém quan trọng hơn?

Bạn chỉ có thể sử dụng AI hiệu quả trong phát triển nếu bạn vẫn nhớ định nghĩa của tốt là gì. Bạn cần có chuyên môn đó để hướng dẫn các tác nhân của mình, xem xét kết quả, đặt ra các ràng buộc và xác định các quy tắc. Bạn cần hiểu thực hành tốt nhất là gì và kiến trúc tốt nên như thế nào, vì nếu không, bạn có thể không biết đang phát triển gì, và giá trị của loại chuyên môn này đang tăng lên rất, rất đáng kể.

Hiểu các mẫu kiến trúc là quan trọng, cũng như hiểu những gì phù hợp trong một ngành, ứng dụng hoặc loại giải pháp cụ thể. Bạn cần biết loại kiến trúc nào đang tốt hiện tại và loại nào sẽ vẫn tốt khi giải pháp mở rộng, vì đôi khi cùng một kiến trúc không hoạt động suốt vòng đời của một giải pháp hoặc nền tảng.

Sự cân bằng giữa những gì phù hợp cho một giải pháp cụ thể là phần con người. Đó là gu thẩm mỹ, sự tinh tế trong dịch vụ và phát triển phần mềm. Bạn phải biết mình đang làm gì, và điều đó cũng bắt nguồn từ việc hiểu khách hàng và ngành nghề.

Kỹ năng nào trở nên kém quan trọng hơn? Thật khó để tôi trả lời, mặc dù có thể là tốc độ gõ mã của bạn. Tôi đang đùa, nhưng hiện nay mã có thể được tạo ra nhanh hơn rất nhiều, và kiến thức chuyên sâu về một thư viện hay ngôn ngữ cụ thể cũng có thể được học nhanh hơn nhiều với AI.

Tôi đã chứng kiến các nhà phát triển .NET được đào tạo lại thành nhà phát triển Java trong thời gian rất ngắn, và năm hay mười năm trước tôi sẽ nói rằng việc làm đó ở quy mô lớn gần như không thể. Hiện nay, bạn có thể làm được. Một nhà phát triển senior mạnh mẽ ngày càng có thể chuyển đổi giữa các ngôn ngữ vì điều thực sự quan trọng là sự hiểu biết của họ về công nghệ, kiến trúc, các thực tiễn tốt nhất của giải pháp, SDLC và ADLC.

Khi các doanh nghiệp chuyển từ hàng chục dự án thí điểm AI sang các hệ thống sản xuất có thể thực hiện hành động một cách độc lập, trách nhiệm cuối cùng nên thuộc về ai khi một tác nhân AI gây ra lỗi tốn kém: nhà phát triển, chủ doanh nghiệp, nhà cung cấp mô hình, đội quản trị, hay một sự kết hợp của chúng?

Tôi thích ý tưởng hợp tác không đổ lỗi và trách nhiệm chia sẻ vì mọi người trong tổ chức đều đóng góp vào các thực hành tốt nhất, khung kiến trúc và giải pháp. Ngay cả khi một nhà phát triển tạo mã bằng AI hay không, một nhà phát triển khác sẽ xem xét nó, các trưởng nhóm cung cấp hướng dẫn, kiến trúc sư đưa ra kiến trúc và các ràng buộc, và đội quản trị tham gia vào các quyết định về ngân sách, thời gian và phát hành. Mọi người đều tham gia theo cách nào đó.

Rất thường xuyên, khi có sự cố, chính quy trình không hoạt động, vì vậy trách nhiệm ở mức độ này được chia sẻ giữa các vai trò khác nhau. Nhưng nếu chỉ nói trách nhiệm được chia sẻ và do đó không có người chịu lỗi, thì điều đó không đủ. Nó vẫn cần được phân chia thành các trách nhiệm cụ thể.

Nhà phát triển chịu trách nhiệm về mã họ gửi dưới dạng pull request, và họ cần hiểu những gì đang diễn ra. Kiến trúc sư chịu trách nhiệm về các quyết định họ đưa ra và các quyết định kiến trúc được cung cấp cho các tác nhân và nhà phát triển. Nhóm nền tảng chịu trách nhiệm về độ tin cậy của giải pháp bất kể ai hoặc gì đã tạo ra dòng mã cụ thể.

Vì vậy trách nhiệm đã tồn tại, nhưng bạn cần xác định chi tiết theo đội, vai trò và phòng ban. Điều bạn không thể làm là dừng việc phân tích ở mức “AI đã làm điều này”. Bạn cần hỏi những kiểm soát, kiểm thử hoặc giám sát nào đã cho phép lỗi đó tới môi trường production.

Nếu thiếu các kiểm thử đơn vị khiến mã lỗi được đẩy vào production, hoặc thiếu giám sát và đánh giá cho phép điều đó xảy ra, bạn không thể chuyển trách nhiệm đó sang AI. Bạn cũng không thể đơn giản đổ lỗi cho nhà cung cấp mô hình hoặc nhà cung cấp đám mây cho mọi lỗi hoặc sự cố.

Cảm ơn vì buổi phỏng vấn tuyệt vời, các độc giả muốn tìm hiểu thêm nên truy cập DataArt.