Juan E. Riojas, director de sistemas de información de Bland – Serie de entrevistas

Juan E. Riojas, director de sistemas de información de Bland, es un experimentado ejecutivo de tecnología y datos cuya trayectoria abarca las tecnologías de la información empresariales, la gestión de datos, la analítica, las operaciones y la transformación digital. Antes de incorporarse a Bland en diciembre de 2025, fue director de sistemas de información en Twilio y Rackspace Technology, tras ocupar cargos directivos como director de datos en Informatica y vicepresidente de Gestión y Analítica de Datos en Gogo. Su trayectoria también incluye puestos de alta dirección en operaciones y gestión en Dell, Accenture, Expeditors International, OfficeMax y AxonGroup, que le han dado una amplia experiencia en la gestión de iniciativas tecnológicas y de datos en organizaciones de gran escala.

Bland es una empresa de IA de voz para el mercado empresarial que desarrolla agentes de IA capaces de gestionar llamadas entrantes y salientes, atención al cliente, programación de citas, recepción de solicitudes, enrutamiento y otros flujos de trabajo complejos. Su plataforma prioriza el control de la infraestructura tecnológica subyacente: Bland desarrolla y opera sus propios modelos de voz, lenguaje y habla, y ofrece implementación a través de Bland Cloud, nubes virtuales privadas o entornos empresariales totalmente autohospedados y aislados de redes externas. La empresa se centra especialmente en casos de uso regulados y sensibles desde el punto de vista de la seguridad, y ofrece funciones como rutas conversacionales, integraciones con sistemas de telefonía existentes, retención de datos configurable, controles de acceso basados en roles y capacidades de cumplimiento normativo para empresas.

Has ocupado cargos de director de sistemas de información en Twilio y Rackspace, fuiste director de datos en Informatica y has dedicado gran parte de tu carrera a la infraestructura de comunicaciones y los datos empresariales. ¿Qué te enseñaron esas experiencias sobre las barreras que enfrentan las empresas con la IA y cómo han influido en la plataforma autohospedada que estás desarrollando ahora en Bland?

Mi experiencia en Twilio, Rackspace e Informatica me enseñó que el mayor obstáculo para la IA empresarial no es la tecnología, sino la confianza, el control y la capacidad de operar de forma segura a gran escala. Las empresas necesitan saber dónde residen sus datos, quién los controla y si la IA puede integrarse en los marcos de seguridad y gobernanza que llevan años desarrollando. Eso ha definido nuestro enfoque en Bland: ofrecer a las empresas una plataforma autohospedada que les brinde el potencial de la IA sin obligarlas a renunciar al control de su infraestructura ni de sus datos.

Bland es la única plataforma autohospedada de IA de voz, lo que significa que controlas todas las capas de la orquestación de IA: conversión de voz a texto, inferencia de LLM y conversión de texto a voz. ¿Por qué eligió Bland este enfoque y cuáles fueron los desafíos técnicos más difíciles de asumir el control de toda la infraestructura de IA de voz?

Elegimos alojar y controlar todas las capas, desde el reconocimiento automático del habla (ASR) hasta el razonamiento de los modelos de lenguaje grandes (LLM) y la conversión de texto a voz (TTS), por tres motivos: una latencia conversacional inferior a 1 segundo, límites estrictos de privacidad de los datos y una alta fiabilidad operativa.

Cuando se encadenan proveedores externos distintos, las demoras se acumulan. Los saltos de red de ida y vuelta, las demoras independientes en las colas y los arranques en frío se suman. El resultado es ese tipo de pausa poco natural que rompe el flujo de la conversación.

Al ubicar nuestros modelos en un entorno de ejecución unificado y eliminar la dependencia de API de terceros, suprimimos esos saltos. Además, obtenemos plena soberanía sobre los datos: las transmisiones de voz sensibles y las transcripciones nunca se filtran a proveedores externos de modelos de IA de frontera.

