Juan E. Riojas, Chief Information Officer bij Bland – interviewreeks

Juan E. Riojas is Chief Information Officer bij Bland en een ervaren leidinggevende op het gebied van technologie en data. Zijn loopbaan omvat enterprise-IT, databeheer, analytics, bedrijfsvoering en digitale transformatie. Voordat hij in december 2025 bij Bland aan de slag ging, was hij Chief Information Officer bij Twilio en Rackspace Technology. Daarvoor bekleedde hij leidinggevende functies als Chief Data Officer bij Informatica en vicepresident Databeheer en Analytics bij Gogo. Ook vervulde hij senior functies in de bedrijfsvoering en het management bij Dell, Accenture, Expeditors International, OfficeMax en AxonGroup. Daardoor heeft hij ruime ervaring met het beheren van technologie- en data-initiatieven binnen grote organisaties.

Bland is een bedrijf dat spraak-AI voor ondernemingen ontwikkelt en AI-agenten bouwt die inkomende en uitgaande telefoongesprekken, klantenservice, planning, intake, routering en andere complexe werkprocessen kunnen afhandelen. Het platform legt de nadruk op controle over de onderliggende technologiestack. Bland ontwikkelt en beheert eigen spraak-, taal- en spraakherkenningsmodellen en biedt implementatie via Bland Cloud, private virtuele private clouds of volledig zelfgehoste, van het internet afgeschermde bedrijfsomgevingen. Het bedrijf richt zich met name op gereguleerde toepassingen en toepassingen waarbij beveiliging van groot belang is. Het biedt onder meer gespreksroutes, integraties met bestaande telefoniesystemen, instelbare bewaartermijnen voor gegevens, rolgebaseerde toegangscontroles en mogelijkheden om aan regelgeving voor ondernemingen te voldoen.

Je hebt CIO-functies bekleed bij Twilio en Rackspace, was Chief Data Officer bij Informatica en hebt een groot deel van je loopbaan gewerkt aan communicatie-infrastructuur en bedrijfsdata. Wat hebben die ervaringen je geleerd over de obstakels waar bedrijven tegenaan lopen bij AI, en hoe hebben ze vormgegeven aan het zelfgehoste platform dat je nu bij Bland ontwikkelt?

Door mijn ervaring bij Twilio, Rackspace en Informatica heb ik geleerd dat de grootste belemmering voor AI in ondernemingen niet de technologie is, maar vertrouwen, controle en de mogelijkheid om de technologie veilig op grote schaal in te zetten. Bedrijven moeten weten waar hun gegevens staan, wie er de controle over heeft en of AI past binnen de beveiligings- en governancekaders waaraan ze jarenlang hebben gebouwd. Dat heeft onze aanpak bij Bland bepaald: bedrijven een zelfgehost platform bieden dat de kracht van AI levert zonder dat ze de controle over hun infrastructuur of gegevens hoeven op te geven.

Bland is het enige zelfgehoste platform voor spraak-AI. Dat betekent dat je eigenaar bent van elke laag van de AI-orkestratie: spraak-naar-tekst, inferentie met een LLM en tekst-naar-spraak. Waarom heeft Bland voor deze aanpak gekozen en wat waren de lastigste technische uitdagingen bij het beheer van de volledige stack voor spraak-AI?

We hebben ervoor gekozen alles zelf te hosten en elke laag in eigen beheer te nemen, van automatische spraakherkenning (ASR) en redeneren met grote taalmodellen (LLM’s) tot tekst-naar-spraak (TTS), om drie redenen: een gesprekslatentie van minder dan één seconde, strikte grenzen voor gegevensprivacy en een hoge operationele betrouwbaarheid.

Wanneer je verschillende externe leveranciers achter elkaar schakelt, lopen de vertragingen op. De heen-en-terugreistijd van netwerkverbindingen, afzonderlijke wachtrijen en koude starts komen allemaal boven op elkaar. Het resultaat is een onnatuurlijke pauze die de gespreksstroom verstoort.

Door onze modellen in één gedeelde runtime onder te brengen en afhankelijkheden van API’s van derden weg te nemen, voorkomen we die extra stappen. Zo hebben we ook volledige soevereiniteit over onze gegevens: gevoelige spraakstromen en transcripties komen nooit terecht bij externe aanbieders van geavanceerde frontiermodellen.

