Yuri Gubin, CTO di DataArt – Seri Wawancara

Yuri Gubin, CTO di DataArt adalah eksekutif teknologi veteran dan arsitek perangkat lunak yang telah menghabiskan lebih dari 18 tahun bersama DataArt, menapaki peran yang mencakup arsitektur perangkat lunak, arsitektur solusi, teknologi cloud, inovasi, dan kepemimpinan eksekutif sebelum menjadi Chief Technology Officer pada Maret 2026. Pekerjaannya berfokus pada penyelesaian tantangan teknologi kompleks di berbagai industri termasuk layanan keuangan, perawatan kesehatan, perjalanan, dan IoT, dengan keahlian khusus dalam komputasi awan, AI, platform data, dan arsitektur perangkat lunak perusahaan. Sebelum menjadi CTO, Gubin menjabat lebih dari lima tahun sebagai Chief Innovation Officer DataArt dan menjadi anggota Board of Partners perusahaan sejak 2021. Ia juga merupakan anggota profesional Forbes Technology Council, berpartisipasi dalam grup ahli AI dan Cloud Computing, serta bertindak sebagai Teknologi Advisor untuk Girls Who Code, di mana ia memberi nasihat tentang arsitektur, perlindungan data, tata kelola platform, dan kebijakan teknologi. DataArt saat ini mencantumkannya sebagai Chief Technology Officer yang berbasis di New York.

DataArt adalah perusahaan rekayasa perangkat lunak global serta transformasi data dan AI yang didirikan di New York pada tahun 1997. Perusahaan ini telah tumbuh menjadi lebih dari 6.000 profesional teknologi yang beroperasi di lebih dari 20 negara dan bekerja dengan lebih dari 400 klien, menyediakan layanan di bidang termasuk kecerdasan buatan dan pembelajaran mesin, data dan analitik, transformasi cloud, rekayasa perangkat lunak khusus, keamanan siber, dan modernisasi warisan. DataArt beroperasi di sektor-sektor seperti layanan keuangan, perawatan kesehatan dan ilmu hayat, perjalanan, media dan hiburan, serta ritel, dan menjaga kemitraan teknologi dengan platform termasuk AWS, Google Cloud, Microsoft Azure, Snowflake, dan Databricks. Pada tahun 2025, perusahaan mengumumkan investasi sebesar $100 juta selama tiga tahun dalam kemampuan data dan AI-nya, diikuti pada tahun 2026 dengan peluncuran Artisyn, model operasi berbasis AI yang dirancang untuk mengintegrasikan agen AI, akselerator yang dapat digunakan kembali, tata kelola, keamanan, dan kepatuhan ke dalam pengembangan perangkat lunak perusahaan.

Anda telah menghabiskan hampir dua dekade di DataArt, naik dari arsitek perangkat lunak dan arsitek solusi menjadi Chief Innovation Officer dan kini CTO. Bagaimana perjalanan itu membentuk cara Anda membedakan teknologi yang benar‑benar transformatif dari siklus hype, dan bagaimana hal itu memengaruhi \”skeptical optimism\” Anda terhadap AI saat ini?

Kami telah menyaksikan banyak gelombang berbeda selama bertahun‑tahun, termasuk kebangkitan cloud dan mobile, generasi‑generasi AI yang berbeda, otomatisasi, DevOps, dan SRE, dan saya telah melakukan pemrograman, perancangan arsitektur, serta memberi nasihat kepada klien kami tentang banyak topik ini sepanjang waktu. Apa yang saya sadari adalah bahwa, ya, Anda dapat melakukan hampir apa saja dengan teknologi, dan teknologi memang sangat kuat, tetapi tantangannya terletak pada detailnya dan Anda harus memahami apa yang Anda lakukan agar semuanya masuk akal dan berfungsi.

Saya telah melihat lingkungan cloud menjadi semakin mahal, model AI yang tidak berperformasi seperti yang Anda harapkan, serta upaya otomatisasi siklus rilis yang diimplementasikan dengan buruk. Saya telah menyaksikan dampak dari keputusan yang baik maupun yang buruk, jadi setiap kali sesuatu yang baru muncul dan Anda membaca semua pengumuman, janji, serta hype, saya kembali ke premis yang sama: hampir segala hal mungkin dengan teknologi, tetapi Anda perlu mengetahui apa yang Anda lakukan.

