Juan E. Riojas, Direktur Informasi di Bland – Seri Wawancara

Juan E. Riojas, Direktur Informasi di Bland, adalah eksekutif teknologi dan data berpengalaman dengan karier yang mencakup teknologi informasi perusahaan, pengelolaan data, analitik, operasional, dan transformasi digital. Sebelum bergabung dengan Bland pada Desember 2025, ia menjabat sebagai Direktur Informasi di Twilio dan Rackspace Technology, setelah sebelumnya memegang posisi kepemimpinan sebagai Direktur Data di Informatica dan Wakil Presiden Pengelolaan Data dan Analitik di Gogo. Pengalamannya juga mencakup posisi senior di bidang operasional dan manajemen di Dell, Accenture, Expeditors International, OfficeMax, dan AxonGroup, yang memberinya pengalaman luas dalam mengelola inisiatif teknologi dan data di organisasi berskala besar.

Bland adalah perusahaan AI suara untuk bisnis yang mengembangkan agen AI untuk menangani percakapan telepon masuk dan keluar, dukungan pelanggan, penjadwalan, penerimaan, perutean, serta alur kerja kompleks lainnya. Platformnya mengutamakan kendali atas tumpukan teknologi yang mendasarinya. Bland mengembangkan dan mengoperasikan model suara, bahasa, dan ucapannya sendiri, sekaligus mendukung penerapan melalui Bland Cloud, cloud privat virtual, atau lingkungan perusahaan yang sepenuhnya dikelola sendiri dan terisolasi dari jaringan luar. Perusahaan ini secara khusus berfokus pada penggunaan yang diatur dan sensitif terhadap keamanan, dengan menyediakan fitur seperti alur percakapan, integrasi dengan sistem telepon yang sudah ada, pengaturan retensi data, kontrol akses berbasis peran, serta kemampuan untuk memenuhi persyaratan kepatuhan perusahaan.

Anda pernah menjabat sebagai Direktur Informasi di Twilio dan Rackspace, menjadi Direktur Data di Informatica, serta menghabiskan sebagian besar karier Anda menangani infrastruktur komunikasi dan data perusahaan. Apa yang Anda pelajari dari pengalaman tersebut tentang hambatan yang dihadapi perusahaan dalam menerapkan AI, dan bagaimana pengalaman itu membentuk platform yang kini Anda kembangkan di Bland agar dapat dikelola sendiri?

Pengalaman saya di Twilio, Rackspace, dan Informatica mengajarkan bahwa hambatan terbesar bagi AI di perusahaan bukanlah teknologinya—melainkan kepercayaan, kendali, dan kemampuan untuk beroperasi dengan aman dalam skala besar. Perusahaan perlu tahu di mana data mereka tersimpan, siapa yang mengendalikannya, dan apakah AI dapat digunakan dalam kerangka keamanan dan tata kelola yang telah mereka bangun selama bertahun-tahun. Hal itulah yang membentuk pendekatan kami di Bland: menyediakan platform yang dikelola sendiri oleh perusahaan dan menghadirkan kemampuan AI tanpa memaksa mereka melepaskan kendali atas infrastruktur atau data mereka.

Bland adalah satu-satunya platform AI suara yang dikelola sendiri, yang berarti Anda memiliki setiap lapisan orkestrasi AI: konversi ucapan menjadi teks, inferensi LLM, dan konversi teks menjadi ucapan. Mengapa Bland memilih pendekatan ini, dan apa tantangan teknis tersulit dalam mengelola seluruh tumpukan AI suara secara mandiri?

Kami memilih untuk mengelola sendiri dan memiliki setiap lapisan, mulai dari pengenalan ucapan otomatis (ASR), penalaran model bahasa besar (LLM), hingga konversi teks menjadi ucapan (TTS), karena tiga alasan: latensi percakapan di bawah 1 detik, batas privasi data yang ketat, dan keandalan operasional yang tinggi.

Ketika Anda merangkai berbagai vendor eksternal yang berbeda, penundaannya akan menumpuk. Perpindahan jaringan bolak-balik, penundaan antrean yang terpisah, dan proses awal yang dingin menambah jeda. Akibatnya, muncul jeda yang terasa tidak alami dan mengganggu kelancaran percakapan.

Dengan menempatkan model-model kami bersama dalam satu lingkungan waktu proses terpadu dan menghapus ketergantungan pada API pihak ketiga, kami menghilangkan perpindahan tersebut. Pendekatan ini juga memberi kami kedaulatan penuh atas data, sehingga aliran suara dan transkrip sensitif tidak pernah bocor ke penyedia model mutakhir eksternal.

