OpenAI API añade dos rutas de transcripción, pero los nombres de los modelos importan

OpenAI ha ampliado su conjunto de herramientas de transcripción en dos vías: una para audio en vivo y otra para grabaciones terminadas. La OpenAI API ahora aborda ambas cargas de trabajo, pero una discrepancia en la nomenclatura oficial complica el anuncio.

Una publicación para desarrolladores describió GPT-Live-Transcribe para streaming de baja latencia y GPT-Transcribe para archivos asíncronos. Sin embargo, la documentación actual de OpenAI enumera GPT-Realtime-Whisper para la transcripción en vivo y GPT-4o Transcribe para el audio cargado.

Esta discrepancia no elimina el cambio de producto más amplio. OpenAI está convirtiendo el reconocimiento de voz, de un endpoint generalista, en infraestructura específica para cada carga de trabajo, elevando la presión sobre Amazon, Microsoft, Google y proveedores especializados de voz.

La OpenAI API ahora trata de forma distinta el audio en vivo y las grabaciones

El cambio importante no es simplemente otro lanzamiento de modelo. OpenAI está separando la transcripción según el momento en que los desarrolladores necesitan texto utilizable.

La transcripción en vivo convierte un flujo de audio en curso en texto incremental. Sirve para subtítulos, reuniones, emisiones, llamadas de clientes, aulas e interfaces de voz que no pueden esperar a que termine una grabación.

La transcripción de grabaciones comienza después de que ya existe un archivo de audio. Esta vía es adecuada para podcasts, entrevistas, sesiones de investigación, archivos de soporte y otros trabajos donde la integridad importa más que los resultados parciales inmediatos.

La distinción parece sencilla, pero afecta a casi todas las capas de una aplicación. Los productos en vivo necesitan gestión de sesiones, almacenamiento en búfer, detección de turnos, lógica de reconexión y un manejo cuidadoso de las revisiones de la transcripción.

Los flujos de trabajo con archivos tienen requisitos distintos. A menudo necesitan colas, estados de trabajo persistentes, reintentos, etiquetas de hablantes, marcas de tiempo y procesamiento predecible en grandes colecciones.

El lanzamiento oficial de OpenAI en mayo presentó GPT-Realtime-Whisper como su modelo de voz a texto para streaming. El lanzamiento de modelos de voz indica que produce transcripción mientras la persona sigue hablando.

La empresa posicionó el modelo para subtítulos que aparecen de inmediato y notas de reuniones que se desarrollan durante una conversación. También identificó la atención al cliente, la salud, las ventas y la contratación como posibles aplicaciones de alto volumen.

Para las grabaciones terminadas, el modelo documentado sigue siendo GPT-4o Transcribe. OpenAI lo describe como un modelo de voz a texto basado en GPT-4o, con un reconocimiento de idiomas más sólido y tasas de error de palabras más bajas que los modelos Whisper originales.

La tasa de error de palabras, o WER, mide sustituciones, eliminaciones e inserciones frente a una transcripción de referencia. Una puntuación más baja generalmente significa que el texto reconocido contiene menos errores.

Estas dos rutas reflejan objetivos de optimización diferentes. Un modelo de streaming debe devolver texto útil antes de haber escuchado la frase completa, mientras que un modelo para archivos puede usar el audio posterior como contexto.

Ese contexto adicional importa cuando una persona corrige un número, presenta un nombre desconocido o termina una expresión técnica. Un sistema orientado al procesamiento por lotes puede reconsiderar palabras anteriores antes de producir su resultado final.

Un sistema en vivo afronta una decisión más difícil. Puede esperar más contexto y aumentar el retraso, o devolver texto antes y arriesgarse a revisarlo unos momentos después.

La documentación de OpenAI afirma que GPT-Realtime-Whisper está diseñado para desarrolladores que necesitan ajustar la latencia y la precisión. Esa formulación importa porque reconoce que la velocidad y la estabilidad de la transcripción siguen estando relacionadas.

El modelo utiliza el endpoint de transcripción Realtime en lugar de comportarse como una simple carga de archivos. La interfaz documentada produce deltas de transcripción, que son fragmentos incrementales de texto entregados durante la sesión.

En cambio, la Audio API sigue ofreciendo rutas de transcripción y traducción para audio cargado. La guía de la API de audio de OpenAI distingue explícitamente las grabaciones terminadas de los flujos en curso.

