Qué debe revisar tu agencia a nivel legal antes de entregar una web en 2026

Hay una situación que se repite demasiado en mi trabajo como consultora de cumplimiento normativo en negocios digitales.

El cliente llega preocupado porque ha recibido una reclamación, porque alguien le ha advertido de que su web incumple alguna obligación o porque un cliente enfadado le ha amenazado con denunciarle.

Muchas veces me dicen: “Pero si la web me la hizo una agencia. Me dijeron que estaba lista”.

Y entonces empiezo a revisar.

La web puede estar perfectamente diseñada, funcionar bien, cargar rápido y cumplir técnicamente con todo lo que el cliente pidió. Pero eso no significa que esté preparada para operar desde el punto de vista del cumplimiento.

Demasiadas veces encuentro webs que presentan carencias de cumplimiento que nadie había detectado. No necesariamente porque la agencia haya hecho un mal trabajo. El problema suele empezar antes, durante el desarrollo, porque no se hicieron las preguntas necesarias.

Qué datos se iban a recoger, qué herramientas se iban a integrar, qué ocurría realmente al enviar un formulario o completar una compra. Qué cuestiones debía resolver el cliente antes de poner la web en funcionamiento para poder operar sin riesgos y ofrecer el nivel de garantías óptimo para los usuarios que interactúen con ella.

Y ahí es donde veo una oportunidad enorme para las agencias.

No se trata de convertir a diseñadores y desarrolladores en expertos en normativa ni de trasladarles la responsabilidad jurídica del cliente: se trata de incorporar una capa básica de revisión que permita detectar, documentar y escalar las cuestiones de cumplimiento que aparecen durante el desarrollo y que no deberían descuidarse.

Porque una agencia no asume automáticamente la responsabilidad jurídica del titular de la web por cada incumplimiento que exista en el proyecto, pero tampoco es irrelevante cómo ha intervenido, qué servicios ha prestado, qué obligaciones ha asumido o qué cuestiones ha detectado y comunicado.

Eso es lo que quiero abordar en este artículo: qué deberías revisar como agencia antes de entregar una web, qué aspectos conviene comunicar al cliente, qué herramientas pueden ayudar y cómo convertir todo esto en un protocolo práctico y repetible.

Qué cubrir como parte de la revisión legal de una web

Lo habitual en la mayoría de las agencias es pedirle al cliente sus textos legales, copiarlos, pegarlos en el footer y dar el trabajo por terminado. Si acaso, el control de calidad consiste en abrir la política de privacidad, comprobar que menciona el RGPD y poner un visto bueno.

El problema de este enfoque es que el documento sólo describe lo que la web debería hacer. Una auditoría comprueba lo que la web hace en la práctica. Y esas dos realidades coinciden con muchísima menos frecuencia de la que nos gustaría.

Por eso, antes de abrir un solo texto legal, pruebo la web exactamente como lo haría un usuario: navego, relleno formularios, simulo un proceso de compra, inspecciono la consola del navegador y compruebo qué cookies o scripts se cargan antes de que nadie haga clic en «aceptar». Solo cuando tengo claro el comportamiento de la página tiene sentido revisar los documentos y comprobar si coinciden con la realidad.

¿Están todos los textos legales?

Antes de entregar una web, comprueba que están incluidos y accesibles todos los textos legales que correspondan al proyecto: aviso legal, política de privacidad, política de cookies, condiciones de contratación y, cuando proceda, otros textos específicos según la actividad.

No basta con que exista una página de «Legal». Hay que asegurarse de que cada texto esté publicado, sea accesible desde la web y corresponda a las funcionalidades y servicios que realmente ofrece.

La revisión debe servir para detectar tanto textos que faltan como documentos que han quedado desactualizados o que no corresponden con la web entregada.

Formularios y recogida de datos

Cada formulario cuenta una historia sobre qué datos se tratan y para qué. Por eso es importante revisar:

• Qué campos pide realmente frente a qué campos necesita para la finalidad declarada;
• Si existe información en el propio formulario, no solo en un enlace perdido al final de la página;
• Qué ocurre técnicamente con esos datos una vez enviados: a qué correo llegan, si se guardan en una base de datos, si pasan por un CRM o una herramienta de automatización;
• Si hay casillas de consentimiento marcadas por defecto, algo que contradice el principio de protección de datos por defecto del artículo 25 del RGPD.

