Bland 首席資訊總監 Juan E. Riojas 訪談系列

Juan E. Riojas, Chief Information Officer at Bland, is an experienced technology and data executive with a career spanning enterprise IT, data management, analytics, operations, and digital transformation. Before joining Bland in December 2025, he served as Chief Information Officer at Twilio and Rackspace Technology, following earlier leadership roles as Chief Data Officer at Informatica and VP of Data Management and Analytics at Gogo. His background also includes senior operational and management positions at Dell, Accenture, Expeditors International, OfficeMax, and AxonGroup, giving him extensive experience managing technology and data initiatives across large-scale organizations.

Bland is an enterprise voice AI company building AI agents capable of handling inbound and outbound phone conversations, customer support, scheduling, intake, routing, and other complex workflows. Its platform emphasizes control over the underlying technology stack, with Bland developing and operating its own voice, language, and speech models while supporting deployment through Bland Cloud, private virtual private clouds, or fully self-hosted and air-gapped enterprise environments. The company is particularly focused on regulated and security-sensitive use cases, offering features such as conversational pathways, integrations with existing telephony systems, configurable data retention, role-based access controls, and enterprise compliance capabilities.

You’ve held CIO roles at Twilio and Rackspace, served as Chief Data Officer at Informatica, and spent much of your career dealing with communications infrastructure and enterprise data. What did those experiences teach you about the barriers enterprises face with AI, and how have they shaped the self-hosted platform you’re now building at Bland?

My experience at Twilio, Rackspace, and Informatica taught me that the biggest barrier to enterprise AI isn’t the technology—it’s trust, control, and the ability to operate securely at scale. Companies need to know where their data lives, who controls it, and whether AI can fit within the security and governance frameworks they’ve spent years building. That’s shaped our approach at Bland: giving companies a self-hosted platform that delivers the power of AI without forcing them to give up control of their infrastructure or data.

Bland is the only self-hosted voice AI platform, which means you own every layer of the AI orchestration: speech to text, LLM inference, and text-to-speech. Why did Bland choose this route, and what were the hardest technical challenges in owning the entire voice AI stack? 

We chose to self-host and own every layer, from automatic speech recognition (ASR) to large language model (LLM) reasoning to text-to-speech (TTS), for three reasons: sub-1-second conversational latency, strict data privacy boundaries, and high operational reliability.

When you daisy-chain disparate external vendors, the delays compound. Round-trip network hops, independent queue delays, and cold starts stack on top of each other. The result is the kind of unnatural pause that breaks conversational flow.

By co-locating our models within a unified runtime and eliminating third-party API dependencies, we get rid of those hops. It also gives us total data sovereignty, and sensitive voice streams and transcripts never leak to external frontier model providers.

The hardest technical challenges came down to latency orchestration, streaming synchronization, and high-concurrency GPU scheduling. Real-time bi-directional voice requires seamless streaming token generation. The TTS engine has to begin synthesizing audio before the LLM has even finished generating the sentence.

To make that work, we built custom inference engines, low-latency speculative decoding pipelines, and acoustic model adaptations. Together, they prevent jitter, manage turn-taking, and handle user interruptions gracefully, all without saturating GPU memory.

Many voice AI platforms assemble transcription, reasoning and speech generation from different third-party providers. What advantages and engineering tradeoffs come from Bland owning and operating more of that stack itself?

The biggest advantage is end-to-end latency control. There’s zero network overhead between ASR, the LLM, and TTS, so we can run unified streaming pipelines, make cross-layer optimizations, and keep tight control over time-to-first-byte. You just don’t get that level of control when every piece comes from a different vendor.

Second is having a unified security and compliance boundary. Data never leaves our controlled environment, so customer audio and transcripts stay within our verified perimeter. That eliminates third-party subprocessor risk and makes HIPAA, SOC 2, and PCI DSS compliance a lot simpler. Anyone who’s been through a vendor security review knows how much that matters.

Third is cost predictability. We’re not paying per-token or per-minute markups on external foundation model APIs, so our unit economics stay predictable at enterprise scale. And because the models are ours, we can fine-tune acoustics, prosody, and task-specific reasoning weights directly.

None of that comes free, though. This approach is heavy on infrastructure and GPU capital. Managing large fleets of dedicated GPUs takes sophisticated scheduling, orchestration, and multi-region failover, and the hardware overhead is high.

We also carry the model maintenance and specialization burden ourselves. We can’t offload frontier research to external vendors. Instead, we take on the continuous engineering work of training, evaluating, and maintaining in-house models across diverse accents, background noise conditions, and languages.

For us, that tradeoff is worth it.

Bland received FedRAMP 20x Class A certification in August, and says it is the first voice AI platform to hold it. Most readers won’t know 20x from legacy FedRAMP. What is Class A, what did you actually have to demonstrate to get it?

FedRAMP 20x is the modernized, cloud-native framework introduced under the FedRAMP Consolidated Rules for 2026 (CR26). The legacy process sorted everything into FIPS 199 impact levels (Low, Moderate, and High), and it was notoriously paperwork-heavy. 20x replaces those with lettered Certification Classes: A, B, C, and D.

