Juan E. Riojas, informationschef på Bland – intervjuserie

Juan E. Riojas är informationschef på Bland och en erfaren teknik- och dataansvarig med en karriär som omfattar företags-IT, datahantering, analys, verksamhetsdrift och digital omställning. Innan han började på Bland i december 2025 var han informationschef på Twilio och Rackspace Technology, efter att tidigare ha haft ledande roller som dataansvarig på Informatica och vice vd för datahantering och analys på Gogo. Hans bakgrund omfattar även högre befattningar inom verksamhetsdrift och ledning på Dell, Accenture, Expeditors International, OfficeMax och AxonGroup, vilket har gett honom omfattande erfarenhet av att leda teknik- och datainitiativ i stora organisationer.

Bland är ett företag inom röstbaserad AI för stora företag som utvecklar AI-agenter som kan hantera inkommande och utgående telefonsamtal, kundsupport, schemaläggning, intagning, dirigering och andra komplexa arbetsflöden. Plattformen betonar kontroll över den underliggande teknikstacken. Bland utvecklar och driver sina egna modeller för röst, språk och tal och stöder samtidigt driftsättning via Bland Cloud, privata virtuella privata moln eller helt egenhostade och nätverksisolerade företagsmiljöer. Företaget fokuserar särskilt på användningsområden som omfattas av reglering eller ställer höga krav på säkerhet och erbjuder funktioner som samtalsflöden, integrationer med befintliga telefonisystem, konfigurerbar datalagringstid, rollbaserade åtkomstkontroller och funktioner för regelefterlevnad i företag.

Du har varit informationschef på Twilio och Rackspace, dataansvarig på Informatica och ägnat en stor del av din karriär åt kommunikationsinfrastruktur och företagsdata. Vad har de erfarenheterna lärt dig om de hinder företag möter när de inför AI, och hur har de format den plattform för egen drift som du nu bygger på Bland?

Min erfarenhet från Twilio, Rackspace och Informatica lärde mig att det största hindret för AI i företag inte är tekniken – det är förtroende, kontroll och möjligheten att bedriva verksamheten säkert i stor skala. Företag behöver veta var deras data finns, vem som kontrollerar den och om AI kan användas inom de säkerhets- och styrningsramverk som de har lagt år på att bygga upp. Det har format vårt arbetssätt på Bland: vi ger företag en plattform för egen drift som erbjuder AI:s fulla kraft utan att tvinga dem att ge upp kontrollen över sin infrastruktur eller sina data.

Bland är den enda plattformen för röstbaserad AI som kan köras i egen drift, vilket innebär att ni äger varje lager i AI-orkestreringen: tal till text, inferens med stora språkmodeller och text till tal. Varför valde Bland den här vägen, och vilka var de största tekniska utmaningarna med att äga hela teknikstacken för röstbaserad AI?

Vi valde att köra allt i egen drift och äga varje lager – från automatisk taligenkänning (ASR) och resonemang med stora språkmodeller (LLM) till text till tal (TTS) – av tre skäl: samtalsfördröjning under en sekund, strikta gränser för dataskydd och hög driftsäkerhet.

När man kedjekopplar olika externa leverantörer byggs fördröjningarna på. Nätverkshopp tur och retur, separata köfördröjningar och kallstarter läggs ovanpå varandra. Resultatet blir den sortens onaturliga paus som bryter samtalsflödet.

Genom att samlokalisera våra modeller i en gemensam körmiljö och eliminera beroenden av API:er från tredje part slipper vi de här hoppen. Det ger oss också full rådighet över våra data, och känsliga röstströmmar och transkriptioner läcker aldrig ut till externa leverantörer av avancerade grundmodeller.

De största tekniska utmaningarna handlade om att samordna fördröjningar, synkronisera strömning och schemalägga GPU:er med hög samtidighet. Röstkommunikation i realtid i båda riktningarna kräver sömlös strömmande generering av token. TTS-motorn måste börja syntetisera ljud innan LLM:en ens har hunnit generera hela meningen.

För att få det att fungera byggde vi egna inferensmotorer, pipeliner för spekulativ avkodning med låg fördröjning och anpassningar av akustiska modeller. Tillsammans förhindrar de jitter, hanterar turtagning och tar smidigt hand om avbrott från användaren, utan att GPU-minnet överbelastas.

Många plattformar för röstbaserad AI kombinerar transkribering, resonemang och talgenerering från olika tredjepartsleverantörer. Vilka fördelar och tekniska avvägningar följer av att Bland själv äger och driver en större del av teknikstacken?

Den största fördelen är att vi kan styra fördröjningen från början till slut. Det finns ingen nätverksfördröjning mellan ASR, LLM och TTS, så vi kan köra enhetliga strömningspipeliner, optimera mellan lagren och ha noggrann kontroll över tiden till första byte. Den kontrollnivån går helt enkelt inte att uppnå när varje del kommer från en annan leverantör.