Esta separación ofrece a los desarrolladores una elección arquitectónica más clara. No significa que todas las integraciones existentes deban cambiar de modelo de inmediato.

Los equipos primero deben confirmar el identificador público exacto del modelo, el endpoint, la disponibilidad regional, el formato de salida y el límite de tasa asociados a sus cuentas. Esos detalles determinan si una migración es rutinaria o extensa.

El anuncio también llega con un problema de verificación. Los nombres GPT-Live-Transcribe y GPT-Transcribe no aparecen en el catálogo público actual de modelos revisado para este artículo.

Podrían describir alias próximos, etiquetas de producto informales o terminología empleada en una publicación social antes de que la documentación se actualizara. OpenAI no ha aclarado públicamente esa diferencia en las páginas de documentación citadas.

Por ello, los desarrolladores deberían evitar incluir directamente esas dos cadenas no verificadas en la configuración de producción. Los identificadores documentados ofrecen un punto de partida más seguro hasta que OpenAI publique páginas de modelos o notas de lanzamiento correspondientes.

Esta brecha de nomenclatura crea la tensión central del artículo. OpenAI ha establecido una estrategia creíble para dos cargas de trabajo, pero los desarrolladores todavía necesitan contratos precisos en lugar de etiquetas generales de producto.

Por qué la transcripción de la OpenAI API se está convirtiendo en infraestructura

OpenAI compite por la capa que transforma la actividad hablada en datos consultables y accionables, no simplemente por una mejor caja de transcripción.

Una transcripción en vivo puede activar software posterior antes de que termine una conversación. Un sistema de soporte podría detectar un número de cuenta, recuperar un registro y preparar una respuesta sugerida para un agente.

Un asistente de reuniones puede identificar una decisión, conectarla con material previo del proyecto y crear un borrador de seguimiento. Un servicio de subtitulado puede distribuir texto mientras un evento aún está ocurriendo.

Las grabaciones terminadas respaldan una forma diferente de automatización. Una empresa puede transcribir un archivo, extraer problemas recurrentes, clasificar conversaciones y crear un corpus consultable de conocimiento institucional.

Estos flujos de trabajo convierten la transcripción en una entrada para el razonamiento, la recuperación de información, la analítica y la automatización. La precisión importa porque cada paso posterior hereda los errores de la transcripción.

Un nombre de producto equivocado puede romper la recuperación de información. Un número incorrecto puede corromper un registro de cliente, mientras que una negación omitida puede invertir el significado de una declaración médica o legal.

OpenAI afirma que sus modelos de voz recientes gestionan mejor los acentos, los entornos ruidosos, las distintas velocidades de habla y el reconocimiento de idiomas. Su anterior investigación sobre modelos de audio atribuyó las mejoras al entrenamiento centrado en audio, el aprendizaje por refuerzo y conjuntos de datos diversos.

Siguen siendo afirmaciones de la empresa salvo que un comprador las reproduzca con audio representativo. Los benchmarks públicos rara vez capturan cada micrófono, entorno acústico, dialecto, patrón de alternancia de idiomas o vocabulario especializado presente en producción.

La promesa práctica más sólida es el reconocimiento contextual. Los sistemas de voz suelen tener dificultades con enunciados breves porque contienen pocas pistas sobre lo que pretendía decir una persona.

Una persona que dice “quince” podría referirse a una cantidad, una fecha, parte de un número de teléfono o una respuesta a una pregunta anterior. La conversación circundante determina el formato correcto.

La terminología profesional plantea el mismo problema. Un modelo debe distinguir un medicamento poco común, un producto, un apellido, un acrónimo o un código de palabras conocidas con sonidos similares.

El lanzamiento de voz de OpenAI afirma que su modelo de tiempo real más amplio mejoró la retención de terminología especializada, nombres propios y términos sanitarios. Sin embargo, la empresa no publicó mediciones detalladas equivalentes para todos los escenarios de transcripción.

El diseño de dos vías puede mejorar la forma en que los desarrolladores gestionan este contexto. Una sesión en vivo puede acumular estado conversacional, mientras que un modelo de archivo terminado puede procesar una grabación coherente más extensa.

Sin embargo, el contexto por sí solo no garantiza la corrección. Un modelo de lenguaje puede usar un contexto plausible para elegir con seguridad la palabra equivocada, especialmente cuando la señal de audio es débil.