Los desafíos técnicos más difíciles se redujeron a la orquestación de la latencia, la sincronización de la transmisión en continuo y la programación de GPU con alta concurrencia. La comunicación de voz bidireccional en tiempo real requiere una generación fluida de tokens en continuo. El motor de TTS tiene que empezar a sintetizar audio antes incluso de que el LLM haya terminado de generar la frase.

Para hacerlo posible, desarrollamos motores de inferencia propios, canales de decodificación especulativa de baja latencia y adaptaciones de modelos acústicos. En conjunto, evitan las fluctuaciones, gestionan los turnos de conversación y permiten responder con naturalidad a las interrupciones del usuario, todo ello sin saturar la memoria de la GPU.

Muchas plataformas de IA de voz combinan servicios de transcripción, razonamiento y generación de voz de distintos proveedores externos. ¿Qué ventajas y contrapartidas de ingeniería supone que Bland sea propietaria de una mayor parte de esa infraestructura y la opere por su cuenta?

La mayor ventaja es el control de la latencia de extremo a extremo. No hay ninguna sobrecarga de red entre ASR, el LLM y TTS, así que podemos ejecutar canales unificados de transmisión en continuo, optimizar las distintas capas y controlar con precisión el tiempo hasta el primer byte. Simplemente, no se alcanza ese nivel de control cuando cada componente procede de un proveedor distinto.

La segunda ventaja es contar con un perímetro unificado de seguridad y cumplimiento normativo. Los datos nunca salen de nuestro entorno controlado, por lo que el audio y las transcripciones de los clientes permanecen dentro de nuestro perímetro verificado. Así se elimina el riesgo asociado a los subencargados del tratamiento de terceros y se simplifica mucho el cumplimiento de HIPAA, SOC 2 y PCI DSS. Cualquiera que haya pasado por una evaluación de seguridad de proveedores sabe lo importante que es esto.

La tercera ventaja es la previsibilidad de los costos. No pagamos recargos por token ni por minuto en las API externas de modelos fundacionales, así que nuestros costos unitarios son previsibles a escala empresarial. Además, como los modelos son nuestros, podemos ajustar directamente los parámetros de acústica, prosodia y razonamiento específico para cada tarea.

Sin embargo, nada de eso es gratis. Este enfoque exige una gran inversión en infraestructura y GPU. Gestionar grandes flotas de GPU dedicadas requiere una programación sofisticada, orquestación y conmutación por error en varias regiones, además de unos costos elevados de hardware.

También asumimos la carga del mantenimiento y la especialización de los modelos. No podemos delegar la investigación de vanguardia en proveedores externos. En cambio, nos hacemos cargo del trabajo continuo de ingeniería necesario para entrenar, evaluar y mantener modelos propios que funcionen con diversos acentos, condiciones de ruido ambiental e idiomas.

Para nosotros, vale la pena asumir ese costo.

Bland recibió la certificación FedRAMP 20x Class A en agosto y afirma ser la primera plataforma de IA de voz que la obtiene. La mayoría de los lectores no conocerá FedRAMP 20x, a diferencia del FedRAMP tradicional. ¿Qué es Class A y qué tuvieron que demostrar para obtenerla?

FedRAMP 20x es un marco modernizado y nativo de la nube, introducido en virtud de las Reglas Consolidadas de FedRAMP para 2026 (CR26). El proceso tradicional clasificaba todo según los niveles de impacto de FIPS 199 (Low, Moderate y High) y era conocido por su excesiva carga de documentación. 20x los reemplaza por clases de certificación identificadas con letras: A, B, C y D.

Class A es el nivel inicial. Está diseñada específicamente para proveedores comerciales de servicios en la nube (CSP) que ya cuentan con programas de seguridad maduros y quieren ingresar al mercado federal. Considérela una vía de acceso, no un destino permanente. Se obtiene una certificación de programa reconocida, emitida directamente por la Oficina de Gestión del Programa (PMO) de FedRAMP, y luego se dispone de un plazo de 2 años para pasar a Class B, C o D.

