Guía práctica · PotencIA · WhatsApp y CRM

Datos personales en conversaciones: qué debería guardar un CRM y con qué criterio

Qué datos personales de una conversación debe guardar un CRM y cuánto tiempo: minimización, plazos legales y el dato de salud que llega sin pedirlo.

Equipo editorial de PotencIAPublicado el
Dos mujeres con americana azul marino, de pie junto a una mesa alta de madera clara en una oficina inmobiliaria; la de la izquierda sostiene un móvil con la pantalla encendida y la de la derecha escribe con bolígrafo en un impreso de papel. Al fondo, el escaparate a la calle con fichas de viviendas colgadas y una planta pequeña en el alféizar.

Un CRM debe guardar el dato que hace falta para prestar el servicio o para cumplir una obligación legal, y borrarlo cuando deje de hacer falta. Ese es el criterio entero: cada campo tiene que poder decir para qué está y hasta cuándo. Lo que la conversación suelta de paso —un diagnóstico, una situación familiar, el motivo real de la prisa— casi nunca pasa esa prueba.

Debajo está lo que exige la norma con el texto delante, qué entra en la ficha y qué se queda en el hilo, los tres relojes que marcan el plazo y cómo repartimos nosotros ese plazo campo por campo. Es criterio operativo con el Reglamento abierto, no asesoramiento jurídico: la base jurídica y los plazos concretos de tu negocio los fija quien lleve tu protección de datos.

El criterio cabe en dos líneas del Reglamento

La norma no da una lista de campos permitidos: da dos pruebas que cada dato tiene que pasar. El Reglamento general de protección de datos exige que los datos personales sean «adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que son tratados» —es el principio de minimización, artículo 5.1.c— y que se mantengan «de forma que se permita la identificación de los interesados durante no más tiempo del necesario para los fines del tratamiento de los datos personales», que es la limitación del plazo de conservación del artículo 5.1.e. Las dos citas son del texto español del Diario Oficial, alojado en el BOE.

Leídas juntas dicen algo muy poco romántico: un campo no se justifica porque algún día pueda ser útil, sino porque hoy sirve a una finalidad concreta. «Por si acaso» no es una finalidad.

Y hay una tercera línea que impide dejar el plazo para más adelante. El artículo 13.2.a obliga a informar a la persona, cuando se obtienen sus datos, de «el plazo durante el cual se conservarán los datos personales o, cuando no sea posible, los criterios utilizados para determinar este plazo». O sea: no hace falta un número exacto para cada campo, pero sí un criterio escrito que permita deducirlo. Las dos opciones que da el Reglamento son un plazo o un criterio; «ya lo miraremos» no es ninguna de las dos.

Esto afecta de lleno a un CRM conversacional, porque es la categoría de herramienta que acumula conversaciones enteras de personas identificables en lugar de formularios con campos acotados.

Qué entra en la ficha y qué se queda en el hilo

En la ficha entra el resultado operativo de la conversación; en el hilo se queda la prueba de lo que se dijo. Son dos cosas distintas con dos plazos distintos, y confundirlas es el origen de casi todos los problemas: la transcripción pegada en el campo de notas convierte un registro de trabajo en un archivo de confidencias.

Para repartir sirve preguntarse, dato a dato, en cuál de estos tres grupos cae:

  1. Sostiene el servicio. Sin ese dato no se puede dar la cita, hacer el presupuesto o montar la instalación. Entra en la ficha.
  2. Sostiene una obligación legal. Normalmente no es la conversación, sino lo que vino después: la factura, el justificante, el libro contable. Entra, pero con su propio reloj, que es el que se explica más abajo.
  3. Solo es contexto de una frase. Explica por qué esa persona escribió ese martes y no sirve para nada más. No entra.

La Agencia Española de Protección de Datos describe exactamente estas dos maneras de decidir en su Guía de Privacidad desde el Diseño (versión de octubre de 2019, PDF). Llama «seleccionar» a elegir «únicamente la muestra de individuos relevante y los atributos necesarios siguiendo una actitud conservadora al establecer el criterio de selección», es decir, la lista blanca; y llama «excluir» al enfoque inverso, apartar de antemano «los sujetos y atributos que resulten irrelevantes para el tratamiento realizado», con el matiz de que ahí hay que «intentar excluir el máximo posible de registros a menos que pueda justificarse que son absolutamente necesarios».

Dicho en castellano de taller: la lista de campos de tu CRM es una lista blanca, no un contenedor. Qué campos operativos son los que de verdad hacen falta —y en qué plazo técnico hay que capturarlos antes de que la plataforma de mensajería los pierda— lo desarrollamos en qué información debe quedar después de cada conversación. Esta pieza se ocupa de la decisión anterior: cuáles de esos datos son personales, cuáles no deberían copiarse y cuánto tiempo se quedan.

