Hay un tipo de publicación que se repite cada vez que se acerca la entrada en vigencia de la ley de datos: alguien explica que el consentimiento es una cosa sencilla, que basta con poner una casilla antes del botón de enviar y guardar que la persona dijo que sí. Es una media verdad, y de las peligrosas. Capturar el sí es lo fácil. Lo que la Ley 21.719 te va a exigir el día que alguien reclame es otra cosa, y es justo la parte que esos posts no mencionan.
La diferencia se entiende con una pregunta incómoda. Si mañana un cliente, la Agencia o un juez te pide que demuestres que cierta persona consintió, ¿qué puedes mostrar? No basta con afirmar que en tu base hay un registro que dice que aceptó. Tienes que poder mostrar qué texto leyó exactamente, en qué momento, por qué canal, y que ese registro no se modificó después. Esa es la parte difícil del consentimiento, y no se resuelve con una casilla.
Qué es un consentimiento bajo la 21.719
El artículo 12 de la ley fija cuatro condiciones para que un consentimiento valga. Tiene que ser libre, o sea sin presión ni una contraprestación encubierta. Informado, lo que significa que la persona supo qué datos entrega, para qué y quién los va a tratar. Específico, atado a una finalidad concreta y no a un permiso general para todo. E inequívoco, expresado con una acción afirmativa clara y no deducido de tu silencio.
Eso entierra varias prácticas que hoy son comunes. Se acabó el consentimiento tácito, las casillas que vienen premarcadas y los esquemas de opt-out donde tu inacción se interpreta como un sí. Si querías inscribir a alguien en una lista de correo porque no se molestó en desmarcar una casilla, eso ya no es consentimiento válido.
Hay un punto que cambia todo el diseño del problema y que casi nadie subraya: la carga de la prueba es tuya. Ante un reclamo, no es la persona la que tiene que demostrar que nunca aceptó. Eres tú, como responsable del tratamiento, quien tiene que probar que el consentimiento se obtuvo de forma válida. Si no puedes mostrar la evidencia, a efectos prácticos es como si nunca lo hubieras pedido. El consentimiento, entonces, no es el momento en que la persona hace clic. Es la prueba de ese clic que tú vas a tener que conservar y poder reconstruir mucho después.
El primer detalle que se pierde: qué texto aceptó
Tu formulario de consentimiento no es un documento eterno. Vas a cambiar la redacción, vas a sumar una finalidad nueva, vas a ajustar a quién le compartes datos. Cada uno de esos cambios crea, en la práctica, un consentimiento distinto, porque la persona que aceptó la versión de enero leyó algo distinto de la que acepta la de junio.
Acá aparece la falla silenciosa de casi toda implementación casera. Si guardas un campo que dice "aceptó términos de marketing", ese campo apunta al texto vigente. El día que edites el texto, todos los consentimientos viejos quedan apuntando a una redacción que esas personas nunca vieron. Perdiste la prueba sin darte cuenta, y encima ahora tu registro afirma algo falso.
La forma correcta es tratar cada versión del formulario como un documento sellado e inmutable. Al publicarla, se le calcula un hash, una huella única de su contenido, y queda congelada. El consentimiento no guarda un sí genérico: guarda el identificador y el hash de la versión exacta que la persona tuvo enfrente. Cambiar el texto crea una versión nueva y no toca ninguna de las anteriores.
Versionado sellado
El formulario evoluciona
Lo que aceptó cada persona queda anclado
El segundo detalle: que el registro no se pueda alterar
Supongamos que sí guardas el texto correcto. Queda un problema más profundo, y es el que de verdad separa un sistema serio de una planilla. Una fila en una tabla con aceptó = verdadero y una fecha es trivial de editar. Cualquier persona con acceso a la base puede cambiar la fecha, dar vuelta el flag o borrar la fila, y no queda ninguna huella de que eso pasó. Frente a un reclamo, un registro que cualquiera pudo modificar sin dejar rastro no prueba demasiado.
La salida es no permitir ediciones. Otorgar y revocar dejan de ser cambios sobre una fila y pasan a ser eventos que se agregan, uno tras otro, sin borrar nunca el anterior. Revocar no apaga el consentimiento anterior: anota encima un evento nuevo de revocación. Así queda la historia completa de lo que ocurrió, en orden.
Encima de eso va la pieza que vuelve el registro a prueba de manipulación. Cada evento se encadena con el anterior mediante su hash. Ese hash se calcula sobre todo el contenido del evento (la fecha, el canal, la identidad con que se verificó a la persona, la versión aceptada y los adjuntos) e incluye además el hash del evento previo. Los eventos quedan entrelazados como eslabones. Si alguien edita un solo campo de un evento pasado directamente en la base, su hash recalculado deja de coincidir con el guardado, y como ese valor alimentaba al siguiente eslabón, la cadena se rompe desde ese punto hacia adelante. La alteración no se puede esconder: una verificación la detecta de inmediato.
Cadena de evidencia
- Fecha
- 12 abr 2026
- Canal
- Widget web
- Identidad
- Identidad autenticada
- Versión
- v2
prev 0000…0000
hash 4c7a…91e2
- Fecha
- 03 may 2026
- Canal
- Portal del titular
- Identidad
- Identidad autenticada
- Versión
- v2
prev 4c7a…91e2
hash 9f31…c20b
Cadena íntegra. Recalcular cada hash da el mismo valor guardado. La verificación pasa con cero discrepancias.
Cualquier cambio se nota. Editar una sola fecha o un flag en la base recalcula su hash, deja de coincidir y rompe la cadena desde ahí.
Por qué armarlo en casa sale más caro de lo que parece
Visto de lejos, capturar consentimiento parece un fin de semana de trabajo: un formulario, una tabla, un campo booleano. Por eso tantos equipos lo subestiman. El problema es que lo que parece el trabajo completo es apenas la punta visible, y lo que falta debajo es lo que la ley realmente te va a pedir mostrar.
Una implementación hecha en casa para salir del paso suele quedarse sin lo que importa. No versiona el texto, así que pierde la redacción exacta que cada persona aceptó. Guarda el consentimiento en una tabla editable, sin forma de demostrar que no se tocó. No registra con qué nivel de certeza se verificó la identidad de quien aceptó, ni si fue por el sitio, por un formulario en papel o de viva voz. Trata la revocación como un borrado en vez de un evento que se conserva. Y no tiene cómo reconstruir, persona por persona y fecha por fecha, la historia que una fiscalización te va a pedir.
Nada de eso es imposible de construir. Lo difícil es que ninguno de esos elementos es opcional, y juntos forman un sistema de evidencia, no un formulario. Sellado de versiones, registro append-only, encadenamiento por hash, grados de verificación de identidad, captura por varios canales, verificación de integridad. Cada uno tiene sus aristas, y un error en cualquiera deja un hueco que recién vas a notar cuando ya sea tarde, el día que tengas que probar algo y descubras que la prueba no resiste. Subcontratar el formulario es barato. Reconstruir la confianza en un registro que alguien pudo haber editado no lo es.
Lo que hace confiable un consentimiento
Al final, la pregunta no es si capturaste el sí. Es si, dos años después, puedes abrir el expediente de una persona y demostrar, sin pedirle a nadie que te crea, qué texto aceptó, cuándo, por qué canal, con qué verificación de identidad, y que ese registro está intacto desde el primer día.
En Alicanto construimos la plataforma de protección de datos sobre esa idea. Cada consentimiento guarda el hash de la versión exacta que la persona leyó, cada otorgamiento y cada revocación quedan como eventos encadenados que no se pueden alterar sin que se note, y el historial completo se puede verificar y exportar cuando alguien lo pida. No es un formulario con una casilla. Es la prueba que vas a necesitar el día que cumplir deje de ser una intención y haya que demostrarlo.
