Juan E. Riojas ประธานเจ้าหน้าที่ฝ่ายสารสนเทศของ Bland – บทสัมภาษณ์

Juan E. Riojas ประธานเจ้าหน้าที่ฝ่ายสารสนเทศของ Bland เป็นผู้บริหารมากประสบการณ์ด้านเทคโนโลยีและข้อมูล โดยทำงานครอบคลุมทั้งไอทีระดับองค์กร การจัดการข้อมูล การวิเคราะห์ การปฏิบัติการ และการเปลี่ยนผ่านสู่ดิจิทัล ก่อนเข้าร่วมงานกับ Bland ในเดือนธันวาคม 2025 เขาดำรงตำแหน่งประธานเจ้าหน้าที่ฝ่ายสารสนเทศที่ Twilio และ Rackspace Technology หลังจากเคยดำรงตำแหน่งผู้นำในบทบาทประธานเจ้าหน้าที่ฝ่ายข้อมูลที่ Informatica และรองประธานฝ่ายการจัดการและวิเคราะห์ข้อมูลที่ Gogo นอกจากนี้ ประสบการณ์ของเขายังครอบคลุมตำแหน่งระดับสูงด้านปฏิบัติการและการบริหารที่ Dell, Accenture, Expeditors International, OfficeMax และ AxonGroup ทำให้เขามีประสบการณ์กว้างขวางในการบริหารโครงการด้านเทคโนโลยีและข้อมูลในองค์กรขนาดใหญ่

Bland เป็นบริษัท AI ด้านเสียงสำหรับองค์กรที่พัฒนาเอเจนต์ AI ซึ่งสามารถจัดการการสนทนาทางโทรศัพท์ทั้งขาเข้าและขาออก การสนับสนุนลูกค้า การจัดตารางเวลา การรับข้อมูลเบื้องต้น การกำหนดเส้นทาง และเวิร์กโฟลว์ซับซ้อนอื่น ๆ แพลตฟอร์มนี้เน้นการควบคุมเทคโนโลยีพื้นฐาน โดย Bland พัฒนาและดำเนินงานโมเดลเสียง ภาษา และการพูดของตนเอง พร้อมรองรับการติดตั้งใช้งานผ่าน Bland Cloud คลาวด์ส่วนตัวเสมือน หรือสภาพแวดล้อมระดับองค์กรที่โฮสต์ด้วยตนเองทั้งหมดและแยกขาดจากเครือข่ายภายนอก บริษัทมุ่งเน้นเป็นพิเศษกับกรณีใช้งานที่อยู่ภายใต้ข้อกำกับดูแลและมีข้อกำหนดด้านความปลอดภัยสูง โดยมีฟีเจอร์ต่าง ๆ เช่น เส้นทางการสนทนา การเชื่อมต่อกับระบบโทรศัพท์ที่มีอยู่ การกำหนดระยะเวลาเก็บรักษาข้อมูล การควบคุมสิทธิ์ตามบทบาท และความสามารถด้านการปฏิบัติตามข้อกำหนดสำหรับองค์กร

คุณเคยดำรงตำแหน่งประธานเจ้าหน้าที่ฝ่ายสารสนเทศที่ Twilio และ Rackspace เคยเป็นประธานเจ้าหน้าที่ฝ่ายข้อมูลที่ Informatica และใช้เวลาส่วนใหญ่ในอาชีพทำงานเกี่ยวกับโครงสร้างพื้นฐานด้านการสื่อสารและข้อมูลระดับองค์กร ประสบการณ์เหล่านั้นสอนอะไรคุณเกี่ยวกับอุปสรรคที่องค์กรต้องเผชิญเมื่อนำ AI มาใช้ และส่งผลต่อแพลตฟอร์มที่โฮสต์ด้วยตนเองซึ่งคุณกำลังสร้างที่ Bland อย่างไร

