Lista de comprobación y marco de evaluación para comprar IA de voz empresarial

Nota sobre el alcance. Esta lista de comprobación sirve de apoyo a la revisión técnica y de compras. No es asesoramiento jurídico, de seguridad, regulatorio ni financiero, y no puede sustituir a los procesos propios de riesgo y aprobación de la organización.

Ideas clave

• Descarte las opciones que incumplan una restricción obligatoria de despliegue, datos o derechos antes de comparar la calidad de voz o el precio.
• Acepte una afirmación solo cuando el proveedor aporte evidencia para el producto, la región y el modo de despliegue propuestos.
• Pruebe todas las opciones viables con el mismo corpus oculto, la misma carga de trabajo, la misma vía de integración y las mismas reglas de apto/no apto.
• Recoja el tratamiento de datos, los niveles de servicio, el control de cambios, los derechos sobre las voces y las obligaciones de salida en anexos contractuales, no en diapositivas de presentación.
• Ensaye la supresión, la revocación de accesos y la exportación durante el piloto, mientras cambiar de proveedor sigue siendo viable.

El objetivo no es obtener una puntuación alta, sino llegar a una decisión defendible de adelante, adelante con condiciones o descarte. Una media alta nunca debe compensar el incumplimiento de un requisito obligatorio de seguridad, legal, de accesibilidad o de producción.

¿Qué debería definir una empresa antes de contactar con proveedores?

Empiece por un informe de evaluación de una página redactado por el comprador. Debe indicar el recorrido de usuario, las personas afectadas, los idiomas, los canales, las clases de datos, el tráfico previsto, el impacto de los fallos, el límite de integración, las restricciones de despliegue y el responsable del servicio. Marque cada requisito como obligatorio o como preferencia. Derive los criterios de aceptación del flujo de trabajo real en lugar de copiar umbrales genéricos de latencia o de calidad de otra licitación.

Use un único registro de evidencias para todos los proveedores. Cada afirmación debe tener un responsable, una fuente, un alcance, una fecha, un estado y un impacto en la decisión. Un vocabulario de estados útil es afirmado, documentado, probado y contratado. El logotipo de una certificación o la respuesta de un comercial solo están afirmados hasta que se comprueban su alcance y su pertinencia. Un piloto exitoso está probado, pero no es un compromiso exigible en producción salvo que la condición correspondiente también esté contratada.

Si las fuentes se contradicen, no las promedie. Registre el conflicto y exija al proveedor que concilie la documentación, el resultado del piloto y el contrato propuesto. El comprador debe aplicar la interpretación admitida más restrictiva o mantener abierto el punto de decisión. Toda excepción aceptada necesita un responsable, un control compensatorio, una fecha de caducidad y una condición de nueva prueba.

El marco voluntario de gestión de riesgos de IA del NIST organiza el trabajo de riesgos en torno a gobernar, mapear, medir y gestionar. Resulta útil para asignar responsabilidades y registrar decisiones, pero el NIST lo presenta explícitamente como un marco flexible, no como una certificación ni una lista universal.

¿Qué preguntas de arquitectura debería responder todo proveedor de IA de voz?

Pida al proveedor que anote la arquitectura que propone para esta compra, no todo su catálogo. El diagrama debe incluir la telefonía o aplicación cliente, el reconocimiento del habla, la orquestación, el modelo de lenguaje, la síntesis de voz, la identidad, los logs, la analítica, las herramientas de soporte, las copias de seguridad y todas las dependencias externas. Para cada componente, registre la entidad que lo suministra, la que lo opera, la región, los datos que recibe, el almacenamiento y las conexiones salientes.

El anexo de arquitectura debe responder a:

• ¿Dónde cruzan el texto, el audio, los metadatos, las credenciales y los datos de diagnóstico una frontera de red o de entidad legal?
• ¿Qué ubicaciones se usan para la ruta principal, la conmutación por error, las copias de seguridad y el soporte humano?
• ¿Qué identidades del cliente y del proveedor pueden administrar el servicio, y cómo se registra y se revoca ese acceso?
• ¿Qué versiones de modelo, voz, diccionario, normalización y orquestación forman parte del sistema probado?
• ¿Qué ocurre cuando una dependencia agota el tiempo de espera, se sobrecarga, cambia de versión o deja de estar disponible?
• ¿Quién asume la monitorización, el escalado, los parches, las copias de seguridad, la respuesta a incidentes, las actualizaciones y la reversión?