Tantangan teknis tersulit berkaitan dengan orkestrasi latensi, sinkronisasi aliran data, dan penjadwalan GPU dengan konkurensi tinggi. Interaksi suara dua arah secara waktu nyata memerlukan pembuatan token secara streaming yang lancar. Mesin TTS harus mulai menyintesis audio bahkan sebelum LLM selesai menghasilkan kalimat.

Agar hal itu dapat dilakukan, kami membangun mesin inferensi khusus, alur pemrosesan dekode spekulatif berlatensi rendah, dan adaptasi model akustik. Secara bersama-sama, semua itu mencegah suara tersendat, mengelola pergiliran bicara, dan menangani interupsi pengguna dengan baik, tanpa membuat memori GPU jenuh.

Banyak platform AI suara menggabungkan transkripsi, penalaran, dan pembuatan ucapan dari berbagai penyedia pihak ketiga. Apa keuntungan dan kompromi teknis yang timbul ketika Bland memiliki dan mengoperasikan lebih banyak bagian dari tumpukan tersebut secara mandiri?

Keuntungan terbesarnya adalah kendali atas latensi dari awal hingga akhir. Tidak ada beban tambahan jaringan antara ASR, LLM, dan TTS, sehingga kami dapat menjalankan alur streaming terpadu, melakukan optimasi lintas lapisan, dan mengendalikan waktu hingga byte pertama dikirim dengan ketat. Tingkat kendali seperti itu tidak mungkin diperoleh jika setiap komponen berasal dari vendor yang berbeda.

Keuntungan kedua adalah adanya batas keamanan dan kepatuhan yang terpadu. Data tidak pernah meninggalkan lingkungan yang kami kendalikan, sehingga audio dan transkrip pelanggan tetap berada dalam perimeter yang telah kami verifikasi. Hal ini menghilangkan risiko subpemroses pihak ketiga dan sangat menyederhanakan kepatuhan terhadap HIPAA, SOC 2, dan PCI DSS. Siapa pun yang pernah menjalani peninjauan keamanan vendor pasti tahu betapa pentingnya hal itu.

Keuntungan ketiga adalah biaya yang lebih mudah diprediksi. Kami tidak membayar markup per token atau per menit untuk API model fondasi eksternal, sehingga keekonomian unit kami tetap dapat diprediksi dalam skala perusahaan. Selain itu, karena model-model tersebut milik kami, kami dapat langsung menyempurnakan akustik, prosodi, dan bobot penalaran yang disesuaikan dengan tugas tertentu.

Namun, semua itu tentu ada biayanya. Pendekatan ini membutuhkan infrastruktur dan investasi besar untuk GPU. Mengelola armada besar GPU khusus memerlukan penjadwalan, orkestrasi, dan mekanisme failover multiwilayah yang canggih, sementara biaya perangkat kerasnya tinggi.

Kami juga menanggung sendiri beban pemeliharaan dan spesialisasi model. Kami tidak bisa menyerahkan riset mutakhir kepada vendor eksternal. Sebaliknya, kami menangani sendiri pekerjaan rekayasa berkelanjutan untuk melatih, mengevaluasi, dan memelihara model internal dalam menghadapi beragam aksen, kondisi kebisingan latar, dan bahasa.

Bagi kami, kompromi itu sepadan.

Bland memperoleh sertifikasi FedRAMP 20x Class A pada Agustus dan menyatakan bahwa platform tersebut merupakan platform AI suara pertama yang memilikinya. Kebanyakan pembaca mungkin tidak mengetahui perbedaan 20x dengan FedRAMP lama. Apa itu Class A, dan apa saja yang harus Anda buktikan untuk mendapatkannya?

FedRAMP 20x adalah kerangka kerja modern berbasis cloud yang diperkenalkan berdasarkan FedRAMP Consolidated Rules for 2026 (CR26). Proses lama mengelompokkan semuanya ke dalam tingkat dampak FIPS 199 (Low, Moderate, dan High) dan terkenal sarat dokumen. 20x menggantinya dengan kelas sertifikasi berhuruf: A, B, C, dan D.