ประสบการณ์ที่ Twilio, Rackspace และ Informatica สอนผมว่า อุปสรรคใหญ่ที่สุดของ AI ระดับองค์กรไม่ใช่เทคโนโลยี แต่เป็นความไว้วางใจ การควบคุม และความสามารถในการดำเนินงานอย่างปลอดภัยในวงกว้าง บริษัทต่าง ๆ ต้องรู้ว่าข้อมูลของตนจัดเก็บอยู่ที่ใด ใครเป็นผู้ควบคุม และ AI สามารถทำงานภายใต้กรอบความปลอดภัยและการกำกับดูแลที่พวกเขาใช้เวลาหลายปีสร้างขึ้นได้หรือไม่ สิ่งเหล่านี้หล่อหลอมแนวทางของเราที่ Bland นั่นคือการมอบแพลตฟอร์มที่โฮสต์ด้วยตนเองให้บริษัทต่าง ๆ ซึ่งใช้พลังของ AI ได้โดยไม่ต้องแลกกับการสูญเสียการควบคุมโครงสร้างพื้นฐานหรือข้อมูลของตน

Bland เป็นแพลตฟอร์ม AI ด้านเสียงเพียงแพลตฟอร์มเดียวที่โฮสต์ด้วยตนเอง ซึ่งหมายความว่าคุณเป็นเจ้าของทุกชั้นของการประสานงาน AI ตั้งแต่การแปลงเสียงพูดเป็นข้อความ การประมวลผลของ LLM ไปจนถึงการแปลงข้อความเป็นเสียง เหตุใด Bland จึงเลือกแนวทางนี้ และความท้าทายทางเทคนิคที่ยากที่สุดในการเป็นเจ้าของชุดเทคโนโลยี AI ด้านเสียงทั้งหมดคืออะไร

เราเลือกโฮสต์และเป็นเจ้าของทุกชั้นด้วยตนเอง ตั้งแต่การรู้จำเสียงพูดอัตโนมัติ (ASR) การให้เหตุผลของโมเดลภาษาขนาดใหญ่ (LLM) ไปจนถึงการแปลงข้อความเป็นเสียง (TTS) ด้วยเหตุผลสามประการ ได้แก่ เวลาแฝงในการสนทนาต่ำกว่า 1 วินาที การกำหนดขอบเขตความเป็นส่วนตัวของข้อมูลอย่างเข้มงวด และความน่าเชื่อถือในการปฏิบัติงานระดับสูง

เมื่อเชื่อมต่อผู้ให้บริการภายนอกหลายรายที่ใช้ระบบแตกต่างกัน ความล่าช้าก็จะสะสมเพิ่มขึ้น ทั้งการรับส่งข้อมูลผ่านเครือข่ายไปกลับ ความล่าช้าของคิวที่แยกจากกัน และการเริ่มระบบใหม่หลังไม่มีการใช้งาน ล้วนเพิ่มเวลาเข้าด้วยกัน ผลลัพธ์คือช่วงเงียบที่ฟังดูไม่เป็นธรรมชาติและทำให้การสนทนาสะดุด

การวางโมเดลของเราไว้ร่วมกันในสภาพแวดล้อมการทำงานแบบรวม และตัดการพึ่งพา API ของบุคคลที่สาม ทำให้เราไม่ต้องเสียเวลาไปกับการรับส่งข้อมูลเหล่านั้น นอกจากนี้ เรายังมีอธิปไตยเหนือข้อมูลอย่างเต็มที่ โดยข้อมูลเสียงและบทถอดเสียงที่ละเอียดอ่อนจะไม่รั่วไหลไปยังผู้ให้บริการโมเดล AI แนวหน้าภายนอก

ความท้าทายทางเทคนิคที่ยากที่สุดเกี่ยวข้องกับการประสานงานเพื่อลดเวลาแฝง การซิงโครไนซ์ข้อมูลสตรีมมิง และการจัดตารางการใช้ GPU ที่มีภาระงานพร้อมกันสูง การสื่อสารด้วยเสียงแบบสองทางเรียลไทม์ต้องอาศัยการสร้างโทเค็นแบบสตรีมที่ต่อเนื่องไร้รอยต่อ เครื่องมือ TTS ต้องเริ่มสังเคราะห์เสียงก่อนที่ LLM จะสร้างประโยคเสร็จด้วยซ้ำ