En un servicio gestionado, exija por escrito el endpoint propuesto, los límites y el comportamiento en conmutación por error. En un despliegue operado por el cliente, pida al proveedor que instale a partir de los entregables que el cliente recibirá realmente. Observe la obtención de imágenes o modelos, las comprobaciones de licencia, la telemetría saliente, los secretos, el arranque, la monitorización, la actualización, la reversión y la recuperación. «Autoalojado» no es una descripción suficiente si el servicio sigue dependiendo de un plano de control del proveedor no revelado.

KugelAudio documenta sus regiones disponibles y su vía de despliegue autoalojado. Esas páginas definen opciones de producto admitidas; el comprador sigue necesitando un diagrama aprobado de su ruta de voz completa.

¿Cómo deberían los compradores evaluar la calidad de voz y la adecuación lingüística?

Construya un corpus de prueba oculto con entradas de forma similar a la producción, sin copiar datos personales o confidenciales a un piloto no aprobado. Cubra los idiomas y las variedades regionales que los usuarios encontrarán realmente, incluidos nombres, cifras, fechas, importes, direcciones, abreviaturas, términos del dominio, alternancia de idioma, fragmentos con mucha puntuación, confirmaciones breves y turnos largos. Añada entradas deliberadamente malformadas para exponer la normalización y el comportamiento ante errores.

Use oyentes nativos o cualificados en el dominio y una rúbrica escrita. Juzgue por separado la inteligibilidad, la pronunciación, la naturalidad, la coherencia del hablante, la adecuación del estilo y el éxito de la tarea. Aleatorice las muestras y oculte la identidad del proveedor cuando sea posible. La recomendación ITU-T P.800 es una referencia oficial para pruebas subjetivas controladas de calidad del habla, pero el comprador debe añadir comprobaciones propias de la tarea, como si se pronunció correctamente un número de cuenta o el nombre de un medicamento.

El expediente de evidencias debe contener la entrada exacta, la representación esperada cuando esté definida, la salida original, la versión del modelo y de la voz, los ajustes de generación, el protocolo de escucha y las valoraciones individuales. Consérvelo como base aceptada para las pruebas de regresión tras cambios de modelo o de configuración. No deduzca la idoneidad de un recuento de idiomas, de una grabación de demostración o de una única puntuación media global.

Pruebe el tratamiento del texto por separado de la calidad acústica. La guía de normalización y pronunciación explica cómo aislar la preparación del texto y los diccionarios, mientras que la metodología de benchmark en alemán muestra cómo conservar las entradas y las salidas originales para su revisión.

¿Cómo deben compararse el rendimiento y la preparación para producción?

Defina los escenarios a partir del servicio real: turnos típicos, entradas largas difíciles, ráfagas de tráfico, reconexiones, cancelaciones, fallos de dependencias y recuperación tras sobrecarga. Dé a cada proveedor la misma región de cliente, el mismo conjunto de textos, el mismo formato de audio, la misma política de reutilización de conexiones, el mismo calendario de concurrencia y la misma regla de calentamiento. Si los modos de despliegue difieren, preséntelos como escenarios distintos en lugar de fingir que los resultados son directamente intercambiables.

Mida en el punto que experimentan los usuarios. En el habla por streaming, eso suele incluir el tiempo hasta el primer audio reproducible, el tiempo de finalización, el tiempo en cola, las tasas de fallo y de reintento, el comportamiento ante cancelaciones y el tiempo de recuperación. Conserve las observaciones originales con marca de tiempo y presente distribuciones, no la petición más rápida ni solo una media. Registre la versión de modelo y de voz, el hardware, el runtime, el número de réplicas, el batching, los límites y la ventana de medición para poder reproducir o explicar el resultado más adelante.

La evidencia de fiabilidad necesita una semántica de los fallos, no solo un porcentaje de disponibilidad. Verifique si los reintentos duplican audio, si un turno cancelado sigue consumiendo recursos, si la conexión sigue siendo reutilizable, cómo se señaliza la sobrecarga y si los identificadores de petición conectan las trazas del cliente con el soporte del proveedor. Ejercite la vía documentada de actualización, reversión e incidentes con las personas que operarán la producción.

