Juan E. Riojas，Bland 首席信息官——访谈系列

Juan E. Riojas是Bland的首席信息官，拥有丰富的技术与数据管理经验，职业生涯涵盖企业 IT、数据管理、分析、运营和数字化转型。2025年12月加入Bland之前，他曾担任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 编排的每个环节：语音转文本、大语言模型推理和文本转语音。Bland为何选择这条路线？在自主掌控整个语音 AI 技术栈的过程中，最棘手的技术挑战是什么？ 

我们选择自行托管并掌控每个环节，从自动语音识别（ASR）到大语言模型（LLM）推理，再到文本转语音（TTS），原因有三：将对话延迟控制在1秒以内、严格划定数据隐私边界，以及确保高运营可靠性。

如果把多个彼此独立的外部供应商串联起来，延迟就会层层叠加。网络往返、各自独立的排队延迟以及冷启动耗时都会累积，最终产生不自然的停顿，打断对话的流畅性。

通过将模型部署在统一运行环境中，并消除对第三方 API 的依赖，我们可以避免这些网络往返。这也让我们完全掌握数据主权，敏感的语音流和转录文本绝不会泄露给外部前沿模型供应商。

最棘手的技术挑战主要涉及延迟编排、流式处理同步，以及高并发 GPU 调度。实时双向语音要求无缝地流式生成令牌。即使大语言模型尚未生成完整句子，TTS 引擎也必须开始合成音频。

为实现这一点，我们构建了定制推理引擎、低延迟推测解码管线，并对声学模型进行适配。这些技术协同运作，能够避免卡顿、管理对话轮次，并妥善处理用户打断，同时确保 GPU 内存不会耗尽。

许多语音 AI 平台会从不同的第三方供应商那里组合转录、推理和语音生成服务。Bland自行掌控并运营更多技术栈环节，能带来哪些优势，又需要在工程上做出哪些权衡？

最大的优势是能够端到端地控制延迟。ASR、LLM 和 TTS 之间没有任何网络开销，因此我们可以运行统一的流式处理管线、进行跨层优化，并严格控制首字节时间。每个环节都来自不同供应商时，你就无法获得这种程度的掌控力。

第二个优势是拥有统一的安全与合规边界。数据绝不会离开我们受控的环境，因此客户的音频和转录文本始终留在经过验证的安全边界内。这消除了第三方分处理方带来的风险，也让符合HIPAA、SOC 2和PCI DSS要求变得容易得多。经历过供应商安全审查的人都知道，这一点有多重要。

第三个优势是成本可预测。我们无需为外部基础模型 API 按令牌或分钟支付加价，因此即使在企业级规模下，单位经济效益也保持可预测。而且模型由我们掌控，所以我们可以直接微调声学、韵律以及针对特定任务的推理权重。

不过，这些都不是免费的。这种做法对基础设施和 GPU 资本投入的需求很大。管理大量专用 GPU 需要复杂的调度、编排和多区域故障切换机制，硬件开销也很高。

我们还必须自行承担模型维护和专业化的负担。我们无法把前沿研究工作外包给外部供应商。相反，我们承担持续的工程工作，在不同口音、背景噪声条件和语言下训练、评估并维护自研模型。

对我们来说，这种取舍是值得的。

Bland 于 8 月获得 FedRAMP 20x Class A 认证，并称自己是首个获得该认证的语音 AI 平台。大多数读者可能不了解 20x 与旧版 FedRAMP 有何不同。Class A 是什么？要获得这项认证，你们实际需要证明什么？

FedRAMP 20x 是一套现代化的云原生框架，根据《2026 年 FedRAMP 综合规则》（CR26）推出。旧流程按照 FIPS 199 的影响等级（低、中、高）对所有项目进行分类，而且以文书工作繁重而闻名。20x 则以字母标示的认证类别取而代之：A、B、C 和 D。

Class A 是入门级别，专为已经建立成熟安全计划、希望进入联邦市场的商业云服务提供商（CSP）而设计。可以把它看作进入市场的跳板，而非最终归宿。你可以获得由 FedRAMP 项目管理办公室（PMO）直接颁发、获认可的项目认证，随后有 2 年时间过渡到 Class B、C 或 D。

要获得认证，我们必须证明四项内容。第一，完成当前有效且经过验证的 SOC 2 Type II 审查，涵盖安全、保密性和可用性等核心原则。第二，明确界定并在逻辑上隔离联邦云服务边界，将我们的语音、SMS 和聊天服务纳入其中。

第三，落实 FedRAMP 20x 强制要求的关键安全指标（KSI）基线，并具备持续监控能力。这包括漏洞扫描、事件响应流程、访问控制执行，以及机器可读的持续安全报告。