Este modo de fallo cambia la forma en que los equipos deberían evaluar la calidad de la transcripción. Necesitan más que una puntuación WER agregada sobre grabaciones limpias.

Una evaluación de producción debería separar nombres, números, abreviaturas, turnos multilingües, ruido de fondo, interrupciones y respuestas breves. También debería medir si los errores críticos se concentran en grupos específicos.

La latencia merece un tratamiento igualmente cuidadoso. Un producto puede informar de un primer token rápido, pero tardar más en estabilizar las palabras finales de cada segmento.

Los usuarios perciben la inestabilidad cuando los subtítulos se reescriben repetidamente. Los sistemas posteriores también necesitan saber si un delta es provisional o definitivo antes de activar una acción.

Por eso la expansión de la OpenAI API presiona a los equipos de aplicaciones tanto como a los proveedores rivales. Los desarrolladores deben decidir qué estado de la transcripción es seguro para la búsqueda, el almacenamiento, el resumen y las decisiones automatizadas.

Para el trabajo de conocimiento, el resultado más útil rara vez es una transcripción sin procesar. Las personas necesitan que la conversación esté conectada con documentos, decisiones, responsabilidades y contexto previo.

Una base de conocimiento consultable puede preservar esa relación después de la transcripción. Sin embargo, el flujo de trabajo solo es tan fiable como su proceso de captura y revisión.

Por tanto, los nuevos modelos importan más allá de los asistentes de voz. Hacen que la información hablada sea una entrada más inmediata para el software, al tiempo que aumentan el coste de los errores de reconocimiento que pasan desapercibidos.

OpenAI se enfrenta a un mercado consolidado de streaming y procesamiento por lotes

La competencia principal enfrenta la plataforma unificada de modelos de OpenAI con infraestructura de voz consolidada que cuenta con controles operativos maduros.

Amazon Transcribe ya separa los trabajos por lotes de las sesiones de streaming. Su documentación describe los medios cargados como trabajo por lotes y los medios en curso como trabajo de streaming.

La documentación de streaming de Amazon también explica una disyuntiva conocida. Los resultados parciales más rápidos pueden tener limitaciones de precisión porque el sistema dispone de menos audio futuro.

Ese es el mismo mecanismo que OpenAI debe gestionar. Un modelo no puede usar palabras que aún no ha escuchado, independientemente de la inteligencia asociada a su marca.

El servicio de voz de Microsoft también admite transcripción en tiempo real y por lotes. Ofrece funciones de personalización y se integra en el entorno de identidad, almacenamiento, cumplimiento y despliegue de Azure.

Google Cloud proporciona reconocimiento en streaming y asíncrono mediante sus servicios de voz. Los proveedores especializados compiten con funciones centradas en baja latencia, diarización, control de vocabulario, analítica de llamadas y datos de confianza detallados.

Estos competidores cuentan con una ventaja importante. Muchos compradores empresariales ya conectan su audio, permisos, almacenamiento, supervisión y procesos de cumplimiento con un proveedor de nube existente.

La ventaja de OpenAI reside en otra parte. Puede conectar la transcripción con modelos que resumen, razonan sobre el contexto, llaman herramientas y generan respuestas dentro de la misma plataforma para desarrolladores.

Esa integración puede reducir la cantidad de servicios necesarios para un flujo de trabajo de voz. También puede simplificar la experimentación para equipos que ya utilizan modelos de OpenAI para el procesamiento de texto.

Sin embargo, utilizar un solo proveedor no simplifica automáticamente las operaciones de producción. Las sesiones Realtime y los trabajos asíncronos siguen requiriendo rutas de código, gestión de errores, observabilidad y planificación de capacidad distintas.

Una empresa también puede preferir la separación para gestionar riesgos. Puede usar un proveedor para la transcripción y otro para el razonamiento, evitando que la interrupción de un servicio deshabilite todo el flujo de trabajo.

La concentración de proveedores genera preocupaciones adicionales en torno al manejo de datos, la cobertura regional, los controles contractuales y la capacidad de migración. Estos temas cobran más importancia cuando las transcripciones contienen conversaciones sensibles.

Por lo tanto, la comparación competitiva no puede terminar con un gráfico de benchmarks. Los compradores deben evaluar cómo se comporta cada servicio ante pérdida de paquetes, silencios prolongados, hablantes superpuestos, reconexiones y picos repentinos de tráfico.