La guía de rendimiento y capacidad aporta la estructura de medición. La guía de preparación para producción cubre los escenarios de fallo operativo y de cambio.

¿Qué evidencia de seguridad y privacidad deberían pedir los compradores?

Parta del flujo de datos aprobado y de la evaluación de riesgos. Pida únicamente evidencia capaz de cambiar una decisión y compruebe su fecha y su alcance. Una certificación de seguridad puede apoyar la revisión, pero su logotipo no demuestra que se examinaran el producto, la región, el subencargado o el despliegue operado por el cliente propuestos.

La evidencia habitual incluye un modelo de amenazas, una matriz de responsabilidades de seguridad, el diseño de control de acceso y de gestión de claves, la cobertura de los registros de auditoría, el proceso de vulnerabilidades y parches, el alcance de las pruebas de penetración con el estado de la subsanación, el procedimiento ante incidentes, una prueba de recuperación y el inventario de componentes. El recurso oficial sobre listas de materiales de software de CISA puede ayudar a definir una petición de transparencia sobre componentes. Un SBOM es una evidencia útil de inventario, no una prueba de que los componentes sean seguros o estén bien configurados.

Cuando el proveedor trate datos personales por cuenta del comprador, las condiciones de tratamiento necesitan algo más que una declaración genérica de «preparado para el RGPD». Adjunte un contrato de encargo o un anexo de tratamiento completo que identifique:

• el objeto, la finalidad, la duración, las categorías de datos y las personas afectadas;
• las instrucciones documentadas y cualquier uso separado controlado por el proveedor, como la analítica de producto o la mejora de modelos;
• las medidas técnicas y organizativas del servicio propuesto;
• la entidad legal, la función y el lugar de tratamiento de cada subencargado, junto con el proceso de autorización, preaviso y oposición ante cambios;
• la asistencia en solicitudes de derechos, incidentes, evaluaciones de impacto y auditorías;
• la conservación por tipo de objeto, incluidas peticiones, audio, transcripciones, logs, cachés, copias de seguridad y datos derivados;
• la devolución o supresión al finalizar el servicio, incluido cómo se gestiona la caducidad de las copias de seguridad; y
• las ubicaciones de las transferencias internacionales, su mecanismo y la evaluación de apoyo cuando sea necesaria.

La Comisión Europea publica cláusulas del artículo 28 entre responsable y encargado y orientaciones oficiales aparte sobre garantías para las transferencias internacionales de datos. Son cuestiones distintas: la dirección de un centro de datos no responde por sí sola a si el soporte remoto, la conmutación por error o un subencargado generan otra transferencia.

Durante el piloto, envíe datos de prueba rastreables, localícelos en los logs y las exportaciones, solicite su supresión y verifique el resultado documentado una vez transcurrida la ventana correspondiente de tratamiento y de copias de seguridad. La guía de infraestructura de IA de voz on-premise ofrece una revisión más completa del flujo de datos. Ni esa guía ni una prueba de supresión satisfactoria acreditan el cumplimiento legal del caso de uso del comprador.

¿Cómo deben comprobarse los derechos sobre las voces, la accesibilidad y las obligaciones del Reglamento de IA?

Trate los derechos sobre las voces como una cadena de autorizaciones. En las voces de catálogo, pregunte quién autorizó la grabación, la creación del modelo y el uso comercial de la salida, y qué territorios, canales o usos prohibidos se aplican. En una voz clonada o encargada, identifique quién puede solicitar su creación, aprobar su uso, acceder al modelo, generar salida, revocar la autorización y ordenar su supresión. Recoja en el contrato la titularidad o el alcance de la licencia sobre las grabaciones, los artefactos del modelo y el audio generado. Defina también los controles frente a la suplantación y la evidencia que se conserva de las aprobaciones. Las cuestiones de derechos de la personalidad, laborales, de propiedad intelectual y de protección de datos varían según la jurisdicción, así que una casilla de consentimiento del proveedor no resuelve los derechos del comprador.

