Juan E. Riojas, IT-direktør i Bland – intervjuserie

Juan E. Riojas er IT-direktør i Bland og en erfaren leder innen teknologi og data. Karrieren hans spenner over IT i større virksomheter, datahåndtering, analyse, drift og digital transformasjon. Før han begynte i Bland i desember 2025, var han IT-direktør i Twilio og Rackspace Technology. Før det hadde han lederroller som Chief Data Officer i Informatica og visepresident for datahåndtering og analyse i Gogo. Han har også hatt ledende drifts- og lederstillinger i Dell, Accenture, Expeditors International, OfficeMax og AxonGroup, noe som har gitt ham omfattende erfaring med å lede teknologi- og datainitiativer i store organisasjoner.

Bland er et selskap innen tale-KI for større virksomheter, som utvikler KI-agenter som kan håndtere innkommende og utgående telefonsamtaler, kundestøtte, timebestilling, mottak, ruting og andre komplekse arbeidsflyter. Plattformen legger vekt på kontroll over den underliggende teknologistakken. Bland utvikler og drifter sine egne tale-, språk- og taleteknologimodeller, og tilbyr samtidig utrulling via Bland Cloud, private virtuelle private skyer eller helt egenhostede og frakoblede driftsmiljøer for virksomheter. Selskapet retter seg særlig mot regulerte bruksområder og bruksområder med strenge sikkerhetskrav, og tilbyr blant annet samtaleforløp, integrasjoner med eksisterende telefonsystemer, konfigurerbar lagringstid for data, rollebasert tilgangskontroll og funksjoner for etterlevelse av krav i virksomheter.

Du har vært IT-direktør i Twilio og Rackspace, Chief Data Officer i Informatica og har brukt mye av karrieren på kommunikasjonsinfrastruktur og data i større virksomheter. Hva har disse erfaringene lært deg om hindringene virksomheter møter når de tar i bruk KI, og hvordan har de formet plattformen for egen drift som du nå bygger i Bland?

Erfaringene mine fra Twilio, Rackspace og Informatica lærte meg at den største hindringen for KI i større virksomheter ikke er teknologien – det er tillit, kontroll og muligheten til å drifte sikkert i stor skala. Selskaper må vite hvor dataene deres befinner seg, hvem som har kontroll over dem, og om KI kan inngå i sikkerhets- og styringsrammeverkene de har brukt flere år på å bygge opp. Dette har formet tilnærmingen vår i Bland: Vi gir selskaper en plattform for egen drift som utnytter kraften i KI, uten at de må gi avkall på kontrollen over infrastrukturen eller dataene sine.

Bland er den eneste tale-KI-plattformen som kan driftes på egen infrastruktur. Det betyr at du eier hvert lag i KI-orkestreringen: tale til tekst, inferens med store språkmodeller (LLM) og tekst til tale. Hvorfor valgte Bland denne løsningen, og hva var de største tekniske utfordringene ved å eie hele tale-KI-stakken?

Vi valgte å drifte alt selv og eie hvert lag – fra automatisk talegjenkjenning (ASR) via resonnering med store språkmodeller (LLM) til tekst-til-tale (TTS) – av tre grunner: samtaleforsinkelse på under ett sekund, strenge grenser for personvern og høy driftssikkerhet.

Når man kobler sammen flere ulike eksterne leverandører etter hverandre, hoper forsinkelsene seg opp. Nettverksturer tur-retur, uavhengige køforsinkelser og kaldstarter kommer i tillegg til hverandre. Resultatet er den typen unaturlige pauser som bryter samtaleflyten.

Ved å plassere modellene våre sammen i én felles kjøretidsplattform og fjerne avhengigheten av tredjeparts-API-er, slipper vi disse nettverksturene. Det gir oss også full råderett over dataene, og sensitive talestrømmer og transkripsjoner lekker aldri ut til eksterne leverandører av frontier-modeller.