Class A adalah tingkat pemula. Kelas ini dirancang khusus bagi penyedia layanan cloud komersial (CSP) yang sudah memiliki program keamanan matang dan ingin memasuki pasar federal. Anggap saja ini sebagai jalur masuk, bukan tujuan akhir. Anda memperoleh Sertifikasi Program yang diakui dan diterbitkan langsung oleh FedRAMP Program Management Office (PMO), lalu memiliki waktu 2 tahun untuk beralih ke Class B, C, atau D.

Untuk mendapatkannya, kami harus membuktikan empat hal. Pertama, audit SOC 2 Type II terkini dan terverifikasi yang mencakup prinsip-prinsip inti keamanan, kerahasiaan, dan ketersediaan. Kedua, batas layanan cloud federal yang didefinisikan dengan jelas dan diisolasi secara logis, yang mencakup layanan suara, SMS, dan obrolan kami.

Ketiga, penerapan dasar Key Security Indicators (KSI) wajib FedRAMP 20x, beserta kesiapan untuk pemantauan berkelanjutan. Cakupannya meliputi pemindaian kerentanan, prosedur tanggap insiden, penegakan kontrol akses, dan pelaporan keamanan berkelanjutan yang dapat dibaca mesin.

Hal keempat menunjukkan betapa besar manfaatnya karena kami memiliki kendali atas seluruh tumpukan teknologi. Kami harus memverifikasi bahwa semua proses transkripsi, penalaran, dan sintesis ucapan berjalan sepenuhnya di dalam batas kontainer Bland yang diotorisasi, tanpa mengirimkan data federal kepada penyedia AI mutakhir pihak ketiga yang belum diperiksa. Bagi platform yang dirangkai dari layanan vendor eksternal, persyaratan ini sangat sulit dipenuhi.

Bland mendukung berbagai model penerapan, mulai dari VPC cloud privat hingga infrastruktur GPU khusus di lokasi. Bagaimana arsitekturnya berubah saat beralih di antara model-model penerapan tersebut, terutama dalam hal latensi, penskalaan, dan kebutuhan infrastruktur?

Singkatnya, semakin dekat penerapan ke lingkungan di lokasi, semakin besar keuntungan dari segi latensi dan kendali, tetapi semakin berkurang pula elastisitasnya.

Mulai dari latensi. Penerapan di lokasi dan VPC khusus sama-sama meminimalkan lalu lintas jaringan eksternal karena letaknya sangat dekat dengan trunk telepon internal dan gateway SIP perusahaan. Di VPC cloud privat, misalnya di AWS atau GCP, latensi ditentukan oleh jaringan dalam wilayah dan koneksi antarcloud. Perangkat keras bare-metal khusus di lokasi memberikan peningkatan lebih jauh. Perangkat ini sepenuhnya menghilangkan lapisan virtualisasi hipervisor dan perutean melalui internet publik sehingga menghasilkan jitter akustik serendah mungkin.

Kompromi terlihat jelas dalam hal penskalaan. Di VPC cloud, kami melakukan penskalaan horizontal menggunakan orkestrasi elastis, seperti klaster Kubernetes yang menyesuaikan skala secara otomatis dengan dukungan instans GPU cloud, sehingga kapasitas dapat berubah secara dinamis saat jumlah panggilan melonjak. Penerapan di lokasi tidak bekerja seperti itu. Kapasitas GPU fisik yang tersedia menjadi batas tetap, sehingga diperlukan kontrol penerimaan yang ketat, kebijakan antrean, dan penyediaan perangkat keras statis berdasarkan volume panggilan serentak saat mencapai puncaknya. Anda harus merencanakan kebutuhan sejak awal untuk mengantisipasi hari tersibuk.

Kebutuhan infrastrukturnya juga cukup berbeda. Penerapan VPC privat dapat mengandalkan penyimpanan cloud terkelola, IAM bawaan, dan pengelolaan rahasia oleh layanan cloud. Instalasi di lokasi memerlukan klaster GPU khusus yang dipasang di rak (misalnya akselerator kelas perusahaan NVIDIA), jaringan lokal berkapasitas tinggi, modul keamanan perangkat keras (HSM) atau brankas kunci lokal, serta pengumpul telemetri lokal. Semuanya harus berjalan pada lingkungan operasi kontainer perusahaan yang dapat beroperasi sepenuhnya tanpa koneksi eksternal atau dengan akses keluar yang dibatasi.

Bland memungkinkan perusahaan mengendalikan rilis, memelihara lingkungan pengujian terpisah, dan menguji versi baru pada sebagian panggilan nyata sebelum meluncurkannya secara lebih luas. Mengapa praktik rilis perangkat lunak tradisional menjadi sangat penting ketika agen AI mulai digunakan dalam lingkungan produksi yang berhadapan langsung dengan pelanggan?

