Per diffusione immediata · Londra, 28 maggio 2026
Una specifica indipendente dal fornitore consente agli agenti di intelligenza artificiale vocale, ai sistemi IVR, ai contact center e agli operatori umani di trasferire le conversazioni in tempo reale, con identità, intento, consenso e continuità multimediale verificati, tra piattaforme diverse. La gestione multi-vendor è un prerequisito per qualsiasi rilascio della versione 1.0.
Cloudax ha pubblicato oggi la bozza pubblica di OHP: il protocollo di trasferimento aperto, una specifica indipendente dal fornitore per il trasferimento di conversazioni vocali in tempo reale tra agenti AI, IVR, contact center e personale umano. La bozza è disponibile all'indirizzo github.com/OpenHandoffProtocol/OHP sotto licenza Apache-2.0.
OHP colma una lacuna che il settore della telefonia vocale ha cercato di aggirare per oltre un decennio: non esiste un metodo condiviso che permetta a un'IA vocale di un fornitore di trasferire una conversazione in tempo reale, con identità del chiamante verificata, intento, stato della sessione, consenso e continuità multimediale, a un'IA vocale, a un IVR o a un operatore umano di un fornitore diverso. Ogni livello al di sotto della conversazione ha già uno standard. La conversazione in sé no.
Il problema, in quattro numeri
Il divario si manifesta nell'esperienza del cliente e nei costi misurabili, non solo negli schemi architetturali.
Indice CX 2025 di Forrester: ai chiamanti viene chiesto di ripetere le informazioni dopo un trasferimento da IVR a operatore.
Standard di settore che regolano il passaggio di stato delle conversazioni tra IA. SIP, WebRTC, MCP e OVON gestiscono ciascuno un livello diverso.
Formati di trasferimento proprietari osservati in Genesys, NICE, Avaya, Twilio, Vapi, Retell, Bland, ElevenLabs, Cloudax, Pindrop, Cresta, PolyAI, Cognigy e Voiceflow.
Costo medio aggiuntivo per chiamata derivante da riautenticazione e riscoperta su trasferimento a caldo (audit interno di Cloudax, n = 412.000 trasferimenti SIP, primo trimestre 2026).
“Ogni livello al di sotto della conversazione ha già uno standard: SIP per la segnalazione, WebRTC per i media, MCP per l'utilizzo degli strumenti, OpenTelemetry per l'osservabilità. La conversazione in sé non ne ha uno. OHP è il livello mancante, ed è troppo importante per essere gestito da un singolo fornitore, noi compresi.”
Cosa definisce OHP
OHP è un formato di collegamento a livelli per il passaggio di consegne di conversazioni in tempo reale. si compone con, non sostituisce, SIP, WebRTC, MCP, OVON Open Floor e i piani di controllo CPaaS esistenti. La specifica definisce cinque livelli componibili.
- L4: Inviluppo dello stato di conversazione (CSE). Un documento JSON/CBOR canonico e firmato, contenente l'identità verificata del chiamante, lo stack degli intenti, lo stato dello slot, la trascrizione redatta, i suggerimenti di memoria del modello, le ricevute di consenso e le prove di continuità multimediale.
- L3: Piano di controllo. Cinque verbi idempotenti con ack-ed:
PROPOSE,ACCEPT,REJECT,ASSUME,RETURN, più una riservaINCIDENTverbo per la segnalazione di incidenti gravi ai sensi dell'articolo 73 della legge europea sull'intelligenza artificiale. - L2: Legami di trasporto. SIP INFO, WebSocket, HTTP e gRPC, quindi lo stesso pacchetto viaggia senza modifiche sui piani di telefonia, web e operativi.
- L1: Fiducia e identità. Firme ibride Ed25519 + ML-DSA-65 (con copertura post-quantistica, FIPS 204), sigillo HPKE per destinatario, credenziali verificabili SD-JWT, ricevute di consenso ISO/IEC 27560 e un registro di trasparenza in stile Sigstore.
- L0: Continuità dei media. Suggerimenti SDP re-INVITE, inoltro di traccia SFU e un controllo opzionale dell'impronta audio che associa ogni busta a una specifica tratta di chiamata.
Quattro livelli di conformità: dal livello minimo di adozione al livello massimo regolamentato.
OHP è progettato in modo che un piccolo fornitore possa spedire il livello del pavimento in un lungo fine settimana, mentre un'azienda regolamentata può illuminare il soffitto senza modificare la configurazione dei cavi. Ogni livello è un superset rigoroso di quello sottostante.
Un documento JSON firmato con cinque verbi su TLS. Sufficiente per la navigazione IVR anonima, la pianificazione, le FAQ e la continuità "dove mi trovavo quando la chiamata è caduta?". Implementabile in pochi giorni da qualsiasi fornitore in grado di codificare una struttura in JSON e inviarla tramite POST su HTTPS.
Aggiunge Ed25519 JWS distaccato su CBOR canonico, pubblicazione del set JWK e idempotenza dell'involucro. Sufficiente per un servizio clienti autenticato e non contenente dati personali.
Aggiunge la sigillatura HPKE per destinatario, la divulgazione selettiva SD-JWT VC, le ricevute di consenso ISO/IEC 27560, il vincolo del mittente DPoP e il binding dell'impronta digitale RTP. Sufficiente per le informazioni sanitarie protette (PHI) conformi a HIPAA tramite riferimenti FHIR sigillati, token di rete PCI e dati personali transfrontalieri nell'ambito di un meccanismo di trasferimento lecito.
Aggiunge la firma ibrida post-quantistica, un registro di trasparenza in stile Sigstore, la creazione di trust di OpenID Federation e metadati leggibili automaticamente conformi alla legge europea sull'IA: attestazione di pratiche proibite ai sensi dell'articolo 5, registrazione ai sensi dell'articolo 12, stato di supervisione ai sensi dell'articolo 14, prova di divulgazione ai sensi dell'articolo 50, segnalazione di incidenti ai sensi dell'articolo 73 e endpoint per il diritto di spiegazione ai sensi dell'articolo 86.
I carichi di lavoro dichiarano il livello minimo richiesto e il formato del bonifico stesso, non la buona volontà del fornitore o la documentazione di attestazione trimestrale, rifiuta i trasferimenti non conformi. Un'impresa regolamentata può imporre audience.minTier="sealed" O "regulated" negli appalti e avere un rifiuto automatico e vincolante al momento della transazione se una controparte tenta di trasferire i fondi al di sotto di tale soglia.
Progettato per dati regolamentati fin dalla prima linea
OHP è il primo formato di trasferimento vocale progettato per essere leggibile automaticamente sia per l'AI Act dell'UE che per il sistema di gestione dell'IA ISO/IEC 42001. Un unico documento contiene l'identità e la versione del sistema di IA, la classificazione del rischio, la clausola dell'Allegato III, il riferimento alla conformità CE, i riferimenti AIIA e FRIA, la catena di fornitura GPAI (articolo 53), la prova di divulgazione ai sensi dell'articolo 50, la posizione di supervisione ai sensi dell'articolo 14 e una catena di provenienza strutturata per ogni decisione.
Un ente regolatore che si imbatte in un singolo hash di una busta può ricostruire il quadro completo della responsabilità relativa a una conversazione: quale sistema di intelligenza artificiale ha elaborato la chiamata, in quale classe di rischio, cosa è stato comunicato al chiamante e quando, chi ha supervisionato, quali decisioni ha preso il sistema e perché, e quali modelli a monte erano coinvolti nella catena, senza strumenti specifici del fornitore e senza accesso al payload.
Ogni implementazione conforme deve soddisfare tutti e sei i requisiti.
- Minima divulgazione. L'inserimento di PAN non elaborati, CVV, password, OTP, SSN completi, modelli biometrici e informazioni sanitarie protette (PHI) in formato libero è vietato in qualsiasi campo dell'OHP, a qualsiasi livello.
- Divulgazione selettiva. Le richieste di identità utilizzano credenziali verificabili SD-JWT: i destinatari visualizzano solo gli attributi a cui hanno diritto contrattualmente.
- Riservatezza totale. I campi sensibili sono protetti da HPKE per ogni chiave pubblica del destinatario; gli intermediari instradano byte opachi.
- Provenienza crittografica. Ibrido Ed25519 + ML-DSA distaccato JWS, vincolato a DPoP, ancorato a un registro di trasparenza.
- Vincolante per consenso e finalità. Ogni passaggio di consegne è accompagnato da una ricevuta di consenso ISO/IEC 27560 che specifica la base giuridica, lo scopo, l'ambito di applicazione e la giurisdizione.
- A tempo determinato e revocabile. Le buste trasportano
notAfterDurata massima 5 minuti, associata a una specifica fase della chiamata, con chiave revocabile e identificativi di consenso.
Perché gli standard esistenti non colmano il divario
Ogni livello al di sotto della conversazione ha già uno standard. La conversazione in sé non ne ha, e OHP specifica esplicitamente con cosa si compone, anziché sostituire.
- SIP / SIP REFER. Consente di impostare, trasferire e terminare le sessioni vocali, ma non ha alcun contenuto semantico: le intestazioni X sono ad hoc, subiscono perdite di dati tra i vari operatori e sono limitate a poche centinaia di byte.
- WebRTC + DataChannel. Definisce una pipeline, non uno schema. Ogni fornitore crea il proprio JSON al di sopra.
- MCP. Standardizza il modo in cui un modello chiama gli strumenti. Limitato a un singolo runtime dell'agente, senza alcuna nozione di conversazione, identità del chiamante o trasferimento multimediale.
- OVON Open Floor. Un vocabolario di alto livello per consentire agli agenti di presentarsi. Nessun collegamento audio/mediale, nessuna connessione telefonica, nessuna semantica di consenso o conservazione.
- CCXML / VoiceXML. Scripting IVR dell'era pre-LLM. Nessuno stato del modello, nessun embedding, nessuno streaming parziale.
- Webhook CPaaS e dati allegati CC. Vincolato a un unico fornitore; unidirezionale; nessun spazio per lo stato dell'IA e nessuna difendibilità transfrontaliera.
- OpenTelemetry GenAI semconv. Telemetria di sola lettura, non un'interfaccia di trasferimento dati in fase di esecuzione.
Governance: scritto da Cloudax, di proprietà del settore
Cloudax pubblica OHP sotto licenza Apache-2.0 con un modello di contributo esclusivamente DCO e detiene la licenza solo per la serie v0.x. Prima di qualsiasi v1.0, l'azienda convocherà un gruppo di lavoro con almeno tre fornitori di IA vocale diversi da Cloudax e trasferire la gestione a un comitato direttivo composto da più fornitori.
Una suite di test di conformità pubblica viene fornita insieme alla bozza. Ogni modifica alla specifica deve essere accompagnata da nuovi vettori di test e il test di conformità rappresenta la fonte di riferimento per il significato di "parla OHP".
“Questo standard deve appartenere al settore a cui si rivolge, non a noi. Stiamo scrivendo la prima versione e rilasciando la prima implementazione di riferimento. Dopodiché, ci ritireremo, riprendendo il nostro posto al tavolo delle discussioni.”
Tabella di marcia per la versione 1.0
- v0.1: oggi. Pubblicate la bozza pubblica, l'implementazione di riferimento e il documento di conformità. Inizia il contatto con i partner di progettazione.
- v0.2. Sono arrivati due tecnici esterni; sono state pubblicate le specifiche per i test pubblici.
- v0.9 RC. Gruppo di lavoro ampliato; revisione finale dei candidati rispetto al runner di conformità.
- v1.0. Il gruppo di lavoro guidato da Cloudax si trasforma in un comitato direttivo multi-vendor.
Partner di riferimento per l'implementazione e la progettazione
Cloudax ha pubblicato un'implementazione di riferimento basata sulla sua piattaforma di intelligenza artificiale vocale esistente, Cloudax Fabric. Il runner di conformità completo, lo schema JSON, le regole di canonizzazione CBOR e gli esempi di buste sono disponibili insieme alla bozza.
Cloudax è alla ricerca attiva di partner di progettazione e partecipanti a gruppi di lavoro tra piattaforme per contact center, fornitori di CPaaS, runtime di intelligenza artificiale vocale, fornitori di biometria vocale, fornitori di identità e implementatori aziendali regolamentati. I fornitori che già utilizzano formati di trasferimento proprietari sono esplicitamente invitati: la struttura a livelli di OHP è pensata per rendere l'adozione un fine settimana di lavoro a livello operativo e un pacchetto di prove a livello dirigenziale, non un'operazione complessa.
Disponibilità
Informazioni su OHP
OHP (Open Handoff Protocol) è una specifica indipendente dal fornitore per il trasferimento di conversazioni vocali in tempo reale: contesto, intento, stato, identità, consenso e media, tra agenti di intelligenza artificiale vocale, IVR, contact center e persone. È progettato per essere integrato nei piani di controllo SIP, WebRTC e HTTP/WS senza imporre un singolo runtime, modello o fornitore di telefonia, ed è stato concepito fin dall'inizio per flussi di dati regolamentati in modo che lo stato di autenticazione, i risultati di identificazione e verifica, le istruzioni di pagamento, il contesto sanitario e altri dati personali sensibili possano attraversare i confini del fornitore con la stessa difendibilità legale di un messaggio ISO 20022 tra banche.
Informazioni su Cloudax
Cloudax sviluppa infrastrutture di intelligenza artificiale vocale per aziende operanti in settori regolamentati. L'azienda è l'ente autore della bozza pubblica dell'OHP (Office of Human Policy) e il responsabile della manutenzione dell'implementazione di riferimento iniziale. Cloudax è responsabile solo della serie v0.x della specifica e si impegna a una gestione multi-vendor prima di qualsiasi rilascio della versione 1.0.
Contatti per la stampa e la redazione
Redattori delle specifiche, richieste della stampa e partecipazione ai gruppi di lavoro: [email protected]
Vuoi contribuire a plasmare OHP? Unisciti al gruppo di lavoro.
Fornitori, operatori, provider di identità e autorità di regolamentazione sono invitati a partecipare. Che si distribuisca Core durante un lungo weekend o si imponga Regulated nei propri acquisti, OHP funziona solo se è lo standard implementato dall'intero settore, non quello definito da Cloudax in via esclusiva.