เพื่อให้ทำงานได้เช่นนั้น เราสร้างเอนจินประมวลผลอนุมานแบบเฉพาะ กระบวนการถอดรหัสแบบคาดการณ์ที่มีเวลาแฝงต่ำ และการปรับแต่งโมเดลเสียง องค์ประกอบเหล่านี้ทำงานร่วมกันเพื่อป้องกันเสียงกระตุก จัดการการผลัดกันพูด และรองรับการขัดจังหวะจากผู้ใช้ได้อย่างราบรื่น โดยไม่ทำให้หน่วยความจำ GPU เต็ม

แพลตฟอร์ม AI ด้านเสียงหลายแห่งนำการถอดเสียง การให้เหตุผล และการสร้างเสียงพูดมาประกอบเข้าด้วยกัน โดยใช้ผู้ให้บริการบุคคลที่สามหลายราย การที่ Bland เป็นเจ้าของและดำเนินงานระบบส่วนต่าง ๆ ด้วยตนเองมีข้อดีและข้อแลกเปลี่ยนด้านวิศวกรรมอย่างไร

ข้อได้เปรียบที่สำคัญที่สุดคือการควบคุมเวลาแฝงได้ตั้งแต่ต้นจนจบ ไม่มีค่าใช้จ่ายด้านเครือข่ายระหว่าง ASR, LLM และ TTS เราจึงใช้กระบวนการสตรีมแบบรวม ปรับแต่งการทำงานข้ามชั้น และควบคุมเวลาจนถึงไบต์แรกได้อย่างแม่นยำ คุณจะควบคุมได้ไม่ถึงระดับนี้หากแต่ละส่วนมาจากผู้ให้บริการคนละราย

ข้อดีประการที่สองคือการมีขอบเขตด้านความปลอดภัยและการปฏิบัติตามข้อกำหนดที่เป็นหนึ่งเดียว ข้อมูลจะไม่ออกจากสภาพแวดล้อมที่เราควบคุม เสียงและบทถอดเสียงของลูกค้าจึงอยู่ภายในขอบเขตที่เราตรวจสอบยืนยันแล้ว วิธีนี้ช่วยขจัดความเสี่ยงจากผู้ประมวลผลช่วงต่อของบุคคลที่สาม และทำให้การปฏิบัติตาม HIPAA, SOC 2 และ PCI DSS ง่ายขึ้นมาก ใครก็ตามที่เคยผ่านการตรวจสอบความปลอดภัยของผู้ให้บริการย่อมรู้ดีว่าเรื่องนี้สำคัญเพียงใด

ข้อดีประการที่สามคือการคาดการณ์ต้นทุนได้ เราไม่ต้องจ่ายค่าบวกเพิ่มตามจำนวนโทเค็นหรือต่อนาทีสำหรับ API ของโมเดลพื้นฐานจากภายนอก เศรษฐศาสตร์ต่อหน่วยของเราจึงคาดการณ์ได้เมื่อดำเนินงานในระดับองค์กร และเพราะโมเดลเป็นของเราเอง เราจึงปรับแต่งคุณลักษณะทางเสียง ท่วงทำนองการพูด และค่าน้ำหนักด้านการให้เหตุผลเฉพาะงานได้โดยตรง

อย่างไรก็ตาม สิ่งเหล่านี้ไม่ได้มาโดยไม่มีต้นทุน แนวทางนี้ต้องใช้โครงสร้างพื้นฐานและเงินลงทุนด้าน GPU จำนวนมาก การจัดการ GPU เฉพาะทางจำนวนมากต้องอาศัยการจัดตารางงาน การประสานระบบ และระบบสำรองเมื่อเกิดข้อขัดข้องข้ามหลายภูมิภาคที่ซับซ้อน อีกทั้งยังมีค่าใช้จ่ายด้านฮาร์ดแวร์สูง

เรายังต้องรับภาระดูแลรักษาและปรับแต่งโมเดลให้เหมาะกับงานด้วยตัวเอง เราไม่สามารถโยนภาระการวิจัยเทคโนโลยีแนวหน้าที่สุดให้ผู้ให้บริการภายนอกได้ แต่เราต้องทำงานด้านวิศวกรรมอย่างต่อเนื่อง ทั้งฝึก ประเมิน และดูแลรักษาโมเดลที่พัฒนาขึ้นเอง ให้รองรับสำเนียงที่หลากหลาย สภาพแวดล้อมที่มีเสียงรบกวน และภาษาต่าง ๆ

