Хуан Е. Ріохас, директор з інформаційних технологій у Bland — серія інтерв’ю

Хуан Е. Ріохас — досвідчений керівник у сфері технологій і даних, який обіймає посаду директора з інформаційних технологій у Bland. Його кар’єра охоплює корпоративні ІТ, управління даними, аналітику, операційну діяльність і цифрову трансформацію. До приходу в Bland у грудні 2025 року він був директором з інформаційних технологій у Twilio та Rackspace Technology, а раніше обіймав керівні посади директора з даних в Informatica і віцепрезидента з управління даними й аналітики в Gogo. Він також має досвід роботи на старших операційних і управлінських посадах у Dell, Accenture, Expeditors International, OfficeMax і AxonGroup, що дало йому змогу набути значного досвіду в управлінні технологічними ініціативами та проєктами у сфері даних у великих організаціях.

Bland — компанія у сфері корпоративного голосового ШІ, яка створює ШІ-агентів для вхідних і вихідних телефонних розмов, підтримки клієнтів, планування, первинного опрацювання запитів, маршрутизації та інших складних робочих процесів. Платформа компанії робить акцент на контролі над базовим технологічним стеком: Bland самостійно розробляє й експлуатує голосові, мовні та мовленнєві моделі, а також підтримує розгортання в Bland Cloud, приватних віртуальних хмарах або повністю самостійно розміщених корпоративних середовищах без підключення до зовнішніх мереж. Компанія особливо зосереджена на сценаріях використання, що підпадають під регуляторні вимоги або потребують підвищеного рівня безпеки. Серед доступних можливостей — сценарії розмов, інтеграція з наявними телефонними системами, налаштовувані строки зберігання даних, керування доступом на основі ролей і функції для дотримання корпоративних вимог.

Ви обіймали посади директорів з інформаційних технологій у Twilio та Rackspace, були директором з даних в Informatica й значну частину кар’єри присвятили комунікаційній інфраструктурі та корпоративним даним. Чого цей досвід навчив вас про перешкоди, з якими стикаються компанії під час упровадження ШІ, і як він вплинув на платформу, яку ви зараз розробляєте для самостійного розгортання в Bland?

Досвід роботи в Twilio, Rackspace та Informatica навчив мене, що найбільша перешкода для впровадження ШІ в компаніях — не технології, а довіра, контроль і здатність безпечно працювати у великих масштабах. Компаніям потрібно знати, де зберігаються їхні дані, хто ними керує та чи можна інтегрувати ШІ в системи безпеки й управління, які вони будували роками. Саме це визначило наш підхід у Bland: ми надаємо компаніям платформу для самостійного розгортання, яка дає змогу використовувати переваги ШІ, не змушуючи відмовлятися від контролю над власною інфраструктурою чи даними.

Bland — єдина платформа голосового ШІ для самостійного розгортання, тож ви володієте кожним рівнем оркестрації ШІ: перетворенням мовлення на текст, логічними висновками великої мовної моделі (LLM) і перетворенням тексту на мовлення. Чому Bland обрала такий підхід і які технічні завдання було найскладніше розв’язати, створюючи весь стек голосового ШІ?

Ми вирішили самостійно розміщувати й контролювати кожен рівень — від автоматичного розпізнавання мовлення (ASR) до логічних висновків великої мовної моделі (LLM) і перетворення тексту на мовлення (TTS) — з трьох причин: затримка в розмові менш як 1 секунду, суворі межі конфіденційності даних і висока операційна надійність.

Коли ви послідовно поєднуєте різних зовнішніх постачальників, затримки накопичуються. До них додаються мережеві затримки під час обміну даними, затримки в окремих чергах і холодні запуски. У результаті виникають неприродні паузи, які порушують плавність розмови.

Розмістивши наші моделі в єдиному середовищі виконання та усунувши залежність від сторонніх API, ми позбулися цих затримок. Це також дає нам повний суверенітет над даними: конфіденційні голосові потоки й транскрипти ніколи не потрапляють до зовнішніх постачальників передових моделей.