De største tekniske utfordringene dreide seg om orkestrering av forsinkelser, synkronisering av strømming og GPU-planlegging med høy samtidighet. Toveis tale i sanntid krever sømløs generering av token i strømming. TTS-motoren må begynne å syntetisere lyd før LLM-en i det hele tatt er ferdig med å generere setningen.

For å få dette til bygde vi egne inferensmotorer, spekulative dekodingsløp med lav forsinkelse og tilpasninger av akustiske modeller. Samlet hindrer disse hakking, håndterer turtaking og lar systemet takle avbrytelser fra brukeren på en smidig måte – uten å overbelaste GPU-minnet.

Mange plattformer for tale-KI setter sammen transkripsjon, resonnering og talegenerering fra ulike tredjepartsleverandører. Hvilke fordeler og tekniske avveininger følger av at Bland selv eier og drifter en større del av denne stakken?

Den største fordelen er at vi kan styre forsinkelsen fra start til slutt. Det er ingen nettverksforsinkelse mellom ASR, LLM og TTS, så vi kan kjøre enhetlige strømmingsløp, optimalisere på tvers av lagene og ha god kontroll over tiden frem til første byte. Du får rett og slett ikke den samme graden av kontroll når hver komponent kommer fra en forskjellig leverandør.

Den andre fordelen er én felles grense for sikkerhet og etterlevelse. Data forlater aldri det kontrollerte miljøet vårt, så kundenes lydopptak og transkripsjoner forblir innenfor den verifiserte sikkerhetssonen vår. Det fjerner risikoen knyttet til tredjepartsunderdatabehandlere og gjør det langt enklere å etterleve HIPAA, SOC 2 og PCI DSS. Alle som har vært gjennom en sikkerhetsvurdering av en leverandør, vet hvor viktig dette er.

Den tredje fordelen er forutsigbare kostnader. Vi betaler ikke påslag per token eller per minutt for eksterne API-er til grunnmodeller, så enhetsøkonomien vår er forutsigbar også i stor skala. Og fordi modellene er våre, kan vi finjustere akustikk, prosodi og vektene for oppgavespesifikk resonnering direkte.

Men alt dette har en kostnad. Denne tilnærmingen krever mye infrastruktur og store investeringer i GPU-er. Det krever avansert planlegging, orkestrering og failover på tvers av flere regioner å administrere store GPU-flåter, og maskinvarekostnadene er høye.

Vi tar også selv ansvaret for vedlikehold og spesialisering av modellene. Vi kan ikke sette bort banebrytende forskning til eksterne leverandører. I stedet tar vi på oss det kontinuerlige ingeniørarbeidet med å trene, evaluere og vedlikeholde egne modeller for ulike aksenter, bakgrunnsstøyforhold og språk.

For oss er denne avveiningen verdt det.

Bland mottok FedRAMP 20x Class A-sertifisering i august og sier at selskapet er den første tale-KI-plattformen som har fått den. De fleste lesere kjenner neppe forskjellen på 20x og den eldre FedRAMP-ordningen. Hva er Class A, og hva måtte dere faktisk dokumentere for å få sertifiseringen?

FedRAMP 20x er et modernisert, skybasert rammeverk som ble innført under FedRAMP Consolidated Rules for 2026 (CR26). Den eldre prosessen sorterte alt etter konsekvensnivåene i FIPS 199 (Low, Moderate og High) og var kjent for å innebære svært mye papirarbeid. 20x erstatter disse med sertifiseringsklasser betegnet med bokstaver: A, B, C og D.

Class A er det grunnleggende nivået. Det er spesielt utformet for kommersielle leverandører av skytjenester (CSP-er) som allerede har modne sikkerhetsprogrammer og ønsker å gå inn i det føderale markedet. Tenk på det som en inngangsport, ikke et permanent mål. Man får en anerkjent programsertifisering som utstedes direkte av FedRAMP Program Management Office (PMO), og har deretter et tidsrom på 2 år til å gå over til Class B, C eller D.

