Juan E. Riojas, Chief Information Officer bei Bland – Interviewreihe

Juan E. Riojas, IT-Leiter bei Bland, ist eine erfahrene Führungskraft im Technologie- und Datenbereich. Seine Laufbahn umfasst Unternehmens-IT, Datenmanagement, Analytik, Betriebsabläufe und digitale Transformation. Bevor er im Dezember 2025 zu Bland kam, war er IT-Leiter bei Twilio und Rackspace Technology. Zuvor hatte er Führungspositionen als Datenchef bei Informatica und als Vizepräsident für Datenmanagement und Analytik bei Gogo inne. Zu seinem beruflichen Werdegang zählen außerdem leitende Positionen in Betrieb und Management bei Dell, Accenture, Expeditors International, OfficeMax und AxonGroup. Dadurch verfügt er über umfassende Erfahrung in der Leitung von Technologie- und Dateninitiativen in Großunternehmen.

Bland ist ein Unternehmen für KI-gestützte Sprachkommunikation im Enterprise-Bereich. Es entwickelt KI-Agenten, die eingehende und ausgehende Telefongespräche, Kundensupport, Terminplanung, die Erfassung von Anliegen, die Weiterleitung und andere komplexe Arbeitsabläufe übernehmen können. Bei seiner Plattform steht die Kontrolle über den zugrunde liegenden Technologie-Stack im Vordergrund: Bland entwickelt und betreibt eigene Sprach-, Sprachverarbeitungs- und Sprachsynthesemodelle und bietet zugleich Bereitstellungen über Bland Cloud, private virtuelle private Clouds sowie vollständig selbst gehostete und netzwerkisolierte Unternehmensumgebungen an. Das Unternehmen konzentriert sich besonders auf regulierte und sicherheitssensible Anwendungsfälle und bietet dafür unter anderem konfigurierbare Gesprächsabläufe, Integrationen in bestehende Telefoniesysteme, anpassbare Aufbewahrungsfristen für Daten, rollenbasierte Zugriffskontrollen und Funktionen zur Erfüllung von Compliance-Anforderungen in Unternehmen.

Sie waren CIO bei Twilio und Rackspace, Chief Data Officer bei Informatica und haben einen großen Teil Ihrer Karriere mit Kommunikationsinfrastruktur und Unternehmensdaten verbracht. Was haben Sie aus diesen Erfahrungen über die Hürden gelernt, vor denen Unternehmen beim Einsatz von KI stehen, und wie haben sie die selbst gehostete Plattform geprägt, die Sie jetzt bei Bland entwickeln?

Meine Erfahrungen bei Twilio, Rackspace und Informatica haben mich gelehrt, dass die größte Hürde für KI in Unternehmen nicht die Technologie ist, sondern Vertrauen, Kontrolle und die Möglichkeit, den Betrieb in großem Maßstab sicher zu gestalten. Unternehmen müssen wissen, wo ihre Daten gespeichert sind, wer sie kontrolliert und ob sich KI in die Sicherheits- und Governance-Rahmenwerke einfügt, die sie über Jahre aufgebaut haben. Das hat unseren Ansatz bei Bland geprägt: Wir geben Unternehmen eine selbst gehostete Plattform, die ihnen die Leistungsfähigkeit von KI bietet, ohne sie dazu zu zwingen, die Kontrolle über ihre Infrastruktur oder Daten abzugeben.

Bland ist die einzige selbst gehostete Plattform für Sprach-KI. Das bedeutet, dass Sie jede Ebene der KI-Orchestrierung selbst besitzen: Spracherkennung, LLM-Inferenz und Sprachsynthese. Warum hat sich Bland für diesen Weg entschieden, und was waren die größten technischen Herausforderungen beim Betrieb des gesamten Sprach-KI-Stacks?

Wir haben uns dafür entschieden, alles selbst zu hosten und jede Ebene selbst zu betreiben – von der automatischen Spracherkennung (ASR) über die Verarbeitung durch das Large Language Model (LLM) bis hin zur Sprachsynthese (TTS) –, und zwar aus drei Gründen: Gesprächslatenz von unter einer Sekunde, strenge Grenzen für den Datenschutz und hohe betriebliche Zuverlässigkeit.

Wenn man verschiedene externe Anbieter hintereinander schaltet, summieren sich die Verzögerungen. Hin- und Rückwege im Netzwerk, unabhängige Warteschlangen und Kaltstarts kommen jeweils hinzu. Das Ergebnis sind unnatürliche Pausen, die den Gesprächsfluss unterbrechen.

Indem wir unsere Modelle in einer einheitlichen Laufzeitumgebung zusammenführen und Abhängigkeiten von APIs Dritter beseitigen, vermeiden wir diese Umwege. Außerdem erhalten wir dadurch die volle Datenhoheit: Vertrauliche Sprachdatenströme und Transkripte gelangen niemals zu externen Anbietern führender Modelle.

