Juan E. Riojas, it-direktør hos Bland – interviewserie

Juan E. Riojas er en erfaren leder inden for teknologi og data med en karriere, der spænder over virksomheders IT, datastyring, analyse, drift og digital transformation. Før han kom til Bland i december 2025, var han it-direktør hos Twilio og Rackspace Technology, efter tidligere at have haft ledende stillinger som dataansvarlig hos Informatica og vicepræsident for datastyring og analyse hos Gogo. Hans baggrund omfatter også ledende drifts- og lederstillinger hos Dell, Accenture, Expeditors International, OfficeMax og AxonGroup, hvilket har givet ham omfattende erfaring med at lede teknologi- og datainitiativer i store organisationer.

Bland er en virksomhed inden for stemmebaseret AI til erhvervslivet, som udvikler AI-agenter, der kan håndtere indgående og udgående telefonsamtaler, kundesupport, planlægning, modtagelse, viderestilling og andre komplekse arbejdsgange. Platformen lægger vægt på kontrol over den underliggende teknologistak, og Bland udvikler og driver sine egne tale-, sprog- og stemmemodeller, samtidig med at virksomheden understøtter implementering via Bland Cloud, private virtuelle private clouds eller fuldt selvhostede og netværksisolerede virksomhedsmiljøer. Virksomheden fokuserer især på brugsscenarier, der er underlagt regulering eller stiller høje krav til sikkerhed, og tilbyder funktioner som samtaleforløb, integrationer med eksisterende telefonsystemer, konfigurerbar dataopbevaring, rollebaseret adgangskontrol og funktioner til overholdelse af virksomheders krav.

Du har været it-direktør hos Twilio og Rackspace, dataansvarlig hos Informatica og har brugt en stor del af din karriere på kommunikationsinfrastruktur og virksomhedsdata. Hvad har de erfaringer lært dig om de barrierer, virksomheder møder med AI, og hvordan har de præget den selvhostede platform, du nu udvikler hos Bland?

Min erfaring hos Twilio, Rackspace og Informatica lærte mig, at den største barriere for AI i virksomheder ikke er teknologien – det er tillid, kontrol og evnen til at drive løsninger sikkert i stor skala. Virksomheder skal vide, hvor deres data befinder sig, hvem der kontrollerer dem, og om AI kan indpasses i de sikkerheds- og styringsrammer, som de har brugt årevis på at opbygge. Det har præget vores tilgang hos Bland: Vi giver virksomheder en selvhostet platform, der leverer AI’s muligheder uden at tvinge dem til at opgive kontrollen over deres infrastruktur eller data.

Bland er den eneste selvhostede platform til stemmebaseret AI, hvilket betyder, at du ejer alle lag i AI-orkestreringen: tale-til-tekst, inferens med store sprogmodeller (LLM’er) og tekst-til-tale. Hvorfor valgte Bland denne tilgang, og hvad var de største tekniske udfordringer ved selv at eje hele stakken til stemmebaseret AI?

Vi valgte selv at hoste og eje alle lag – fra automatisk talegenkendelse (ASR) over ræsonnering med store sprogmodeller (LLM’er) til tekst-til-tale (TTS) – af tre grunde: samtaleforsinkelse på under 1 sekund, strenge grænser for databeskyttelse og høj driftssikkerhed.

Når man kæder forskellige eksterne leverandører sammen, lægges forsinkelserne oven i hinanden. Netværksrundture, separate køforsinkelser og kolde opstarter akkumuleres. Resultatet er den slags unaturlige pauser, der bryder samtalens flow.

Ved at placere vores modeller sammen i ét samlet kørselsmiljø og fjerne afhængigheden af tredjeparts-API’er slipper vi for disse netværksrundture. Det giver os også fuld suverænitet over data, og følsomme talestrømme og transskriptioner lækkes aldrig til eksterne udbydere af avancerede frontier-modeller.