De lastigste technische uitdagingen hadden te maken met de orkestratie van latentie, synchronisatie van gegevensstromen en GPU-planning bij hoge gelijktijdigheid. Voor realtime spraakverkeer in twee richtingen is het nodig tokens naadloos via een gegevensstroom te genereren. De TTS-engine moet al beginnen met het synthetiseren van audio voordat de LLM de zin heeft gegenereerd.

Om dat mogelijk te maken, hebben we eigen inferentie-engines, speculatieve decoderingspipelines met lage latentie en aanpassingen aan akoestische modellen ontwikkeld. Samen voorkomen die haperingen, regelen ze de beurtwisseling en verwerken ze onderbrekingen door gebruikers soepel, zonder het GPU-geheugen volledig te benutten.

Veel platforms voor spraak-AI combineren transcriptie, redeneren en spraakgeneratie van verschillende externe aanbieders. Welke voordelen en technische afwegingen brengt het met zich mee dat Bland een groter deel van die stack zelf beheert en exploiteert?

Het grootste voordeel is dat we de latentie van begin tot eind kunnen beheersen. Tussen ASR, de LLM en TTS is er geen netwerkvertraging, waardoor we uniforme streamingpipelines kunnen uitvoeren, optimalisaties over meerdere lagen heen kunnen doorvoeren en de tijd tot de eerste byte nauwlettend kunnen bewaken. Dat niveau van controle krijg je niet wanneer elk onderdeel van een andere leverancier komt.

Het tweede voordeel is één samenhangende grens voor beveiliging en compliance. Gegevens verlaten onze gecontroleerde omgeving nooit, waardoor audio en transcripties van klanten binnen onze gevalideerde beveiligingsperimeter blijven. Dat neemt de risico’s van subverwerkers van derden weg en maakt naleving van HIPAA, SOC 2 en PCI DSS een stuk eenvoudiger. Iedereen die weleens een beveiligingsbeoordeling van een leverancier heeft doorlopen, weet hoe belangrijk dat is.

Het derde voordeel is voorspelbaarheid van de kosten. We betalen geen toeslagen per token of per minuut voor API’s van externe basismodellen, waardoor onze kostenstructuur per eenheid voorspelbaar blijft op ondernemingsschaal. En omdat de modellen van ons zijn, kunnen we de akoestiek, prosodie en redeneergewichten voor specifieke taken rechtstreeks verfijnen.

Dat alles heeft natuurlijk wel een prijs. Deze aanpak vraagt veel van de infrastructuur en vergt aanzienlijke investeringen in GPU’s. Het beheer van grote aantallen gespecialiseerde GPU’s vereist geavanceerde planning, orkestratie en failover tussen meerdere regio’s, en de overhead van de hardware is hoog.

Ook de verantwoordelijkheid voor het onderhoud en de specialisatie van de modellen ligt bij ons. We kunnen baanbrekend onderzoek niet uitbesteden aan externe leveranciers. In plaats daarvan nemen we het doorlopende technische werk op ons: het trainen, evalueren en onderhouden van eigen modellen voor uiteenlopende accenten, achtergrondgeluiden en talen.

Voor ons is die afweging het waard.

Bland ontving in augustus de FedRAMP 20x Class A-certificering en zegt daarmee het eerste spraak-AI-platform te zijn dat deze certificering heeft. De meeste lezers kennen 20x niet en zijn alleen bekend met het oudere FedRAMP. Wat houdt Class A in en wat moesten jullie precies aantonen om de certificering te behalen?

FedRAMP 20x is het gemoderniseerde, cloud-native raamwerk dat is geïntroduceerd onder de FedRAMP Consolidated Rules for 2026 (CR26). In het oude proces werd alles ingedeeld volgens de impactniveaus van FIPS 199 (laag, gemiddeld en hoog), en dat proces stond berucht om de enorme hoeveelheid papierwerk. 20x vervangt die niveaus door certificeringsklassen met letters: A, B, C en D.

