--- title: "Retención de Datos de Formularios: Una Política Que Sí Se Ejecuta" slug: form-data-retention-policy description: "Las políticas de retención fallan al borrar, no al redactarse. Cómo fijar el reloj, elegir un plazo por formulario y hacer del borrado una rutina." publishedAt: "2026-10-08" author: "Instaform Team" tags: ["forms", "compliance", "how-to"] locale: es --- Casi todas las políticas de retención fallan en el mismo punto. Alguien escribe "las consultas se conservan 24 meses" en un documento, lo archiva, y nada cambia aguas abajo. Dos años después la bandeja de entrada sigue conteniendo todas las consultas desde el lanzamiento, más una hoja de cálculo en un portátil y una carpeta de CVs en el almacenamiento compartido. Redactar la política es la mitad fácil. La mitad que decide si es real es si puedes encontrar todas las copias de un envío y eliminarlas sin que alguien pierda un día entero en ello. ## Empieza por el reloj, no por el plazo "Doce meses" no significa nada hasta que dices doce meses desde qué. Hay tres relojes habituales y se comportan de forma muy distinta. *Desde el envío* es el más simple y el adecuado para consultas que no llegaron a nada. El registro caduca en un calendario fijo, pase lo que pase después. *Desde el último contacto* encaja con cualquier cosa que pueda convertirse en una relación. Un lead con el que hablaste en marzo no debería desaparecer porque consultó por primera vez hace catorce meses. Este reloj se reinicia, lo que significa que la fecha de último contacto tiene que estar guardada en un campo por el que puedas filtrar, no deducida de un hilo de correo. *Desde el fin de la relación* es lo que necesitan los registros contables y contractuales. La obligación suele contarse desde el cierre del ejercicio fiscal en el que terminó la relación, no desde la fecha de un formulario concreto. Elige uno por tipo de formulario y escribe el disparador junto al número. Casi todas las discusiones sobre retención son en realidad discusiones sobre el reloj. ## Un plazo por formulario es mejor que un plazo por empresa Una única regla global acaba siendo demasiado corta para los registros que necesitas o demasiado larga para los que no. Puntos de partida razonables: consultas generales que nunca convirtieron, doce meses. Solicitudes de presupuesto, de doce a veinticuatro meses, porque los clientes vuelven. Candidaturas de empleo, de seis a doce meses salvo que la persona acepte permanecer en la base. Tickets de soporte, veinticuatro meses, porque son tu historial de lo que salió mal. Altas de newsletter, hasta la baja, más un registro de supresión conservado indefinidamente, porque necesitas recordar que a esa persona no hay que escribirle. Los registros de clientes y financieros siguen lo que exija tu administración tributaria, y esa exigencia se impone a tu preferencia en ambos sentidos. ## Las copias que vas a olvidar Borrar el envío de la herramienta de formularios es la parte que todo el mundo recuerda. Las copias son la parte que suspende una auditoría. Las notificaciones por correo que incluían el cuerpo completo del envío están en el buzón de cada destinatario, en su teléfono y en el archivo que conserve su proveedor de correo. Es la fuga más común con diferencia, y por eso los correos de notificación deberían decir "ha llegado una consulta nueva" con un enlace en vez de reproducir las respuestas. Las exportaciones en CSV viven en portátiles y unidades compartidas sin caducidad. Cada exportación es una copia nueva fuera de tu sistema de retención, envejeciendo por su cuenta. Los archivos subidos suelen guardarse aparte del registro que los referencia. Borrar un envío puede dejar un CV huérfano en el almacenamiento de objetos indefinidamente. Las copias de seguridad conservan los datos después del borrado por diseño. Eso suele ser aceptable si rotan en un ciclo conocido y nunca se usan para consultas. Anota el ciclo, porque "borramos a petición" y "nuestras copias lo guardan 90 días" tienen que ser ciertas las dos y estar dichas las dos. ## Anonimiza cuando borrar te haga perder algo útil A menudo quieres la forma de los datos sin la persona. Si borras un año de envíos, también borras tu visión de qué canales generaron consultas, qué semanas fueron flojas y qué preguntaba la gente. Quitar los identificadores conserva la respuesta. Elimina nombre, email, teléfono, IP, texto libre y adjuntos; conserva la marca de tiempo, la fuente y las opciones estructuradas. El registro deja de ser dato personal y sigue sirviendo para el [análisis de encuestas](/survey-analytics) y la planificación de volumen. Hazlo deliberadamente. Una anonimización que se deshace cruzando dos tablas no es una anonimización. ## Convierte el borrado en una tarea, no en una intención Las políticas que se ejecutan tienen tres cosas: un responsable con nombre, una fecha recurrente y un filtro guardado que produce la lista. Trimestral basta para la mayoría de negocios. El responsable abre el filtro, comprueba que el recuento tiene sentido, borra y anota la fecha y la cifra en algún sitio. Esa nota es la prueba de que la política funciona, y lleva unos diez minutos cuando los datos están estructurados. Si producir la lista lleva más de unos minutos, el problema es el modelo de datos y no la disciplina. Una bandeja de entrada no se puede filtrar por "último contacto antes de X y nunca convirtió". Los registros estructurados sí. ## Da a las solicitudes de borrado su propia vía Al margen de tu calendario, habrá gente que pida que borres sus datos. Envía eso a algún sitio que no sea la bandeja de entrada de una persona. Un formulario corto con la dirección que usaron, qué quieren eliminar y un paso de confirmación se atiende más rápido y te deja constancia de que actuaste. Nuestra [plantilla de solicitud de eliminación de datos](/templates/data-deletion-request) es ese formulario. En Instaform un envío se convierte en un registro estructurado con fuente, marca de tiempo y fecha de último contacto, así que una ronda de retención es un filtro y un borrado masivo en lugar de un trabajo de arqueología. Esa misma estructura es lo que hace funcionar el [pipeline de CRM](/crm-pipeline). La retención es menos una función de cumplimiento que un efecto secundario de no guardar los datos de clientes en un correo.