De største tekniske udfordringer handlede om orkestrering af forsinkelser, synkronisering af streaming og GPU-planlægning ved høj samtidighed. Tale i realtid i begge retninger kræver problemfri generering af tokens som streaming. TTS-motoren skal begynde at syntetisere lyd, før LLM’en overhovedet er færdig med at generere sætningen.

For at få det til at fungere byggede vi egne inferensmotorer, spekulative afkodningspipelines med lav forsinkelse og tilpasninger af akustiske modeller. Tilsammen forhindrer de ujævnheder, styrer turtagningen og håndterer afbrydelser fra brugeren på en smidig måde – alt sammen uden at overbelaste GPU-hukommelsen.

Mange platforme til stemmebaseret AI sammensætter transskription, ræsonnering og talegenerering fra forskellige tredjepartsleverandører. Hvilke fordele og tekniske kompromiser følger der af, at Bland selv ejer og driver en større del af denne stak?

Den største fordel er kontrol over forsinkelsen fra ende til anden. Der er ingen netværksforsinkelse mellem ASR, LLM’en og TTS, så vi kan køre samlede streamingpipelines, optimere på tværs af lagene og have præcis kontrol over tiden frem til den første byte. Den grad af kontrol får man simpelthen ikke, når hver del kommer fra en anden leverandør.

Den anden fordel er en samlet ramme for sikkerhed og overholdelse af krav. Data forlader aldrig vores kontrollerede miljø, så kundernes lydoptagelser og transskriptioner forbliver inden for vores kontrollerede perimeter. Det fjerner risikoen forbundet med underdatabehandlere og gør det langt enklere at overholde HIPAA, SOC 2 og PCI DSS. Alle, der har været igennem en sikkerhedsgennemgang af en leverandør, ved, hvor meget det betyder.

Den tredje fordel er forudsigelige omkostninger. Vi betaler ikke tillæg pr. token eller pr. minut for eksterne API’er til grundmodeller, så vores enhedsøkonomi forbliver forudsigelig i stor skala for virksomheder. Og fordi modellerne er vores egne, kan vi finjustere akustik, prosodi og vægte for ræsonnering, der er tilpasset bestemte opgaver, direkte.

Intet af det er dog gratis. Denne tilgang kræver omfattende infrastruktur og store investeringer i GPU’er. Det kræver avanceret planlægning, orkestrering og failover på tværs af flere regioner at administrere store flåder af dedikerede GPU’er, og hardwareomkostningerne er høje.

Vi påtager os også selv ansvaret for vedligeholdelse og specialisering af modellerne. Vi kan ikke overlade den førende forskning til eksterne leverandører. I stedet står vi selv for det løbende tekniske arbejde med at træne, evaluere og vedligeholde interne modeller på tværs af forskellige accenter, baggrundsstøj og sprog.

For os er den afvejning det værd.

Bland modtog FedRAMP 20x Class A-certificering i august og siger, at det er den første stemmebaserede AI-platform, der har opnået den. De fleste læsere kender ikke forskellen på 20x og det tidligere FedRAMP. Hvad er Class A, og hvad skulle I konkret dokumentere for at opnå certificeringen?

FedRAMP 20x er en moderniseret, cloudbaseret ramme, der blev indført under FedRAMP Consolidated Rules for 2026 (CR26). Den tidligere proces inddelte alt efter FIPS 199-påvirkningsniveauer (Low, Moderate og High) og var berygtet for at kræve store mængder papirarbejde. 20x erstatter disse niveauer med certificeringsklasser betegnet med bogstaverne A, B, C og D.

Class A er det grundlæggende niveau. Det er specifikt beregnet til kommercielle cloudtjenesteudbydere (CSP’er), som allerede har veletablerede sikkerhedsprogrammer og ønsker at komme ind på det føderale marked. Se det som en adgangsvej, ikke som en permanent destination. Man opnår en anerkendt programcertificering, der udstedes direkte af FedRAMP Program Management Office (PMO), og har derefter 2 år til at gå videre til Class B, C eller D.