Den andra fördelen är att vi har en enhetlig gräns för säkerhet och regelefterlevnad. Data lämnar aldrig vår kontrollerade miljö, så kundernas ljud och transkriptioner stannar inom vår verifierade säkerhetsgräns. Det eliminerar risker kopplade till underbiträden från tredje part och gör det mycket enklare att uppfylla HIPAA, SOC 2 och PCI DSS. Alla som har genomgått en säkerhetsgranskning av en leverantör vet hur stor betydelse det har.

Den tredje fördelen är förutsägbara kostnader. Vi betalar inte påslag per token eller minut för externa API:er till grundmodeller, vilket gör att vår enhetsekonomi förblir förutsägbar även i stor skala. Och eftersom modellerna är våra kan vi finjustera akustik, prosodi och vikter för uppgiftsspecifikt resonemang direkt.

Inget av det här är dock gratis. Den här metoden kräver omfattande infrastruktur och stora investeringar i GPU:er. Att hantera stora GPU-flottor med dedikerade GPU:er kräver sofistikerad schemaläggning, orkestrering och redundans mellan flera regioner, och hårdvarukostnaderna är höga.

Vi tar också själva på oss ansvaret för modellunderhåll och specialanpassning. Vi kan inte överlåta den ledande forskningen till externa leverantörer. I stället tar vi oss an det löpande ingenjörsarbetet med att träna, utvärdera och underhålla interna modeller för olika dialekter, bakgrundsljud och språk.

För oss är den avvägningen värd det.

Bland fick FedRAMP 20x Class A-certifiering i augusti och uppger att det är den första röstbaserade AI-plattformen som har den. De flesta läsare känner nog inte till skillnaden mellan 20x och det äldre FedRAMP. Vad är Class A, och vad behövde ni faktiskt visa för att få certifieringen?

FedRAMP 20x är ett moderniserat, molnbaserat ramverk som infördes genom FedRAMP Consolidated Rules for 2026 (CR26). I den äldre processen sorterades allt in i FIPS 199:s konsekvensnivåer (Low, Moderate och High), och den var ökänd för att kräva mycket pappersarbete. 20x ersätter dessa med certifieringsklasser med bokstavsbeteckningarna A, B, C och D.

Class A är grundnivån. Den är särskilt utformad för kommersiella leverantörer av molntjänster (CSP:er) som redan har välutvecklade säkerhetsprogram och vill etablera sig på den federala marknaden. Se den som en inkörsport, inte som en permanent slutdestination. Man får en erkänd programcertifiering som utfärdas direkt av FedRAMP Program Management Office (PMO), och har sedan 2 år på sig att gå vidare till Class B, C eller D.

För att nå dit behövde vi visa fyra saker. För det första en aktuell, verifierad SOC 2 Type II-granskning som omfattade grundläggande principer för säkerhet, konfidentialitet och tillgänglighet. För det andra en tydligt definierad och logiskt avskild avgränsning för den federala molntjänsten, som omfattade våra röst-, SMS- och chattjänster.

För det tredje en grundläggande implementering av de obligatoriska FedRAMP 20x Key Security Indicators (KSI:er), samt beredskap för kontinuerlig övervakning. Det omfattar sårbarhetsskanning, rutiner för incidenthantering, upprätthållande av åtkomstkontroll och maskinläsbar, kontinuerlig säkerhetsrapportering.

Det fjärde kravet var där det verkligen lönade sig att äga hela vår teknikstack. Vi behövde verifiera att all transkribering, slutledning och talsyntes körs helt inom den auktoriserade containergränsen för Bland, utan att federala data överförs till oprövade externa leverantörer av de mest avancerade AI-modellerna. För en plattform som satts ihop av externa leverantörer är det mycket svårt att uppfylla det kravet.

Bland stöder driftsättningar som sträcker sig från privata VPC-moln till dedikerad GPU-infrastruktur i egna lokaler. Hur förändras arkitekturen mellan dessa driftsättningsmodeller, särskilt när det gäller svarstid, skalning och infrastrukturkrav?

Kort sagt får man lägre svarstid och större kontroll ju närmare lokal drift man kommer, men man får samtidigt ge upp en del av den elastiska skalbarheten.

Börja med svarstiden. Både lokal drift och dedikerade VPC-driftsättningar minimerar trafik över externa nätverk, eftersom de ligger alldeles intill företagets interna telefonitrunkar och SIP-gateways. I ett privat VPC-moln, till exempel på AWS eller GCP, beror svarstiden på nätverkstrafiken inom regionen och molnanslutningarna. Dedikerad hårdvara med direkt åtkomst till maskinvaran i egna lokaler tar det ett steg längre. Den eliminerar helt virtualiseringslagren i hypervisorn och routning via det publika internet, vilket ger minsta möjliga akustiska jitter.