สำหรับเราแล้ว การแลกเปลี่ยนข้อดีข้อเสียดังกล่าวคุ้มค่า

Bland ได้รับการรับรอง FedRAMP 20x Class A ในเดือนสิงหาคม และระบุว่าเป็นแพลตฟอร์ม AI ด้านเสียงแพลตฟอร์มแรกที่ได้รับการรับรองนี้ ผู้อ่านส่วนใหญ่คงไม่ทราบว่า 20x แตกต่างจาก FedRAMP แบบเดิมอย่างไร Class A คืออะไร และคุณต้องแสดงให้เห็นอะไรบ้างจึงจะได้รับการรับรองนี้

FedRAMP 20x คือกรอบการทำงานสมัยใหม่ที่ออกแบบมาสำหรับคลาวด์โดยเฉพาะ ซึ่งเริ่มใช้ภายใต้กฎรวมของ FedRAMP สำหรับปี 2026 (CR26) กระบวนการแบบเดิมจัดทุกอย่างตามระดับผลกระทบของ FIPS 199 ได้แก่ ต่ำ ปานกลาง และสูง และขึ้นชื่อว่าต้องจัดทำเอกสารจำนวนมาก FedRAMP 20x เปลี่ยนมาใช้ระดับการรับรองที่กำหนดด้วยตัวอักษร ได้แก่ A, B, C และ D

Class A เป็นระดับเริ่มต้น ออกแบบมาโดยเฉพาะสำหรับผู้ให้บริการคลาวด์เชิงพาณิชย์ (CSP) ที่มีโปรแกรมรักษาความปลอดภัย成熟แล้ว และต้องการเข้าสู่ตลาดภาครัฐ ลองนึกภาพว่าเป็นทางเข้าสู่ระบบ ไม่ใช่จุดหมายปลายทางถาวร คุณจะได้รับการรับรองโปรแกรมที่เป็นที่ยอมรับ ซึ่งออกให้โดยสำนักงานบริหารโครงการ FedRAMP (PMO) โดยตรง จากนั้นมีเวลา 2 ปีในการเปลี่ยนไปใช้ Class B, C หรือ D

เพื่อให้ได้รับการรับรอง เราต้องแสดงให้เห็น 4 ข้อ ประการแรก ต้องผ่านการตรวจสอบ SOC 2 Type II ที่เป็นปัจจุบันและได้รับการยืนยัน ครอบคลุมหลักการสำคัญด้านความปลอดภัย การรักษาความลับ และความพร้อมใช้งาน ประการที่สอง ต้องกำหนดขอบเขตบริการคลาวด์ของรัฐบาลกลางให้ชัดเจนและแยกออกจากกันอย่างเป็นระบบ โดยครอบคลุมบริการเสียง SMS และแชตของเรา

ประการที่สาม ต้องดำเนินการตามตัวชี้วัดความปลอดภัยหลัก (KSIs) ที่ FedRAMP 20x กำหนดให้เป็นข้อบังคับในระดับพื้นฐาน พร้อมเตรียมความพร้อมสำหรับการตรวจสอบติดตามอย่างต่อเนื่อง ซึ่งครอบคลุมการสแกนหาช่องโหว่ ขั้นตอนรับมือเหตุการณ์ การบังคับใช้นโยบายควบคุมการเข้าถึง และการรายงานความปลอดภัยอย่างต่อเนื่องในรูปแบบที่เครื่องอ่านได้

ข้อที่สี่คือจุดที่การเป็นเจ้าของเทคโนโลยีทั้งระบบของเราส่งผลอย่างมาก เราต้องตรวจสอบให้แน่ใจว่าการถอดเสียง การให้เหตุผล และการสังเคราะห์เสียงทั้งหมดทำงานอยู่ภายในขอบเขตคอนเทนเนอร์ที่ได้รับอนุญาตของ Bland อย่างเคร่งครัด โดยไม่มีการส่งข้อมูลของรัฐบาลกลางไปยังผู้ให้บริการ AI แนวหน้าจากภายนอกที่ยังไม่ผ่านการตรวจสอบ สำหรับแพลตฟอร์มที่ประกอบขึ้นจากบริการของผู้ให้บริการภายนอกหลายราย การยืนยันเรื่องนี้ให้ผ่านเป็นเรื่องยากมาก