También necesitan contratos de salida estables. El texto de la transcripción es solo un componente del resultado.

La separación de hablantes, las marcas de tiempo, las señales de confianza, los indicadores de versión final, la redacción, la identificación de canales, la detección de idioma y el vocabulario personalizado pueden importar más que una pequeña mejora de precisión agregada.

El endpoint documentado de transcripción en tiempo real de OpenAI admite funcionamiento en streaming, pero la página pública del modelo no establece paridad de funciones con todas las plataformas de voz maduras. Los desarrolladores deberían comparar los campos requeridos uno por uno.

El procesamiento por lotes crea otro punto de presión. Los grandes archivos necesitan envío predecible de trabajos, visibilidad de colas, comportamiento de reintentos y resultados duraderos.

El informe original describe GPT-Transcribe como optimizado para cargas de trabajo asíncronas y por lotes. Las páginas públicas actuales de OpenAI no documentan un modelo independiente con ese nombre exacto ni un nuevo sistema de trabajos específico para lotes.

GPT-4o Transcribe admite el endpoint de transcripción y puede procesar audio terminado. Eso no confirma, por sí solo, todas las capacidades de orquestación asíncrona que se afirman.

La distinción es importante. Un modelo puede procesar un archivo sin proporcionar un flujo de trabajo por lotes gestionado para miles de archivos.

Los equipos de aplicaciones podrían seguir necesitando crear colas, rastrear el estado de los trabajos, controlar la concurrencia, conservar el audio de origen y asociar los resultados con registros internos. Estas tareas pueden dominar el esfuerzo de implementación.

Aquí es donde las plataformas de nube consolidadas siguen siendo competidores difíciles. Sus servicios de voz se encuentran junto al almacenamiento, las colas de eventos, los sistemas de identidad, los registros de auditoría y la infraestructura regional.

OpenAI puede responder haciendo más valiosa la inteligencia que rodea a la transcripción. Una transcripción que admita de inmediato clasificación, recuperación, resumen y uso de herramientas puede compensar las brechas operativas.

El resultado dependerá de integraciones reales, no del nombre de los modelos. Los desarrolladores premiarán al proveedor que ofrezca texto fiable y un comportamiento de sistemas predecible en ambos tipos de carga de trabajo.

Un Mejor Contexto No Elimina el Problema de la Precisión

La afirmación central de OpenAI necesita pruebas allí donde el reconocimiento de voz suele fallar, especialmente con nombres, números, acentos, ruido y audio en idiomas mezclados.

La empresa afirma que sus modelos de transcripción comprenden el contexto mejor que los sistemas anteriores. La afirmación es plausible porque los modelos basados en GPT pueden utilizar patrones lingüísticos más amplios al resolver audio incierto.

Sin embargo, la predicción contextual puede ocultar errores. Una transcripción gramaticalmente perfecta puede ser más peligrosa que una evidentemente defectuosa cuando contiene un número de cuenta o medicamento incorrecto.

Esto crea un estándar de calidad diferente para el uso profesional. La legibilidad no puede sustituir la fidelidad a la grabación.

Los equipos deberían construir evaluaciones a partir de su propio audio, en lugar de depender solo de demostraciones pulidas. La muestra debe incluir casos difíciles, no únicamente los habituales.

Una evaluación de atención al cliente debería incluir conexiones móviles deficientes, superposición de hablantes, números de identificación largos, acentos, interrupciones y voces de fondo. Una prueba de reuniones debería incluir siglas, apellidos, códigos de proyecto y micrófonos distantes.

Las pruebas multilingües deben cubrir la alternancia de códigos, donde un hablante cambia de idioma dentro de una misma conversación. Una amplia compatibilidad de idiomas no revela el rendimiento en esas transiciones.

Los desarrolladores también deberían distinguir el reconocimiento del formato. Un sistema puede oír las palabras correctas, pero formatear incorrectamente una fecha, un valor monetario o un identificador.

La transcripción en directo añade el comportamiento de revisión a la prueba. Los equipos deben medir el retraso antes de que aparezca el texto y el retraso antes de que ese texto se estabilice.

Un subtítulo que llega rápido pero cambia varias veces puede perjudicar la accesibilidad y la comprensión. Un subtítulo estable que llega demasiado tarde también puede no cumplir su propósito.