Найскладніші технічні завдання стосувалися координації затримок, синхронізації потокових даних і планування роботи графічних процесорів (GPU) за високого рівня одночасного навантаження. Для двостороннього голосового зв’язку в реальному часі потрібне безперебійне потокове генерування токенів. Модуль TTS має почати синтезувати аудіо ще до того, як LLM завершить генерувати речення.

Щоб це стало можливим, ми створили власні механізми інференсу, конвеєри спекулятивного декодування з низькою затримкою та адаптації акустичних моделей. Разом вони запобігають тремтінню звуку, керують черговістю реплік і належно обробляють перебивання з боку користувачів, не перевантажуючи пам’ять GPU.

Багато платформ голосового ШІ поєднують транскрибування, логічні висновки й синтез мовлення від різних сторонніх постачальників. Які переваги та компроміси в інженерних рішеннях дає Bland власна розробка й експлуатація більшої частини цього стека?

Найбільша перевага — контроль над затримкою на всіх етапах. Між ASR, LLM і TTS немає жодних мережевих затримок, тож ми можемо використовувати єдині потокові конвеєри, оптимізувати взаємодію між рівнями й ретельно контролювати час до отримання першого байта. Такого рівня контролю просто неможливо досягти, коли кожен компонент надає окремий постачальник.

Друга перевага — єдиний контур безпеки та відповідності вимогам. Дані не залишають контрольованого нами середовища, тому аудіозаписи клієнтів і транскрипти залишаються в межах перевіреного периметра. Це усуває ризики, пов’язані зі сторонніми субпідрядниками з обробки даних, і значно спрощує дотримання вимог HIPAA, SOC 2 і PCI DSS. Кожен, хто проходив перевірку безпеки постачальника, знає, наскільки це важливо.

Третя перевага — передбачуваність витрат. Ми не сплачуємо націнки за кожен токен чи хвилину використання зовнішніх API базових моделей, тому наші питомі витрати залишаються передбачуваними навіть у масштабах великого підприємства. А оскільки моделі належать нам, ми можемо безпосередньо налаштовувати акустичні характеристики, просодію та ваги логічних висновків для конкретних завдань.

Утім, усе це потребує значних ресурсів. Такий підхід вимагає потужної інфраструктури та значних капіталовкладень у графічні процесори. Керування великими парками виділених графічних процесорів потребує складного планування, оркестрації та резервного перемикання між регіонами, а витрати на обладнання високі.

Ми також самостійно беремо на себе відповідальність за обслуговування та спеціалізацію моделей. Ми не можемо передати зовнішнім постачальникам дослідження передових моделей. Натомість ми постійно виконуємо інженерну роботу з навчання, оцінювання та обслуговування власних моделей для роботи з різними акцентами, умовами фонового шуму й мовами.

Для нас такий компроміс вартий цих зусиль.

У серпні Bland отримала сертифікацію класу A FedRAMP 20x і стверджує, що стала першою платформою голосового ШІ, яка її здобула. Більшість читачів не знають, чим 20x відрізняється від попередньої системи FedRAMP. Що таке клас A і що саме вам довелося підтвердити, щоб його отримати?

FedRAMP 20x — це модернізована хмарна система, запроваджена відповідно до Консолідованих правил FedRAMP на 2026 рік (CR26). У попередній системі все поділяли за рівнями впливу FIPS 199 (низький, помірний і високий), а сам процес був відомий надмірною кількістю паперової роботи. 20x замінює ці рівні класами сертифікації, позначеними літерами: A, B, C і D.

Клас A — це початковий рівень. Він спеціально призначений для комерційних постачальників хмарних послуг (CSP), які вже мають зрілі програми безпеки й хочуть вийти на федеральний ринок. Сприймайте його як стартовий майданчик, а не кінцеву зупинку. Ви отримуєте офіційну сертифікацію програми безпосередньо від Офісу управління програмою FedRAMP (PMO), після чого маєте 2 роки, щоб перейти до класу B, C або D.

