Sobre una grabación se pueden pedir dos análisis además de la transcripción: el tono —si la voz suena tensa, alegre, plana— y el perfil del hablante, que estima características como el rango de edad o el género a partir de la señal.
Los dos son útiles. Los dos se malinterpretan con mucha facilidad. Y hay una frontera que preferimos poner nosotros antes de que la ponga un titular de periódico.
Son estimaciones acústicas. El sistema mide características físicas de la señal —tono fundamental, timbre, energía, ritmo— y las compara con patrones aprendidos.
Eso significa dos cosas incómodas:
Se equivocan. No ocasionalmente: de forma perfectamente normal. Una voz ronca por un resfriado, un acento poco representado en los datos de entrenamiento, una línea telefónica mala, alguien que habla bajo porque está en una oficina. Cualquiera de esas cosas cambia el resultado.
No miden lo que parece que miden. El análisis de tono no dice si alguien está enfadado: dice que su voz suena como suenan las voces que en los datos de entrenamiento estaban etiquetadas como enfadadas. Hay gente que discute en voz baja y gente que se alegra gritando.
En agregado y sobre procesos, no sobre personas:
Fíjate en el patrón: en los tres casos el resultado apunta a un proceso que hay que revisar, no a una persona a la que juzgar.
No deben usarse para decidir sobre una persona. Ni para contratar, ni para descartar un currículum, ni para puntuar a un empleado, ni para decidir a quién se atiende antes.
No lo decimos por prudencia legal. Lo decimos porque el sistema no sabe hacer eso, y usarlo así produce decisiones que parecen objetivas —salen de una máquina, vienen con un número— y que en realidad están midiendo el resfriado de alguien, o su acento.
Cuando una estimación acústica entra en una decisión con consecuencias, el error deja de ser un porcentaje en una tabla y pasa a ser una persona concreta a la que le ha pasado algo.
Conviene decirlo porque casi nadie lo advierte: estos análisis producen inferencias sobre una persona a partir de su voz. Según para qué se usen, pueden acercarse a lo que el RGPD llama categorías especiales de datos, del artículo 9.
Y si el resultado alimenta una decisión automatizada con efectos significativos sobre alguien, hay más artículos en juego. Si tu caso se acerca a esa frontera, es un caso que pide una evaluación de impacto antes que una integración.
Estas dos funciones llevan su advertencia en la documentación, en la página de casos de uso y en la propia respuesta de la API. No está escondida en un anexo: está en el mismo sitio donde se explica para qué sirven.
Podríamos no ponerla. Vendería marginalmente mejor. Pero un proveedor que te deja construir algo que se va a caer —legalmente, éticamente o las dos— no te está haciendo un favor; te está pasando el problema y cobrándote por ello.
Y va también la otra mitad, que es igual de importante: identificar a una persona por su voz no lo ofrecemos y no lo vamos a ofrecer. Eso es tratamiento biométrico, es otra categoría de producto y de riesgo, y casi nadie que lo pide lo necesita de verdad — lo que necesita suele ser separar interlocutores, que es otra cosa y sí está disponible.
¿Algo que añadir o que corregir? Escríbenos a support@uttera.ai. Si nos corriges, editamos la entrada y te damos crédito.
Uttera