La revisión de accesibilidad empieza por el servicio, no solo por la voz sintética. Identifique a las personas que pueden quedar excluidas por barreras de habla, audición, idioma, motoras o cognitivas. Pruebe el canal real con usuarios representativos y tecnología de apoyo. Según el uso, los requisitos pueden incluir una alternativa escrita o humana, controles de repetición y corrección, reproducción ajustable, tiempo suficiente, autenticación sin voz y transcripciones o registros accesibles. La Ley Europea de Accesibilidad se aplica a determinados productos y servicios de consumo, no automáticamente a todo sistema de IA de voz. Las WCAG 2.2 son relevantes para las interfaces web, pero no validan por sí solas un recorrido telefónico.

En cuanto al Reglamento de IA de la UE, documente el caso de uso completo, la clasificación del sistema, el papel de cada parte y las obligaciones que de ello se derivan. El artículo 50 del texto oficial del reglamento contiene obligaciones de transparencia para determinados sistemas que interactúan con personas o generan contenido sintético, con condiciones propias de cada rol y contexto. No acepte un distintivo genérico de «conforme al Reglamento de IA» como análisis. Registre quién facilita cualquier aviso exigido, quién aplica los marcados técnicos, quién conserva la evidencia y quién vigila los cambios regulatorios o de producto.

¿Cómo debe aceptarse una prueba de concepto con forma de producción?

Congele el protocolo del piloto antes de que ningún proveedor genere resultados. Cada criterio necesita un identificador, un escenario, un método de medición o revisión, una regla de aceptación, un responsable de la evidencia y una consecuencia en caso de fallo. Los umbrales deben derivarse de las necesidades de usuario, legales y operativas del servicio. Si no existe un umbral defendible, use una revisión experta identificada y registre la decisión en lugar de inventarse una cifra.

Como mínimo, el piloto debe ejercitar:

• la vía prevista de telefonía, cliente y orquestación;
• el corpus oculto de idioma, pronunciación y calidad;
• las cargas de trabajo normales, de pico y de fallo definidas en el informe de evaluación;
• el comportamiento ante interrupciones, cancelaciones, reintentos y el turno siguiente;
• entradas malformadas, tiempos de espera de dependencias, sobrecarga y recuperación;
• la monitorización, los eventos de auditoría, los identificadores de petición y el escalado al soporte;
• la concesión y revocación de accesos, la conservación, la exportación y la supresión;
• la instalación, actualización y reversión en el despliegue operado por el cliente;
• la alternativa en caso de fallo, el traspaso a una persona y las alternativas de accesibilidad acordadas; y
• la detección de cambios de modelo o de configuración frente a la base aceptada.

Conserve la evidencia original en el repositorio del comprador. No sustituya en silencio un servicio autoalojado previsto por una demo en la nube, ni la vía de telefonía prevista por una prueba directa contra la API. Un criterio obligatorio no superado equivale a un descarte hasta que se corrija, se vuelva a probar o se acepte mediante el proceso documentado de excepciones. La presión comercial no es un control compensatorio.

¿Cómo deben comparar los equipos el coste total y la responsabilidad operativa?

Ponga precio a los mismos escenarios de demanda baja, prevista, pico y de crecimiento en cada opción. Indique el volumen de texto o de audio, el patrón de concurrencia, la geografía, el nivel de modelo y el periodo contractual de cada escenario. Incluya los compromisos mínimos, el volumen no consumido, las reglas de exceso, el redondeo, las voces o modelos premium, los recargos regionales, la salida de datos de red, los niveles de soporte, la puesta en marcha, los servicios profesionales y las condiciones de cambio de precio.

En la infraestructura operada por el cliente, incluya los aceleradores, la capacidad ociosa de conmutación por error, la orquestación, la observabilidad, el mantenimiento de seguridad, las actualizaciones, la respuesta a incidentes y el equipo de ingeniería que se ocupa de todo ello. Cree una matriz de responsabilidades para cada tarea recurrente y valore como riesgo, no como cero, las filas sin resolver. La guía de TTS autoalojable explica por qué el acceso a los pesos de un modelo no equivale a un servicio de producción operado.

¿Qué preguntas contractuales y de salida deben resolverse antes de firmar?