Anda memperoleh pemahaman yang baik tentang suatu teknologi melalui R&D dan, yang lebih penting, melalui proyek nyata, karena itulah cara Anda belajar apa yang mungkin, apa yang tidak, dan di mana hal‑hal dapat berjalan salah. Anda mengambil pelajaran tersebut dari setiap keterlibatan, berbicara dengan rekan‑rekan, arsitek lain, dan analis, serta berusaha memahami apakah ada pola dan apakah Anda dapat menciptakan semacam sistem di sekitarnya. Pada akhirnya, hal itu menjadi panduan, dan kemudian Anda melihat apakah keputusan yang Anda anggap baik benar‑benar menghasilkan hasil yang baik.

Itulah asal mula skeptical optimism. Apapun janji teknologi, Anda tetap harus mengetahui apa yang Anda lakukan, dan pengetahuan itu berasal dari pengalaman, kolaborasi, serta upaya berkelanjutan untuk belajar, menjadi lebih baik, dan menciptakan semacam sistem di balik hype.

Enterprise AI tampaknya beralih dari fase mendorong eksperimen ke fase menentukan eksperimen mana yang benar‑benar layak untuk di‑scale. Sinyal apa yang memberi tahu Anda bahwa suatu kasus penggunaan AI siap untuk diterapkan secara lebih luas, dan apa saja tanda peringatan bahwa sebuah perusahaan sedang melakukan scaling terlalu dini?

Saya menggunakan dua metode untuk memahami apakah kami dapat menskalakan sesuatu atau apakah kami perlu melakukan hal lain: kurva adopsi dan kurva pembelajaran.

Untuk memahami apakah sebuah kasus penggunaan AI berfungsi, Anda perlu memberikannya waktu dan memahami nilai apa yang dibawanya serta bagaimana perjalanan penggunaannya, karena dengan begitu Anda dapat melihat naik‑turunnya alih‑alih hanya efek ‘wow’ yang langsung pada tim atau alur kerja tertentu. Anda harus melihat apa yang terjadi pada orang‑orang yang sama beberapa minggu kemudian. Apakah mereka masih menggunakannya? Apakah mereka masih puas dengan kasus penggunaan tersebut, otomatisasi itu, atau kemampuan AI yang mereka ciptakan, atau itu hanya sebuah kilatan singkat yang sebenarnya tidak layak untuk di‑scale?

Beberapa hal ini hanya dapat divalidasi seiring waktu. Akan selalu ada pionir pertama, biasanya orang yang paling cakap secara teknis dan yang sangat penasaran, kemudian Anda harus mencobanya dengan segmen lain, dengan mereka yang mengikuti para adopter awal dan kemudian mayoritas awal. Setelah terbukti di sana, ya, Anda dapat mulai memperluasnya dan memperluas kasus penggunaan tersebut ke departemen lain.

Setiap rilis model utama dapat menimbulkan tekanan dalam organisasi untuk segera memberikan karyawan akses ke kemampuan terbaru. Bagaimana pemimpin teknologi harus mengevaluasi apakah model baru merupakan peningkatan yang berarti daripada sekadar menghasilkan gelombang eksperimen dan biaya lainnya?

Berikut lagi optimisme skeptis saya. Anggaplah Anda sudah memiliki sebuah model dan beberapa ribu orang menggunakan AI setiap hari, dengan berbagai model dan alat yang sudah tersedia. Ketika sebuah model baru diluncurkan, karena hype dan rasa ingin tahu alami, Anda dapat mengharapkan semua orang ingin bereksperimen dengannya, yang memang baik, tetapi eksperimen tersebut belum tentu dipandu atau diarahkan pada hasil tertentu, dan terkadang Anda bahkan tidak dapat mengukur perbedaannya.

Pada skala besar, hal itu penting. Bukan hanya satu atau dua orang yang mengutak-atik untuk melihat bagaimana model baru berperforma dibandingkan yang lama. Bisa jadi ribuan orang menghabiskan waktu bereksperimen, padahal untuk kasus penggunaan tertentu, hasilnya mungkin tidak begitu signifikan. Pada saat yang sama, jika sesuatu memang bekerja sangat baik, pembelajaran tentang apa yang berhasil dalam organisasi Anda mungkin tidak dijelaskan dengan jelas atau terlihat oleh semua orang.