El dato que llega sin que lo pidas

Un cliente te cuenta por qué necesita la cita y, sin haberlo pedido, tienes un dato de salud en el móvil. Pasa a diario en clínicas, centros de estética, fisioterapias y despachos, y es el caso que la mayoría de los criterios de «qué campos pongo» no contempla, porque nadie creó un campo para eso: llegó dentro de un mensaje.

El Reglamento es tajante con esa categoría. Su artículo 9.1 empieza así: «Quedan prohibidos el tratamiento de datos personales que revelen el origen étnico o racial, las opiniones políticas, las convicciones religiosas o filosóficas, o la afiliación sindical, y el tratamiento de datos genéticos, datos biométricos dirigidos a identificar de manera unívoca a una persona física, datos relativos a la salud…». Y la definición es amplia: el artículo 4.15 llama datos relativos a la salud a los «datos personales relativos a la salud física o mental de una persona física, incluida la prestación de servicios de atención sanitaria, que revelen información sobre su estado de salud». La prohibición solo se levanta si concurre alguna de las circunstancias del artículo 9.2, entre ellas el consentimiento explícito o el tratamiento necesario para fines de diagnóstico o asistencia sanitaria.

Qué datos conviene no pedir por chat cuando lo único que se está haciendo es dar una cita ya lo tratamos en automatizar reservas por WhatsApp. Aquí el problema es el contrario y no se resuelve igual, porque el dato ya está dicho:

  • El mensaje no se persigue. Está en la conversación y es la prueba de lo que se habló. Borrar mensajes sueltos para «limpiar» deja un historial que no cuadra y no quita el dato de las copias del destinatario.
  • La ficha no lo transcribe. En el campo de qué pidió va la categoría de servicio —revisión, urgencia, tratamiento en curso—, no el motivo clínico. Es la táctica que la AEPD llama «excluir» aplicada al momento de escribir el registro.
  • El hilo tiene su propio plazo, y es el más corto. Si la conversación contiene lo que la ficha no contiene, el plazo de la conversación importa más, no menos.
  • Si eso te pasa todas las semanas, no es una excepción. Un negocio en el que las categorías especiales entran de forma habitual tiene obligaciones que un comercio no tiene, y eso se decide con quien lleve tu protección de datos antes de configurar nada.

Cuánto tiempo: tres relojes que no van juntos

No hay un plazo legal general para la ficha de un cliente; hay tres relojes distintos y el que manda sobre cada dato depende de para qué está ese dato. Confundirlos lleva a los dos extremos que vemos a menudo: guardar todo seis años porque «lo dice la ley», o borrar a los seis meses algo que había que conservar.

El reloj del servicio. Es el del artículo 5.1.e: mientras el dato sirva a la finalidad. No lo fija nadie por ti, lo fijas tú y tienes que poder explicarlo. Es el reloj de la mayoría de los campos de un CRM conversacional.

El reloj de las obligaciones. El artículo 30.1 del Código de Comercio obliga a los empresarios a conservar «los libros, correspondencia, documentación y justificantes concernientes a su negocio, debidamente ordenados, durante seis años, a partir del último asiento realizado en los libros». Por su parte, la Ley 58/2003, General Tributaria impone en su artículo 29.2.d la obligación de «llevar y conservar libros de contabilidad y registros, así como los programas, ficheros y archivos informáticos que les sirvan de soporte», y su artículo 66 fija en cuatro años la prescripción del derecho de la Administración «para determinar la deuda tributaria mediante la oportuna liquidación». Qué documento concreto cae bajo cuál de esos plazos es cosa de tu asesoría; lo que importa aquí es la consecuencia operativa: una conversación que terminó en factura no se borra con el mismo criterio que una que no llegó a nada.

El reloj del bloqueo. Cuando borras, en España no siempre borras del todo. El artículo 32 de la Ley Orgánica 3/2018 obliga al responsable «a bloquear los datos cuando proceda a su rectificación o supresión», y define ese bloqueo como «la identificación y reserva de los mismos, adoptando medidas técnicas y organizativas, para impedir su tratamiento, incluyendo su visualización», salvo para ponerlos a disposición de jueces, Ministerio Fiscal o Administraciones competentes y «solo por el plazo de prescripción» de las posibles responsabilidades. Pasado ese plazo, dice la norma, «deberá procederse a la destrucción de los datos».

