GDPR
La UE quiere cerrar la puerta de las redes sociales a los menores de 13 años
19 min lectura
Imagen generada por IALa Comisión Europea quiere que las plataformas de redes sociales dejen de tratar la edad de los usuarios como una casilla que se marca sin mirar. Su propuesta de EU KIDS Act, adoptada el 17 de septiembre de 2026, prohíbe que estos servicios accedan a menores de 13 años y fija en 15 años la edad mínima común para que un menor abra una cuenta por iniciativa propia.
La novedad política no está solo en las edades. La Comisión pretende cambiar quién tiene que demostrar que el servicio es seguro. Hasta ahora, buena parte del debate europeo se ha construido alrededor de la responsabilidad de padres, colegios y usuarios. La propuesta desplaza el centro de gravedad hacia las plataformas: tendrán que demostrar que sus servicios son apropiados para la edad y seguros desde el diseño.
La frase suena contundente. La ejecución será bastante menos limpia. Una prohibición para menores de 13 años exige verificar la edad sin convertir cada acceso en una entrega masiva de datos personales. Una edad mínima de 15 años plantea preguntas sobre la autonomía del menor, la responsabilidad parental y las diferencias con las reglas nacionales. Y exigir seguridad desde el diseño obliga a revisar algoritmos de recomendación, publicidad, mensajería, moderación y modelos de inteligencia artificial, no solo a añadir un formulario de consentimiento.
La propuesta cambia la pregunta: de “¿lo consienten los padres?” a “¿puede la plataforma demostrar que es segura?”
El modelo anunciado por la Comisión contiene tres piezas concretas. La primera es la prohibición de acceso de las plataformas de redes sociales a menores de 13 años. La segunda establece en 15 años la edad mínima común para que un menor pueda abrir una cuenta propia. La tercera invierte la carga de la prueba: el proveedor debe acreditar que el servicio es adecuado para la edad y seguro desde el diseño.
Ese tercer elemento es el más relevante para los equipos de compliance. No basta con publicar una política de protección de menores ni con activar por defecto una cuenta privada. La plataforma tendría que poder explicar, documentar y defender sus decisiones de diseño: qué perfiles puede recomendar, qué contenido se muestra a un usuario de 13 años, qué señales utiliza el sistema de publicidad, cuándo puede contactar un adulto desconocido y qué ocurre si el sistema no conoce con suficiente fiabilidad la edad del usuario.
La Comisión ha presentado el EU KIDS Act como una propuesta para proteger a los menores frente a servicios digitales y sistemas de IA de riesgo, mantener un mercado digital único y reforzar una estructura coherente de aplicación. Pero la noticia de septiembre de 2026 es una adopción de la Comisión, no la entrada en vigor de una obligación directamente aplicable. El texto tendrá que avanzar por el proceso legislativo europeo y su redacción final puede cambiar. Confundir una propuesta con una norma vigente sería un error jurídico; diseñar controles como si nunca fuera a aprobarse sería un error operativo.
La edad mínima de 15 años no elimina la complejidad: la concentra
La elección de los 15 años pretende crear un umbral europeo común para la apertura autónoma de cuentas. Es una decisión política con una consecuencia técnica inmediata: las plataformas no podrán resolver el problema con una única pantalla de “tengo la edad mínima”. Tendrán que distinguir, como poco, entre menores de 13 años, adolescentes de 13 y 14, y usuarios de 15 años o más.
La situación actual ya es fragmentada. El artículo 8 del Reglamento General de Protección de Datos permite que cada Estado miembro establezca entre 13 y 16 años la edad a partir de la cual un menor puede consentir por sí mismo el tratamiento de datos relacionado con servicios de la sociedad de la información. Por debajo de ese umbral, el consentimiento debe ser autorizado por quien ejerza la responsabilidad parental, con esfuerzos razonables para verificarlo.
El EU KIDS Act introduce una propuesta sectorial distinta: una edad mínima común de 15 años para que el menor abra una cuenta propia en redes sociales. La relación entre ambas reglas será decisiva. El artículo 8 del RGPD no es una autorización general para prestar cualquier servicio a un menor; regula una base jurídica concreta para determinados tratamientos. Una plataforma no podría concluir que, porque un adolescente puede consentir el tratamiento de sus datos en un país a los 13 o 14 años, también puede abrir una cuenta autónoma si la futura norma fija los 15 como umbral común.
También queda abierta la cuestión de los servicios híbridos. Una plataforma de mensajería con funciones sociales, un videojuego con chat público, una aplicación educativa con recomendaciones de contenido o un servicio de vídeo corto pueden intentar quedar fuera de la etiqueta “red social”. El regulador tendrá que definir el perímetro con suficiente precisión para evitar dos resultados previsibles: que las empresas rediseñen la interfaz para escapar de la categoría o que los proveedores apliquen restricciones idénticas a productos con perfiles de riesgo muy diferentes.
El verdadero campo de batalla será la verificación de edad
La prohibición de acceso a menores de 13 años requiere algún mecanismo para estimar o verificar la edad. Aquí aparece la contradicción que la propuesta tendrá que resolver: cuanto más fiable sea la comprobación, más probable es que el sistema recopile documentos de identidad, datos biométricos, información de dispositivos o señales de comportamiento. Cuantos menos datos quiera tratar la plataforma, mayor será el riesgo de errores, evasión o exclusión injustificada.
Una simple declaración de edad ofrece poca protección. Un documento de identidad centralizado puede ser desproporcionado para acceder a una red social. La inferencia algorítmica basada en la voz, la cara, la escritura o la actividad digital puede producir falsos positivos y falsos negativos, además de abrir nuevas superficies de vigilancia. Y un sistema basado en terceros especializados desplaza el riesgo, pero no lo elimina: la plataforma seguirá siendo responsable de decidir qué proveedor acepta, qué datos recibe y cuánto tiempo conserva la respuesta.
Desde el punto de vista de privacidad, el diseño más defendible tendería a separar la prueba de edad de la identidad. La plataforma debería recibir, idealmente, una afirmación limitada —por ejemplo, que el usuario supera o no un determinado umbral— sin obtener una copia del documento utilizado para demostrarlo. Eso no resuelve todos los problemas. Habría que determinar quién actúa como responsable del tratamiento, qué base jurídica se utiliza, cuánto dura la credencial, cómo se revoca, cómo se evita que pueda reutilizarse para rastrear al usuario y qué alternativa existe para quien no pueda utilizar el método principal.
El principio de minimización del artículo 5.1.c del RGPD será difícil de aplicar si la empresa diseña el sistema pensando primero en la prevención del fraude y solo después en la proporcionalidad. El artículo 25 del RGPD, sobre protección de datos desde el diseño y por defecto, apunta en la dirección contraria: la arquitectura de verificación debe limitar el tratamiento desde el inicio, no confiar en una política de privacidad redactada después del lanzamiento.
Hay una consecuencia práctica que muchos programas de cumplimiento pasan por alto: la verificación de edad no es un control aislado de onboarding. Debe funcionar también cuando cambia la cuenta, cuando se modifica el país de residencia, cuando el usuario recupera una cuenta comprometida, cuando se vincula un nuevo dispositivo y cuando una cuenta adulta se transforma en una cuenta utilizada por un menor. Un control que solo se ejecuta una vez al registrarse será sencillo de eludir y difícil de defender ante un regulador.
“Seguro desde el diseño” no significa activar el modo privado
Las plataformas ya tienen obligaciones relevantes sobre la protección de menores. El Reglamento de Servicios Digitales —Reglamento (UE) 2022/2065— exige, en su artículo 28, que los prestadores de plataformas en línea accesibles a menores adopten medidas adecuadas y proporcionadas para garantizar un alto nivel de privacidad, seguridad y protección de los menores. El mismo artículo prohíbe presentar publicidad basada en perfiles cuando el proveedor sepa con seguridad razonable que el destinatario es un menor.
El artículo 28 no convierte cada cuenta juvenil en un entorno inocuo. Tampoco permite procesar más datos de los necesarios para descubrir si alguien es menor. La propuesta KIDS Act parece apuntar a una aplicación más uniforme y a una carga de prueba más exigente, pero su relación exacta con el DSA tendrá que concretarse durante la tramitación legislativa.
La diferencia entre cumplir formalmente y reducir riesgos reales se aprecia en cinco capas del producto.
La primera es la recomendación de contenido. Un adolescente no debería recibir la misma secuencia de recomendaciones que un adulto si el sistema ha identificado que ciertos patrones pueden intensificar la exposición a contenidos dañinos, contactos no deseados o uso compulsivo. No basta con excluir categorías evidentes. La empresa tendrá que evaluar los efectos de la clasificación, la repetición y la velocidad de entrega.
La segunda es el contacto entre usuarios. Las cuentas de menores pueden requerir límites para mensajes directos, descubrimiento por número de teléfono, invitaciones de adultos desconocidos, menciones públicas y adición automática a grupos. Una política que prohíba el contacto adulto-menor pero permita encontrar al menor por nombre de usuario deja un agujero con aspecto de funcionalidad.
La tercera es la publicidad. El artículo 28 del DSA ya impide la publicidad basada en perfiles dirigida a menores cuando la plataforma tiene certeza razonable de que el usuario es menor. En la práctica, esto obliga a conectar la clasificación de edad con el sistema de anuncios, los segmentos comerciales, los proveedores de medición y las herramientas de atribución. Si el equipo de seguridad conoce la edad y el equipo de publicidad sigue enviando señales de segmentación, la empresa tiene un problema de gobierno interno, no de redacción legal.
La cuarta es la configuración por defecto. Privacidad, visibilidad del perfil, descargas, comentarios, ubicación, etiquetado y recomendaciones de contactos deberían revisarse por grupo de edad. El ajuste predeterminado importa porque el consentimiento de un adolescente no transforma una configuración agresiva en una configuración adecuada.
La quinta es la inteligencia artificial. La Comisión sitúa la iniciativa también en la protección frente a sistemas de IA de riesgo. Eso puede afectar a moderadores automáticos, asistentes conversacionales, generadores de imágenes, sistemas de recomendación y herramientas que evalúan estados emocionales o preferencias. Un chatbot que conversa con menores no es equivalente a un filtro de spam, y tratar ambos como “funcionalidades de IA” no ayuda a identificar los riesgos específicos.
La inversión de la carga de la prueba cambia el trabajo del consejo
Si el texto final mantiene este enfoque, los equipos directivos tendrán que responder a una pregunta incómoda: ¿qué evidencia demuestra que el producto es apropiado para un usuario de 13, 14 o 15 años?
La respuesta no puede ser una presentación de PowerPoint sobre valores corporativos. Tendrá que apoyarse en evaluaciones de riesgo, pruebas de diseño, métricas de incidentes, decisiones de producto, resultados de simulaciones y trazabilidad de cambios. La empresa debería poder reconstruir por qué activó una función, qué riesgos identificó, qué población menor podía quedar expuesta y qué controles aplicó antes del lanzamiento.
El DSA ofrece ya una referencia importante para las plataformas muy grandes: el artículo 34 exige evaluar y analizar los riesgos sistémicos derivados del diseño y funcionamiento del servicio, incluidos los riesgos relacionados con derechos fundamentales y bienestar de los menores; el artículo 35 exige adoptar medidas razonables, proporcionadas y eficaces para mitigarlos. El artículo 42 añade obligaciones de transparencia para determinados proveedores y el artículo 37 contempla auditorías independientes para plataformas en línea muy grandes y motores de búsqueda muy grandes.
El futuro marco KIDS Act podría apoyarse en esa infraestructura, complementarla o crear exigencias propias. En cualquiera de los tres escenarios, el mensaje para un CISO o un responsable de cumplimiento es el mismo: la evidencia debe generarse durante el ciclo de desarrollo, no improvisarse cuando llega una solicitud del regulador.
Una prueba útil sería revisar un cambio de producto reciente y preguntar:
- ¿Qué grupo de edad podía utilizar la función?
- ¿Qué riesgos específicos para menores se evaluaron antes del despliegue?
- ¿Qué datos alimentan el modelo de recomendación o clasificación?
- ¿Qué métricas activarían una revisión o retirada de la función?
- ¿Quién aprobó el riesgo residual y dónde quedó registrado?
Si las respuestas están repartidas entre producto, ingeniería, legal, privacidad y seguridad sin un propietario claro, la inversión de la carga de la prueba ya ha empezado a hacer su trabajo, aunque la norma todavía no sea aplicable.
Padres en el centro, pero sin convertirlos en el control de seguridad
La Comisión presenta la iniciativa como una forma de devolver a los padres herramientas para ayudar a sus hijos a navegar por internet. Esa dimensión será políticamente atractiva, pero no debe transformarse en una transferencia de responsabilidad. Un control parental no compensa un algoritmo que recomienda contenido de riesgo, una bandeja de entrada abierta a desconocidos o una política de retención de datos indefinida.
Además, no todas las familias tienen la misma capacidad para supervisar una cuenta. Exigir una intervención parental constante puede penalizar a menores en hogares con menos tiempo, menos conocimientos digitales o situaciones familiares complejas. El diseño regulatorio tendrá que evitar que la seguridad dependa de que un adulto revise cada notificación y entienda cada ajuste escondido en siete menús.
La responsabilidad parental también plantea una cuestión de privacidad dentro de la propia familia. ¿Debe el padre o la madre poder leer todos los mensajes? ¿Puede la plataforma revelar la actividad completa del menor? ¿Cómo se gestiona una denuncia cuando la persona que controla la cuenta familiar es precisamente la fuente del riesgo? La propuesta necesitará reglas claras sobre acceso, proporcionalidad, confidencialidad y canales de ayuda.
El enfoque más sólido combinaría controles técnicos del servicio, ajustes apropiados por edad, herramientas parentales comprensibles y vías de denuncia accesibles para el menor. La plataforma no debería vender a las familias una falsa elección entre vigilancia total y ausencia de protección. Ese modelo es cómodo para el marketing y bastante pobre para la seguridad.
Qué cambia para las plataformas, los proveedores y los equipos internos
La iniciativa no afecta únicamente a las grandes redes sociales. Su alcance práctico dependerá de cómo defina la Comisión las categorías de servicios cubiertos, pero la cadena de responsabilidad puede extenderse a proveedores de verificación de edad, sistemas de identidad digital, servicios de analítica, redes publicitarias, moderadores externos, desarrolladores de modelos de IA y proveedores de infraestructura.
Para las plataformas, la prioridad será construir un mapa de dependencias. La edad declarada en la aplicación puede no coincidir con la edad almacenada en el proveedor de identidad, la señal recibida por el sistema de anuncios o la categoría utilizada por el motor de recomendaciones. Cada transferencia puede crear una incoherencia operativa y un punto de incumplimiento.
Para los proveedores de verificación, la cuestión será demostrar que su solución no convierte la protección infantil en un sistema de identificación permanente. Contratos, evaluaciones de impacto, controles de acceso, segregación de datos, cifrado, retención y gestión de incidentes pasarán a tener una relevancia que va mucho más allá del departamento de compras.
Para los equipos de privacidad, el artículo 35 del RGPD sobre evaluaciones de impacto relativas a la protección de datos será una referencia evidente cuando el tratamiento implique alto riesgo, especialmente si se utilizan datos biométricos o tecnologías de evaluación de edad con efectos significativos. Una evaluación genérica para toda la aplicación tendrá poco valor si no analiza por separado el tratamiento de menores, la inferencia de edad y la interacción con algoritmos de recomendación.
Para seguridad, el reto será proteger el propio control. Las bases de datos de credenciales de edad serán objetivos atractivos. Un atacante que consiga manipular una señal de edad podría desbloquear mensajería, publicidad o contenido restringido. El diseño debe contemplar autenticidad de la señal, prevención de reutilización, resistencia a la suplantación, registro de accesos y respuesta ante compromiso del proveedor externo.
Para producto, habrá una tensión comercial evidente. Reducir funciones para menores puede afectar a la retención y al crecimiento, especialmente en servicios cuyo modelo depende del tiempo de uso y de la personalización. La futura norma no eliminará esa tensión; obligará a hacerla visible y a justificar por qué el riesgo residual es aceptable.
La relación con NIS2, DORA y el resto del mosaico europeo
El EU KIDS Act no es una norma de resiliencia operativa financiera ni una ley general de ciberseguridad. Una plataforma social que presta servicios a consumidores no queda automáticamente dentro del ámbito de DORA por tener controles de edad, y una empresa no puede convertir una referencia a NIS2 en sustituto de sus obligaciones de protección de menores.
Aun así, los marcos se cruzan en la práctica. NIS2, cuya obligación de gestión de riesgos de ciberseguridad se articula en el artículo 21 de la Directiva (UE) 2022/2555, exige medidas sobre análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro y evaluación de la eficacia de los controles para las entidades comprendidas en su ámbito. Si la verificación de edad se externaliza, la seguridad del proveedor, su continuidad y su capacidad de respuesta dejan de ser una cuestión puramente contractual.
DORA sigue una lógica similar para entidades financieras y sus proveedores de servicios de tecnologías de la información y las comunicaciones. Sus artículos 28 a 30 regulan la gestión del riesgo de terceros ICT, mientras que el artículo 30 fija elementos contractuales esenciales. Un banco o una aseguradora que integre una red social, una herramienta de identidad o un servicio de IA en una experiencia dirigida a clientes menores tendrá que separar dos preguntas: si el servicio protege adecuadamente al menor y si el proveedor cumple el marco de resiliencia aplicable. Una respuesta positiva a una no garantiza la otra.
El RGPD, el DSA, NIS2, DORA y el EU KIDS Act pueden compartir evidencias, pero no deben fusionarse en una matriz de cumplimiento absurda. Un registro de incidentes de ciberseguridad no demuestra que un algoritmo sea apropiado para menores. Una evaluación de impacto de privacidad no demuestra que exista capacidad de recuperación ante una caída del proveedor de verificación. Un contrato con un tercero no demuestra que la configuración por defecto reduzca la exposición de un adolescente.
Aquí conviene resistirse a la tentación habitual de crear una única columna llamada “cumplimiento digital”. Las obligaciones se parecen lo suficiente para generar sinergias y son diferentes lo suficiente para provocar fallos si se mezclan.
Qué deberían hacer ahora las empresas, sin esperar a que termine el proceso legislativo
La adopción de la propuesta no justifica lanzar un proyecto de transformación con nombre grandilocuente y presupuesto infinito. Sí justifica varias decisiones concretas.
La primera es identificar qué servicios podrían considerarse redes sociales o tener funciones equivalentes. El inventario debe incluir productos aparentemente secundarios: comentarios, comunidades, chats dentro de videojuegos, perfiles públicos, recomendaciones y herramientas de creación de contenido. La etiqueta comercial del producto no será necesariamente la definición jurídica que importe.
La segunda es segmentar el tratamiento por edad. La empresa debería saber qué controles se aplican a menores de 13 años, a usuarios de 13 y 14 años y a mayores de 15. Si todos reciben la misma experiencia porque el sistema solo distingue entre “menor” y “adulto”, será difícil demostrar que el diseño responde a la gradualidad anunciada por la Comisión.
La tercera es revisar el flujo de datos de edad. Hay que documentar qué se recoge, quién lo recibe, si se utiliza para publicidad o personalización, cuánto tiempo se conserva, cómo se elimina y qué ocurre cuando el usuario impugna una clasificación. El equipo legal no puede responder estas preguntas sin ingeniería, y la ingeniería no debería responderlas sin privacidad.
La cuarta es ejecutar pruebas específicas de abuso. No solo pruebas de penetración del backend. También escenarios de suplantación de edad, evasión de controles, contacto adulto-menor, creación de cuentas múltiples, recuperación de credenciales, explotación de recomendaciones y manipulación de sistemas de IA. El objetivo no es producir una colección de capturas de pantalla, sino demostrar que los controles sobreviven a un usuario que intenta sortearlos.
La quinta es preparar una posición pública y técnica durante la tramitación. Las empresas afectadas tendrán que explicar a la Comisión y a los legisladores qué métodos de verificación son proporcionales, qué riesgos introducen y qué interoperabilidad necesitan. El silencio no simplifica el texto; solo deja que otros definan la arquitectura por ellas.
El riesgo de una buena intención mal implementada
La protección de menores ofrece un objetivo regulatorio difícil de cuestionar. Precisamente por eso conviene examinar con rigor las herramientas elegidas. Una prohibición de acceso para menores de 13 años puede reducir exposición, pero también puede empujar a los usuarios hacia servicios menos transparentes, cuentas falsas o plataformas que no tengan controles de seguridad equivalentes. Una verificación invasiva puede proteger la edad y deteriorar la privacidad. Un control parental demasiado amplio puede crear vigilancia familiar sin resolver el diseño adictivo o la exposición a contenido dañino.
El EU KIDS Act acertará si consigue que la seguridad infantil se convierta en una propiedad demostrable del producto, no en un documento jurídico que aparece después del incidente. Para lograrlo necesitará definiciones precisas, métodos de verificación proporcionales, coordinación con el DSA y el RGPD, y una supervisión capaz de distinguir entre una plataforma que ha instalado controles cosméticos y otra que ha cambiado realmente sus sistemas.
La Comisión ha puesto tres cifras sobre la mesa: menos de 13 años, 15 años y 17 de septiembre de 2026. Las dos primeras definen la arquitectura de acceso; la tercera marca el inicio de la siguiente fase política. Para las empresas, la fecha no debe ser la de una auditoría sorpresa futura. Debe ser el momento de comprobar si pueden demostrar, con datos y decisiones trazables, que un menor no está siendo utilizado como beta tester de un servicio diseñado para adultos.