Щоб її отримати, нам довелося підтвердити чотири речі. По-перше, пройти актуальну перевірку SOC 2 Type II, яка охоплює основні принципи безпеки, конфіденційності та доступності, і підтвердити її результати. По-друге, чітко визначити й логічно ізолювати межі федерального хмарного сервісу, що охоплюють наші послуги голосового зв’язку, SMS і чату.

По-третє, впровадити базові обов’язкові ключові показники безпеки FedRAMP 20x (KSI) і забезпечити готовність до безперервного моніторингу. Це охоплює сканування вразливостей, процедури реагування на інциденти, контроль доступу та безперервне звітування про безпеку в машинозчитуваному форматі.

Саме четверта вимога показала, наскільки корисно було володіти всім нашим технологічним стеком. Нам довелося підтвердити, що всі процеси транскрибування, міркування та синтезу мовлення відбуваються виключно в межах авторизованого контейнерного середовища Bland, без передавання федеральних даних неперевіреним стороннім постачальникам передових моделей ШІ. Для платформи, зібраної з рішень зовнішніх постачальників, виконати цю вимогу було б дуже складно.

Bland підтримує розгортання — від приватних хмарних VPC до виділеної локальної інфраструктури на графічних процесорах. Як змінюється архітектура під час переходу між цими моделями розгортання, зокрема щодо затримки, масштабування та вимог до інфраструктури?

Якщо коротко, що ближче ви до локального розгортання, то менша затримка й більше контролю, але менше еластичності.

Почнімо із затримки. Локальне розгортання й розгортання у виділеній VPC мінімізують передавання даних через зовнішні мережі, оскільки розташовані безпосередньо поруч із внутрішніми телефонними каналами та SIP-шлюзами підприємства. У приватній хмарній VPC, наприклад на AWS або GCP, затримка залежить від мережевої взаємодії в межах регіону та хмарних з’єднань. Виділене локальне обладнання безпосередньо на фізичних серверах іде ще далі: воно повністю усуває рівні віртуалізації гіпервізора й маршрутизацію через публічний інтернет, що забезпечує найнижчий можливий акустичний джитер.

Компроміс стає помітним під час масштабування. У хмарній VPC ми масштабуємо систему горизонтально за допомогою еластичної оркестрації, наприклад автоматично масштабуємо кластери Kubernetes, підключені до хмарних графічних процесорів. Завдяки цьому потужність динамічно збільшується, коли різко зростає кількість дзвінків. Локальне розгортання працює інакше. Тут є фіксована межа фізичної потужності графічних процесорів, а отже, потрібні суворий контроль допуску, правила керування чергами та попереднє статичне забезпечення обладнання з урахуванням пікової кількості одночасних дзвінків. До найзавантаженішого дня потрібно підготуватися заздалегідь.

Вимоги до інфраструктури також суттєво різняться. Для розгортання у приватній VPC можна використовувати кероване хмарне сховище, вбудовані засоби керування ідентифікацією та доступом (IAM) і керовані хмарою сховища секретів. Для локального встановлення потрібні виділені стійкові кластери графічних процесорів (наприклад, корпоративні прискорювачі NVIDIA), локальні мережеві канали з високою пропускною здатністю, апаратні модулі безпеки (HSM) або локальні сховища ключів, а також локальні збирачі телеметрії. І все це має працювати на корпоративних середовищах виконання контейнерів, здатних функціонувати в повністю ізольованих від мережі середовищах або в середовищах з обмеженим вихідним трафіком.

Bland дає підприємствам змогу контролювати випуски, підтримувати окремі тестові середовища та тестувати нові версії на частині реальних дзвінків, перш ніж розгортати їх ширше. Чому традиційні практики випуску програмного забезпечення стають особливо важливими, коли ШІ-агенти починають працювати з клієнтами в продуктивному середовищі?

