Para publicación inmediata · Londres, 28 de mayo de 2026
Una especificación independiente del proveedor permite que los agentes de IA de voz, los sistemas IVR, los centros de contacto y los operadores humanos transfieran conversaciones en directo, con identidad, intención, consentimiento y continuidad multimedia verificados, a través de plataformas de la competencia. La gestión multivendedor es un requisito previo para cualquier lanzamiento de la versión 1.0.
Cloudax publicó hoy el borrador público de OHP: el protocolo de transferencia abierta, una especificación independiente del proveedor para transferir conversaciones de voz en vivo entre agentes de IA, IVR, centros de contacto y personal humano. El borrador está disponible en github.com/OpenHandoffProtocol/OHP bajo una licencia Apache-2.0.
OHP cierra una brecha que la industria de la voz ha sorteado durante más de una década: no existe un método común para que una IA de voz de un proveedor transfiera una conversación en vivo, con identidad verificada del llamante, intención, estado de la ranura, consentimiento y continuidad de medios, a una IA de voz, IVR o operador humano de un proveedor diferente. Cada capa inferior a la conversación ya cuenta con un estándar. La conversación en sí misma no.
El problema, en cuatro números
La brecha se manifiesta en la experiencia del cliente y en los costes, que son aspectos medibles, no solo en los diagramas de arquitectura.
Índice CX 2025 de Forrester: se solicita a las personas que llaman que repitan la información después de una transferencia del sistema IVR a un agente.
Estándares de la industria que cubren la transferencia del estado de la conversación entre IA. SIP, WebRTC, MCP y OVON poseen cada uno una capa diferente.
Se han observado formatos de transferencia propietarios en Genesys, NICE, Avaya, Twilio, Vapi, Retell, Bland, ElevenLabs, Cloudax, Pindrop, Cresta, PolyAI, Cognigy y Voiceflow.
Coste medio adicional por llamada derivado de la reautenticación y el redescubrimiento en la transferencia en caliente (auditoría interna de Cloudax, n = 412.000 transferencias SIP, primer trimestre de 2026).
“Cada capa inferior a la conversación ya cuenta con un estándar: SIP para señalización, WebRTC para medios, MCP para el uso de herramientas y OpenTelemetry para la observabilidad. La conversación en sí misma no. OHP es la capa que falta, y es demasiado importante como para que un solo proveedor, incluido nosotros, sea el único responsable.”
Lo que define OHP
OHP es un formato de cable escalonado para la transferencia de conversaciones en vivo. se compone con, no reemplaza, SIP, WebRTC, MCP, OVON Open Floor y planos de control CPaaS existentes. La especificación define cinco capas componibles.
- L4: Envolvente del estado de la conversación (CSE). Un documento JSON/CBOR canónico y firmado que contiene la identidad verificada del llamante, la pila de intenciones, el estado de la ranura, la transcripción censurada, sugerencias de memoria del modelo, recibos de consentimiento y pruebas de continuidad de los medios.
- L3: Plano de control. Cinco verbos idempotentes, ack-ed:
PROPOSE,ACCEPT,REJECT,ASSUME,RETURN, más una reservadaINCIDENTVerbo para notificar incidentes graves según el artículo 73 de la Ley de IA de la UE. - L2: Enlaces de transporte. SIP INFO, WebSocket, HTTP y gRPC, por lo que el mismo protocolo se mantiene sin cambios en los planos de telefonía, web y operaciones.
- L1: Confianza e identidad. Firmas híbridas Ed25519 + ML-DSA-65 (con protección post-cuántica, FIPS 204), sellado HPKE por destinatario, credenciales verificables SD-JWT, recibos de consentimiento ISO/IEC 27560 y un registro de transparencia al estilo Sigstore.
- L0: Continuidad de los medios. Sugerencias SDP re-INVITE, reenvío de pista SFU y una comprobación opcional de huella digital de audio que vincula cada paquete a una rama de llamada específica.
Cuatro niveles de conformidad: desde el nivel mínimo de adopción hasta el nivel máximo regulado.
OHP está diseñado para que un pequeño proveedor pueda enviar la iluminación de piso en un fin de semana largo, mientras que una empresa regulada puede iluminar el techo sin cambiar el formato del cableado. Cada nivel es un superconjunto estricto del nivel inferior.
Documento JSON firmado con cinco verbos transmitido por TLS. Suficiente para la navegación anónima en IVR, la programación de citas, las preguntas frecuentes y la continuidad de la llamada (¿dónde estaba cuando se cortó la llamada?). Cualquier proveedor que pueda codificar una estructura en JSON y enviarla mediante HTTPS puede implementarla en cuestión de días.
Agrega JWS Ed25519 independiente sobre CBOR canónico, publicación de JWK Set e idempotencia de sobre. Suficiente para un servicio al cliente autenticado y sin información de identificación personal.
Añade el sellado por destinatario de HPKE, la divulgación selectiva de SD-JWT VC, recibos de consentimiento ISO/IEC 27560, la restricción del remitente DPoP y la vinculación de huellas digitales RTP. Suficiente para HIPAA PHI mediante referencias FHIR selladas, tokens de red PCI e información de identificación personal transfronteriza bajo un mecanismo de transferencia legal.
Añade firma híbrida post-cuántica, un registro de transparencia al estilo Sigstore, establecimiento de confianza de OpenID Federation y metadatos legibles por máquina de la Ley de IA de la UE: certificación de prácticas prohibidas del artículo 5, registro del artículo 12, estado de supervisión del artículo 14, prueba de divulgación del artículo 50, notificación de incidentes del artículo 73 y punto final del derecho a explicación del artículo 86.
Las cargas de trabajo declaran el nivel mínimo que requieren, y el formato de la transmisión en sí, no la buena voluntad del proveedor ni la documentación de certificación trimestral, rechaza las transferencias que no cumplen con los requisitos. Una empresa regulada puede exigir audience.minTier="sealed" o "regulated" en materia de adquisiciones y contar con un rechazo ejecutable por máquina en el último momento si una contraparte intenta entregar el pago por debajo de ese límite.
Diseñado para datos regulados desde la primera línea.
OHP es el primer formato de transferencia de voz diseñado para ser legible por máquina, conforme a la Ley de IA de la UE y al Sistema de Gestión de IA ISO/IEC 42001. Un único sobre contiene la identidad y versión del sistema de IA, la clasificación de riesgos, la cláusula del Anexo III, la referencia de conformidad CE, las referencias AIIA y FRIA, la cadena de proveedores de GPAI (Artículo 53), la prueba de divulgación del Artículo 50, la postura de supervisión del Artículo 14 y una cadena de procedencia estructurada por decisión.
Un regulador que analice un único hash de sobre puede reconstruir el panorama completo de la responsabilidad de una conversación: qué sistema de IA procesó la llamada, bajo qué clase de riesgo, qué se reveló a la persona que llamó y cuándo, quién supervisó, qué decisiones tomó el sistema y por qué, y qué modelos anteriores estaban en la cadena, sin herramientas específicas del proveedor y sin acceso a la carga útil.
Toda implementación conforme debe satisfacer las seis.
- Divulgación mínima. El uso de datos personales en formato libre (PAN, CVV, contraseñas, OTP, números de seguridad social completos, plantillas biométricas e información de salud protegida de formato libre) está prohibido en cualquier campo de OHP, en cualquier nivel.
- Divulgación selectiva. Las reclamaciones de identidad utilizan credenciales verificables SD-JWT: los receptores solo ven los atributos a los que tienen derecho contractualmente.
- Confidencialidad total. Los campos sensibles están sellados con HPKE por clave pública del destinatario; los intermediarios enrutan bytes opacos.
- Procedencia criptográfica. JWS híbrido Ed25519 + ML-DSA separado, vinculado a DPoP, anclado a un registro de transparencia.
- El consentimiento y la finalidad son vinculantes. Cada traspaso incluye un recibo de consentimiento ISO/IEC 27560 que especifica la base legal, el propósito, el alcance y la jurisdicción.
- Con plazo definido y revocable. Los sobres llevan
notAfter≤ 5 minutos, vinculado a una llamada específica, con clave revocable e identificadores de consentimiento.
Por qué las normas existentes no cierran la brecha.
Cada capa inferior a la conversación ya tiene un estándar. La conversación en sí no lo tiene, y OHP especifica claramente con qué se compone, en lugar de reemplazarlo.
- SIP / SIP REFER. Configura, transfiere y finaliza las sesiones de voz, pero no tiene carga útil semántica: los encabezados X son ad hoc, presentan pérdidas entre operadores y están limitados a unos pocos cientos de bytes.
- WebRTC + Canal de datos. Define una tubería, no un esquema. Cada proveedor inventa su propio JSON encima.
- MCP. Estandariza la forma en que un modelo llama a las herramientas. Limitado a un único entorno de ejecución de agente, sin tener en cuenta la conversación, la identidad de la persona que llama ni la transferencia de medios.
- Espacio abierto de OVON. Un vocabulario de alto nivel para que los agentes se presenten. Sin vinculación de audio/medios, sin conexión telefónica, sin semántica de consentimiento o retención.
- CCXML / VoiceXML. Programación de IVR en la era anterior a LLM. Sin estado del modelo, sin incrustaciones, sin fragmentos de transmisión.
- Webhooks de CPaaS y datos adjuntos de CC. Limitado a un solo proveedor; unidireccional; sin lugar para un estado de IA y sin capacidad de defensa transfronteriza.
- OpenTelemetry GenAI semconv. Telemetría de solo lectura, no un paquete de transferencia en tiempo de ejecución.
Gobernanza: redactado por Cloudax, propiedad de la industria.
Cloudax publica OHP bajo Apache-2.0 con un modelo de contribución solo DCO y mantiene la escritura solo para la serie v0.x. Antes de cualquier v1.0, la empresa convocará un grupo de trabajo con al menos tres proveedores de IA de voz que no son Cloudax y transferir la gestión a un comité directivo con múltiples proveedores.
El borrador incluye un conjunto de pruebas de conformidad públicas. Cada cambio en la especificación debe ir acompañado de nuevos vectores de prueba, y el ejecutor de pruebas de conformidad es la fuente de información fidedigna sobre lo que significa "hablar OHP".
“Este estándar debe pertenecer a la industria a la que sirve, no a nosotros. Estamos redactando la primera versión y distribuyendo la primera implementación de referencia. Después, nos retiramos a un segundo plano, ocupando un lugar más en la mesa entre muchos.”
Hoja de ruta para la versión 1.0
- v0.1: hoy. Se ha publicado el borrador público, la implementación de referencia y el ejecutor de conformidad. Comienza el contacto con los socios de diseño.
- v0.2. Dos empresas externas se han incorporado; se han publicado los calendarios de las pruebas públicas.
- v0.9 RC. El grupo de trabajo se ha ampliado; se realizará una revisión final del candidato en función del proceso de verificación de conformidad.
- v1.0. El grupo de trabajo liderado por Cloudax se transforma en un comité directivo con representantes de múltiples proveedores.
Socios de referencia para la implementación y el diseño
Cloudax ha publicado una implementación de referencia basada en su plataforma de IA de voz existente, Cloudax Fabric. El ejecutor de conformidad completo, el esquema JSON, las reglas de canonización CBOR y los ejemplos de sobres están disponibles junto con el borrador.
Cloudax busca activamente socios de diseño y participantes para grupos de trabajo en plataformas de centros de contacto, proveedores de CPaaS, entornos de ejecución de IA de voz, proveedores de biometría de voz, proveedores de identidad y empresas de implementación reguladas. Se invita explícitamente a los proveedores que ya utilizan formatos de transferencia propietarios: el diseño escalonado de OHP pretende que la adopción sea un trabajo de fin de semana en el terreno y un informe detallado en la parte superior, no una tarea titánica.
Disponibilidad
Acerca de OHP
OHP (Open Handoff Protocol) es una especificación independiente del proveedor para la transferencia de conversaciones de voz en directo: contexto, intención, estado, identidad, consentimiento y medios, entre agentes de IA de voz, IVR, centros de contacto y personas. Está diseñado para integrarse en planos de control SIP, WebRTC y HTTP/WS sin imponer un único entorno de ejecución, modelo o proveedor de telefonía, y está diseñado desde el principio para flujos de datos regulados, de modo que el estado de autenticación, los resultados de ID&V, las instrucciones de pago, el contexto sanitario y otros datos personales sensibles puedan cruzar las fronteras de los proveedores con la misma validez legal que un mensaje ISO 20022 entre bancos.
Acerca de Cloudax
Cloudax desarrolla infraestructura de IA de voz para empresas de sectores regulados. La compañía es la responsable del borrador público de OHP y del mantenimiento de la implementación de referencia inicial. Cloudax solo es propietaria de la serie v0.x de la especificación y se compromete a colaborar con múltiples proveedores antes del lanzamiento de la versión 1.0.
Contacto de prensa y redacción
Editores de especificaciones, consultas de prensa y participación en grupos de trabajo: [email protected]
¿Quieres ayudar a dar forma a OHP? Únete al grupo de trabajo.
Se invita a participar a proveedores, operadores, proveedores de identidad y reguladores. Ya sea que implemente Core en un fin de semana largo o que exija Regulated en sus procesos de adquisición, OHP solo funciona si es el estándar que implementa toda la industria, no el que Cloudax desarrolla por su cuenta.