Class A is het instapniveau. Deze klasse is specifiek bedoeld voor commerciële cloudserviceproviders (CSP’s) die al beschikken over volwassen beveiligingsprogramma’s en actief willen worden op de federale markt. Zie het als een opstap, niet als een permanente bestemming. Je behaalt een erkende programmacertificering die rechtstreeks wordt afgegeven door het FedRAMP Program Management Office (PMO), waarna je 2 jaar de tijd hebt om over te stappen naar Class B, C of D.

Om die certificering te behalen, moesten we vier zaken aantonen. Ten eerste een actueel, geverifieerd SOC 2 Type II-onderzoek dat de kernbeginselen van beveiliging, vertrouwelijkheid en beschikbaarheid omvatte. Ten tweede een duidelijk afgebakende en logisch geïsoleerde grens voor onze federale clouddienst, met daarin onze spraak-, sms- en chatdiensten.

Ten derde moesten we de verplichte FedRAMP 20x Key Security Indicators (KSI’s) op basisniveau implementeren en aantonen dat we klaar waren voor continue monitoring. Dit omvat het scannen op kwetsbaarheden, procedures voor incidentrespons, de handhaving van toegangsbeheer en doorlopende beveiligingsrapportage in een machineleesbaar formaat.

Bij het vierde punt wierp het bezit van onze volledige technologie-stack echt zijn vruchten af. We moesten controleren of alle transcriptie, redenering en spraaksynthese strikt binnen de geautoriseerde containergrens van Bland plaatsvonden, zonder federale gegevens door te sturen naar niet-geverifieerde externe aanbieders van geavanceerde AI. Voor een platform dat met diensten van externe leveranciers in elkaar is gezet, is dat een bijzonder lastig punt om af te vinken.

Bland ondersteunt implementaties die uiteenlopen van private cloud-VPC’s tot speciale GPU-infrastructuur op locatie. Hoe verandert de architectuur wanneer je tussen die implementatiemodellen schakelt, met name wat betreft latentie, schaalbaarheid en infrastructuurvereisten?

Kort gezegd: hoe dichter je bij een implementatie op locatie komt, hoe meer je wint aan lage latentie en controle, maar hoe meer flexibiliteit je opgeeft.

Om te beginnen met de latentie: implementaties op locatie en in een speciale VPC beperken beide het externe netwerkverkeer tot een minimum, omdat ze zich vlak bij de interne telefoonverbindingen en SIP-gateways van de onderneming bevinden. In een private cloud-VPC, bijvoorbeeld op AWS of GCP, wordt de latentie bepaald door het netwerkverkeer binnen de regio en de verbindingen met de cloud. Speciale bare-metalhardware op locatie gaat nog een stap verder. Die haalt de virtualisatielagen van de hypervisor en het openbare internet volledig uit de keten, waardoor de akoestische jitter zo laag mogelijk wordt.

Bij het schalen wordt de afweging duidelijk. In een cloud-VPC schalen we horizontaal met elastische orkestratie, bijvoorbeeld automatisch schalende Kubernetes-clusters die gebruikmaken van GPU-instanties in de cloud. Zo wordt de capaciteit dynamisch aangepast wanneer het aantal gesprekken plotseling toeneemt. Op locatie werkt dat anders. Je bent gebonden aan een vaste maximale GPU-capaciteit, wat betekent dat je streng moet bepalen welke aanvragen worden toegelaten, wachtrijbeleid moet hanteren en de hardware vooraf statisch moet inrichten op basis van het piekaantal gelijktijdige gesprekken. Je moet vooraf plannen voor je drukste dag.

Ook de infrastructuurvereisten verschillen behoorlijk. Bij private VPC-implementaties kun je gebruikmaken van beheerde cloudopslag, native IAM en door de cloud beheerde geheimen. Voor installaties op locatie zijn speciale GPU-clusters in serverracks nodig (bijvoorbeeld NVIDIA-accelerators voor ondernemingen), snelle lokale netwerkverbindingen, hardwarebeveiligingsmodules (HSM’s) of lokale sleutelkluizen, en lokale telemetrieverzamelaars. Bovendien moet alles draaien op container-runtimes voor ondernemingen die volledig geïsoleerde omgevingen of omgevingen met beperkte uitgaande netwerkverbindingen aankunnen.