Itulah mengapa kelompok pertama yang mengevaluasi model baru tidak boleh mencakup seluruh organisasi. Harusnya berupa tim R&D yang bekerja erat dengan tim terkait, serta bagian hukum dan keamanan. Kami mengevaluasi model secara menyeluruh, melakukan penilaian cepat, kemudian menyampaikannya ke audiens yang lebih luas dengan beberapa komentar dan panduan mengenai keamanan, kepatuhan, dan teknologi. Dengan model baru dan pembaruan besar yang terus datang, Anda perlu memiliki model dan pola pikir ini. Ini memang bukan latihan satu kali atau sesekali.

DataArt telah membentuk “AI SWAT” lintas fungsi yang melibatkan teknologi, hukum, kepatuhan, InfoSec, dan tim lainnya. Bagaimana kelompok ini beroperasi dalam praktik, dan jenis risiko atau pertanyaan apa yang perlu diselesaikan sebelum sebuah alat AI baru disetujui untuk penggunaan yang lebih luas?

Sejak dibentuk, saya rasa kami telah menetapkan tujuan yang berbeda untuk kelompok ini kira-kira setiap empat atau lima bulan. Kami mengubah prioritas, tujuan, dan kadang misi, dan banyak dari tujuan ini berkaitan dengan AI. Bisa berupa peningkatan keterampilan tenaga kerja, strategi go-to-market dan kemampuan baru, kemitraan, atau memperluas penerapan AI secara lebih luas di dalam organisasi dan di seluruh ADLC.

Topik-topik spesifik berkembang seiring waktu, dan saya rasa itu sehat karena Anda harus terus meninjau kembali strategi Anda, memvalidasi asumsi, dan memahami apakah perlu beralih arah serta apa tema berikutnya untuk tim.

Kelompok ini melibatkan perwakilan dari berbagai departemen, dan salah satu tujuannya hanyalah menjaga semua orang tetap terinformasi. Setiap kali ada pengumuman, pertanyaan, atau peluang baru, seseorang dapat mengangkat topik tersebut dalam salah satu pertemuan rutin kami. Bahkan jika tampak seperti pertanyaan teknologi yang relevan hanya untuk tim kecil, kini topik tersebut dapat memiliki implikasi bagi banyak bagian organisasi.

Itulah mengapa, ketika kami mengevaluasi kemitraan, alat, atau akselerator baru, kami membahasnya secara terbuka agar semua orang memahami arah perkembangan dan memiliki kesempatan untuk mengajukan pertanyaan atau memberikan pengawasan. Untuk alat AI baru, teknologi tidak dapat menilainya secara terpisah. Keamanan, hukum, dan kepatuhan juga perlu memahami bagaimana alat tersebut menangani data perusahaan atau klien, batasan apa yang berlaku, dan apakah dapat digunakan secara aman pada skala besar.

Terkadang tim AI SWAT juga mengerjakan program khusus, seperti peningkatan keterampilan, di mana kami menetapkan target, menyusun peta jalan, dan memutuskan bagaimana kelompok yang berbeda akan diintegrasikan. Begitulah cara kerjanya: menjaga orang tetap terinformasi, bekerja bersama pada program khusus, dan memberikan visibilitas kepada dewan tentang apa yang terjadi dengan AI di seluruh perusahaan.

Anda melihat sikap yang sangat berbeda terhadap pengembangan perangkat lunak yang dibantu AI, dengan beberapa organisasi secara aktif memperluas pengembangan agenik sementara yang lain masih melarang kode yang dihasilkan AI. Apa yang menjelaskan perbedaan ini, dan apa yang perlu diubah sebelum lebih banyak perusahaan yang berhati-hati terhadap risiko merasa nyaman dengan AI yang memainkan peran lebih besar dalam rekayasa perangkat lunak?

Mungkin yang menjadi penyebab perbedaan antara yang mengatakan tidak dan yang mengatakan ya adalah selera risiko mereka serta sikap mereka terhadap ambiguitas dan ketidakpastian. Apa yang membantu kedua jenis organisasi tersebut adalah pendidikan, eksperimen, dan evaluasi yang berkelanjutan. Bahkan di antara banyak organisasi yang kami kerja sama yang mengadopsi AI dan mengintegrasikannya di mana-mana, masih ada tantangan dalam mengukur hasil dan dampaknya. Sejujurnya, pertanyaan tentang bagaimana mengukur dampak AI dan bagaimana mengevaluasi kinerja tim kadang muncul begitu saja, seolah-olah tidak ada yang pernah memikirkannya sebelumnya.