Class A is the entry-level tier. It’s designed specifically for commercial Cloud Service Providers (CSPs) that already have mature security programs and want to enter the federal marketplace. Think of it as an on-ramp, not a permanent destination. You earn a recognized Program Certification issued directly by the FedRAMP Program Management Office (PMO), and then you have a 2-year window to transition to Class B, C, or D.

To get there, we had to demonstrate four things. First, a current, verified SOC 2 Type II examination covering core security, confidentiality, and availability principles. Second, a clearly defined and logically isolated federal cloud service boundary encompassing our voice, SMS, and chat services.

Third, baseline implementation of the mandatory FedRAMP 20x Key Security Indicators (KSIs), along with continuous monitoring readiness. That covers vulnerability scanning, incident response procedures, access control enforcement, and machine-readable, continuous security reporting.

The fourth is where owning our stack really paid off. We had to verify that all transcription, reasoning, and speech synthesis run strictly inside Bland’s authorized container boundary, without transmitting federal data to unvetted third-party frontier AI providers. For a platform stitched together from outside vendors, that’s a very hard box to check.

Bland supports deployments ranging from private cloud VPCs to dedicated on-premises GPU infrastructure. How does the architecture change as you move across those deployment models, particularly around latency, scaling, and infrastructure requirements?

The short version is that the closer you get to on-prem, the more you gain in latency and control, and the more elasticity you give up.

Start with latency. On-premises and dedicated VPC deployments both minimize external network transit, because they sit right next to the enterprise’s internal telephony trunks and SIP gateways. In a private cloud VPC, on AWS or GCP for example, latency comes down to intra-region networking and cloud interconnects. Dedicated bare-metal on-premises hardware goes a step further. It removes hypervisor virtualization layers and public internet routing entirely, which gives you the lowest possible acoustic jitter.

Scaling is where the tradeoff shows up. In a cloud VPC, we scale horizontally using elastic orchestration, like autoscaling kubernetes clusters backed by cloud GPU instances, so capacity adjusts dynamically when calls spike. On-prem doesn’t work that way. You’re operating under a fixed physical GPU capacity ceiling, which means strict admission control, queueing policies, and static hardware provisioning based on peak concurrent call volume. You have to plan for your busiest day up front.

The infrastructure requirements look pretty different, too. Private VPC deployments can lean on managed cloud storage, native IAM, and cloud-managed secrets. On-premises installations need dedicated rack-mounted GPU clusters (NVIDIA enterprise accelerators, for example), high-throughput local network fabrics, hardware security modules (HSMs) or local key vaults, and local telemetry collectors. And all of it has to run on enterprise container runtimes that can operate in fully air-gapped or restricted-egress environments.

Bland allows enterprises to control releases, maintain separate testing environments and canary new versions on a portion of real calls before rolling them out more broadly. Why are traditional software release practices becoming especially important as AI agents move into customer-facing production environments?

It’s because AI agents don’t behave like traditional enterprise software.

Deterministic software does the same thing every time. Generative AI agents are probabilistic and non-deterministic. A subtle prompt tweak, model weight update, or pathway change can inadvertently cause conversational regression, hallucination, or a compliance policy violation. Often, nothing about the change itself tells you that’s about to happen.

That’s why the old release discipline matters more now, not less. Isolated staging environments and rigorous regression testing against historical call corpora catch a lot before anything goes live. Canary deployments take it a step further. You roll the new version out to a controlled percentage of live calls and watch real-time metrics like sentiment drop-off, goal-completion rates, latency spikes, and escalation or hand-off triggers. All of that happens before the broader customer base is exposed to it.

The stakes are what make this non-negotiable. In customer service, claims, or account management, a failure mode can mean regulatory exposure or severe brand damage. Disciplined canary gating and instant rollbacks are how you keep a bad update from turning into a bad headline.

Banks, healthcare organizations, insurers and government agencies often face much higher hurdles for deploying generative AI than other businesses. In your conversations with these organizations, what is actually preventing more voice AI deployments today: security, data sovereignty, reliability, integration complexity, procurement, or something else?

Security and data sovereignty, by a wide margin, with integration complexity and legacy architecture a close second. That’s been consistent across our conversations in banking, healthcare, insurance, and government.

On the security side, highly regulated organizations simply can’t tolerate an architecture where sensitive audio streams, PHI, or non-public personal information cross external API perimeters or get retained by third-party model providers for training. For these buyers, auditability, zero-data-retention guarantees, and rigorous compliance boundaries like HIPAA, FedRAMP, and PCI DSS aren’t nice-to-haves. They’re baseline prerequisites. If you can’t meet them, the conversation usually ends there.

Integration is the next hurdle. A lot of these enterprises still run on legacy on-premise PBX systems, complex IVRs, and fragmented core systems of record, like Epic or Cerner in healthcare or mainframe cores in banking. Bridging conversational pathways with real-time, low-latency bidirectional read/write API access across those environments creates significant integration overhead.

Then there’s reliability and hallucination risk. Legal, risk, and procurement teams are understandably nervous about an autonomous voice agent giving inaccurate financial, medical, or regulatory advice. Before they’ll sign off on production scale, they want granular guardrails, deterministic conversational fallbacks, and clear human-escalation pathways.

Thanks for the great interview, readers who wish to learn more should visit Bland.