Bland รองรับการติดตั้งใช้งานตั้งแต่ VPC บนคลาวด์ส่วนตัวไปจนถึงโครงสร้างพื้นฐาน GPU ภายในองค์กรแบบเฉพาะ การเปลี่ยนสถาปัตยกรรมเมื่อนำไปใช้กับรูปแบบการติดตั้งใช้งานเหล่านี้เป็นอย่างไร โดยเฉพาะในด้านความหน่วง การปรับขนาด และข้อกำหนดด้านโครงสร้างพื้นฐาน

กล่าวโดยสรุป ยิ่งเข้าใกล้การติดตั้งใช้งานภายในองค์กรมากเท่าไร คุณก็ยิ่งได้ประโยชน์ด้านความหน่วงและการควบคุมมากขึ้น แต่ต้องแลกกับความยืดหยุ่นในการปรับขนาด

เริ่มจากความหน่วง การติดตั้งใช้งานภายในองค์กรและ VPC เฉพาะต่างช่วยลดการรับส่งข้อมูลผ่านเครือข่ายภายนอกให้น้อยที่สุด เพราะอยู่ใกล้กับวงจรโทรศัพท์ภายในและเกตเวย์ SIP ขององค์กร ใน VPC บนคลาวด์ส่วนตัว เช่น บน AWS หรือ GCP ความหน่วงขึ้นอยู่กับการเชื่อมต่อเครือข่ายภายในภูมิภาคและการเชื่อมต่อระหว่างคลาวด์เป็นหลัก ส่วนฮาร์ดแวร์แบบ Bare Metal เฉพาะที่ติดตั้งภายในองค์กรไปได้ไกลกว่านั้น โดยตัดทั้งชั้นเวอร์ชวลไลเซชันของไฮเปอร์ไวเซอร์และการกำหนดเส้นทางผ่านอินเทอร์เน็ตสาธารณะออกทั้งหมด จึงทำให้ความแปรปรวนของสัญญาณเสียงต่ำที่สุดเท่าที่จะเป็นไปได้

ข้อแลกเปลี่ยนจะเห็นได้ชัดเมื่อพูดถึงการปรับขนาด ใน VPC บนคลาวด์ เราปรับขนาดในแนวนอนด้วยระบบประสานงานที่ยืดหยุ่น เช่น คลัสเตอร์ Kubernetes ที่ปรับขนาดอัตโนมัติและใช้ GPU บนคลาวด์รองรับ ทำให้ปรับความจุได้ตามต้องการเมื่อมีสายโทรเข้าเพิ่มขึ้นอย่างรวดเร็ว แต่การติดตั้งใช้งานภายในองค์กรทำเช่นนั้นไม่ได้ คุณต้องทำงานภายใต้ขีดจำกัดความจุ GPU จริงที่มีอยู่ ซึ่งหมายถึงต้องควบคุมการรับงานอย่างเคร่งครัด กำหนดนโยบายจัดคิว และจัดเตรียมฮาร์ดแวร์ล่วงหน้าโดยอิงจากปริมาณสายที่โทรพร้อมกันสูงสุด คุณต้องวางแผนรองรับวันที่มีงานมากที่สุดไว้ตั้งแต่แรก

ข้อกำหนดด้านโครงสร้างพื้นฐานก็แตกต่างกันมากเช่นกัน การติดตั้งใช้งานบน VPC ส่วนตัวสามารถพึ่งพาพื้นที่จัดเก็บข้อมูลบนคลาวด์ที่มีผู้ให้บริการจัดการ ระบบ IAM ในตัว และการจัดการข้อมูลลับโดยบริการคลาวด์ได้ ส่วนการติดตั้งภายในองค์กรต้องใช้คลัสเตอร์ GPU แบบติดตั้งบนแร็กโดยเฉพาะ (เช่น ตัวเร่งการประมวลผลระดับองค์กรของ NVIDIA) โครงข่ายภายในที่รับส่งข้อมูลได้ในอัตราสูง โมดูลรักษาความปลอดภัยฮาร์ดแวร์ (HSM) หรือห้องเก็บกุญแจเข้ารหัสในพื้นที่ และเครื่องรวบรวมข้อมูลเทเลเมทรีในพื้นที่ นอกจากนี้ ทั้งหมดต้องทำงานบนแพลตฟอร์มคอนเทนเนอร์สำหรับองค์กรที่รองรับสภาพแวดล้อมซึ่งแยกขาดจากเครือข่ายภายนอกโดยสิ้นเชิง หรือจำกัดการรับส่งข้อมูลขาออก