For å oppnå dette måtte vi dokumentere fire ting. For det første en aktuell, verifisert SOC 2 Type II-revisjon som dekker grunnleggende prinsipper for sikkerhet, konfidensialitet og tilgjengelighet. For det andre en tydelig definert og logisk isolert grense for den føderale skytjenesten, som omfatter tale-, SMS- og chattetjenestene våre.

For det tredje måtte vi som et grunnleggende krav implementere FedRAMP 20x Key Security Indicators (KSI-er) og være klare for kontinuerlig overvåking. Dette omfatter sårbarhetsskanning, prosedyrer for hendelseshåndtering, håndheving av tilgangskontroll og kontinuerlig, maskinlesbar sikkerhetsrapportering.

Det fjerde punktet viste virkelig verdien av å eie hele teknologistakken vår. Vi måtte verifisere at all transkripsjon, resonnering og talesyntese utelukkende foregår innenfor Bland sin godkjente containergrense, uten at føderale data overføres til ikke-godkjente tredjepartsleverandører av banebrytende KI. For en plattform som er satt sammen av eksterne leverandører, er dette svært vanskelig å dokumentere.

Bland støtter distribusjoner som spenner fra private VPC-er i skyen til dedikert, lokalt installert GPU-infrastruktur. Hvordan endres arkitekturen når man går mellom disse distribusjonsmodellene, særlig når det gjelder forsinkelse, skalering og infrastrukturkrav?

Kort fortalt får du lavere forsinkelse og mer kontroll jo nærmere du kommer en lokal installasjon, men du gir samtidig avkall på mer elastisk kapasitet.

La oss begynne med forsinkelse. Både lokale installasjoner og dedikerte VPC-er minimerer ekstern nettverkstrafikk fordi de ligger rett ved virksomhetens interne telefonitrunker og SIP-gatewayer. I en privat VPC i skyen, for eksempel på AWS eller GCP, avhenger forsinkelsen av nettverkstrafikk innenfor regionen og skytjenestens nettverkstilkoblinger. Dedikert, lokalt installert maskinvare uten hypervisor går enda et skritt videre. Den fjerner virtualiseringslagene til hypervisoren og ruting via det offentlige internett fullstendig, noe som gir lavest mulig akustisk jitter.

Avveiningen blir tydelig når det gjelder skalering. I en VPC i skyen skalerer vi horisontalt ved hjelp av elastisk orkestrering, for eksempel Kubernetes-klynger med automatisk skalering, støttet av GPU-instanser i skyen. Dermed tilpasses kapasiteten dynamisk når samtalevolumet øker kraftig. Lokale installasjoner fungerer ikke på samme måte. Der opererer man med en fast øvre grense for fysisk GPU-kapasitet, noe som krever streng adgangskontroll, køregler og statisk klargjøring av maskinvare basert på det høyeste samtidige samtalevolumet. Man må planlegge for den travleste dagen på forhånd.

Infrastrukturkravene er også ganske forskjellige. Private VPC-er kan dra nytte av administrert skylagring, innebygd IAM og hemmeligheter som administreres av skytjenesten. Lokale installasjoner krever dedikerte, rackmonterte GPU-klynger (for eksempel NVIDIA-akseleratorer for bedriftsbruk), lokale nettverk med høy gjennomstrømming, maskinvaresikkerhetsmoduler (HSM-er) eller lokale nøkkelhvelv og lokale telemetrisystemer. Alt dette må dessuten kjøre på containerkjøremiljøer for bedriftsbruk som fungerer i helt isolerte miljøer uten nettverkstilkobling eller i miljøer med begrenset utgående trafikk.

Bland lar virksomheter kontrollere utrullinger, opprettholde separate testmiljøer og prøve ut nye versjoner på en del av de reelle samtalene før de rulles ut bredere. Hvorfor blir tradisjonelle rutiner for programvareutgivelser særlig viktige når KI-agenter tas i bruk i kundevendte produksjonsmiljøer?

