← Todos los artículos

Ley de datos

El formulario de contacto de tu web probablemente ya no cumple: qué le falta

Nombre, correo, mensaje y enviar. Ese formulario que llevas años usando hoy recolecta datos personales sin decir para qué. Qué revisar y qué cambiar, punto por punto.

· 6 min de lectura

El formulario de tu web lo pusiste hace años y funciona: nombre, correo, teléfono, mensaje, enviar. Llega un aviso a tu casilla, tú respondes y la conversación sigue por WhatsApp. Nadie se ha quejado nunca.

El problema no es que el formulario esté roto. El problema es que está recolectando datos personales de tus clientes sin decirles para qué, sin registrar que aceptaron nada y sin que tú sepas dónde terminan esos datos. Eso hasta ahora era desprolijidad. Desde el 1 de diciembre de 2026 pasa a ser un incumplimiento con nombre.

Y es la pieza más fácil de arreglar de toda tu presencia digital, porque es la puerta por donde entran los datos.

¿Qué cambió exactamente?

La Ley 21.719 de protección de datos personales ya está publicada. Su fecha de entrada en vigencia es el 1 de diciembre de 2026. Existe un proyecto, ingresado el 1 de septiembre de 2026, que la postergaría a diciembre de 2027: está en la Comisión de Constitución del Senado y todavía no se vota.

Dicho de otra forma: la ley está publicada, la Agencia de Protección de Datos se está instalando y la fecha se discute. Que entra en vigencia, no se discute.

Lo que cambia para ti es simple. Hasta ahora, pedir el correo de alguien era un trámite. Desde la vigencia de la ley, cada vez que alguien llena tu formulario tú pasas a ser responsable de esos datos: tienes que poder explicar para qué los pediste, con qué permiso los guardas, por cuánto tiempo y quién más los ve.

Y la carga de la prueba es tuya. No basta con que hayas actuado bien: tienes que poder demostrarlo.

¿Por qué un formulario de tres campos se volvió un problema?

Porque a ese formulario le faltan cosas que nunca nadie te dijo que necesitaba. Repasemos lo que hoy típicamente no tiene.

No declara la finalidad. La ley exige que el consentimiento sea específico en cuanto a la finalidad: la persona tiene que saber para qué entrega sus datos. "Contáctanos" no es una finalidad. "Para responder tu consulta y coordinar una hora" sí lo es.

No tiene base de licitud declarada. La base de licitud es el permiso legal que te habilita a tratar un dato. La regla general es el consentimiento, pero hay otras: ejecutar un contrato, cumplir una obligación legal, el interés legítimo. Necesitas saber cuál invocas en cada formulario, porque de eso dependen los derechos que puede ejercer la persona.

Tiene la casilla premarcada, o no tiene casilla. El consentimiento debe ser previo, inequívoco y otorgado por un acto afirmativo claro. Una casilla que viene marcada de fábrica no es un acto afirmativo: es una suposición. Y la ley presume que el consentimiento no fue libre cuando se recaba dentro de un servicio donde esa recolección no era necesaria.

Mezcla todo en una sola aceptación. Responder una consulta y mandar promociones son dos finalidades distintas. Si las juntas en un "acepto", el permiso para la segunda no vale. Cada finalidad secundaria —marketing, newsletter, analítica, uso de inteligencia artificial— va como una casilla aparte que se puede dejar sin marcar.

Pide más datos de los que necesita. El principio de minimización obliga a pedir solo lo estrictamente necesario. Ese campo de RUT "por si acaso", la fecha de nacimiento, el campo abierto donde el paciente escribe su diagnóstico: si no lo usas, no lo pidas. Lo que no guardas no lo puedes perder.

No guarda evidencia. Aunque la persona haya aceptado, si tu formulario solo te manda un correo, no tienes registro de qué texto aceptó, en qué versión ni en qué fecha. El día que alguien reclame, tu defensa es tu memoria.

¿Dónde terminan realmente los datos que entran por ahí?

Esta es la parte que casi nadie revisó. El formulario de tu web probablemente no guarda nada: envía un correo. Y ese correo viaja y queda copiado en varios lugares al mismo tiempo.

Haz el ejercicio con tu propio sitio y anota las respuestas:

  • ¿A qué casilla llega? Si llega a un Gmail personal que también usan otras personas, ya tienes un problema de accesos.
  • ¿Pasa por algún servicio intermedio? Muchos formularios de plantilla mandan los datos a la plataforma que los provee antes de llegar a ti. Esa plataforma es un encargado de tratamiento y necesita un contrato.
  • ¿Se guarda una copia en el sitio? Algunos sistemas almacenan cada envío en una base de datos que nadie mira ni depura nunca.
  • ¿Se copia a una planilla o a un CRM? Un CRM es el sistema donde se registran clientes y conversaciones. Si está fuera de Chile, hay una transferencia internacional que declarar.
  • ¿Quién tiene acceso a todo eso? Incluye a quien te hizo el sitio, si todavía tiene las claves.

Si no puedes responder estas cinco preguntas, no es porque seas desordenado. Es porque nadie te entregó esa información cuando te hicieron la web, y ese es exactamente el vacío que la ley ahora te pide llenar.

