Juan E. Riojas, direttore informatico di Bland – Intervista

Juan E. Riojas, direttore dei sistemi informativi di Bland, è un dirigente esperto nei settori della tecnologia e dei dati, con una carriera che spazia dall’IT aziendale alla gestione dei dati, dall’analisi alle attività operative e alla trasformazione digitale. Prima di entrare in Bland nel dicembre 2025, è stato direttore dei sistemi informativi presso Twilio e Rackspace Technology, dopo aver ricoperto in precedenza ruoli dirigenziali come direttore dei dati presso Informatica e vicepresidente per la gestione e l’analisi dei dati presso Gogo. Il suo percorso comprende anche posizioni di alto livello in ambito operativo e manageriale presso Dell, Accenture, Expeditors International, OfficeMax e AxonGroup, che gli hanno permesso di maturare una vasta esperienza nella gestione di iniziative tecnologiche e relative ai dati in organizzazioni di grandi dimensioni.

Bland è un’azienda enterprise specializzata nell’intelligenza artificiale vocale, che sviluppa agenti di IA in grado di gestire conversazioni telefoniche in entrata e in uscita, assistenza clienti, pianificazione di appuntamenti, raccolta delle informazioni iniziali, instradamento e altri flussi di lavoro complessi. La sua piattaforma punta a garantire il controllo dello stack tecnologico sottostante: Bland sviluppa e gestisce i propri modelli vocali, linguistici e di sintesi vocale, offrendo al contempo la possibilità di implementazione tramite Bland Cloud, cloud privati virtuali oppure ambienti aziendali completamente autogestiti e isolati da reti esterne. L’azienda si concentra in particolare sui casi d’uso regolamentati e sensibili sotto il profilo della sicurezza, offrendo funzionalità quali percorsi conversazionali, integrazioni con i sistemi di telefonia esistenti, criteri configurabili di conservazione dei dati, controlli degli accessi basati sui ruoli e funzionalità per la conformità aziendale.

Hai ricoperto il ruolo di CIO presso Twilio e Rackspace, sei stato Chief Data Officer presso Informatica e hai trascorso gran parte della tua carriera occupandoti di infrastrutture di comunicazione e dati aziendali. Cosa ti hanno insegnato queste esperienze sugli ostacoli che le aziende incontrano nell’adozione dell’IA e in che modo hanno influenzato la piattaforma self-hosted che stai sviluppando ora in Bland?

La mia esperienza presso Twilio, Rackspace e Informatica mi ha insegnato che il principale ostacolo all’IA in ambito aziendale non è la tecnologia, ma la fiducia, il controllo e la capacità di operare in sicurezza su larga scala. Le aziende devono sapere dove risiedono i loro dati, chi li controlla e se l’IA può integrarsi nei framework di sicurezza e governance che hanno impiegato anni a costruire. Questo ha plasmato il nostro approccio in Bland: offrire alle aziende una piattaforma self-hosted che garantisce la potenza dell’IA senza costringerle a rinunciare al controllo delle proprie infrastrutture o dei propri dati.

Bland è l’unica piattaforma di IA vocale self-hosted: questo significa che controlli ogni livello dell’orchestrazione dell’IA, dalla conversione del parlato in testo all’inferenza degli LLM, fino alla sintesi vocale. Perché Bland ha scelto questa strada e quali sono state le sfide tecniche più difficili nel gestire internamente l’intero stack dell’IA vocale?

Abbiamo scelto di ospitare internamente e gestire ogni livello, dal riconoscimento automatico del parlato (ASR) al ragionamento dei modelli linguistici di grandi dimensioni (LLM), fino alla sintesi vocale (TTS), per tre ragioni: una latenza conversazionale inferiore a un secondo, rigorosi limiti alla circolazione dei dati e un’elevata affidabilità operativa.

Quando si collegano in sequenza fornitori esterni diversi, i ritardi si sommano. I passaggi di rete di andata e ritorno, i tempi di attesa nelle code indipendenti e gli avvii a freddo si accumulano. Il risultato è quella pausa innaturale che interrompe il flusso della conversazione.

