Juan E. Riojas, dyrektor ds. informatyki w Bland — cykl wywiadów

Juan E. Riojas, dyrektor ds. informatyki w Bland, jest doświadczonym menedżerem w obszarze technologii i danych. Jego kariera obejmuje informatykę korporacyjną, zarządzanie danymi, analitykę, operacje i transformację cyfrową. Zanim w grudniu 2025 r. dołączył do Bland, pełnił funkcję dyrektora ds. informatyki w Twilio i Rackspace Technology, a wcześniej zajmował kierownicze stanowiska: dyrektora ds. danych w Informatica oraz wiceprezesa ds. zarządzania danymi i analityki w Gogo. Ma również doświadczenie na wyższych stanowiskach operacyjnych i kierowniczych w Dell, Accenture, Expeditors International, OfficeMax i AxonGroup, dzięki czemu zdobył rozległe doświadczenie w zarządzaniu inicjatywami technologicznymi i dotyczącymi danych w dużych organizacjach.

Bland to firma oferująca rozwiązania głosowe oparte na sztucznej inteligencji dla przedsiębiorstw. Tworzy agentów AI zdolnych do obsługi przychodzących i wychodzących rozmów telefonicznych, obsługi klienta, umawiania spotkań, przyjmowania zgłoszeń, kierowania połączeń i innych złożonych procesów. Jej platforma kładzie nacisk na kontrolę nad bazowym stosem technologicznym: Bland opracowuje i obsługuje własne modele głosu, języka i mowy, a wdrożenia udostępnia za pośrednictwem Bland Cloud, prywatnych chmur wirtualnych lub w pełni samodzielnie hostowanych, odizolowanych od sieci środowisk korporacyjnych. Firma koncentruje się zwłaszcza na zastosowaniach podlegających regulacjom i wymagających wysokiego poziomu bezpieczeństwa. Oferuje między innymi ścieżki konwersacyjne, integracje z istniejącymi systemami telefonicznymi, konfigurowalne zasady przechowywania danych, kontrolę dostępu opartą na rolach oraz funkcje zapewniające zgodność z wymogami korporacyjnymi.

Pełnił Pan funkcję dyrektora ds. informatyki w Twilio i Rackspace, był dyrektorem ds. danych w Informatica, a znaczną część kariery poświęcił zagadnieniom infrastruktury komunikacyjnej i danych korporacyjnych. Czego te doświadczenia nauczyły Pana o barierach, z którymi przedsiębiorstwa mierzą się we wdrażaniu AI, i jak wpłynęły na kształt opracowywanej przez Pana samodzielnie hostowanej platformy Bland?

Doświadczenie zdobyte w Twilio, Rackspace i Informatica nauczyło mnie, że największą barierą dla AI w przedsiębiorstwach nie jest technologia, lecz zaufanie, kontrola i możliwość bezpiecznego działania na dużą skalę. Firmy muszą wiedzieć, gdzie znajdują się ich dane, kto sprawuje nad nimi kontrolę i czy AI można wdrożyć w ramach zabezpieczeń oraz zasad zarządzania, które budowały przez lata. To ukształtowało nasze podejście w Bland: udostępniamy firmom platformę hostowaną we własnym środowisku, która zapewnia możliwości AI, nie zmuszając ich do rezygnacji z kontroli nad infrastrukturą ani danymi.

Bland to jedyna samodzielnie hostowana platforma głosowej AI, co oznacza, że użytkownik kontroluje każdą warstwę orkiestracji AI: zamianę mowy na tekst, wnioskowanie z użyciem dużego modelu językowego (LLM) i zamianę tekstu na mowę. Dlaczego Bland wybrało takie podejście i jakie były największe wyzwania techniczne związane z przejęciem kontroli nad całym stosem głosowej AI?

Zdecydowaliśmy się samodzielnie hostować rozwiązanie i kontrolować każdą jego warstwę — od automatycznego rozpoznawania mowy (ASR), przez wnioskowanie z użyciem dużego modelu językowego (LLM), po zamianę tekstu na mowę (TTS) — z trzech powodów: opóźnienia w rozmowie krótszego niż 1 sekunda, ścisłej ochrony prywatności danych oraz wysokiej niezawodności operacyjnej.

Łączenie w szereg rozmaitych zewnętrznych usługodawców powoduje kumulowanie się opóźnień. Nakładają się na siebie opóźnienia związane z przesyłaniem danych w obie strony przez sieć, niezależnymi kolejkami i uruchamianiem usług od zera. W rezultacie pojawiają się nienaturalne pauzy, które zakłócają płynność rozmowy.