Bland geeft ondernemingen de mogelijkheid releases te beheren, aparte testomgevingen aan te houden en nieuwe versies eerst op een deel van de echte gesprekken uit te rollen voordat ze breder beschikbaar worden. Waarom zijn traditionele software-releasepraktijken juist nu zo belangrijk, nu AI-agenten hun intrede doen in productieomgevingen die rechtstreeks met klanten communiceren?

Dat komt doordat AI-agenten zich niet gedragen als traditionele bedrijfssoftware.

Deterministische software doet elke keer hetzelfde. Generatieve AI-agenten werken probabilistisch en niet-deterministisch. Een kleine aanpassing van een prompt, een update van modelgewichten of een wijziging van een uitvoeringspad kan onbedoeld leiden tot verslechtering van gesprekken, hallucinaties of een overtreding van compliancebeleid. Vaak geeft niets aan de wijziging zelf aan dat dit op het punt staat te gebeuren.

Daarom is de oude release-discipline nu belangrijker dan ooit. Afgeschermde stagingomgevingen en strenge regressietests op basis van historische gespreksgegevens vangen veel problemen op voordat er iets live gaat. Met canary-uitrols ga je nog een stap verder. Je rolt de nieuwe versie uit naar een gecontroleerd percentage van de livegesprekken en houdt realtime statistieken in de gaten, zoals een dalende klanttevredenheid, het percentage behaalde doelen, pieken in de latentie en triggers voor escalatie of overdracht. Dat gebeurt allemaal voordat de bredere klantenkring ermee in aanraking komt.

De grote belangen maken dit ononderhandelbaar. In klantenservice, claimsafhandeling of accountbeheer kan een fout leiden tot blootstelling aan regelgevingsrisico’s of ernstige reputatieschade. Met gedisciplineerde canary-uitrols en onmiddellijke terugdraaiingen voorkom je dat een slechte update uitmondt in een negatieve krantenkop.

Banken, zorginstellingen, verzekeraars en overheidsinstanties staan vaak voor veel hogere drempels bij de inzet van generatieve AI dan andere bedrijven. Wat houdt de uitrol van meer voice-AI-toepassingen bij deze organisaties volgens jullie gesprekken momenteel vooral tegen: beveiliging, datasoevereiniteit, betrouwbaarheid, integratiecomplexiteit, inkoop of iets anders?

Beveiliging en datasoevereiniteit, met ruime voorsprong, gevolgd door integratiecomplexiteit en verouderde architectuur. Dat beeld komt consequent naar voren in onze gesprekken met organisaties in de banksector, de zorg, de verzekeringssector en de overheid.

Op het gebied van beveiliging kunnen organisaties in sterk gereguleerde sectoren eenvoudigweg geen architectuur accepteren waarin gevoelige audiostromen, PHI of niet-openbare persoonsgegevens de grenzen van externe API’s overschrijden of door externe modelaanbieders worden bewaard om hun modellen te trainen. Voor deze klanten zijn auditmogelijkheden, garanties dat gegevens niet worden bewaard en strenge nalevingskaders zoals HIPAA, FedRAMP en PCI DSS geen extraatjes. Het zijn absolute basisvereisten. Als je daar niet aan kunt voldoen, houdt het gesprek meestal meteen op.

Integratie is de volgende hindernis. Veel van deze bedrijven werken nog met verouderde lokale PBX-systemen, complexe IVR-systemen en versnipperde kernsystemen voor hun administratie, zoals Epic of Cerner in de zorg en mainframesystemen in de banksector. Het verbinden van conversatiestromen met realtime, bidirectionele API-toegang met lage latentie en lees- en schrijfmogelijkheden in deze omgevingen brengt aanzienlijke extra integratielasten met zich mee.

Dan zijn er nog de betrouwbaarheid en het risico op hallucinaties. Juridische teams, risicoteams en inkoopteams maken zich begrijpelijkerwijs zorgen dat een autonome spraakagent onjuist financieel, medisch of regelgevingsadvies geeft. Voordat ze goedkeuring geven voor grootschalige productie-inzet, willen ze gedetailleerde waarborgen, deterministische terugvalscenario’s in gesprekken en duidelijke routes om gesprekken naar een medewerker over te dragen.

Bedankt voor het geweldige interview. Lezers die meer willen weten, kunnen terecht bij Bland.