Collocando i nostri modelli nello stesso ambiente di esecuzione unificato ed eliminando la dipendenza dalle API di terze parti, evitiamo questi passaggi. Otteniamo inoltre la piena sovranità sui dati: i flussi vocali sensibili e le trascrizioni non vengono mai esposti a fornitori esterni di modelli di frontiera.

Le sfide tecniche più difficili riguardavano l’orchestrazione della latenza, la sincronizzazione dei flussi e la pianificazione delle GPU in condizioni di concorrenza elevata. Le conversazioni vocali bidirezionali in tempo reale richiedono una generazione fluida dei token in streaming. Il motore TTS deve iniziare a sintetizzare l’audio prima ancora che l’LLM abbia finito di generare la frase.

Per riuscirci, abbiamo sviluppato motori di inferenza personalizzati, pipeline di decodifica speculativa a bassa latenza e adattamenti dei modelli acustici. Nel loro insieme, queste soluzioni evitano le oscillazioni, gestiscono l’alternanza dei turni di conversazione e rispondono con naturalezza alle interruzioni degli utenti, senza saturare la memoria della GPU.

Molte piattaforme di IA vocale combinano servizi di trascrizione, ragionamento e generazione vocale offerti da diversi fornitori terzi. Quali vantaggi e compromessi ingegneristici comporta la scelta di Bland di gestire internamente una parte maggiore di questo stack?

Il vantaggio principale è il controllo della latenza dall’inizio alla fine. Non c’è alcun overhead di rete tra ASR, LLM e TTS: possiamo quindi eseguire pipeline di streaming unificate, ottimizzare i diversi livelli e mantenere uno stretto controllo sul tempo al primo byte. È un livello di controllo impossibile da ottenere quando ogni componente proviene da un fornitore diverso.

Il secondo vantaggio è disporre di un perimetro unificato per la sicurezza e la conformità. I dati non escono mai dall’ambiente sotto il nostro controllo, quindi l’audio e le trascrizioni dei clienti rimangono all’interno del perimetro verificato. Questo elimina i rischi legati ai sub-responsabili del trattamento di terze parti e semplifica notevolmente la conformità a HIPAA, SOC 2 e PCI DSS. Chiunque abbia affrontato una verifica di sicurezza di un fornitore sa quanto questo sia importante.

Il terzo vantaggio è la prevedibilità dei costi. Non paghiamo maggiorazioni per token o al minuto sulle API di modelli di base esterni, perciò i nostri costi unitari rimangono prevedibili su scala aziendale. Inoltre, poiché i modelli sono nostri, possiamo ottimizzare direttamente l’acustica, la prosodia e i pesi di ragionamento specifici per le diverse attività.

Tutto questo, però, ha un costo. Questo approccio richiede infrastrutture e ingenti investimenti in GPU. Gestire grandi flotte di GPU dedicate richiede sistemi sofisticati di pianificazione, orchestrazione e failover tra più regioni, oltre a comportare costi hardware elevati.

Ci facciamo carico anche della manutenzione e della specializzazione dei modelli. Non possiamo delegare la ricerca di frontiera a fornitori esterni. Ci assumiamo invece il lavoro ingegneristico continuo necessario per addestrare, valutare e mantenere modelli sviluppati internamente, in grado di gestire accenti diversi, rumori di fondo e lingue differenti.

Per noi, questo compromesso vale la pena.

Bland ha ottenuto la certificazione FedRAMP 20x Class A ad agosto e afferma di essere la prima piattaforma di IA vocale a conseguirla. La maggior parte dei lettori non saprà in cosa FedRAMP 20x si differenzi dal FedRAMP tradizionale. Che cos’è la Class A e che cosa avete dovuto dimostrare concretamente per ottenerla?

FedRAMP 20x è il framework modernizzato e nativo per il cloud introdotto nell’ambito delle FedRAMP Consolidated Rules per il 2026 (CR26). Il processo tradizionale classificava tutto in base ai livelli di impatto FIPS 199 (Low, Moderate e High) ed era noto per l’enorme quantità di documentazione richiesta. 20x sostituisce questi livelli con classi di certificazione contrassegnate da lettere: A, B, C e D.