Este último punto, personalmente, lo explico siempre con el mismo ejemplo. Un formulario de contacto que pide nombre y correo para responder a una consulta no necesita, además, fecha de nacimiento, empresa, cargo y teléfono, salvo que esos datos tengan una finalidad concreta y declarada. Cuantos más campos innecesarios, más difícil resulta justificar después por qué se recogieron.

Cookies y tecnologías de seguimiento

Aquí es donde suelo encontrar la distancia más grande entre la teoría y la práctica.

Por regla general, el cliente no tiene la menor idea de qué cookies o scripts se van a instalar en su web, simplemente pide un chat en vivo, un reproductor de vídeo, una tipografía concreta o un mapa interactivo para su página de contacto. Es la agencia la que elige e integra el plugin o la herramienta que lo hace posible y, con esa decisión técnica, quien termina «plantando» en el sitio todo un ecosistema de rastreadores, en ocasiones sin avisar a nadie.

Por eso, una agencia no puede limitarse a instalar código de forma alegre. Necesita saber exactamente qué implica cada integrador técnico y explicárselo con claridad al cliente antes de publicar nada.

Hay que identificar qué tecnologías cargan en segundo plano (píxeles publicitarios, métricas de analítica, herramientas de remarketing, mapas o scripts de terceros) y recordar el principio básico de la Agencia Española de Protección de Datos que, en su guía sobre el uso de cookies, deja claro que ninguna cookie no esencial debe ejecutarse antes de que el usuario otorgue su consentimiento informado.

A partir de ahí, la auditoría revisa el comportamiento del banner: si el botón de rechazar tiene exactamente la misma visibilidad y nivel de acceso que el de aceptar, si ofrece un panel de configuración granular por categorías y si el mecanismo no añade trabas innecesarias para denegar el rastreo. Un banner impecable en lo estético no legitima nada si, por detrás, la agencia ha dejado cargando scripts sin el permiso del usuario.

Contratación electrónica y checkout

Si la web vende, ya sean productos físicos, digitales, servicios o membresías, el nivel de exigencia sube un escalón. El Real Decreto Legislativo 1/2007 regula, entre otras cuestiones, la información precontractual y determinados requisitos de los contratos celebrados a distancia con consumidores.

En esta parte de la auditoría, es importante revisar si el proceso de compra muestra el precio total, los gastos de envío cuando existan, el derecho de desistimiento cuando corresponda, y si el resumen del pedido antes de pagar deja claro qué está aceptando el usuario.

También es importante que compruebes si existe un botón que indique de forma expresa la obligación de pago, algo que en muchos checkouts sigue apareciendo simplemente como «continuar» o «siguiente».

El botón de desistimiento

Una obligación reciente que casi ninguna de las webs que reviso tiene incorporada y que conviene incluir en cualquier auditoría es la función del botón de desistimiento online que desarrollo en mi blog.

La Directiva (UE) 2023/2673 introdujo una función específica para facilitar el ejercicio del derecho de desistimiento en determinados contratos a distancia celebrados mediante una interfaz en línea. Los Estados miembros debían adoptar las medidas de transposición antes del 19 de diciembre de 2025 y aplicarlas desde el 19 de junio de 2026. España figura entre los estados respecto de los cuales la Comisión Europea inició un procedimiento por falta de comunicación de la transposición completa.

Para las agencias, la consecuencia práctica es sencilla: este punto ya debe formar parte de la revisión de cualquier proyecto de comercio electrónico en el que exista derecho de desistimiento.

La obligación es concreta: el comerciante debe ofrecer una función de desistimiento visible, permanente durante todo el plazo del derecho de desistimiento y fácilmente localizable, identificada con la expresión «desistir del contrato aquí» o una formulación igualmente inequívoca. Esta función debe permitir al consumidor enviar su declaración de desistimiento directamente desde la interfaz, sin tener que buscar un correo de contacto o rellenar un formulario ajeno al proceso de compra.

Por eso, en cualquier auditoría de una tienda online, hay que revisar si existe, aunque todavía no haya un desarrollo reglamentario español específico que exija esta función de forma literal.

Integraciones de terceros e inteligencia artificial