El equilibrio aceptable depende de la aplicación. Los subtítulos de emisiones, las notas de reuniones, la detección de turnos de agentes de voz y los archivos de cumplimiento tienen umbrales distintos.

La página del modelo en tiempo real de OpenAI indica que los desarrolladores pueden ajustar la latencia y la precisión. La documentación del modelo confirma la compatibilidad con streaming y el endpoint específico de sesiones de transcripción.

Esa documentación no elimina la necesidad de una evaluación específica para cada carga de trabajo. Establece la disponibilidad y las características de la interfaz, no el rendimiento con los datos privados de un comprador.

También existe un riesgo de nomenclatura durante la adopción. Los equipos suelen copiar cadenas de modelos de publicaciones, ejemplos o discusiones internas antes de consultar el catálogo.

Si GPT-Live-Transcribe y GPT-Transcribe son alias, OpenAI debería documentar su relación con los modelos existentes. Si son productos futuros, debería publicar sus interfaces y guías de migración.

Hasta entonces, los desarrolladores deberían tratar la descripción en redes sociales como una afirmación sobre la dirección del producto. Deberían tratar las páginas públicas de modelos como la referencia autorizada para el despliegue.

Los alias de modelos introducen otra preocupación operativa. Un alias puede pasar a una instantánea más reciente, cambiando el comportamiento sin modificar el código de la aplicación.

Eso puede ser útil para recibir mejoras. También puede dificultar la investigación de regresiones cuando cambia el comportamiento de las transcripciones.

Los equipos con requisitos estrictos deberían registrar identificadores de modelos, parámetros de API, conjuntos de prueba y resultados de evaluación para cada versión. Deberían volver a ejecutar audio crítico antes de cambiar una instantánea o alias.

La revisión humana sigue siendo necesaria para contenido de alta consecuencia. Las señales automáticas de confianza pueden priorizar la revisión, pero no deberían definir por sí solas la verdad.

Un sistema puede equivocarse con confianza, especialmente cuando el ruido de fondo se parece al habla o el contexto favorece una frase plausible. Los nombres y números críticos suelen merecer una confirmación explícita.

La privacidad y la gobernanza añaden más incertidumbre. Las conversaciones habladas pueden contener características biométricas, estrategia confidencial, información de salud e identificadores personales.

Los desarrolladores deben comprender cómo se mueven el audio y las transcripciones por sus sistemas. Deberían documentar la retención, el acceso, la eliminación, el procesamiento regional y el uso posterior por modelos.

OpenAI afirma que la API Realtime admite residencia de datos en la UE y está cubierta por sus compromisos de privacidad empresarial. Esas declaraciones no satisfacen automáticamente las obligaciones legales o contractuales de todas las organizaciones.

La preocupación final es la transparencia de las mediciones. El anuncio de OpenAI de 2025 mostró un WER inferior al de Whisper en varios benchmarks, incluida una evaluación multilingüe.

La afirmación de julio, tal como se proporciona a través de la fuente social, no presenta una tabla pública de benchmarks para los dos modelos recién nombrados. Tampoco ofrece una distribución de latencia ni análisis de errores por subgrupos.

Esa ausencia no significa que las mejoras afirmadas sean falsas. Significa que los compradores aún no pueden comparar rigurosamente las nuevas etiquetas con modelos documentados o servicios competidores.

La respuesta apropiada no es ni el rechazo ni la adopción ciega. Los desarrolladores deberían probar los endpoints documentados mientras esperan páginas formales que resuelvan las brechas de nomenclatura y benchmarks.

Qué Deberían Vigilar los Desarrolladores Tras la Afirmación de Dos Modelos

Tres señales determinarán si OpenAI ha entregado una plataforma de transcripción clara o solo ha descrito una antes de completar su documentación.

La primera señal es una actualización formal del catálogo de modelos. OpenAI necesita publicar páginas para GPT-Live-Transcribe y GPT-Transcribe, o explicar cómo esos nombres se corresponden con GPT-Realtime-Whisper y GPT-4o Transcribe.

Esta aclaración debería incluir identificadores exactos de API, endpoints compatibles, estado de lanzamiento, instantáneas, esquemas de salida y disponibilidad de cuentas. Sin ello, los desarrolladores corren el riesgo de construir en torno a una terminología que la API no acepta.