Die größten technischen Herausforderungen betrafen die Koordination der Latenz, die Synchronisierung der Datenströme und die GPU-Planung bei hoher Parallelität. Sprachkommunikation in Echtzeit und in beide Richtungen erfordert eine nahtlose Generierung von Token im Datenstrom. Die TTS-Engine muss mit der Audiosynthese beginnen, bevor das LLM den Satz überhaupt fertig generiert hat.

Damit das funktioniert, haben wir eigene Inferenz-Engines, latenzarme Pipelines für spekulatives Dekodieren und Anpassungen der Akustikmodelle entwickelt. Zusammen verhindern sie Jitter, steuern den Sprecherwechsel und ermöglichen einen reibungslosen Umgang mit Unterbrechungen durch Nutzer – und das alles, ohne den GPU-Speicher auszulasten.

Viele Plattformen für Sprach-KI kombinieren Transkription, Schlussfolgern und Sprachgenerierung von verschiedenen Drittanbietern. Welche Vorteile und technischen Abwägungen ergeben sich daraus, dass Bland mehr Teile des Stacks selbst besitzt und betreibt?

Der größte Vorteil ist, dass wir die Latenz Ende zu Ende kontrollieren können. Zwischen ASR, dem LLM und TTS gibt es keinerlei Netzwerk-Overhead. Dadurch können wir einheitliche Streaming-Pipelines betreiben, Optimierungen über mehrere Ebenen hinweg vornehmen und die Zeit bis zum ersten Byte genau steuern. Ein solches Maß an Kontrolle ist nicht möglich, wenn jeder Bestandteil von einem anderen Anbieter stammt.

Der zweite Vorteil ist eine einheitliche Grenze für Sicherheit und Compliance. Die Daten verlassen unsere kontrollierte Umgebung nicht, sodass Audioaufnahmen und Transkripte unserer Kunden innerhalb unseres geprüften Sicherheitsbereichs bleiben. Dadurch entfällt das Risiko durch Unterauftragsverarbeiter und die Einhaltung von HIPAA, SOC 2 und PCI DSS wird deutlich einfacher. Wer schon einmal eine Sicherheitsprüfung durch einen Anbieter durchlaufen hat, weiß, wie wichtig das ist.

Der dritte Vorteil sind vorhersehbare Kosten. Wir zahlen keine Aufschläge pro Token oder Minute für APIs externer Basismodelle, sodass unsere Stückkosten auch im Enterprise-Maßstab vorhersehbar bleiben. Und weil die Modelle uns gehören, können wir Akustik, Prosodie und Gewichte für aufgabenspezifisches Schlussfolgern direkt feinabstimmen.

All das gibt es allerdings nicht kostenlos. Dieser Ansatz erfordert umfangreiche Infrastruktur und hohe Investitionen in GPUs. Der Betrieb großer Flotten dedizierter GPUs setzt ausgefeilte Planung, Orchestrierung und ein regionsübergreifendes Failover voraus; außerdem ist der Hardwareaufwand hoch.

Auch die Wartung und Spezialisierung der Modelle übernehmen wir selbst. Die Grundlagenforschung können wir nicht an externe Anbieter auslagern. Stattdessen leisten wir kontinuierliche Entwicklungsarbeit, um eigene Modelle für unterschiedliche Akzente, Hintergrundgeräusche und Sprachen zu trainieren, zu evaluieren und zu warten.

Für uns ist dieser Kompromiss den Aufwand wert.

Bland erhielt im August die FedRAMP-20x-Zertifizierung der Klasse A und gibt an, die erste Sprach-KI-Plattform mit dieser Zertifizierung zu sein. Die meisten Leser wissen vermutlich nicht, worin sich 20x vom bisherigen FedRAMP unterscheidet. Was ist Klasse A, und was mussten Sie tatsächlich nachweisen, um sie zu erhalten?

FedRAMP 20x ist ein modernisierter, Cloud-nativer Rahmen, der im Rahmen der konsolidierten FedRAMP-Regeln für 2026 (CR26) eingeführt wurde. Im bisherigen Verfahren wurde alles in die Auswirkungsstufen nach FIPS 199 eingeordnet (niedrig, mittel und hoch), und es war berüchtigt für seinen enormen Papieraufwand. 20x ersetzt diese Stufen durch Zertifizierungsklassen mit den Buchstaben A, B, C und D.