Cada herramienta conectada a una web (email marketing, CRM, pasarela de pago, chatbot, sistema de reservas) implica un flujo de datos que hay que identificar y, cuando corresponda, documentar. No basta con que sepas que existe una integración; hay que saber qué datos viajan hacia ella y con qué finalidad.

A esto se suma ahora la inteligencia artificial. El Reglamento (UE) 2024/1689 (AI Act) entró en vigor el 1 de agosto de 2024, y su artículo 50 recoge obligaciones de transparencia para determinados sistemas de IA, entre ellas la de informar a las personas de que están interactuando con un sistema de este tipo. Estas obligaciones son aplicables desde el 2 de agosto de 2026.

Cuando una web incorpora una funcionalidad de IA que interactúa directamente con personas, hay que identificar quién proporciona el sistema, quién lo despliega, qué datos recibe, qué decisiones o respuestas produce y qué obligaciones de información pueden resultar aplicables.

En los supuestos cubiertos por el artículo 50 del AI Act, debe analizarse, además, cómo y cuándo se informa a la persona de que está interactuando con un sistema de IA.

En esta guía de IA y RGPD para WordPress te cuento más.

Qué herramientas pueden ayudarte

Una auditoría también sirve para recomendar con qué herramientas resolver lo que se ha detectado. No todas sirven para lo mismo y elegir mal suele generar más trabajo del que ahorra. Estas son las que más recomiendo, según el problema que resuelven.

La idea no es llenar la web de herramientas. Es utilizar las que realmente ayuden a controlar los puntos críticos del proyecto y, sobre todo, saber qué está haciendo cada una.

En el caso de la inteligencia artificial, esto es especialmente importante. Antes de preguntarse qué aviso hay que colocar, como hemos visto anteriormente, conviene saber qué IA se está utilizando, quién la ha integrado, qué datos recibe y el papel que desempeña en la experiencia del usuario. Solo entonces tiene sentido analizar las obligaciones que pueden resultar aplicables.

Hay otra pieza que suelo revisar y que no tiene que ver con el consentimiento, sino con algo igual de determinante para el cumplimiento: el estado técnico de la web.

Un plugin de WordPress desactualizado, una vulnerabilidad sin parchear o una copia de seguridad que nadie comprueba que funciona son, en la práctica, tan relevantes para la seguridad de los datos que se tratan como un banner de cookies mal configurado.

Aquí es donde las herramientas de mantenimiento centralizado como Modular DS entran en juego. Te permiten ver de un vistazo qué webs tienen plugins o versiones de WordPress pendientes de actualizar, programar copias de seguridad automáticas y generar reportes que documentan al cliente qué se ha hecho y cuándo.

Protocolo práctico para convertir las revisiones legales en un proceso

Para quien gestiona varias webs de clientes, en lugar de improvisar cada vez desde cero, recomiendo apoyarse en un método o diagnóstico estructurado que permita repetir la misma revisión (qué hace la web de un cliente, qué herramientas intervienen y qué queda pendiente de resolver) con criterios homogéneos, evitando que cuestiones importantes pasen desapercibidas. Es lo que uso en mi propio proceso de trabajo con clientes.

1. Comprueba qué hace la web

Haz una lista rápida:

• ¿Vende o permite contratar servicios?
• ¿Recoge datos mediante formularios?
• ¿Tiene usuarios registrados o áreas privadas?
• ¿Utiliza cookies, analítica o publicidad?
• ¿Está conectada con herramientas externas?
• ¿Utiliza funcionalidades de IA?

2. Haz inventario de herramientas

Identifica qué servicios están conectados a la web: analítica, CRM, email marketing, publicidad, pagos, reservas, mapas, vídeos, chatbots, automatizaciones, IA, etc.

No hace falta analizar jurídicamente cada herramienta. Primero hay que saber cuáles existen y qué función cumplen.

3. Prueba la web como usuario

No te limites a mirar que todo funciona. Haz pruebas reales:

• Envía un formulario.
• Haz una compra o contratación de prueba.
• Comprueba las cookies y scripts.
• Revisa qué ocurre después de enviar datos.
• Comprueba y documenta las funcionalidades que dependen de terceros.

4. Comprueba que la documentación encaja

Una vez hayas probado la web, revisa, según el proyecto:

• El aviso legal.
• La política de privacidad.
• La política de cookies.
• Las condiciones de contratación.
• El desistimiento.
• Las suscripciones y renovaciones.
• Información específica de determinadas funcionalidades, cuando corresponda.

La pregunta en este paso no es si la información legal está publicada. La pregunta es: ¿describe lo que la web hace actualmente?

Recuerda que este tipo de documentación debe coincidir con lo que realmente ocurre en el sitio.

5. Deja todo clasificado

Cada incidencia debería terminar en una de estas cuatro categorías:

Sobre todo, deja constancia de lo que has detectado, de quién debe actuar y de cualquier acción pendiente.

Este pequeño protocolo puede evitar que una cuestión detectada durante el desarrollo termine convirtiéndose, meses después, en un problema que nadie recuerda haber visto.

Checklist legal antes de publicar una web

Antes de dar un proyecto por terminado, usa la siguiente checklist como última comprobación.

No sustituye el protocolo anterior, pero te ayudará a confirmar que ningún punto se ha quedado sin mirar o incompleto por el camino.

Identificación y operativa

☐ Sé quién es el titular real de la actividad y he comprobado que los datos identificativos están actualizados.
☐ He identificado qué datos recoge la web a través de formularios, registros, procesos de compra y otras funcionalidades.
☐ Sé qué herramientas y servicios de terceros están conectados, incluyendo analítica, CRM, email marketing, píxeles, mapas, vídeos, pasarelas de pago, sistemas de reservas o herramientas de IA.

Comprobación técnica

☐ He comprobado qué cookies, scripts y tecnologías se cargan realmente y cuándo se activan.
☐ He probado los formularios para ver qué ocurre con los datos después de enviarlos.
☐ He revisado el proceso de compra, si existe, incluyendo la información mostrada antes de realizar el pago.
☐ He comprobado los procesos de cancelación o desistimiento, cuando sean aplicables al proyecto.

Documentación y entrega

☐ He revisado si la documentación disponible coincide con la operativa real de la web.
☐ He identificado los puntos que requieren una decisión o información por parte del cliente.
☐ He documentado los hallazgos que requieren revisión jurídica o especializada.
☐ He dejado constancia de lo que queda pendiente antes de publicar.

Ese último paso puede parecer pequeño, pero evita uno de los clásicos agujeros negros de cualquier proyecto digital: el “pensaba que eso lo revisaba otra persona” o «pensaba que eso ya estaba resuelto».

Qué distingue a una agencia que entrega una web realmente preparada

La diferencia no suele estar en el diseño, en el precio del proyecto ni en el tamaño de la agencia. Está en cómo gestiona las cuestiones que aparecen alrededor de la web mientras la está construyendo.

Una agencia con un proceso bien definido no necesita conocer toda la normativa legal para trabajar mejor. Le basta con saber qué aspectos pueden tener implicaciones de cumplimiento, cuándo debe detenerse a revisarlos y cuándo corresponde trasladar la cuestión al cliente o a un especialista.

Ese matiz, que puede parecer sutil, tiene tres consecuencias muy concretas.

Valor añadido en la entrega

Entregar una web con un protocolo de revisión detrás no es lo mismo que entregar una web que simplemente «funciona». Un cliente al que envías un documento donde consta qué se ha revisado, qué se ha detectado y qué queda pendiente, no solo recibe un producto técnico, sino también información que necesitaba y no sabía cómo pedir.

La mayoría de los clientes no tienen ni idea de qué cookies carga su web ni de qué implica el chatbot que pidieron «porque quedaba bien». Ponérselo por escrito, aunque sea en tres líneas, es un servicio que la mayoría de sus competidores no están prestando.

Ventaja competitiva

Esto, con el tiempo, deja de ser un detalle bonito y se convierte en un argumento comercial. Cuando dos presupuestos son parecidos en precio y en plazos, el que incluye una revisión de cumplimiento legal estructurada, aunque sea básica, parte con ventaja frente al que solo promete «una web bonita y rápida».

No hace falta venderlo como un servicio jurídico porque no lo es. Basta con poder decir, con hechos y no con eslóganes, que el proceso de entrega incluye un control de estos puntos. En un mercado donde cada vez más clientes llegan escaldados de alguna reclamación o de algún susto con la AEPD, eso pesa.

Protección de la propia agencia