Setelah Anda mulai mengevaluasi inisiatif AI secara lebih komprehensif, Anda mulai memahami dampak dan nilai yang sebenarnya diberikan, yang mengarah pada keputusan yang lebih baik tentang di mana teknologi tersebut masuk akal. Bagi perusahaan yang menolak AI, masih diperlukan proses berkelanjutan untuk meninjau apa yang dapat dilakukan teknologi dan di mana posisinya saat ini. Anda tidak ingin keputusan yang dibuat tiga tahun lalu tetap menjadi kebijakan perusahaan hanya karena tidak ada yang meninjau kembali asumsi-asumsinya.

Agentic AI semakin memudahkan tim‑tim individu untuk membuat agen mereka sendiri, yang berpotensi menghasilkan banyak agen yang melakukan tugas hampir identik. Pada titik mana eksperimen menjadi penyebaran agen, dan jenis lapisan tata kelola apa yang diperlukan untuk mengelola kepemilikan, izin, duplikasi, serta manajemen siklus hidup?

Ketika kami melihat skenario tipikal di mana lisensi AI diberikan kepada setiap pengembang dan eksperimen menjadi tidak terarah, semua orang mulai membuat hal mereka sendiri dan bekerja dengan cara masing‑masing. Biasanya, hal ini menyebabkan tim yang berkinerja rendah, harapan yang tidak terpenuhi, kualitas yang menurun, dan biaya yang meningkat. Intinya, AI tidak melakukan apa yang diharapkan semua orang, kualitasnya buruk, dan menjadi mahal. Untuk mengatasinya, diperlukan upaya tim yang menjadi bagian dari upaya departemen atau organisasi yang lebih luas, dan di sinilah tata kelola berperan.

Pada tingkat proyek, Anda dapat menyepakati basis pengetahuan dan konteks, serta kasus penggunaan di mana Anda mulai menggunakan AI. Kemudian Anda membuat keterampilan dan agen yang menjadi bagian dari alur kerja pengembangan dan dapat digunakan kembali oleh semua orang, sehingga Anda mengakumulasi pengetahuan dan praktik terbaik alih‑alih harus membuatnya kembali setiap kali. Upaya pada tingkat proyek tersebut kemudian harus diatur oleh sesuatu seperti dewan arsitektur perusahaan, grup teknologi, CTO, atau tim yang bertanggung jawab atas adopsi AI. Anda ingin menggunakan kembali agen yang berfungsi baik, memastikan prosesnya solid, dan membuatnya bekerja di seluruh organisasi alih‑alih menjadi kekacauan dan kebisingan.

Jadi saya rasa harus ada upaya yang sinkron pada tingkat proyek, mungkin tingkat program, dan kemudian juga pada tingkat departemen serta organisasi.

Konsumsi token dan biaya inferensi dapat tampak relatif kecil selama pilot, tetapi menjadi signifikan ketika sistem AI diterapkan pada ribuan karyawan atau agen otonom. Bagaimana perusahaan seharusnya memikirkan manajemen biaya AI, dan apakah Anda mengharapkan sesuatu yang mirip FinOps muncul khusus untuk beban kerja AI?

Saya akan memulai dengan mengatakan bahwa skenario hampir ideal adalah ketika biaya AI naik, mencapai plateau, dan kemudian mulai menurun sedikit seiring waktu. Itu menunjukkan bahwa Anda dapat meramalkan, mengendalikan biaya, memahami apa yang sebenarnya Anda belanjakan untuk AI, dan melihat hasil dari keputusan yang Anda buat. Situasi buruk terjadi ketika biaya terus naik turun karena biasanya berarti sesuatu tidak berkelanjutan, atau ketika biaya naik lalu turun secara drastis karena adopsi mungkin tidak terjadi, ada yang tidak berfungsi, atau orang menggunakan sesuatu yang lain dan Anda tidak menyadarinya.