La Class A è il livello di accesso. È pensata specificamente per i fornitori commerciali di servizi cloud (CSP) che dispongono già di programmi di sicurezza maturi e vogliono accedere al mercato federale. È una porta d’ingresso, non una destinazione definitiva. Si ottiene una certificazione di programma riconosciuta, rilasciata direttamente dal FedRAMP Program Management Office (PMO), dopodiché si hanno 2 anni per passare alla Class B, C o D.

Per arrivarci, abbiamo dovuto dimostrare quattro cose. Primo, disporre di un esame SOC 2 Type II aggiornato e verificato, che coprisse i principi fondamentali di sicurezza, riservatezza e disponibilità. Secondo, definire con chiarezza e isolare logicamente il perimetro del servizio cloud federale, includendovi i nostri servizi vocali, SMS e chat.

Terzo, attuare le misure di base previste dai FedRAMP 20x Key Security Indicators (KSI) obbligatori ed essere pronti al monitoraggio continuo. Ciò comprende la scansione delle vulnerabilità, le procedure di risposta agli incidenti, l’applicazione dei controlli di accesso e la produzione continua di report di sicurezza leggibili dalle macchine.

Il quarto requisito è quello per cui possedere l’intero stack si è rivelato davvero vantaggioso. Abbiamo dovuto verificare che la trascrizione, il ragionamento e la sintesi vocale avvenissero esclusivamente entro il perimetro dei container autorizzato di Bland, senza trasmettere dati federali a fornitori terzi non verificati di IA di frontiera. Per una piattaforma assemblata con componenti di fornitori esterni, è un requisito molto difficile da soddisfare.

Bland supporta implementazioni che vanno dai VPC di cloud privato alle infrastrutture GPU dedicate on-premise. In che modo cambia l’architettura passando da un modello di implementazione all’altro, soprattutto per quanto riguarda latenza, scalabilità e requisiti infrastrutturali?

In breve, più ci si avvicina a un’implementazione on-premise, maggiori sono i vantaggi in termini di latenza e controllo, ma minore è l’elasticità.

Partiamo dalla latenza. Sia le implementazioni on-premise sia i VPC dedicati riducono al minimo il transito attraverso reti esterne, perché si trovano proprio accanto alle linee telefoniche interne e ai gateway SIP dell’azienda. In un VPC di cloud privato, per esempio su AWS o GCP, la latenza dipende dalla rete all’interno della regione e dalle interconnessioni cloud. L’hardware bare metal dedicato on-premise si spinge oltre: elimina del tutto i livelli di virtualizzazione dell’hypervisor e l’instradamento attraverso Internet pubblica, garantendo il jitter acustico più basso possibile.

È nella scalabilità che emerge il compromesso. In un VPC cloud, aumentiamo la capacità orizzontalmente grazie a un’orchestrazione elastica, ad esempio con cluster Kubernetes a scalabilità automatica supportati da istanze GPU cloud, così da adeguare dinamicamente la capacità quando il volume delle chiamate aumenta. In un’implementazione on-premise, invece, le cose funzionano diversamente. Si opera entro il limite della capacità fisica fissa delle GPU: servono quindi controlli rigorosi sull’ammissione, criteri di accodamento e un approvvigionamento hardware statico basato sul picco delle chiamate simultanee. È necessario pianificare in anticipo tenendo conto della giornata più intensa.

Anche i requisiti infrastrutturali sono piuttosto diversi. Le implementazioni su VPC privati possono affidarsi allo storage cloud gestito, all’IAM nativo e alla gestione dei segreti tramite servizi cloud. Le installazioni on-premise richiedono cluster GPU dedicati montati su rack (per esempio, acceleratori enterprise NVIDIA), fabric di rete locali ad alta velocità, moduli di sicurezza hardware (HSM) o depositi locali di chiavi e strumenti locali di raccolta della telemetria. Inoltre, tutto deve funzionare su runtime di container aziendali compatibili con ambienti completamente isolati o con accesso in uscita limitato.

