Qué tener en cuenta sobre los datos personales antes de crear un asistente de voz

Qué produce realmente un asistente de voz

Cuando se ejecuta un flujo conversacional, deja varios tipos de datos distintos, y no son equivalentes. Hasta que no los separes, no podrás juzgar cuántos necesitas de verdad.

• El audio en bruto: el sonido de lo que dijo la persona. El audio es un dato personal en la medida en que puede identificar a quien habla.
• La transcripción: lo mismo que se dijo, en texto. Puede contener nombres, direcciones, datos de salud o financieros.
• Los campos recogidos: lo que el flujo pide a propósito, como nombre, teléfono, fecha o importe.
• Los documentos subidos: un documento de identidad, una factura o un informe. La imagen y los campos extraídos de ella son datos separados.
• Los registros técnicos: dirección IP, datos del navegador, hora de la sesión.

Cómo trata esto la ley de protección de datos

En la UE esto entra en el RGPD, y en el Reino Unido en el UK GDPR; ambos definen los datos personales como información sobre una persona física identificada o identificable. En Turquía, el marco equivalente es la Ley n.º 6698 (KVKK), con una definición comparable. Una grabación o una transcripción puede entrar en cualquiera de ellos.

Dos obligaciones aparecen en la práctica casi siempre: necesitas una base legal para tratar los datos y debes informar a las personas de ese tratamiento. Informar es un deber aparte: no desaparece porque también hayas recogido su consentimiento.

Algunas categorías, como los datos de salud y biométricos, se consideran especiales y tienen condiciones más estrictas. Que una grabación de voz cuente como dato biométrico depende de lo que hagas con ella: usar una huella de voz para identificar a alguien es distinto de simplemente transcribir lo que dijo.

Preguntas que debes responder antes de crear el asistente

Las siguientes son preguntas de diseño más que legales, pero sus respuestas determinan directamente tu posición legal. Responderlas antes de crear el asistente evita tener que volver atrás a limpiar datos.

• ¿Necesitas guardar el audio en bruto o basta con la transcripción? Si basta con la transcripción, no guardes el audio.
• ¿Cuánto tiempo conservarás las transcripciones? Guardarlas indefinidamente no es una decisión: es la ausencia de una.
• ¿El flujo pide algo que en realidad no necesitas? Los datos que nunca recoges son datos que nunca tienes que proteger.
• Si bastan los campos extraídos, ¿necesitas conservar la imagen del documento?
• ¿Quién dentro de tu organización podrá ver estos datos?
• ¿En qué punto del flujo sabe la persona que la conversación se está grabando?

Lo que resuelve el diseño del flujo

Gran parte del trabajo de protección de datos se resuelve en el propio flujo, no en un documento de políticas. Los datos que nunca recoges son datos que nunca tienes que proteger, guardar ni eliminar.

Algunos enfoques que funcionan en la práctica: hacer que el primer paso sea un mensaje informativo; revisar cada campo con la pregunta «¿de verdad lo necesito?»; extraer de los documentos solo los campos necesarios; y dejar a las personas la opción de escribir en lugar de hablar.

En Agenola, quien crea el flujo decide qué preguntas se hacen, qué documento se pide y qué se registra. Los campos recogidos y las transcripciones se quedan en tu espacio de trabajo y se ven desde tu panel. Eso no hace que la herramienta cumpla la ley por ti: significa que las decisiones son tuyas.

Tres errores habituales

• Grabarlo todo y pensar en filtrar después. Los datos generan responsabilidad desde el momento en que se recogen.
• Poner el aviso al final del flujo. Nadie queda informado después de haber entregado ya los datos.
• Confiar en que una herramienta sea «conforme». La conformidad es una propiedad de la organización que trata los datos y de su finalidad, no del software.