Alasannya, perilaku agen AI tidak seperti perangkat lunak perusahaan tradisional.

Perangkat lunak deterministik melakukan hal yang sama setiap kali dijalankan. Agen AI generatif bersifat probabilistik dan nondeterministik. Perubahan kecil pada prompt, pembaruan bobot model, atau perubahan alur dapat tanpa sengaja menyebabkan kemunduran dalam percakapan, halusinasi, atau pelanggaran kebijakan kepatuhan. Sering kali, tidak ada tanda dari perubahan itu sendiri bahwa hal tersebut akan terjadi.

Itulah sebabnya disiplin peluncuran versi lama kini semakin penting, bukan semakin kurang penting. Lingkungan staging yang terisolasi dan pengujian regresi ketat terhadap korpus panggilan historis dapat menemukan banyak masalah sebelum apa pun diluncurkan. Penerapan canary membawa proses ini selangkah lebih jauh. Anda meluncurkan versi baru ke persentase panggilan aktif yang dikendalikan, lalu memantau metrik secara real-time, seperti penurunan sentimen, tingkat pencapaian sasaran, lonjakan latensi, serta pemicu eskalasi atau pengalihan. Semua itu dilakukan sebelum versi tersebut menjangkau basis pelanggan yang lebih luas.

Besarnya risiko membuat hal ini tidak bisa ditawar. Dalam layanan pelanggan, penanganan klaim, atau pengelolaan akun, kegagalan dapat menimbulkan risiko pelanggaran regulasi atau merusak merek secara serius. Penerapan canary yang disiplin dan pemulihan ke versi sebelumnya secara instan adalah cara untuk mencegah pembaruan yang bermasalah berubah menjadi berita buruk.

Bank, organisasi layanan kesehatan, perusahaan asuransi, dan instansi pemerintah sering menghadapi persyaratan yang jauh lebih ketat untuk menerapkan AI generatif dibandingkan bisnis lain. Berdasarkan percakapan Anda dengan organisasi-organisasi ini, apa yang sebenarnya menghambat penerapan AI suara saat ini: keamanan, kedaulatan data, keandalan, kompleksitas integrasi, pengadaan, atau hal lain?

Keamanan dan kedaulatan data, jauh lebih dominan; kompleksitas integrasi dan arsitektur lama berada di urutan kedua, tidak jauh di belakang. Hal ini konsisten dalam percakapan kami dengan sektor perbankan, layanan kesehatan, asuransi, dan pemerintahan.

Dari sisi keamanan, organisasi yang sangat diatur tidak mungkin menerima arsitektur yang memungkinkan aliran audio sensitif, PHI, atau informasi pribadi nonpublik melintasi batas API eksternal atau disimpan oleh penyedia model pihak ketiga untuk pelatihan. Bagi para pembeli ini, kemampuan audit, jaminan tidak ada penyimpanan data, dan batas kepatuhan yang ketat seperti HIPAA, FedRAMP, dan PCI DSS bukan sekadar nilai tambah. Semuanya merupakan prasyarat mendasar. Jika Anda tidak dapat memenuhinya, pembicaraan biasanya berakhir sampai di situ.

Integrasi menjadi kendala berikutnya. Banyak perusahaan besar ini masih menggunakan sistem PBX lama yang dioperasikan di lokasi, IVR yang kompleks, dan sistem pencatatan utama yang terfragmentasi, seperti Epic atau Cerner di sektor layanan kesehatan atau sistem inti berbasis mainframe di perbankan. Menghubungkan alur percakapan dengan akses API dua arah untuk membaca dan menulis secara real-time dengan latensi rendah di seluruh lingkungan tersebut menimbulkan beban integrasi yang signifikan.

Selanjutnya, ada persoalan keandalan dan risiko halusinasi. Tim hukum, manajemen risiko, dan pengadaan wajar merasa khawatir jika agen suara otonom memberikan saran keuangan, medis, atau regulasi yang tidak akurat. Sebelum menyetujui penerapan dalam skala produksi, mereka menginginkan mekanisme pengamanan yang terperinci, mekanisme percakapan cadangan yang deterministik, serta jalur eskalasi yang jelas kepada manusia.

Terima kasih atas wawancara yang luar biasa. Pembaca yang ingin mengetahui lebih lanjut dapat mengunjungi Bland.