Que haya tres relojes es justo lo que hace que el plazo no pueda ser un ajuste global del sistema. Tiene que ir campo a campo. Y así lo plantea la propia AEPD en la táctica que llama «podar»: eliminar los datos «tan pronto dejen de ser necesarios lo cual supone determinar de antemano cuál es el periodo de conservación para cada uno de los datos recogidos y establecer mecanismos automáticos de borrado cuando se cumpla dicho plazo». La guía añade una salida muy práctica para cuando no se puede tirar la fila entera: si los datos «formen parte de un registro en el que figure más información que sea necesario conservar, el valor de los campos no necesarios puede modificarse a un valor por defecto prefijado».

Cómo lo repartimos nosotros, campo a campo

Esto ya no es la norma: es la configuración por defecto con la que montamos nosotros una ficha conversacional, y la damos como criterio propio, no como estándar del sector ni como plazo legal. Se revisa con cada negocio, porque un instalador y una clínica no tienen el mismo reloj.

  1. Identidad: teléfono, nombre y canal. Vive mientras haya relación comercial. Nuestro disparador de revisión son tres años sin ninguna interacción: ahí la ficha se revisa, no se borra automáticamente, porque puede haber un justificante colgando de ella.
  2. Procedencia. Vive con la identidad y es barata de mantener: es un valor de lista corta, no texto libre, y no dice nada de la persona más allá de por dónde llegó.
  3. Qué pidió, en una frase. Vive mientras la oportunidad está abierta. Cuando el caso se cierra sin venta, al año queda el hecho —se pidió presupuesto de esto, no salió— y desaparece la frase.
  4. Qué se le respondió y qué se le prometió. Es el campo con doble reloj. Si aquello terminó en factura, pasa al reloj de las obligaciones y deja de ser una decisión nuestra. Si no terminó en nada, sigue el del servicio.
  5. Estado y siguiente paso. Mueren con el caso. Al cerrarlo quedan la fecha y el resultado; el texto del siguiente paso, que es donde la gente escribe cosas como «llamar, que está liado con lo del padre», no se queda.
  6. Adjuntos del cliente: fotos, audios, documentos. El plazo más corto de todos. Se borran al cerrar el caso salvo que sean justificante de algo, y entonces van al expediente que corresponda, no a la ficha comercial.
  7. El hilo de la conversación. No es la ficha y no debería heredar su plazo. Es el primer sitio por donde conviene acortar, porque es el que más contiene y el que menos se consulta.

Encima de esos siete, dos reglas que nos ahorran discusiones:

  • Ningún campo libre sin plazo. Un campo de texto abierto sin fecha de caducidad acaba siendo el sitio donde el equipo escribe lo que no cabe en ningún otro sitio.
  • Un campo nuevo solo se abre si su finalidad y su plazo caben en la misma frase. Si al pedirlo nadie sabe terminar «esto sirve para… y se guarda hasta…», el campo no se crea. Es la prueba más barata que conocemos del artículo 5.1.c.

Cuando vence el plazo operativo de un campo pero la fila tiene que seguir existiendo para que cuadren los recuentos, aplicamos lo que describe la AEPD: el contenido se sustituye por un valor por defecto y la fila se queda sin el dato personal. Así el histórico de cuántos presupuestos salieron en marzo sobrevive sin que sobreviva lo que cada persona contó.

Lo que mucha pyme cree que no le toca

El registro de actividades de tratamiento no se libra por ser pequeño. Es la confusión más extendida que nos encontramos, y viene de leer medio artículo del Reglamento.

El artículo 30.5 dice que las obligaciones de llevar ese registro «no se aplicarán a ninguna empresa ni organización que emplee a menos de 250 personas», pero sigue: «a menos que el tratamiento que realice pueda entrañar un riesgo para los derechos y libertades de los interesados, no sea ocasional, o incluya categorías especiales de datos personales indicadas en el artículo 9, apartado 1, o datos personales relativos a condenas e infracciones penales».

Ese es el hecho. Nuestra lectura, separada del hecho: un CRM que recoge conversaciones de clientes todos los días no es un tratamiento ocasional por ninguna definición razonable de la palabra, así que la excepción de las 250 personas se cae sola en cuanto hay un CRM funcionando. Y si además el negocio es una clínica o un centro de estética, se cae dos veces. La buena noticia es que el registro, para un negocio pequeño, es un documento corto, y el trabajo de decidir finalidad y plazo campo a campo que describe este artículo es justo el material con el que se escribe.

Ejemplo: el centro de estética que lo guardaba todo

Un centro de estética atiende las citas por WhatsApp. El asistente responde, propone hueco y confirma. Para que el equipo tenga contexto, alguien decidió en su día que el resumen de la conversación se volcara entero en el campo de notas de la ficha.