Jadi FinOps memang ada, dan AI FinOps juga ada. Beberapa teknik sangat teknis, sementara yang lain cukup sederhana. Bisa sesederhana memilih model yang diutamakan sehingga Anda tidak selalu bergantung pada yang paling mahal, dan keputusan‑keputusan itu secara bertahap mulai menghemat uang. Pada saat yang sama, mengetahui cara menghemat dan mengendalikan biaya hanyalah setengah dari persamaan. FinOps, menurut saya, adalah disiplin dan metodologi yang juga melibatkan pemimpin produk dan bisnis karena Anda perlu menentukan apa yang diukur saat mengevaluasi upaya AI.

Jadi ya, saya pikir AI FinOps adalah topik yang baik untuk tim setara AI SWAT guna dibahas: berapa banyak yang Anda belanjakan, berapa banyak yang Anda dapatkan kembali, bagaimana Anda mengendalikannya, dan di mana peluangnya.

Banyak perusahaan diminta untuk menunjukkan ROI dari AI meskipun mereka belum pernah menetapkan baseline yang dapat diandalkan tentang seberapa produktif tim mereka sebelum AI diperkenalkan. Apa yang sebenarnya harus diukur organisasi jika ingin menentukan apakah AI menciptakan nilai bisnis yang berarti?

Terlepas dari sikap Anda terhadap AI atau posisi Anda saat ini, mungkin Anda sudah menggunakan agen di mana‑mana atau mungkin Anda berpikir bahwa tahun depan Anda akan mulai menggunakan AI, menetapkan baseline kini menjadi hal yang mutlak diperlukan.

Ada beberapa kelas metrik. Beberapa bersifat subjektif, dan itu bisa berupa umpan balik dari pengembang atau karyawan Anda karena Anda bekerja dengan orang dan penting untuk memahami bagaimana mereka memandang nilai AI. Ukuran yang lebih objektif dapat dimulai dengan metrik mekanis atau sintetis, meskipun saya menyarankan agar semua orang tidak terlalu terikat padanya. Maksudnya hal‑hal seperti commit kode atau story point. Metrik‑metrik ini menunjukkan bahwa pekerjaan terjadi, tetapi mereka tidak benar‑benar menunjukkan nilai atau dampaknya.

Yang membuat perbedaan lebih besar adalah metrik yang menjelaskan seberapa cepat atau seberapa baik pekerjaan diselesaikan. Pikirkan metrik DORA seperti lead time atau MTTR, seberapa cepat Anda dapat pulih dari kegagalan, seberapa cepat Anda dapat memperbaiki bug di produksi, atau bagaimana ukuran-ukuran tersebut berubah seiring waktu. Sebuah angka pada satu titik tidak memberi tahu Anda lintasannya. Salah satu arsitek kami baru-baru ini menyebutkan bahwa, dalam pengembangan perangkat lunak, metrik yang baik juga bisa berupa seberapa andal perkiraan ketika adopsi AI meningkat, karena hal itu menunjukkan sesuatu tentang keberlanjutan upaya ini dan seberapa produktif tim sebenarnya. Anda juga perlu melacak biaya karena jika Anda hanya membicarakan manfaat tanpa memahami apa biaya untuk mencapainya, Anda tidak memiliki gambaran lengkap.

Di luar pengembangan perangkat lunak, saya memikirkannya dengan cara yang serupa. Dalam setiap alur kerja atau proses, ada unit kerja tertentu dan definisi selesai tertentu. Baik Anda sedang memproses klaim, meninjau dokumen, atau menangani permintaan pelanggan, tentukan apa yang Anda berikan dan kemudian ukur berapa lama waktu yang dibutuhkan sebelum AI, seberapa cepat dan seberapa baik Anda dapat melakukannya sekarang, serta berapa biayanya. Itu memberi Anda titik awal yang baik untuk baik baseline maupun kerangka metrik.

DataArt telah menyematkan AI di seluruh siklus hidup pengiriman perangkat lunak melalui inisiatif seperti Artisyn. Karena AI mengambil alih lebih banyak tugas implementasi, pengujian, dan alur kerja, bagian mana dari rekayasa perangkat lunak yang menjadi lebih berharga bagi manusia, dan keterampilan apa yang berisiko menjadi kurang penting?

Anda hanya dapat menggunakan AI secara efektif dalam pengembangan jika Anda masih ingat apa definisi dari baik. Anda memerlukan keahlian itu untuk membimbing agen Anda, meninjau hasil, menetapkan batasan, dan mendefinisikan aturan. Anda perlu memahami apa praktik terbaik dan seperti apa arsitektur yang baik karena, tanpa itu, Anda mungkin tidak tahu apa yang sedang dikembangkan, dan nilai keahlian semacam ini meningkat sangat, sangat signifikan.