Klasse A ist die Einstiegsklasse. Sie richtet sich ausdrücklich an kommerzielle Cloud-Service-Provider (CSPs), die bereits über ausgereifte Sicherheitsprogramme verfügen und in den US-Bundesmarkt eintreten möchten. Man kann sie als Einstieg, nicht als dauerhaftes Ziel betrachten. Man erhält eine anerkannte Programmzertifizierung, die direkt vom FedRAMP Program Management Office (PMO) ausgestellt wird, und hat anschließend zwei Jahre Zeit, zu Klasse B, C oder D zu wechseln.

Dafür mussten wir vier Dinge nachweisen. Erstens eine aktuelle, geprüfte SOC-2-Type-II-Prüfung, die die grundlegenden Prinzipien Sicherheit, Vertraulichkeit und Verfügbarkeit abdeckt. Zweitens eine klar definierte und logisch isolierte Grenze für den Cloud-Dienst des Bundes, die unsere Sprach-, SMS- und Chatdienste umfasst.

Drittens die grundlegende Umsetzung der verpflichtenden FedRAMP-20x-Kernindikatoren für Sicherheit (Key Security Indicators, KSIs) sowie die Bereitschaft zur kontinuierlichen Überwachung. Dazu gehören Schwachstellenscans, Verfahren zur Reaktion auf Sicherheitsvorfälle, die Durchsetzung von Zugriffskontrollen und maschinenlesbare, kontinuierliche Sicherheitsberichte.

Der vierte Punkt zeigte besonders deutlich, wie sehr es sich ausgezahlt hat, unseren gesamten Technologie-Stack selbst zu besitzen. Wir mussten nachweisen, dass Transkription, Schlussfolgerungen und Sprachsynthese ausschließlich innerhalb der autorisierten Containerumgebung von Bland ausgeführt werden, ohne Daten des Bundes an nicht geprüfte externe Anbieter von Frontier-KI zu übermitteln. Für eine Plattform, die aus Komponenten externer Anbieter zusammengesetzt ist, lässt sich diese Anforderung nur sehr schwer erfüllen.

Bland unterstützt Bereitstellungen von privaten Cloud-VPCs bis hin zu dedizierter GPU-Infrastruktur vor Ort. Wie verändert sich die Architektur bei diesen verschiedenen Bereitstellungsmodellen, insbesondere im Hinblick auf Latenz, Skalierung und Infrastrukturanforderungen?

Kurz gesagt: Je näher man an eine lokale Bereitstellung heranrückt, desto mehr gewinnt man bei Latenz und Kontrolle, muss dafür aber bei der Flexibilität Abstriche machen.

Beginnen wir mit der Latenz. Sowohl lokale Bereitstellungen als auch dedizierte VPCs minimieren den externen Netzwerkverkehr, da sie sich direkt neben den internen Telefonie-Trunks und SIP-Gateways des Unternehmens befinden. Bei einer privaten Cloud-VPC, etwa auf AWS oder GCP, hängt die Latenz von der Netzwerkanbindung innerhalb der Region und den Cloud-Verbindungen ab. Dedizierte Bare-Metal-Hardware vor Ort geht noch einen Schritt weiter. Sie verzichtet vollständig auf Hypervisor-Virtualisierungsschichten und die Weiterleitung über das öffentliche Internet und ermöglicht so den geringstmöglichen akustischen Jitter.

Bei der Skalierung zeigt sich der Zielkonflikt. In einer Cloud-VPC skalieren wir horizontal mithilfe einer elastischen Orchestrierung, etwa mit automatisch skalierenden Kubernetes-Clustern, die auf Cloud-GPU-Instanzen laufen. So passt sich die Kapazität dynamisch an, wenn das Anrufaufkommen stark ansteigt. Vor Ort funktioniert das anders. Dort arbeitet man mit einer festen Obergrenze für die physische GPU-Kapazität. Deshalb braucht es strenge Zulassungskontrollen, Warteschlangenrichtlinien und eine statische Hardwarebereitstellung, die sich am Spitzenwert gleichzeitig geführter Anrufe orientiert. Auf den geschäftigsten Tag muss man von Anfang an vorbereitet sein.

Auch die Infrastruktur unterscheidet sich deutlich. Private VPC-Bereitstellungen können auf verwalteten Cloud-Speicher, native IAM-Dienste und in der Cloud verwaltete Geheimnisse zurückgreifen. Lokale Installationen benötigen dedizierte, in Racks montierte GPU-Cluster (zum Beispiel NVIDIA-Beschleuniger für Unternehmen), leistungsstarke lokale Netzwerke, Hardware-Sicherheitsmodule (HSMs) oder lokale Schlüsseltresore sowie lokale Telemetrie-Collector. Außerdem muss alles auf Container-Laufzeitumgebungen für Unternehmen laufen, die vollständig abgeschottet oder mit eingeschränktem ausgehendem Netzwerkverkehr betrieben werden können.