Un mapeo documentado de alias reforzaría la idea de que OpenAI está simplificando su familia de productos. El silencio continuado debilitaría la confianza en el planteamiento original de dos modelos.

La segunda señal es evidencia de rendimiento reproducible. OpenAI debería proporcionar resultados de latencia y precisión para voz en directo, archivos terminados, acentos, idiomas mezclados, términos técnicos, números y grabaciones ruidosas.

El WER promedio por sí solo no resolvería la cuestión. Los desarrolladores necesitan categorías de error y suficiente detalle metodológico para comparar los resultados con sus propios conjuntos de evaluación.

Las pruebas independientes también serán importantes. Una ventaja consistente en audio de centros de llamadas, reuniones, subtítulos, entrevistas y habla multilingüe validaría la afirmación de precisión contextual.

Los resultados mixtos no harían inutilizables a los modelos. Mostrarían que la selección de proveedores sigue siendo específica para cada carga de trabajo, algo que ya es habitual en el reconocimiento de voz.

La tercera señal es el comportamiento en producción a escala. Los equipos deberían examinar la estabilidad de las sesiones, las tasas de revisión de transcripciones, la gestión de colas, la recuperación ante fallos, los límites de tasa y los cambios entre versiones de modelos.

Una demostración en directo puede ocultar problemas de reconexión y picos de tráfico. Una prueba breve de archivo dice poco sobre el procesamiento de un archivo con miles de grabaciones.

Las respuestas de los competidores aportarán otra pista dentro de esta señal. Amazon, Microsoft, Google y proveedores especializados pueden responder con menor latencia, controles más sólidos o mejor personalización por dominio.

OpenAI no necesita ganar todos los benchmarks de transcripción. Necesita hacer que el flujo de trabajo combinado de transcripción, razonamiento, recuperación y acción resulte lo bastante convincente como para justificar la adopción.

Esa integración más amplia es la apuesta estratégica. Los datos de voz se vuelven más valiosos cuando el software puede conectarlos con los documentos, decisiones y tareas activas del usuario.

Para un flujo de trabajo de reuniones, la transcripción es solo la primera operación. El sistema debe identificar compromisos, preservar el contexto, conectar material de apoyo y hacer que el resultado pueda recuperarse más tarde.

El mismo patrón se aplica a la atención al cliente. Una transcripción se vuelve operativamente útil cuando ayuda a resolver el caso, actualizar registros e informar futuras interacciones.

Los desarrolladores deberían comenzar con una comparación controlada entre las rutas documentadas de audio en directo y archivos. Deberían usar el mismo audio representativo, reglas de puntuación y comprobaciones de términos críticos en todos los proveedores.

También deberían separar la calidad de la transcripción de la calidad de las tareas posteriores. Un pequeño error de texto puede no afectar a un resumen, mientras que un identificador incorrecto puede romper una acción automatizada.

El despliegue en producción debería seguir el nivel de consecuencia. La búsqueda de reuniones de bajo riesgo puede tolerar más automatización que la documentación médica, los registros legales o los cambios de cuenta.

La API de OpenAI presenta ahora una dirección arquitectónica más clara para la voz. El audio en directo pertenece a un stream con estado, mientras que las grabaciones terminadas pertenecen a un flujo de transcripción orientado a archivos.

Lo que sigue sin estar claro es si los nombres de la publicación social representan nuevos modelos públicos, versiones renombradas o un anuncio que llegó a los desarrolladores antes que su documentación.

Esa pregunta debería poder responderse pronto. Las páginas de modelos, las notas de lanzamiento y las evaluaciones reproducibles confirmarán el lanzamiento afirmado o lo limitarán a una vista previa de la hoja de ruta de OpenAI.

Hasta entonces, los desarrolladores pueden actuar sin adivinar. Usen identificadores de modelos documentados, comparen ambas rutas con audio real, registren las revisiones y mantengan la revisión humana en torno a campos críticos.

La pregunta práctica no es si un modelo de OpenAI puede generar una transcripción impresionante. Es si tu aplicación puede confiar en esa transcripción en el preciso momento en que la utiliza.

Crea la evaluación antes de la migración. Después, observa si OpenAI resuelve la brecha de nomenclatura y publica evidencia que respalde la promesa detrás de su nueva estrategia de transcripción.