Avvägningen blir tydlig när det gäller skalning. I ett VPC-moln skalar vi horisontellt med elastisk orkestrering, till exempel autoskalande Kubernetes-kluster som körs på molnens GPU-instanser, så att kapaciteten anpassas dynamiskt när samtalsvolymen ökar kraftigt. Lokal drift fungerar inte på samma sätt. Där arbetar man med ett fast tak för den fysiska GPU-kapaciteten, vilket innebär att man måste tillämpa strikt kontroll av vilka anrop som tas emot, köhanteringspolicyer och statisk hårdvaruprovisionering utifrån den högsta samtidiga samtalsvolymen. Man måste planera för årets mest belastade dag redan från början.

Infrastrukturkraven skiljer sig också ganska mycket åt. Privata VPC-driftsättningar kan dra nytta av hanterad molnlagring, inbyggd IAM och hemligheter som hanteras av molntjänsten. Lokala installationer kräver dedikerade GPU-kluster i rack (till exempel NVIDIA-acceleratorer för företag), lokala nätverk med hög genomströmning, hårdvarusäkerhetsmoduler (HSM:er) eller lokala nyckelvalv samt lokala telemetriinsamlare. Allt måste dessutom köras i containerkörmiljöer för företag som fungerar i helt frånkopplade miljöer eller miljöer med begränsad utgående trafik.

Bland låter företag styra versionslanseringar, ha separata testmiljöer och testa nya versioner stegvis på en del av de verkliga samtalen innan de rullas ut bredare. Varför blir traditionella rutiner för programvarulanseringar särskilt viktiga när AI-agenter börjar användas i produktionsmiljöer där de möter kunder?

Det beror på att AI-agenter inte beter sig som traditionell företagsprogramvara.

Deterministisk programvara gör samma sak varje gång. Generativa AI-agenter är probabilistiska och icke-deterministiska. En liten ändring av en prompt, en uppdatering av modellvikterna eller en förändring i en processväg kan oavsiktligt leda till försämringar i dialogen, hallucinationer eller överträdelser av efterlevnadspolicyer. Ofta går det inte att förutse utifrån själva ändringen att något sådant kommer att hända.

Därför är den gamla disciplinen i releaseprocessen viktigare nu, inte mindre. Isolerade testmiljöer och noggranna regressionstester mot historiska samtalskorpusar fångar upp mycket innan något tas i drift. Canary-utrullningar tar det ett steg längre. Den nya versionen rullas ut till en kontrollerad andel av de pågående samtalen, samtidigt som mätvärden i realtid följs, till exempel försämrat sentiment, måluppfyllelse, latensökningar och utlösare för eskalering eller överlämning. Allt detta sker innan den bredare kundbasen exponeras för den.

Det är insatserna som gör detta icke förhandlingsbart. Inom kundservice, skadeärenden eller kontohantering kan ett fel leda till regelöverträdelser eller allvarlig skada på varumärket. Strikt kontroll av canary-utrullningar och omedelbara återställningar är sättet att hindra en dålig uppdatering från att leda till en dålig rubrik.

Banker, vårdorganisationer, försäkringsbolag och myndigheter möter ofta betydligt högre trösklar än andra företag när de ska driftsätta generativ AI. I era samtal med dessa organisationer, vad är det som faktiskt hindrar fler driftsättningar av röstbaserad AI i dag: säkerhet, datasuveränitet, tillförlitlighet, integrationskomplexitet, upphandling eller något annat?

Säkerhet och datasuveränitet, med bred marginal, följt tätt av integrationskomplexitet och äldre systemarkitektur. Det har varit ett genomgående mönster i våra samtal inom bank, vård, försäkring och offentlig sektor.

När det gäller säkerhet kan starkt reglerade organisationer helt enkelt inte acceptera en arkitektur där känsliga ljudströmmar, skyddade hälsouppgifter (PHI) eller icke-offentlig personinformation passerar externa API-gränser eller lagras av tredjepartsleverantörer av modeller för träning. För dessa köpare är granskningsbarhet, garantier om att inga data lagras och strikta efterlevnadsramar som HIPAA, FedRAMP och PCI DSS inga extra önskemål. De är grundläggande krav. Om man inte kan uppfylla dem brukar samtalet ta slut där.

Integration är nästa hinder. Många av dessa företag använder fortfarande äldre lokala PBX-system, komplexa IVR-system och fragmenterade centrala registersystem, till exempel Epic eller Cerner inom vården och stordatorsystem inom banksektorn. Att koppla samman konversationsflöden med dubbelriktad API-åtkomst för läsning och skrivning i realtid och med låg latens i dessa miljöer medför betydande integrationsarbete.

Sedan har vi tillförlitlighet och risken för hallucinationer. Juridik-, risk- och upphandlingsteamen är med rätta oroade över att en autonom röstagent ger felaktiga finansiella, medicinska eller regulatoriska råd. Innan de godkänner storskalig produktionsdrift vill de ha detaljerade skyddsräcken, deterministiska reservlösningar för samtal och tydliga vägar för eskalering till en människa.

Tack för en utmärkt intervju! Läsare som vill veta mer bör besöka Bland.