Para lograrlo, tuvimos que demostrar cuatro aspectos. Primero, contar con una auditoría SOC 2 Type II vigente y verificada que abarcara los principios fundamentales de seguridad, confidencialidad y disponibilidad. Segundo, disponer de un límite de servicio en la nube federal claramente definido y aislado desde el punto de vista lógico, que incluyera nuestros servicios de voz, SMS y chat.

Tercero, implementar los Indicadores Clave de Seguridad (KSIs) obligatorios de FedRAMP 20x como línea de base, además de estar preparados para la supervisión continua. Esto abarca el análisis de vulnerabilidades, los procedimientos de respuesta a incidentes, la aplicación de controles de acceso y la elaboración continua de informes de seguridad legibles por máquina.

El cuarto aspecto fue donde realmente dio frutos ser dueños de nuestra plataforma tecnológica. Tuvimos que verificar que todas las tareas de transcripción, razonamiento y síntesis de voz se ejecutaran exclusivamente dentro del perímetro autorizado de contenedores de Bland, sin transmitir datos federales a proveedores externos de IA de vanguardia no aprobados. Para una plataforma ensamblada con componentes de proveedores externos, es muy difícil cumplir este requisito.

Bland admite implementaciones que van desde VPC de nube privada hasta infraestructura de GPU dedicada en las propias instalaciones. ¿Cómo cambia la arquitectura al pasar de un modelo de implementación a otro, sobre todo en lo que respecta a la latencia, el escalado y los requisitos de infraestructura?

En pocas palabras, cuanto más se acerca la implementación a las instalaciones propias, más se gana en latencia y control, pero se renuncia a una mayor elasticidad.

Empecemos por la latencia. Tanto las implementaciones en las propias instalaciones como las VPC dedicadas minimizan el tránsito por redes externas, porque están muy cerca de los troncales de telefonía internos de la empresa y de las pasarelas SIP. En una VPC de nube privada, por ejemplo en AWS o GCP, la latencia depende de las redes dentro de la región y de las interconexiones en la nube. El hardware dedicado bare metal en las propias instalaciones va un paso más allá: elimina por completo las capas de virtualización del hipervisor y el enrutamiento por la internet pública, lo que reduce al mínimo posible la fluctuación acústica.

El equilibrio se hace evidente al escalar. En una VPC en la nube, escalamos horizontalmente mediante orquestación elástica, por ejemplo, con clústeres de Kubernetes con escalado automático respaldados por instancias de GPU en la nube, de modo que la capacidad se ajusta dinámicamente cuando aumenta el volumen de llamadas. En las instalaciones propias no funciona así. Se opera con un límite fijo de capacidad física de GPU, lo que exige un control estricto de admisión, políticas de gestión de colas y un aprovisionamiento estático del hardware basado en el volumen máximo de llamadas simultáneas. Hay que planificar de antemano para el día de mayor actividad.

Los requisitos de infraestructura también son bastante diferentes. Las implementaciones en VPC privadas pueden apoyarse en almacenamiento en la nube gestionado, IAM nativo y gestión de secretos en la nube. Las instalaciones en las propias instalaciones requieren clústeres de GPU dedicadas montadas en bastidores (como aceleradores empresariales de NVIDIA), redes locales de alta capacidad, módulos de seguridad de hardware (HSM) o bóvedas de claves locales, y recopiladores locales de telemetría. Además, todo debe ejecutarse en entornos de ejecución de contenedores empresariales que puedan funcionar en entornos completamente aislados o con salida a internet restringida.

Bland permite a las empresas controlar los lanzamientos, mantener entornos de prueba separados y probar versiones nuevas de forma gradual en una parte de las llamadas reales antes de implementarlas a mayor escala. ¿Por qué las prácticas tradicionales de lanzamiento de software cobran especial importancia a medida que los agentes de IA pasan a entornos de producción de cara al cliente?