Det skyldes at KI-agenter ikke oppfører seg som tradisjonell programvare for virksomheter.

Deterministisk programvare gjør det samme hver gang. Generative KI-agenter er sannsynlighetsbaserte og ikke-deterministiske. En liten justering av en instruks, en oppdatering av modellvektene eller en endring i en prosessflyt kan utilsiktet føre til dårligere samtaler, hallusinering eller brudd på retningslinjer for etterlevelse. Ofte er det ingenting ved selve endringen som forteller deg at dette er i ferd med å skje.

Derfor er den gamle disiplinen for utrulling av nye versjoner viktigere nå, ikke mindre viktig. Isolerte testmiljøer og grundig regresjonstesting mot historiske samtalekorpus fanger opp mye før noe settes i drift. Canary-utrullinger tar dette et skritt videre. Du ruller ut den nye versjonen til en kontrollert andel av samtalene i drift og følger med på måltall i sanntid, som fall i sentiment, måloppnåelse, forsinkelsestopper og utløsere for eskalering eller overføring. Alt dette skjer før den bredere kundebasen blir eksponert for den.

Det er konsekvensene som gjør dette ufravikelig. I kundeservice, skadebehandling eller kontoadministrasjon kan en feil føre til regulatoriske konsekvenser eller alvorlig omdømmeskade. Disiplinert kontroll med canary-utrullinger og umiddelbar tilbakeføring er måten du hindrer en dårlig oppdatering i å bli en dårlig overskrift på.

Banker, helseorganisasjoner, forsikringsselskaper og offentlige etater møter ofte langt større hindringer når de skal ta i bruk generativ KI enn andre virksomheter. I samtalene dine med disse organisasjonene, hva er det egentlig som hindrer flere utrullinger av stemmebasert KI i dag: sikkerhet, datasuverenitet, pålitelighet, integrasjonskompleksitet, anskaffelser eller noe annet?

Sikkerhet og datasuverenitet, med god margin, fulgt like etter av integrasjonskompleksitet og eldre arkitektur. Dette har vært gjennomgående i samtalene våre med bank-, helse-, forsikrings- og offentlig sektor.

Når det gjelder sikkerhet, kan sterkt regulerte organisasjoner ganske enkelt ikke godta en arkitektur der sensitive lydstrømmer, beskyttede helseopplysninger (PHI) eller ikke-offentlig personinformasjon krysser grensene for eksterne API-er eller lagres av tredjepartsleverandører av modeller for trening. For disse kundene er mulighet for revisjon, garantier om at ingen data lagres, og strenge rammer for etterlevelse, som HIPAA, FedRAMP og PCI DSS, ikke bare ønskelige tillegg. De er grunnleggende forutsetninger. Hvis du ikke kan oppfylle dem, stopper samtalen som regel der.

Integrasjon er neste hinder. Mange av disse virksomhetene bruker fortsatt eldre, lokalt installerte PBX-systemer, komplekse IVR-systemer og fragmenterte kjernesystemer for registrering, som Epic eller Cerner i helsesektoren eller stormaskinbaserte kjernesystemer i banksektoren. Det skaper betydelige integrasjonskostnader å koble samtaleflyter til toveis API-tilgang for lesing og skriving i sanntid og med lav forsinkelse på tvers av disse miljøene.

Så har vi risikoen knyttet til pålitelighet og hallusinering. Juridiske team, risikoteam og innkjøpsteam er forståelig nok bekymret for at en autonom stemmeagent skal gi uriktige finansielle, medisinske eller regulatoriske råd. Før de godkjenner løsningen for bruk i stor skala, ønsker de detaljerte sikkerhetstiltak, deterministiske reservealternativer for samtaler og tydelige rutiner for å eskalere til et menneske.

Takk for et flott intervju. Lesere som ønsker å vite mer, kan besøke Bland.