第四项要求让我们真正体会到自主掌控整个技术栈的价值。我们必须验证，所有转录、推理和语音合成都严格在 Bland 获授权的容器边界内运行，不会将联邦数据传输给未经审核的第三方前沿 AI 提供商。对于依赖外部供应商拼凑而成的平台来说，这项要求很难满足。

Bland 支持多种部署方式，从私有云 VPC 到专用本地 GPU 基础设施。随着部署模式的变化，架构会如何调整，尤其是在延迟、扩展能力和基础设施要求方面？

简而言之，部署越接近本地环境，延迟越低、控制力越强，但弹性也会相应降低。

先说延迟。本地部署和专用 VPC 部署都能最大限度减少外部网络传输，因为它们紧邻企业内部电话中继线路和 SIP 网关。以 AWS 或 GCP 上的私有云 VPC 为例，延迟主要取决于区域内网络和云互连。专用本地裸金属硬件则更进一步：它彻底去除了虚拟机监控程序虚拟化层和公共互联网路由，从而实现尽可能低的声学抖动。

扩展能力方面则会显现这种取舍。在云 VPC 中，我们利用弹性编排进行横向扩展，例如依托云 GPU 实例自动扩缩 Kubernetes 集群，以便在通话量激增时动态调整容量。本地部署则无法采用这种方式。其运行受固定的物理 GPU 容量上限约束，因此需要严格的准入控制、排队策略，并依据并发通话峰值预先配置固定硬件。你必须提前为最繁忙的一天做好规划。

基础设施要求也大不相同。私有 VPC 部署可以使用托管云存储、原生 IAM 和云托管密钥。本地安装则需要专用机架式 GPU 集群（例如 NVIDIA 企业级加速器）、高吞吐量本地网络架构、硬件安全模块（HSM）或本地密钥库，以及本地遥测收集器。此外，所有组件都必须运行在企业级容器运行时上，以便在完全隔离网络或限制出站流量的环境中运行。

Bland 允许企业控制版本发布、维护独立的测试环境，并先在部分真实通话中试运行新版本，再逐步扩大部署范围。随着 AI 代理进入面向客户的生产环境，为什么传统的软件发布实践变得尤为重要？

这是因为 AI 代理的行为方式不同于传统企业软件。

确定性软件每次都会执行相同的操作。生成式 AI 代理则具有概率性，行为并不确定。细微的提示词调整、模型权重更新或处理路径变更，都可能无意间导致对话表现退化、产生幻觉，或违反合规政策。很多时候，仅凭变更本身根本无法预知这些问题即将发生。

这就是为什么，旧有的发布纪律如今变得更加重要，而不是不那么重要。隔离的预发布环境，以及针对历史通话语料开展的严格回归测试，能在新版本正式上线前发现许多问题。金丝雀部署则更进一步：将新版本逐步推送到一定比例的实时通话中，并实时监测情绪下滑、目标完成率、延迟突增，以及触发升级或转接的情况等指标。在更广泛的客户群接触到新版本之前，所有这些工作都会完成。

正是高风险性让这件事不容妥协。在客户服务、理赔或账户管理中，一旦出现故障，可能导致监管风险或严重损害品牌声誉。严格把控金丝雀发布，并在出现问题时立即回滚，才能避免一次糟糕的更新演变成负面新闻。

与其他企业相比，银行、医疗机构、保险公司和政府部门在部署生成式 AI 时往往面临高得多的门槛。在你与这些机构的交流中，如今究竟是什么阻碍了更多语音 AI 的部署：安全、数据主权、可靠性、集成复杂性、采购，还是其他因素？

首要障碍是安全和数据主权，远远超过其他因素；紧随其后的是集成复杂性和遗留架构。在我们与银行、医疗、保险和政府部门的交流中，情况始终如此。

在安全方面，受到严格监管的机构根本无法接受这样的架构：敏感音频流、受保护健康信息（PHI）或非公开个人信息会跨越外部 API 边界，或被第三方模型提供商留存用于训练。对于这些客户而言，可审计性、零数据留存保证，以及 HIPAA、FedRAMP 和 PCI DSS 等标准所要求的严格合规边界，并非锦上添花，而是最基本的前提。如果无法满足这些要求，通常谈到这里就结束了。

下一道障碍是集成。许多这类大型企业仍在使用老旧的本地 PBX 系统、复杂的 IVR，以及彼此割裂的核心记录系统，例如医疗领域的 Epic 或 Cerner，或银行业的大型机核心系统。要在这些环境中打通对话流程，并通过 API 实现实时、低延迟的双向读写，会带来大量集成开销。

此外，还有可靠性和幻觉风险。法律、风险管理和采购团队有理由担心，自主语音代理会给出不准确的金融、医疗或监管建议。要让他们批准大规模投入生产使用，就必须提供细致的防护机制、确定性的对话备用方案，以及明确的人工升级处理路径。

感谢这次精彩的访谈。读者如想了解更多，请访问 Bland。