Umieszczając nasze modele w jednym środowisku wykonawczym i eliminując zależności od interfejsów API firm zewnętrznych, pozbywamy się tych opóźnień. Daje nam to również pełną suwerenność nad danymi: poufne strumienie głosowe i transkrypcje nigdy nie trafiają do zewnętrznych dostawców najnowocześniejszych modeli.

Największe wyzwania techniczne dotyczyły zarządzania opóźnieniami, synchronizacji strumieni danych i planowania zadań GPU przy dużej współbieżności. Dwukierunkowa komunikacja głosowa w czasie rzeczywistym wymaga płynnego generowania tokenów w strumieniu. Silnik TTS musi zacząć syntezować dźwięk, zanim LLM skończy generować zdanie.

Aby to osiągnąć, opracowaliśmy własne silniki wnioskowania, potoki spekulacyjnego dekodowania o niskim opóźnieniu oraz adaptacje modeli akustycznych. Razem zapobiegają one zniekształceniom dźwięku, zarządzają naprzemiennością wypowiedzi i sprawnie obsługują przerwania ze strony użytkownika — a przy tym nie dopuszczają do przeciążenia pamięci GPU.

Wiele platform głosowej AI łączy usługi transkrypcji, wnioskowania i generowania mowy pochodzące od różnych dostawców zewnętrznych. Jakie korzyści i kompromisy inżynieryjne wiążą się z tym, że Bland samodzielnie kontroluje i obsługuje większą część tego stosu?

Największą zaletą jest możliwość kontrolowania opóźnień na każdym etapie. Między ASR, LLM i TTS nie ma żadnych opóźnień sieciowych, dzięki czemu możemy uruchamiać zunifikowane potoki strumieniowe, optymalizować rozwiązanie między warstwami i ściśle kontrolować czas do pierwszego bajtu. Taki poziom kontroli jest po prostu nieosiągalny, gdy każdy element pochodzi od innego dostawcy.

Drugą zaletą jest jednolity zakres bezpieczeństwa i zgodności z przepisami. Dane nigdy nie opuszczają kontrolowanego przez nas środowiska, więc nagrania i transkrypcje klientów pozostają w obrębie zweryfikowanego przez nas obszaru. Eliminuje to ryzyko związane z podwykonawcami przetwarzającymi dane i znacznie upraszcza zachowanie zgodności z HIPAA, SOC 2 i PCI DSS. Każdy, kto przeszedł audyt bezpieczeństwa dostawcy, wie, jak duże ma to znaczenie.

Trzecią zaletą jest przewidywalność kosztów. Nie płacimy zewnętrznym dostawcom narzutów za token ani minutę korzystania z interfejsów API modeli bazowych, dlatego nasze koszty jednostkowe pozostają przewidywalne w przedsiębiorstwach działających na dużą skalę. A ponieważ modele należą do nas, możemy bezpośrednio dostrajać akustykę, prozodię i wagi związane z wnioskowaniem w konkretnych zadaniach.

Nic z tego nie jest jednak darmowe. Takie podejście wymaga rozbudowanej infrastruktury i dużych nakładów na procesory GPU. Zarządzanie dużymi flotami dedykowanych procesorów GPU wymaga zaawansowanego planowania, orkiestracji i mechanizmów przełączania awaryjnego między regionami, a koszty sprzętu są wysokie.

Bierzemy też na siebie obowiązek utrzymania i specjalizacji modeli. Nie możemy zlecić zewnętrznym dostawcom badań nad najnowocześniejszymi rozwiązaniami. Zamiast tego stale pracujemy nad trenowaniem, oceną i utrzymywaniem własnych modeli, przystosowanych do różnych akcentów, warunków z szumem w tle i języków.

W naszym przypadku warto ponieść ten koszt.

Bland otrzymała w sierpniu certyfikat klasy A FedRAMP 20x i twierdzi, że jest pierwszą platformą głosowej AI, która go zdobyła. Większość czytelników nie będzie wiedziała, czym 20x różni się od starszego FedRAMP. Czym jest klasa A i co trzeba było wykazać, aby ją uzyskać?

FedRAMP 20x to zmodernizowane, natywne dla chmury ramy wprowadzone na mocy skonsolidowanych zasad FedRAMP na 2026 rok (CR26). W starszym procesie wszystko klasyfikowano według poziomów wpływu FIPS 199 (niskiego, umiarkowanego i wysokiego), a procedura ta słynęła z nadmiaru dokumentacji. W FedRAMP 20x zastąpiono je klasami certyfikacji oznaczonymi literami: A, B, C i D.