For at nå dertil skulle vi dokumentere fire ting. For det første en aktuel, verificeret SOC 2 Type II-erklæring, der dækker de grundlæggende principper om sikkerhed, fortrolighed og tilgængelighed. For det andet en klart defineret og logisk isoleret afgrænsning af den føderale cloudtjeneste, som omfatter vores tale-, SMS- og chattjenester.

For det tredje en grundlæggende implementering af de obligatoriske FedRAMP 20x Key Security Indicators (KSI’er) samt beredskab til løbende overvågning. Det omfatter scanning for sårbarheder, procedurer for håndtering af sikkerhedshændelser, håndhævelse af adgangskontrol og maskinlæsbar, løbende sikkerhedsrapportering.

Det fjerde punkt viste virkelig værdien af at eje hele vores teknologistak. Vi skulle verificere, at al transskription, ræsonnering og talesyntese udelukkende foregår inden for Blands autoriserede containerafgrænsning, uden at føderale data sendes til ikke-godkendte tredjepartsleverandører af førende AI-modeller. For en platform, der er sammensat af eksterne leverandørers løsninger, er det meget svært at leve op til det krav.

Bland understøtter implementeringer lige fra private cloud-VPC’er til dedikeret GPU-infrastruktur på stedet. Hvordan ændrer arkitekturen sig, når man skifter mellem disse implementeringsmodeller, især med hensyn til latenstid, skalering og infrastrukturkrav?

Kort fortalt får man lavere latenstid og større kontrol, jo tættere man kommer på en lokal installation, men man giver samtidig afkald på mere fleksibilitet.

Lad os begynde med latenstiden. Både lokale installationer og dedikerede VPC-implementeringer minimerer trafikken gennem eksterne netværk, fordi de er placeret tæt på virksomhedens interne telefonitrunks og SIP-gateways. I en privat cloud-VPC, for eksempel på AWS eller GCP, afhænger latenstiden af netværksforbindelser inden for regionen og cloudforbindelserne. Dedikeret bare-metal-hardware på stedet går et skridt videre. Den fjerner helt virtualiseringslag fra hypervisorer og routing over det offentlige internet, hvilket giver den lavest mulige akustiske jitter.

Afvejningen bliver tydelig, når det gælder skalering. I en cloud-VPC skalerer vi horisontalt ved hjælp af elastisk orkestrering, for eksempel Kubernetes-klynger med automatisk skalering, der understøttes af GPU-instanser i skyen, så kapaciteten tilpasses dynamisk, når antallet af opkald stiger kraftigt. Lokale installationer fungerer ikke sådan. Her arbejder man med en fast øvre grænse for den fysiske GPU-kapacitet, hvilket kræver streng adgangskontrol, køpolitikker og statisk klargøring af hardware ud fra det maksimale antal samtidige opkald. Man skal planlægge på forhånd efter den travleste dag.

Infrastrukturkravene er også ganske forskellige. Private VPC-implementeringer kan benytte administreret cloudlagring, indbygget IAM og cloudadministreret håndtering af hemmeligheder. Lokale installationer kræver dedikerede, rackmonterede GPU-klynger (for eksempel NVIDIA-acceleratorer til virksomheder), lokale netværk med høj kapacitet, hardwarebaserede sikkerhedsmoduler (HSM’er) eller lokale nøglebokse samt lokale telemetriindsamlere. Og det hele skal køre på containerplatforme til virksomheder, som kan fungere i helt isolerede miljøer uden netværksforbindelse eller med begrænset udgående trafik.

Bland giver virksomheder mulighed for at styre udgivelser, vedligeholde separate testmiljøer og afprøve nye versioner på en del af de reelle opkald, før de rulles bredere ud. Hvorfor bliver traditionelle metoder til softwareudgivelser særligt vigtige, når AI-agenter tages i brug i produktionsmiljøer, hvor de møder kunder?