Річ у тім, що ШІ-агенти працюють не так, як традиційне корпоративне програмне забезпечення.

Детерміноване програмне забезпечення щоразу виконує однакові дії. Генеративні ШІ-агенти працюють імовірнісно й недетерміновано. Незначна зміна запиту, оновлення ваг моделі або зміна способу оброблення запиту можуть ненавмисно призвести до погіршення якості діалогу, галюцинацій або порушення політики відповідності вимогам. Часто сама зміна ніяк не вказує на те, що це може статися.

Саме тому дотримання звичних правил випуску релізів тепер важливе ще більше, а не менше. Ізольовані тестові середовища та ретельне регресійне тестування на історичних масивах дзвінків дають змогу виявити чимало проблем, перш ніж щось стане доступним користувачам. Канаркове розгортання йде ще далі. Нову версію запускають для контрольованої частки реальних дзвінків і стежать за показниками в реальному часі, як-от погіршення тональності розмов, частка досягнення цілей, стрибки затримки та спрацювання тригерів ескалації або передавання звернення оператору. Усе це відбувається до того, як із новою версією зіткнеться ширше коло клієнтів.

Саме високі ставки роблять це обов’язковим. У сфері обслуговування клієнтів, опрацювання страхових вимог або управління рахунками збій може призвести до регуляторних ризиків або серйозної шкоди для бренду. Ретельне поетапне канаркове розгортання та миттєве повернення до попередньої версії допомагають не допустити, щоб невдале оновлення стало гучною новиною.

Банки, медичні організації, страхові компанії та державні установи часто стикаються зі значно вищими вимогами до впровадження генеративного ШІ, ніж інші підприємства. З ваших розмов із цими організаціями, що саме сьогодні найбільше заважає ширшому впровадженню голосового ШІ: безпека, суверенітет даних, надійність, складність інтеграції, закупівельні процедури чи щось інше?

Безпека та суверенітет даних — із великим відривом, а одразу за ними йдуть складність інтеграції та застаріла архітектура. Така картина незмінно повторюється в наших розмовах із представниками банківської сфери, охорони здоров’я, страхування та державних установ.

Що стосується безпеки, організації, діяльність яких суворо регулюється, просто не можуть погодитися на архітектуру, у якій конфіденційні аудіопотоки, захищена медична інформація (PHI) або непублічна персональна інформація передаються через зовнішні API чи зберігаються сторонніми постачальниками моделей для навчання. Для таких замовників можливість аудиту, гарантії повної відсутності зберігання даних і суворе дотримання вимог, зокрема HIPAA, FedRAMP і PCI DSS, — не просто бажані переваги. Це базові передумови. Якщо ви не можете їх забезпечити, розмова зазвичай на цьому й закінчується.

Наступна перешкода — інтеграція. Багато таких підприємств досі використовують застарілі локальні телефонні АТС (PBX), складні системи інтерактивного голосового меню (IVR) і розрізнені основні системи обліку, як-от Epic або Cerner у сфері охорони здоров’я чи мейнфреймові системи в банківській сфері. Поєднання діалогових сценаріїв із двостороннім доступом до API для читання й запису даних у цих середовищах у реальному часі та з низькою затримкою створює значне додаткове навантаження на інтеграцію.

Ще одна проблема — надійність і ризик галюцинацій. Юридичні підрозділи, фахівці з управління ризиками та команди із закупівель цілком обґрунтовано побоюються, що автономний голосовий агент надаватиме неточні фінансові, медичні чи регуляторні поради. Перш ніж погодитися на промислове масштабування, вони хочуть бачити чіткі обмеження, детерміновані резервні сценарії розмови та зрозумілі механізми передавання звернення людині.

Дякуємо за чудове інтерв’ю. Читачі, які хочуть дізнатися більше, можуть відвідати Bland.