Bland ช่วยให้องค์กรควบคุมการออกเวอร์ชัน ดูแลสภาพแวดล้อมทดสอบแยกต่างหาก และทยอยทดลองใช้เวอร์ชันใหม่กับสายสนทนาจริงบางส่วน ก่อนเปิดใช้งานในวงกว้าง เหตุใดแนวปฏิบัติการปล่อยซอฟต์แวร์แบบดั้งเดิมจึงสำคัญเป็นพิเศษ เมื่อ AI agent เริ่มทำงานจริงในสภาพแวดล้อมที่ให้บริการลูกค้าโดยตรง

เพราะ AI agent ไม่ได้ทำงานเหมือนซอฟต์แวร์สำหรับองค์กรแบบดั้งเดิม

ซอฟต์แวร์แบบกำหนดผลลัพธ์แน่นอนจะทำสิ่งเดิมทุกครั้ง แต่ AI agent แบบ Generative ทำงานโดยอาศัยความน่าจะเป็นและไม่ได้ให้ผลลัพธ์ตายตัว การปรับพรอมป์ต์เพียงเล็กน้อย การอัปเดตค่าน้ำหนักของโมเดล หรือการเปลี่ยนเส้นทางการทำงาน อาจทำให้การสนทนาถดถอย เกิดภาพหลอน หรือฝ่าฝืนนโยบายการปฏิบัติตามข้อกำหนดโดยไม่ตั้งใจได้ บ่อยครั้งไม่มีสิ่งใดในการเปลี่ยนแปลงนั้นบ่งชี้ล่วงหน้าว่าปัญหาเหล่านี้กำลังจะเกิดขึ้น

นี่จึงเป็นเหตุผลที่วินัยในการปล่อยซอฟต์แวร์แบบเดิมยิ่งสำคัญมากขึ้น ไม่ใช่น้อยลง สภาพแวดล้อมทดสอบก่อนใช้งานจริงที่แยกเป็นอิสระและการทดสอบถดถอยอย่างเข้มงวดโดยใช้ชุดข้อมูลการโทรย้อนหลัง ช่วยตรวจพบปัญหาต่าง ๆ ได้มากก่อนนำสิ่งใดขึ้นใช้งานจริง การทยอยปล่อยใช้งานแบบแคนารีช่วยยกระดับการตรวจสอบไปอีกขั้น โดยจะปล่อยเวอร์ชันใหม่ให้การโทรจริงในสัดส่วนที่ควบคุมได้ แล้วติดตามตัวชี้วัดแบบเรียลไทม์ เช่น คะแนนความรู้สึกที่ลดลง อัตราการบรรลุเป้าหมาย ความหน่วงที่เพิ่มขึ้นอย่างฉับพลัน และสัญญาณที่ทำให้ต้องยกระดับปัญหาหรือส่งต่อ ทั้งหมดนี้เกิดขึ้นก่อนที่ลูกค้ากลุ่มใหญ่จะได้ใช้งานเวอร์ชันดังกล่าว

สิ่งที่ทำให้เรื่องนี้ละเลยไม่ได้คือผลกระทบที่อาจเกิดขึ้น ในงานบริการลูกค้า การจัดการเคลม หรือการบริหารบัญชี ความผิดพลาดอาจนำไปสู่ความเสี่ยงด้านการปฏิบัติตามกฎระเบียบหรือสร้างความเสียหายร้ายแรงต่อแบรนด์ การควบคุมการทยอยปล่อยใช้งานอย่างรอบคอบและการย้อนกลับเวอร์ชันได้ทันทีคือวิธีป้องกันไม่ให้อัปเดตที่มีปัญหากลายเป็นข่าวฉาว