Aquí está la parte que muchas agencias no calculan hasta que ya es tarde: documentar lo que se ha detectado y comunicado también protege a la agencia.

Si un cliente decide no corregir algo que se le ha señalado por escrito, como un formulario con casillas premarcadas, un banner de cookies mal configurado o un chatbot sin aviso de IA, esa decisión pasa a ser suya, no de quien se lo advirtió. Sin ese registro, si algo sale mal, la conversación se convierte en «la agencia nunca me dijo nada». Y ahí la agencia parte en desventaja, aunque haya hecho bien su trabajo técnico. Un correo suelto, meses después, no sirve como prueba de nada. Un protocolo con fecha, hallazgo y clasificación, sí.

Una agencia que incorpora este tipo de control legal en su metodología aporta más trazabilidad sobre lo que ha construido y menos incertidumbre sobre lo que queda por resolver. No sustituye a una revisión jurídica cuando esta sea necesaria, pero sí mejora la calidad del proceso, evita que las cuestiones de cumplimiento aparezcan por sorpresa cuando la web ya está publicada y deja constancia de quién decidió qué cuando llega el momento de repartir responsabilidades.

Conclusión

Entregar una web profesional no consiste en marcar casillas de una checklist genérica ni en comprobar únicamente que todo funciona. Consiste en saber qué se ha instalado y qué implica, en identificar las herramientas necesarias para resolver lo que falta y en transmitirlo de forma que el cliente entienda qué tiene, qué no tiene aún y por qué importa.

Todo ello exige saber leer el comportamiento real de una web, detectar cuándo algo no encaja con lo que debería estar pasando y dejarlo por escrito antes de dar el proyecto por cerrado. Esa capacidad es lo que separa a una agencia que entrega un producto técnico de una agencia que entrega un proyecto preparado para operar.

Las herramientas ayudan, y mucho, pero no piensan por ti y no sustituyen el criterio de saber qué preguntar y cuándo detenerse a mirar con más cuidado. El punto de partida con el que llega una web a producción depende, en buena medida, de si detrás hubo una agencia que se hizo las preguntas correctas desde el principio.

Preguntas frecuentes

¿Cada cuánto tiempo debería auditarse la web de un cliente?

No hay una periodicidad legal fija. En la práctica, conviene revisarla siempre que cambie algo relevante. Por ejemplo, si se incorpora una nueva herramienta, se lanza un producto nuevo, se activa publicidad o simplemente ha pasado un tiempo prudencial desde la última revisión, especialmente si la normativa aplicable ha cambiado.

¿Basta con instalar una CMP certificada por Google para cumplir con el RGPD?

No. Una CMP (Plataforma de Gestión de Consentimiento) certificada resuelve la parte técnica de transmitir el consentimiento a Google, pero la validez de ese consentimiento depende de cómo esté configurado el banner: qué categorías distingue, si el rechazo es tan accesible como la aceptación y si la información que se ofrece al usuario es clara.

¿Qué debo hacer si detecto en la auditoría que una herramienta de IA no informa a los usuarios?

Documentarlo, explicar al cliente qué exige el artículo 50 del AI Act para ese supuesto concreto y valorar con él cómo incorporar esa información en la interfaz donde el usuario interactúa con el sistema.

¿Una web hecha por una buena agencia ya está legalmente lista?

No necesariamente, pero suele partir de una base mucho más ordenada. Una agencia que entiende de cumplimiento normativo reduce el número de cuestiones pendientes, aunque la revisión o auditoría legal específica siga siendo necesaria.

¿Qué diferencia hay entre Cookiebot y Usercentrics si son de la misma empresa?

Ambas son CMP certificadas por Google y comparten grupo empresarial, pero se comercializan como productos distintos con modelos de precio diferentes. Cookiebot suele facturar por número de subpáginas y Usercentrics por sesiones. La elección depende del volumen y de la estructura de cada web.

¿Toda tienda online necesita el botón de desistimiento?

Solo si la tienda vende a consumidores mediante una interfaz en línea y ese contrato está sujeto a derecho de desistimiento conforme a la Directiva 2011/83/UE. Si el producto o servicio ya está exento de ese derecho por el artículo 103 del Real Decreto Legislativo 1/2007, la función no es obligatoria para ese contrato en concreto.