¿Qué tan común es estar así?

Bastante. Según el estudio de LemonTech y la Asociación Chilena de Ética y Compliance (ACEC) sobre 127 organizaciones con operaciones en Chile, publicado el 23 de septiembre de 2026, el 72% reconoce no estar preparada y la cifra sube al 90% entre las empresas pequeñas. Un 46% no ha implementado ninguna medida y solo un 34% tiene un Registro de Actividades de Tratamiento, el documento que lista qué datos trata la empresa y para qué.

Para dimensionar el otro lado: la ley clasifica las infracciones y las sanciona en UTM. No cumplir el deber de información y transparencia es una infracción leve, de hasta 5.000 UTM. Tratar datos sin consentimiento o sin base legal es grave, de hasta 10.000 UTM.

El dato no es para asustarte. Es para que veas la proporción: arreglar un formulario cuesta infinitamente menos que cualquiera de esos escenarios, y además te deja el negocio ordenado.

¿Cómo se ve un formulario que sí cumple?

Concretamente, esto es lo que hay que dejar montado:

  1. Una frase de finalidad visible junto al botón, no escondida en un enlace: para qué vas a usar esos datos y por cuánto tiempo los guardas.
  2. Una casilla sin premarcar para la finalidad principal, con enlace a tu política de tratamiento de datos.
  3. Casillas separadas y opcionales para cualquier uso secundario, como recibir novedades.
  4. Solo los campos que usas. Revisa uno por uno y borra el resto.
  5. Registro del consentimiento: qué versión del texto aceptó, con fecha y hora, guardado junto al envío.
  6. Una forma fácil de revocar. La ley exige que retirar el consentimiento sea tan expedito y gratuito como darlo.
  7. Un destino definido: una casilla de correo del negocio, con acceso controlado, y un plazo tras el cual los datos de quienes nunca se convirtieron en clientes se eliminan.

Nada de esto te obliga a entender de programación. Te obliga a exigir que quien administra tu sitio te lo deje funcionando y documentado.

¿Y si mi formulario pide datos de salud?

Ahí el estándar sube. Los datos de salud son datos sensibles: información que, mal usada, puede generar discriminación. Requieren consentimiento expreso y solo pueden tratarse para los fines sanitarios que las leyes especiales permiten.

En la práctica eso significa que el campo abierto de "cuéntanos tu caso" en la web de una consulta es un riesgo real: la persona escribe su diagnóstico y ese dato queda viajando por correo. La solución no es dejar de agendar por internet, es que el dato clínico se capture dentro de un sistema con control de acceso y registro, no en un formulario público.

Por dónde partir esta semana

Abre tu propia web como si fueras un cliente. Llena el formulario y mira qué te pide, qué te informa y dónde llega. Después revisa si el enlace a tu política de privacidad existe, si abre, si tiene fecha y si dice algo sobre tus formularios reales.

Con eso ya sabes el tamaño del trabajo. Casi siempre es más chico de lo que temías y más grande que "agregar una casilla".

Una precisión: esto es contenido educativo, no asesoría legal. En LPage implementamos la parte técnica —el formulario, el registro de consentimiento, la política publicada, los accesos— y la revisión legal la visa un abogado, en nuestro caso Gian Piero Serafini. Lo que sí podemos comprometer es cumplimiento documentado y acreditable: que puedas mostrar, con evidencia, cómo tratas los datos de tus clientes.

Tu formulario es la puerta de entrada de tu negocio. Vale la pena que esté a la altura de lo que hay adentro.

Equipo LPage

Preguntas frecuentes

¿Necesito una casilla de aceptación en el formulario de contacto de mi web?

Sí, cuando la base que invocas es el consentimiento. Debe estar sin premarcar, indicar la finalidad específica para la que usarás los datos y enlazar a tu política de tratamiento. Si además quieres enviar promociones o novedades, eso va en una casilla separada y opcional: una sola aceptación que mezcla todo no sirve como permiso para las finalidades secundarias.

¿Desde cuándo rige la Ley 21.719 en Chile?

La ley está publicada y su fecha de entrada en vigencia es el 1 de diciembre de 2026. Hay un proyecto ingresado el 1 de septiembre de 2026, hoy en la Comisión de Constitución del Senado y sin votación, que la postergaría a diciembre de 2027. Mientras ese proyecto no se convierta en ley y se publique, la fecha vigente sigue siendo diciembre de 2026.

¿Qué pasa con los correos y contactos que junté antes de que rija la ley?

Esa base no desaparece, pero tienes que poder explicar con qué permiso la tienes y para qué la usas. Lo práctico es revisar de dónde vino cada contacto, depurar lo que nunca usaste, dejar de enviar comunicaciones a quien no las pidió y ofrecer una salida clara. Los datos que recolectaste para una negociación que no prosperó deben suprimirse o anonimizarse.

¿Quién responde si el formulario lo hizo la persona que me desarrolló el sitio?

Frente a tus clientes respondes tú, porque eres quien decide para qué se usan esos datos. Tu proveedor tecnológico responde como encargado del tratamiento y por eso necesitan un contrato de encargo, conocido como DPA, que defina qué hace con los datos, por cuánto tiempo y qué pasa con ellos cuando termina la relación.