Esto se debe a que los agentes de IA no se comportan como el software empresarial tradicional.

El software determinista hace lo mismo cada vez. Los agentes de IA generativa son probabilísticos y no deterministas. Un pequeño ajuste en una instrucción, una actualización de los pesos del modelo o un cambio en una ruta de ejecución pueden provocar inadvertidamente regresiones en las conversaciones, alucinaciones o incumplimientos de las políticas de conformidad. A menudo, nada en el cambio en sí permite anticipar que eso va a ocurrir.

Por eso la antigua disciplina de lanzamiento es ahora más importante, no menos. Los entornos de puesta en escena aislados y las rigurosas pruebas de regresión con corpus históricos de llamadas permiten detectar muchos problemas antes de que nada entre en producción. Los despliegues canarios van un paso más allá. Se implementa la nueva versión en un porcentaje controlado de las llamadas en curso y se observan métricas en tiempo real, como la caída del sentimiento, las tasas de consecución de objetivos, los picos de latencia y los activadores de escalamiento o transferencia. Todo eso ocurre antes de que la base de clientes más amplia quede expuesta a la nueva versión.

Lo que está en juego hace que esto no sea negociable. En el servicio al cliente, la gestión de reclamaciones o la administración de cuentas, un modo de fallo puede dar lugar a riesgos regulatorios o a un grave daño para la marca. La aplicación disciplinada de controles en los despliegues canarios y las reversiones inmediatas son la manera de evitar que una mala actualización se convierta en un titular perjudicial.

Los bancos, las organizaciones sanitarias, las aseguradoras y los organismos gubernamentales suelen enfrentarse a obstáculos mucho mayores para implementar IA generativa que otras empresas. En sus conversaciones con estas organizaciones, ¿qué está impidiendo realmente que hoy se implementen más soluciones de IA de voz: la seguridad, la soberanía de los datos, la fiabilidad, la complejidad de la integración, las compras o algún otro factor?

La seguridad y la soberanía de los datos, con mucha diferencia, seguidas de cerca por la complejidad de la integración y las arquitecturas heredadas. Esto se ha mantenido constante en nuestras conversaciones con los sectores bancario, sanitario y de seguros, así como con organismos gubernamentales.

En cuanto a la seguridad, las organizaciones sujetas a una regulación estricta sencillamente no pueden tolerar una arquitectura en la que las transmisiones de audio sensibles, la información de salud protegida (PHI) o la información personal no pública atraviesen perímetros de API externos o queden almacenadas por proveedores externos de modelos para entrenarlos. Para estos compradores, la capacidad de auditoría, las garantías de retención cero de datos y los límites rigurosos de cumplimiento normativo, como HIPAA, FedRAMP y PCI DSS, no son extras deseables. Son requisitos básicos. Si no se pueden cumplir, la conversación suele terminar ahí.

La integración es el siguiente obstáculo. Muchas de estas empresas aún utilizan sistemas PBX locales heredados, IVR complejos y sistemas centrales de registro fragmentados, como Epic o Cerner en el sector sanitario o sistemas centrales basados en mainframe en el sector bancario. Conectar los flujos conversacionales con el acceso bidireccional de lectura y escritura mediante API, en tiempo real y con baja latencia, en todos esos entornos genera una considerable sobrecarga de integración.

También están la fiabilidad y el riesgo de alucinaciones. Es comprensible que los equipos jurídicos, de gestión de riesgos y de compras desconfíen de que un agente de voz autónomo proporcione asesoramiento financiero, médico o normativo inexacto. Antes de dar su aprobación para implementarlo a escala de producción, exigen salvaguardas detalladas, mecanismos conversacionales alternativos deterministas y vías claras para escalar los casos a una persona.

Gracias por esta excelente entrevista. Los lectores que quieran saber más pueden visitar Bland.