Memahami pola arsitektur penting, begitu pula memahami apa yang tepat dalam industri, aplikasi, atau kelas solusi tertentu. Anda perlu mengetahui jenis arsitektur apa yang baik saat ini dan jenis apa yang akan tetap baik ketika solusi tersebut skalanya meningkat, karena terkadang arsitektur yang sama tidak berfungsi sepanjang masa hidup solusi atau platform.

Keseimbangan antara apa yang tepat untuk solusi tertentu adalah bagian manusia. Ini adalah selera, keahlian di balik layanan dan pengembangan perangkat lunak. Anda harus tahu apa yang Anda lakukan, dan itu juga berasal dari pemahaman tentang klien dan industri.

Keterampilan mana yang kurang penting? Sangat sulit bagi saya untuk mengatakan hal itu, meskipun mungkin seberapa cepat Anda dapat mengetik kode. Saya bercanda, tetapi kode kini dapat dibuat jauh, jauh lebih cepat, dan pengetahuan khusus tentang perpustakaan atau bahasa tertentu juga dapat dipelajari jauh lebih cepat dengan AI.

Saya telah melihat pengembang .NET dilatih kembali menjadi pengembang Java dengan sangat cepat, dan lima atau sepuluh tahun yang lalu saya akan mengatakan bahwa melakukannya dalam skala besar hampir tidak mungkin. Saat ini, Anda bisa. Seorang pengembang senior yang kuat dapat semakin berpindah antar bahasa karena yang benar-benar penting adalah pemahaman mereka tentang teknologi, arsitektur, praktik terbaik solusi, SDLC, dan ADLC.

Ketika perusahaan beralih dari puluhan pilot AI ke sistem produksi yang dapat mengambil tindakan secara mandiri, di mana seharusnya akuntabilitas pada akhirnya ditempatkan ketika sebuah agen AI membuat kesalahan yang mahal: pada pengembang, pemilik bisnis, penyedia model, tim tata kelola, atau kombinasi di antara mereka?

Saya menyukai gagasan kolaborasi tanpa menyalahkan dan tanggung jawab bersama karena setiap orang dalam organisasi berkontribusi pada praktik terbaik, kerangka kerja arsitektur, dan solusi. Bahkan jika satu pengembang membuat kode dengan AI atau tanpa AI, pengembang lain meninjaunya, pemimpin tim memberikan panduan, arsitek menyediakan arsitektur dan batasan, dan tim tata kelola berkontribusi pada keputusan tentang anggaran, jadwal, dan rilis. Semua orang terlibat dalam cara tertentu.

Seringkali, ketika sesuatu berjalan salah, proses yang tidak berfungsi, jadi dalam arti itu akuntabilitas dibagi di antara berbagai peran. Namun jika Anda hanya mengatakan akuntabilitas dibagi dan oleh karena itu tanpa menyalahkan, itu tidak cukup. Masih perlu diuraikan menjadi tanggung jawab spesifik.

Pengembang bertanggung jawab atas kode yang mereka kirimkan sebagai pull request, dan mereka perlu memahami apa yang terjadi di sana. Arsitek bertanggung jawab atas keputusan yang mereka buat dan atas keputusan arsitektural yang diberikan kepada agen dan pengembang. Tim platform bertanggung jawab atas keandalan solusi terlepas dari siapa atau apa yang membuat baris kode tertentu.

Jadi akuntabilitas ada, tetapi Anda perlu mendefinisikannya secara terperinci berdasarkan tim, peran, dan departemen. Apa yang tidak dapat Anda lakukan adalah menghentikan analisis pada “AI yang melakukan ini.” Anda harus menanyakan kontrol, pengujian, atau pengawasan apa yang memungkinkan kegagalan tersebut mencapai produksi.

Jika kurangnya unit test memungkinkan kode buruk dipush ke produksi, atau kurangnya pengawasan dan tinjauan memungkinkan hal itu terjadi, Anda tidak dapat menyerahkan akuntabilitas itu kepada AI. Anda juga tidak dapat sekadar menyalahkan penyedia model atau penyedia cloud untuk setiap bug atau gangguan.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin belajar lebih lanjut harus mengunjungi DataArt.