Хуан Э. Риохас, директор по информационным технологиям в 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 — единственная платформа голосового ИИ, которую можно развернуть на собственной инфраструктуре; это означает, что вы контролируете каждый уровень оркестрации ИИ: распознавание речи и преобразование ее в текст, инференс больших языковых моделей и синтез речи. Почему Bland выбрала такой подход и какие технические задачи оказались самыми сложными при создании собственного полного стека голосового ИИ?

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

Если последовательно подключать разных внешних поставщиков, задержки накапливаются. Сетевые переходы туда и обратно, задержки в независимых очередях и холодные запуски складываются. В результате возникают неестественные паузы, нарушающие ход разговора.

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

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

Чтобы обеспечить такую работу, мы создали собственные движки инференса, конвейеры спекулятивного декодирования с низкой задержкой и адаптации акустических моделей. Вместе они предотвращают скачки, обеспечивают управление очередностью реплик и корректно обрабатывают перебивания со стороны пользователя — и все это без исчерпания памяти графических процессоров.

Многие платформы голосового ИИ используют сторонних поставщиков для распознавания речи, обработки запросов и синтеза речи. Какие преимущества и инженерные компромиссы связаны с тем, что Bland самостоятельно владеет большей частью этого стека и управляет ею?

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

Второе преимущество — единый периметр безопасности и соответствия требованиям. Данные не покидают контролируемую нами среду, поэтому аудиозаписи и расшифровки разговоров клиентов остаются в проверенном защищенном контуре. Это устраняет риски, связанные со сторонними субобработчиками, и значительно упрощает соблюдение требований HIPAA, SOC 2 и PCI DSS. Любой, кому доводилось проходить проверку безопасности поставщика, знает, насколько это важно.

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

Однако всё это требует значительных затрат. Такой подход требует серьёзных вложений в инфраструктуру и графические процессоры. Управление крупными парками выделенных графических процессоров требует сложных систем планирования, оркестрации и аварийного переключения между регионами, а накладные расходы на оборудование высоки.

Кроме того, мы сами несём ответственность за обслуживание и специализацию моделей. Мы не можем поручить передовые исследования внешним поставщикам. Вместо этого мы постоянно занимаемся инженерной работой: обучаем, оцениваем и поддерживаем собственные модели, адаптируя их к различным акцентам, условиям фонового шума и языкам.

Для нас этот компромисс оправдан.

В августе Bland получила сертификат FedRAMP 20x класса A и заявляет, что стала первой платформой голосового ИИ, удостоившейся его. Большинство читателей не знакомы с 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.