Det skyldes, at AI-agenter ikke opfører sig som traditionel virksomhedssoftware.

Deterministisk software gør det samme hver gang. Generative AI-agenter er probabilistiske og ikke-deterministiske. En mindre justering af en prompt, en opdatering af modelvægte eller en ændring af en proces kan utilsigtet føre til samtaleforringelse, hallucinationer eller overtrædelse af en compliancepolitik. Ofte er der intet ved selve ændringen, der afslører, at det er ved at ske.

Derfor er den gamle disciplin omkring udrulning vigtigere nu, ikke mindre vigtig. Isolerede stagingmiljøer og grundige regressionstests mod historiske opkaldskorpora fanger mange problemer, før noget går live. Canary-udrulninger tager det et skridt videre. Man ruller den nye version ud til en kontrolleret andel af liveopkaldene og overvåger målinger i realtid, såsom fald i sentiment, målopfyldelsesrater, stigninger i latenstid og udløsning af eskaleringer eller overdragelser. Alt dette sker, før den bredere kundebase bliver eksponeret for den.

Det er de potentielle konsekvenser, der gør dette ufravigeligt. Inden for kundeservice, skadebehandling eller kontoadministration kan en fejl føre til regulatoriske konsekvenser eller alvorlig skade på brandet. Disciplineret canary-godkendelse og øjeblikkelige tilbagerulninger er måden, man forhindrer en dårlig opdatering i at føre til en dårlig overskrift.

Banker, sundhedsorganisationer, forsikringsselskaber og offentlige myndigheder møder ofte langt højere barrierer for at udrulle generativ AI end andre virksomheder. I jeres samtaler med disse organisationer, hvad forhindrer så konkret flere udrulninger af stemmebaseret AI i dag: sikkerhed, datasuverænitet, pålidelighed, integrationskompleksitet, indkøbsprocesser eller noget andet?

Sikkerhed og datasuverænitet med klar afstand, mens integrationskompleksitet og ældre arkitektur kommer lige efter. Det har været gennemgående i vores samtaler inden for bankvæsen, sundhedsvæsen, forsikring og offentlig forvaltning.

På sikkerhedsområdet kan stærkt regulerede organisationer ganske enkelt ikke acceptere en arkitektur, hvor følsomme lydstrømme, PHI eller ikke-offentlige personoplysninger krydser eksterne API-grænser eller opbevares af tredjepartsudbydere af modeller med henblik på træning. For disse kunder er revisionssporbarhed, garantier om nul datalagring og strenge rammer for overholdelse af regler som HIPAA, FedRAMP og PCI DSS ikke bare ønskværdige. De er grundlæggende forudsætninger. Hvis man ikke kan opfylde dem, slutter samtalen som regel dér.

Integration er den næste udfordring. Mange af disse virksomheder bruger stadig ældre, lokalt installerede PBX-systemer, komplekse IVR-systemer og fragmenterede kernesystemer til registrering, såsom Epic eller Cerner i sundhedsvæsenet eller mainframesystemer i bankvæsenet. Det medfører betydelige integrationsomkostninger at forbinde samtaleforløb med API-adgang til læsning og skrivning i begge retninger og med lav latenstid i realtid på tværs af disse miljøer.

Dernæst kommer pålidelighed og risikoen for hallucinationer. Juridiske afdelinger, risikoteams og indkøbsteams er med god grund bekymrede for, at en autonom stemmeagent giver unøjagtig finansiel, medicinsk eller regulatorisk rådgivning. Før de godkender udrulning i produktionsskala, ønsker de detaljerede sikkerhedsforanstaltninger, deterministiske samtalemæssige reserveforløb og tydelige muligheder for at eskalere til et menneske.

Tak for et godt interview. Læsere, der gerne vil vide mere, kan besøge Bland.