Convierta la evidencia aceptada en anexos contractuales concretos. El conjunto exacto depende de la compra, pero el acuerdo debe dejar claro dónde encontrar el alcance y la arquitectura aprobados, el contrato de encargo y las medidas de seguridad, los niveles de servicio, el proceso de soporte, los derechos sobre las voces, las hipótesis comerciales, el control de cambios, la aceptación del piloto y las obligaciones de salida. Si una propuesta o una respuesta de seguridad influye en la decisión, incorpórela o explique por qué no es contractual.

El anexo de niveles de servicio debe definir el límite medido del servicio, las peticiones elegibles, el cálculo de la disponibilidad, las exclusiones, el mantenimiento, los límites de capacidad y la región. En el soporte, distinga el acuse de recibo, la mitigación activa, el restablecimiento y el informe de causa raíz. Defina la gravedad con ejemplos del servicio del comprador, el horario de soporte, los canales de contacto, los responsables del escalado, las actualizaciones durante incidentes y el preaviso de cambios o de retirada. Los créditos de servicio no sustituyen a los planes de alternativa y recuperación.

El anexo de salida debe indicar los formatos de exportación, el plazo de entrega, la titularidad de los diccionarios y la configuración, los derechos sobre las voces y los recursos de entrenamiento, la asistencia en la transición, la continuidad del servicio, la revocación de accesos y la evidencia de supresión. Durante el piloto, realice un pequeño ensayo de salida: exporte el material necesario para continuar, impórtelo o inspecciónelo de forma independiente, revoque el acceso del proveedor y del soporte, elimine los datos de prueba bajo control y confirme qué registros debe conservar el comprador. Anote todo artefacto propietario que no pueda trasladarse y el procedimiento de sustitución probado. Una promesa de portabilidad que no ha superado este ejercicio sigue siendo una simple afirmación.

¿Qué limitaciones tiene esta lista de comprobación?

Este marco no clasifica un sistema, no acredita el cumplimiento del RGPD ni del Reglamento de IA, no certifica la seguridad, no determina obligaciones de accesibilidad ni sustituye a las normas sectoriales. El autor trabaja para KugelAudio. Los compradores deberían fijar sus criterios a partir de su propio servicio y riesgo, implicar a los usuarios afectados y a revisores cualificados, y verificar de forma independiente cada respuesta de los proveedores.

Preguntas frecuentes

¿Cuántos proveedores debería preseleccionar una empresa?

No hay un número universal. Conserve solo las opciones que superen los requisitos obligatorios de arquitectura, datos y derechos, y compare después tantas como el equipo pueda probar con la misma profundidad y el mismo protocolo.

¿Debería un comprador empezar por la calidad de voz o por el despliegue?

Empiece por las restricciones obligatorias de despliegue, integración, datos y derechos. Pruebe la calidad de voz solo entre las opciones viables, porque un audio excelente no arregla una arquitectura que la organización no puede aprobar.

¿Basta un endpoint alojado en la UE para el proceso de compra?

No. El comprador debe identificar además las entidades del proveedor y de los subencargados, el acceso de soporte, la conmutación por error, las copias de seguridad, los logs, la conservación, la supresión, los mecanismos de transferencia y el resto de la pila de voz.

¿Qué hace que una prueba de concepto de IA de voz tenga forma de producción?

Que use la arquitectura, la vía de integración, los idiomas, los tipos de entrada, la carga de trabajo, los casos de fallo, los controles de datos y el proceso operativo previstos. Además, conserva la evidencia original y aplica reglas de aceptación redactadas antes de la prueba.

¿Deberían los modelos de código abierto usar la misma lista de comprobación?

Sí, pero la responsabilidad operativa se desplaza hacia el cliente o su socio de integración. Las licencias, la procedencia del modelo, el servicio, el mantenimiento de seguridad, la monitorización, las actualizaciones, los derechos sobre las voces, la accesibilidad y el soporte siguen necesitando responsables explícitos.

¿Cuál es la prueba más importante del plan de salida?

Exportar e inspeccionar de forma independiente la configuración, el vocabulario y los registros necesarios para continuar, revocar el acceso del proveedor, verificar la supresión de los datos de prueba controlados y demostrar el procedimiento de sustitución o de cierre antes de firmar.