Klasa A to podstawowy poziom. Jest przeznaczona specjalnie dla komercyjnych dostawców usług chmurowych (CSP), którzy mają już dojrzałe programy bezpieczeństwa i chcą wejść na rynek federalny. Można ją traktować jako punkt wejścia, a nie cel sam w sobie. Uzyskuje się uznawany certyfikat programu, wydawany bezpośrednio przez Biuro Zarządzania Programem FedRAMP (PMO), a następnie ma się 2 lata na przejście do klasy B, C lub D.

Aby to osiągnąć, musieliśmy wykazać się w czterech obszarach. Po pierwsze, przedstawić aktualny, zweryfikowany audyt SOC 2 typu II obejmujący podstawowe zasady bezpieczeństwa, poufności i dostępności. Po drugie, jasno określić i logicznie odizolować granicę federalnej usługi chmurowej obejmującą nasze usługi głosowe, SMS i czat.

Po trzecie, wdrożyć podstawowy zestaw obowiązkowych kluczowych wskaźników bezpieczeństwa FedRAMP 20x (KSI) i zapewnić gotowość do ciągłego monitorowania. Obejmuje to skanowanie pod kątem luk w zabezpieczeniach, procedury reagowania na incydenty, egzekwowanie kontroli dostępu oraz ciągłe raportowanie bezpieczeństwa w formacie czytelnym dla maszyn.

Właśnie w czwartym obszarze posiadanie własnego stosu technologicznego naprawdę się opłaciło. Musieliśmy potwierdzić, że transkrypcja, wnioskowanie i synteza mowy odbywają się wyłącznie w granicach autoryzowanego kontenera Bland, bez przekazywania danych federalnych niezweryfikowanym zewnętrznym dostawcom najnowocześniejszych rozwiązań AI. Dla platformy złożonej z rozwiązań zewnętrznych dostawców spełnienie tego wymogu byłoby bardzo trudne.

Bland obsługuje wdrożenia obejmujące zarówno prywatne chmury VPC, jak i dedykowaną infrastrukturę GPU lokalnie. Jak zmienia się architektura w zależności od modelu wdrożenia, zwłaszcza pod względem opóźnień, skalowania i wymagań infrastrukturalnych?

Krótko mówiąc, im bliżej wdrożenia lokalnego, tym niższe opóźnienia i większa kontrola, ale mniejsza elastyczność.

Zacznijmy od opóźnień. Wdrożenia lokalne i dedykowane VPC ograniczają ruch przez sieci zewnętrzne, ponieważ znajdują się tuż obok wewnętrznych łączy telefonicznych przedsiębiorstwa i bram SIP. W przypadku prywatnej chmury VPC, na przykład w AWS lub GCP, opóźnienia zależą od sieci w obrębie regionu i połączeń międzysieciowych z chmurą. Dedykowany sprzęt lokalny bezpośrednio na serwerach idzie o krok dalej. Całkowicie eliminuje warstwy wirtualizacji hipernadzorcy i routing przez publiczny internet, zapewniając najniższy możliwy jitter akustyczny.

Różnica staje się widoczna przy skalowaniu. W chmurowym VPC skalujemy poziomo dzięki elastycznej orkiestracji, na przykład automatycznie skalując klastry Kubernetes obsługiwane przez chmurowe instancje GPU, tak aby pojemność dynamicznie dostosowywała się do nagłego wzrostu liczby połączeń. Wdrożenie lokalne nie działa w ten sposób. Działamy w ramach stałego limitu fizycznej mocy obliczeniowej GPU, co oznacza konieczność ścisłej kontroli przyjmowania połączeń, stosowania zasad kolejkowania i statycznego przydzielania sprzętu na podstawie szczytowej liczby równoczesnych połączeń. Trzeba z wyprzedzeniem przygotować się na najbardziej intensywny dzień.

Wymagania infrastrukturalne również znacznie się różnią. Wdrożenia w prywatnym VPC mogą korzystać z zarządzanej pamięci masowej w chmurze, natywnego IAM i zarządzania sekretami przez dostawcę chmury. Instalacje lokalne wymagają dedykowanych, montowanych w szafach klastrów GPU (na przykład akceleratorów klasy enterprise firmy NVIDIA), lokalnych sieci o dużej przepustowości, sprzętowych modułów bezpieczeństwa (HSM) lub lokalnych sejfów kluczy oraz lokalnych kolektorów danych telemetrycznych. Całość musi działać w środowiskach uruchomieniowych kontenerów klasy enterprise, które mogą pracować w całkowicie odizolowanych od sieci lub ograniczających ruch wychodzący środowiskach.

Bland pozwala przedsiębiorstwom kontrolować wydania, utrzymywać oddzielne środowiska testowe i wdrażać nowe wersje pilotażowo w części rzeczywistych połączeń, zanim udostępnią je szerzej. Dlaczego tradycyjne praktyki wydawania oprogramowania stają się szczególnie ważne, gdy agenci AI trafiają do środowisk produkcyjnych obsługujących klientów?