A los seis meses, esa ficha contiene: el tipo de piel que la clienta describió, la reacción que tuvo a un producto, que viene por una boda y la frase «ahora mismo no puedo, estoy con el tratamiento». Nada de eso se pidió: se dijo. Y nada de eso hace falta para dar una cita.

Lo que cambia aplicando el criterio de arriba, sin tocar el asistente ni cambiar de herramienta: en la ficha queda la categoría de servicio, el estado y el siguiente paso; la conversación sigue íntegra en su sitio, con su propio plazo y más corto que el de la ficha; el campo de notas deja de ser libre y pasa a ser una lista de valores; y el histórico de la clienta se mide por citas, no por confidencias. El equipo pierde cero contexto útil y el centro deja de tener un archivo de datos de salud que nunca quiso montar.

El ejemplo está construido a partir de patrones que vemos, no corresponde a ningún cliente concreto y no lleva cifras. Si tu negocio es de este tipo, el encaje entre agenda, conversación y ficha lo contamos en la página de PotencIA para centros de estética y peluquerías.

Preguntas relacionadas

¿Puedo guardar la conversación entera?

Sí, y normalmente debes: es la prueba de lo que se dijo. Lo que no debe hacerse es usarla como ficha. Hay un motivo práctico además del legal: el artículo 15.3 del Reglamento dice que «el responsable del tratamiento facilitará una copia de los datos personales objeto de tratamiento». Si pegaste la transcripción en el campo de notas, esa transcripción es parte de lo que tendrás que entregar el día que alguien ejerza su derecho de acceso, con todo lo que esa persona contó dentro.

¿Necesito el consentimiento del cliente para guardar lo que me escribe?

No necesariamente, y conviene no simplificarlo. El consentimiento es una de las bases de licitud del artículo 6, no la única, y un presupuesto que el cliente pide no se sostiene en la misma base que una campaña comercial. Donde sí cambia el juego es con las categorías especiales del artículo 9: ahí la regla general es la prohibición, y levantarla exige una de las circunstancias del 9.2, entre ellas el consentimiento explícito. Qué base aplica a cada tratamiento de tu negocio no lo decide el proveedor del CRM: lo decide quien lleve tu protección de datos.

¿Qué hago si un cliente me pide que borre lo suyo?

Lo primero es comprobar si procede: el artículo 17.1.a obliga a suprimir sin dilación cuando «los datos personales ya no sean necesarios en relación con los fines para los que fueron recogidos», y puede haber una factura detrás que lo impida. Y lo segundo, que casi nadie tiene montado: en España, suprimir implica bloquear antes, con la identificación y reserva que describe el artículo 32 de la Ley Orgánica 3/2018. En la práctica eso significa que tu herramienta necesita un estado intermedio entre «visible» y «no existe», y que convendría preguntarlo antes de contratarla, no el día que llega la primera solicitud.

¿Y si uso IA para resumir la conversación?

El resumen también son datos personales, y lo que la IA infiere entra en el mismo criterio. La guía de la AEPD lo dice sin rodeos: «en el caso de tratamientos que infieran nueva información personal, también deben seleccionarse para su exclusión aquellos datos que se generen y no sean necesarios para la finalidad perseguida». Traducido a configuración: al asistente se le dice qué campos tiene que rellenar, no se le pide un resumen libre. Un resumen libre vuelve a meter en la ficha justo lo que el criterio acaba de sacar.

¿El plazo se aplica también a las copias de seguridad?

Sí, y es la parte que más se olvida. La misma guía define «eliminar» como suprimir por completo los datos «tan pronto dejen de ser relevantes asegurándose que no es posible su recuperación ni siquiera de las copias de seguridad realizadas». Si el borrado del CRM no llega a las copias, el plazo que has escrito es un plazo de pantalla, no de verdad. Es una pregunta concreta para el proveedor: cuánto duran las copias y qué pasa en ellas con un dato borrado.

¿Quién del equipo debería ver cada campo?

Es una pregunta distinta a esta y con reglas propias. Decidir qué se guarda y cuánto tiempo es una cosa; decidir quién ve qué, cómo se controla el acceso y qué se le enseña al asistente es otra, y la tratamos aparte.

Por dónde seguir

Si lo que buscas es que todo esto no dependa de la disciplina de nadie —que el campo libre no exista, que el plazo esté puesto y que la conversación entre como información estructurada sin copiar a mano—, eso es lo que resuelve un CRM con WhatsApp integrado. Y si prefieres ver cómo se rellena una ficha sobre una conversación real, con sus campos y sin su transcripción, es lo que enseñamos en una demo de PotencIA.

Fuentes