ธนาคาร องค์กรด้านการดูแลสุขภาพ บริษัทประกัน และหน่วยงานภาครัฐ มักเผชิญอุปสรรคในการนำ AI เชิงสร้างสรรค์มาใช้งานสูงกว่าธุรกิจประเภทอื่นมาก จากการพูดคุยของคุณกับองค์กรเหล่านี้ อะไรคือสิ่งที่ขัดขวางการนำ AI เสียงมาใช้มากขึ้นในปัจจุบันอย่างแท้จริง ไม่ว่าจะเป็นความปลอดภัย อธิปไตยด้านข้อมูล ความน่าเชื่อถือ ความซับซ้อนในการผสานระบบ การจัดซื้อจัดจ้าง หรือปัจจัยอื่น

ความปลอดภัยและอธิปไตยด้านข้อมูลเป็นอุปสรรคหลักอย่างทิ้งห่าง ส่วนความซับซ้อนในการผสานระบบและสถาปัตยกรรมระบบเดิมตามมาติด ๆ ประเด็นนี้สอดคล้องกันตลอดการพูดคุยของเราในภาคธนาคาร การดูแลสุขภาพ ประกันภัย และภาครัฐ

ในด้านความปลอดภัย องค์กรที่อยู่ภายใต้การกำกับดูแลอย่างเข้มงวดไม่อาจยอมรับสถาปัตยกรรมที่ส่งข้อมูลเสียงอ่อนไหว ข้อมูลสุขภาพที่ได้รับการคุ้มครอง (PHI) หรือข้อมูลส่วนบุคคลที่ไม่เปิดเผยต่อสาธารณะผ่านขอบเขต API ภายนอก หรือเก็บข้อมูลเหล่านั้นไว้โดยผู้ให้บริการโมเดลบุคคลที่สามเพื่อนำไปฝึกโมเดลได้ สำหรับผู้ซื้อกลุ่มนี้ ความสามารถในการตรวจสอบย้อนหลัง การรับประกันว่าจะไม่มีการเก็บรักษาข้อมูล และขอบเขตการปฏิบัติตามข้อกำหนดที่เข้มงวด เช่น HIPAA, FedRAMP และ PCI DSS ไม่ใช่แค่สิ่งที่มีก็ดีหากไม่มีก็ได้ แต่เป็นข้อกำหนดพื้นฐาน หากทำตามข้อกำหนดเหล่านี้ไม่ได้ การพูดคุยมักจบลงเพียงเท่านั้น

อุปสรรคถัดมาคือการผสานระบบ องค์กรขนาดใหญ่จำนวนมากยังใช้ระบบ PBX แบบติดตั้งภายในองค์กรรุ่นเก่า ระบบ IVR ที่ซับซ้อน และระบบหลักที่จัดเก็บข้อมูลสำคัญซึ่งแยกส่วนกัน เช่น Epic หรือ Cerner ในภาคการดูแลสุขภาพ หรือระบบเมนเฟรมหลักในภาคธนาคาร การเชื่อมเส้นทางการสนทนาเข้ากับการเข้าถึง API แบบอ่านและเขียนได้สองทิศทาง ซึ่งทำงานแบบเรียลไทม์และมีความหน่วงต่ำในสภาพแวดล้อมเหล่านี้ ทำให้เกิดภาระในการผสานระบบอย่างมาก

อีกประเด็นคือความน่าเชื่อถือและความเสี่ยงที่โมเดลจะหลอนข้อมูล ทีมกฎหมาย ทีมบริหารความเสี่ยง และทีมจัดซื้อจัดจ้างย่อมกังวลอย่างเข้าใจได้ว่าเอเจนต์เสียงอัตโนมัติอาจให้คำแนะนำด้านการเงิน การแพทย์ หรือกฎระเบียบที่ไม่ถูกต้อง ก่อนอนุมัติให้นำไปใช้งานจริงในวงกว้าง พวกเขาต้องการมาตรการป้องกันที่ละเอียด กลไกสนทนาสำรองที่ทำงานอย่างกำหนดแน่นอน และช่องทางส่งต่อให้มนุษย์เข้ามาดำเนินการที่ชัดเจน

ขอบคุณสำหรับบทสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านที่ต้องการเรียนรู้เพิ่มเติมสามารถเยี่ยมชม Bland ได้