To dlatego, że agenci AI nie działają tak jak tradycyjne oprogramowanie dla przedsiębiorstw.

Oprogramowanie deterministyczne za każdym razem działa tak samo. Generatywni agenci AI są probabilistyczni i niedeterministyczni. Nieznaczna zmiana promptu, aktualizacja wag modelu lub zmiana ścieżki działania może nieumyślnie doprowadzić do pogorszenia jakości rozmowy, halucynacji lub naruszenia zasad zgodności. Często sama zmiana w żaden sposób nie sygnalizuje, że może do tego dojść.

Dlatego dotychczasowa dyscyplina wydawania nowych wersji jest dziś ważniejsza, a nie mniej ważna. Odizolowane środowiska testowe i rygorystyczne testy regresji na podstawie historycznych korpusów rozmów pozwalają wychwycić wiele problemów, zanim cokolwiek trafi do użytkowników. Wdrożenia kanarkowe idą o krok dalej. Nową wersję udostępnia się określonemu, kontrolowanemu odsetkowi rozmów na żywo i monitoruje wskaźniki w czasie rzeczywistym, takie jak spadek pozytywnego nastawienia, odsetek realizacji celów, nagłe wzrosty opóźnień oraz sygnały wyzwalające eskalację lub przekazanie rozmowy. Wszystko to odbywa się, zanim z nową wersją zetknie się szersza grupa klientów.

To stawka sprawia, że nie można z tego zrezygnować. W obsłudze klienta, likwidacji szkód czy zarządzaniu kontami awaria może narazić firmę na konsekwencje regulacyjne albo poważnie zaszkodzić jej marce. Kontrolowane wdrożenia kanarkowe i natychmiastowe wycofywanie zmian pozwalają nie dopuścić do tego, by nieudana aktualizacja przerodziła się w złą prasę.

Banki, organizacje ochrony zdrowia, ubezpieczyciele i agencje rządowe często muszą pokonać znacznie wyższe bariery przy wdrażaniu generatywnej AI niż inne firmy. Z waszych rozmów z tymi organizacjami wynika, co dziś faktycznie powstrzymuje szersze wdrażanie głosowej AI: bezpieczeństwo, suwerenność danych, niezawodność, złożoność integracji, zamówienia czy coś innego?

Zdecydowanie bezpieczeństwo i suwerenność danych, a tuż za nimi złożoność integracji i przestarzała architektura. To stały wniosek z naszych rozmów z przedstawicielami bankowości, ochrony zdrowia, ubezpieczeń i administracji rządowej.

Jeśli chodzi o bezpieczeństwo, organizacje podlegające ścisłym regulacjom po prostu nie mogą zaakceptować architektury, w której wrażliwe strumienie audio, chronione informacje zdrowotne (PHI) lub niepubliczne dane osobowe przekraczają granice zewnętrznych interfejsów API albo są przechowywane przez zewnętrznych dostawców modeli na potrzeby trenowania. Dla tych klientów możliwość audytu, gwarancje nieprzechowywania danych oraz rygorystyczne wymogi zgodności, takie jak HIPAA, FedRAMP i PCI DSS, nie są opcjonalnymi udogodnieniami. To podstawowe warunki. Jeśli nie można ich spełnić, rozmowy zwykle na tym się kończą.

Kolejną przeszkodą jest integracja. Wiele z tych przedsiębiorstw nadal korzysta z przestarzałych, lokalnych systemów PBX, złożonych systemów IVR oraz rozproszonych podstawowych systemów ewidencji, takich jak Epic lub Cerner w ochronie zdrowia czy systemy mainframe w bankowości. Połączenie ścieżek konwersacyjnych z działającym w czasie rzeczywistym, dwukierunkowym dostępem do odczytu i zapisu przez API o niskich opóźnieniach w tych środowiskach wiąże się ze znacznym nakładem pracy integracyjnej.

Kolejne kwestie to niezawodność i ryzyko halucynacji. Zespoły prawne, ds. zarządzania ryzykiem i zamówień słusznie obawiają się, że autonomiczny agent głosowy może udzielać nieprawidłowych porad finansowych, medycznych lub dotyczących regulacji. Zanim zgodzą się na wdrożenie na dużą skalę w środowisku produkcyjnym, oczekują szczegółowych mechanizmów ochronnych, deterministycznych awaryjnych ścieżek konwersacji i jasno określonych sposobów przekazywania sprawy człowiekowi.

Dziękujemy za świetny wywiad. Czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Bland.