Bland ermöglicht es Unternehmen, Releases zu kontrollieren, separate Testumgebungen zu unterhalten und neue Versionen zunächst mit einem Teil der echten Anrufe zu testen, bevor sie breiter ausgerollt werden. Warum sind traditionelle Praktiken für Software-Releases besonders wichtig, wenn KI-Agenten in kundenorientierten Produktionsumgebungen eingesetzt werden?

Der Grund ist, dass sich KI-Agenten nicht wie herkömmliche Unternehmenssoftware verhalten.

Deterministische Software verhält sich jedes Mal gleich. Generative KI-Agenten arbeiten probabilistisch und nichtdeterministisch. Eine kleine Anpassung an der Eingabeaufforderung, eine Aktualisierung der Modellgewichte oder eine Änderung des Ablaufs kann unbeabsichtigt zu Rückschritten in der Gesprächsqualität, Halluzinationen oder einem Verstoß gegen Compliance-Vorgaben führen. Oft lässt sich der Änderung selbst nicht entnehmen, dass dies passieren könnte.

Deshalb ist die bisherige Disziplin bei Releases heute wichtiger denn je. Isolierte Staging-Umgebungen und gründliche Regressionstests anhand historischer Gesprächsdaten fangen vieles ab, bevor etwas live geht. Canary-Deployments gehen noch einen Schritt weiter. Dabei wird die neue Version für einen kontrollierten Anteil der Live-Anrufe ausgerollt, während Echtzeitkennzahlen wie ein Rückgang der Stimmung, die Zielerreichungsrate, Latenzspitzen sowie Auslöser für Eskalationen oder die Weiterleitung an Mitarbeitende beobachtet werden. All das geschieht, bevor die breitere Kundenbasis damit in Berührung kommt.

Was dies unverzichtbar macht, steht auf dem Spiel. Im Kundenservice, bei Schadensfällen oder in der Kontoverwaltung kann ein Fehler zu regulatorischen Risiken oder schweren Imageschäden führen. Mit disziplinierten Canary-Freigaben und sofortigen Rollbacks lässt sich verhindern, dass ein fehlerhaftes Update für negative Schlagzeilen sorgt.

Banken, Gesundheitsorganisationen, Versicherer und Behörden stehen bei der Einführung generativer KI oft vor deutlich höheren Hürden als andere Unternehmen. Was verhindert Ihrer Erfahrung nach in Gesprächen mit diesen Organisationen derzeit tatsächlich eine stärkere Einführung von Sprach-KI: Sicherheit, Datensouveränität, Zuverlässigkeit, Integrationskomplexität, Beschaffung oder etwas anderes?

Sicherheit und Datensouveränität sind mit großem Abstand die größten Hürden, dicht gefolgt von Integrationskomplexität und veralteten Architekturen. Das hat sich in unseren Gesprächen mit Banken, Gesundheitsorganisationen, Versicherern und Behörden durchgehend gezeigt.

Was die Sicherheit betrifft, können stark regulierte Organisationen schlicht keine Architektur akzeptieren, bei der sensible Audioströme, geschützte Gesundheitsdaten (PHI) oder nicht öffentliche personenbezogene Informationen die Grenzen externer APIs überschreiten oder von Drittanbietern von Modellen zu Trainingszwecken gespeichert werden. Für diese Kunden sind Prüfbarkeit, Garantien, dass keinerlei Daten gespeichert werden, und strenge Compliance-Vorgaben wie HIPAA, FedRAMP und PCI DSS keine wünschenswerten Extras. Sie sind grundlegende Voraussetzungen. Können diese nicht erfüllt werden, ist das Gespräch meist an dieser Stelle beendet.

Die nächste Hürde ist die Integration. Viele dieser Unternehmen nutzen nach wie vor veraltete, lokal betriebene PBX-Telefonanlagen, komplexe IVR-Systeme und fragmentierte zentrale Datensysteme – etwa Epic oder Cerner im Gesundheitswesen oder Mainframe-Kernsysteme im Bankwesen. Gesprächsabläufe über diese Umgebungen hinweg mit bidirektionalem Lese- und Schreibzugriff auf APIs in Echtzeit und mit geringer Latenz zu verbinden, verursacht erheblichen Integrationsaufwand.

Hinzu kommen Zuverlässigkeit und das Risiko von Halluzinationen. Rechts-, Risiko- und Beschaffungsteams sind verständlicherweise besorgt, dass ein autonomer Sprachagent unzutreffende finanzielle, medizinische oder regulatorische Auskünfte geben könnte. Bevor sie einem Einsatz im Produktivbetrieb in großem Maßstab zustimmen, verlangen sie detaillierte Schutzvorkehrungen, deterministische Ausweichdialoge und klar definierte Wege zur Eskalation an Mitarbeitende.

Vielen Dank für das großartige Interview. Leserinnen und Leser, die mehr erfahren möchten, sollten Bland besuchen.