Bland permette alle aziende di controllare i rilasci, mantenere ambienti di test separati e provare le nuove versioni su una parte delle chiamate reali prima di distribuirle su scala più ampia. Perché le pratiche tradizionali di rilascio del software stanno diventando particolarmente importanti ora che gli agenti di IA vengono impiegati in produzione a contatto con i clienti?

Perché gli agenti di IA non si comportano come i tradizionali software aziendali.

Il software deterministico si comporta sempre allo stesso modo. Gli agenti di IA generativa sono probabilistici e non deterministici. Una modifica minima al prompt, un aggiornamento dei pesi del modello o un cambiamento del flusso operativo possono causare inavvertitamente regressioni nella conversazione, allucinazioni o violazioni delle policy di conformità. Spesso, nulla nella modifica in sé lascia intuire che ciò possa accadere.

Ecco perché oggi la vecchia disciplina di rilascio è più importante, non meno. Ambienti di preproduzione isolati e rigorosi test di regressione basati su corpus di chiamate storiche consentono di individuare molti problemi prima che qualcosa venga messo in produzione. Le distribuzioni canary fanno un passo ulteriore. Si distribuisce la nuova versione a una percentuale controllata delle chiamate in corso e si monitorano metriche in tempo reale, come il calo del sentiment, i tassi di raggiungimento degli obiettivi, i picchi di latenza e le condizioni che attivano l’escalation o il passaggio a un operatore. Tutto questo avviene prima che la versione venga resa disponibile a una più ampia base di clienti.

È la posta in gioco a rendere questa precauzione irrinunciabile. Nel servizio clienti, nella gestione dei sinistri o nella gestione dei conti, un malfunzionamento può comportare rischi normativi o gravi danni al marchio. Un rilascio progressivo disciplinato e la possibilità di ripristinare immediatamente la versione precedente sono ciò che impedisce a un aggiornamento problematico di trasformarsi in una brutta notizia.

Banche, organizzazioni sanitarie, compagnie assicurative ed enti governativi spesso devono superare ostacoli molto più impegnativi rispetto ad altre aziende per implementare l’IA generativa. Nelle conversazioni con queste organizzazioni, che cosa impedisce davvero oggi una maggiore diffusione dell’IA vocale: sicurezza, sovranità dei dati, affidabilità, complessità di integrazione, appalti o altro?

Sicurezza e sovranità dei dati, di gran lunga; subito dopo, a breve distanza, complessità di integrazione e architetture legacy. È un quadro che si ripete nelle nostre conversazioni con il settore bancario, sanitario, assicurativo e governativo.

Sul fronte della sicurezza, le organizzazioni soggette a una regolamentazione rigorosa non possono semplicemente tollerare un’architettura in cui flussi audio sensibili, informazioni sanitarie protette (PHI) o informazioni personali non pubbliche attraversino i perimetri di API esterne o vengano conservati da fornitori terzi di modelli per l’addestramento. Per questi clienti, la verificabilità, le garanzie di non conservazione dei dati e rigorosi requisiti di conformità, come HIPAA, FedRAMP e PCI DSS, non sono optional: sono prerequisiti fondamentali. Se non si è in grado di soddisfarli, di solito la conversazione finisce lì.

Il passo successivo è l’integrazione. Molte di queste aziende utilizzano ancora sistemi PBX locali legacy, IVR complessi e sistemi di riferimento centrali frammentati, come Epic o Cerner nel settore sanitario o sistemi centrali basati su mainframe nel settore bancario. Integrare i flussi conversazionali con l’accesso API bidirezionale in tempo reale, a bassa latenza e in lettura/scrittura in questi ambienti comporta notevoli oneri di integrazione.

Ci sono poi l’affidabilità e il rischio di allucinazioni. È comprensibile che i team legali, della gestione del rischio e degli acquisti temano che un agente vocale autonomo fornisca consigli finanziari, medici o normativi inesatti. Prima di autorizzarne l’impiego su scala produttiva, vogliono misure di protezione granulari, procedure alternative conversazionali deterministiche e percorsi chiari di escalation verso operatori umani.

Grazie per la bella intervista. I lettori che desiderano saperne di più possono visitare Bland.