FairSub / Blog

Instalas una app de fútbol base. La primera pantalla te pide añadir a los niños del equipo.

Los nombres. Luego las fotos. Luego los correos de las familias, los teléfonos, los dorsales y un campo libre para notas.

Es fácil rellenarlo todo. La app lo pide, así que parece lo normal.

Pero cada dato extra añade responsabilidad. No mejora necesariamente los cambios.

Tú entrenas a un equipo. No deberías tener que llevar una base de datos sobre niños. Pero si la app lo guarda todo, acaba siendo una pequeña base de datos sobre los niños del equipo. En ese momento estás tratando datos personales, y con ello aparecen unas obligaciones que la normativa europea (el RGPD) regula.

Esto es lo que una app debería saber de verdad sobre tus jugadores, lo que no debería saber, y por qué la diferencia importa.

El principio: minimización de datos

Hay un único principio al que vuelven casi todas las normas sobre datos personales. Recoges lo que necesitas, y nada más.

En la normativa de protección de datos, a esto se le llama minimización de datos. En diseño de producto, se llama no pedir lo que no necesitas. En la banda, es simplemente sentido común. Una lista de nombres basta para entrenar a un equipo. Para gestionar los cambios, basta con eso.

Lo que una app necesita de verdad

Repasa las funciones de una app de cambios. Empareja cada dato con su función.

El nombre del jugador. La app tiene que poder decirte "Sara sale, Leo entra". Sin nombres, la función de cambios no funciona. Esto es imprescindible.

Las posiciones, si quieres. Si la app usa las posiciones para sugerir mejores cambios, necesita saber quién juega en defensa, en el centro del campo o en ataque. Es útil, pero no imprescindible. Un entrenador al que no le interesen los cambios por posición puede dejarlo en blanco.

Y nada más. Los cambios, el tiempo de juego, el historial y la alineación. Todo funciona solo con los nombres, con las posiciones como refinamiento opcional. Para una app de cambios, lo demás debería ser opcional, o no existir siquiera.

Lo que una app no necesita

Las apps de esta categoría suelen pedir bastante más. Repasemos algunos ejemplos.

Datos de contacto de los padres. Correo, teléfono, a veces ambos. El argumento es que quizá quieras escribir a un padre. Pero ya tienes formas de hacerlo. WhatsApp, los grupos del club, los portales de la federación, un SMS de toda la vida. Nada de eso tiene por qué vivir dentro de tu app de cambios. No hay ninguna razón deportiva para duplicarlo. Guardar los datos de contacto de las familias en una app que usas un sábado por la mañana es duplicar datos privados en un sitio donde quizá no hacen falta.

Fotos de niños. El argumento es que las fotos ayudan a recordar quién es quién. Puede que ayuden las primeras semanas. Pero después de unos cuantos entrenamientos ya sabes quién es quién. La foto de un niño es un dato personal y conviene tratarla con cuidado. Y si la imagen se trata con una tecnología pensada para identificar de forma única a una persona, puede entrar en una categoría mucho más sensible, como los datos biométricos. Para una app de cambios, es difícil de justificar.

Notas en texto libre. "Alérgico al cacahuete." "La madre es soltera, el padre vive en Noruega." "Tiene ansiedad antes de los partidos." Los entrenadores escriben estas cosas porque quieren recordar el contexto. En un campo de texto libre es fácil acabar recogiendo cosas que la app nunca debería almacenar: salud, situación familiar, preocupaciones, conflictos u otros asuntos privados del niño. Y los datos de salud son especialmente sensibles: si una app permite escribirlos en un campo libre, ya no hablamos solo de nombres para hacer cambios. Es fácil que pase sin mala intención.

Dorsales. Puede ser práctico, pero rara vez es necesario para gestionar los cambios. Si la app funciona sin ellos, ese campo debería ser opcional.

El patrón es el mismo en todos los casos. Cada uno parece una función útil cuando rellenas los datos en un momento de calma. Cada uno es un pequeño paso hacia una base de datos con información privada sobre niños que no tienes ningún motivo para guardar en un dispositivo personal.

La responsabilidad que viene de la mano

Cuando una app almacena datos personales identificables sobre niños, conviene tratarlo como protección de datos desde el principio. Quién es formalmente el responsable del tratamiento puede variar: puede ser el club, la organización que gestiona la herramienta o, en algunos casos, depender de cómo se usa la app. Lo importante para un entrenador es entender que esos datos no son "solo una lista": alguien debe poder explicar por qué se recogen, cómo se protegen y cuándo se borran.

En España, la autoridad que vigila estas reglas es la Agencia Española de Protección de Datos (AEPD). La AEPD ha venido recordando a los clubes que la imagen de los menores cuenta con una protección reforzada y que, antes de publicar fotos de niños en webs o redes sociales, hace falta el consentimiento expreso, que debe existir de antemano y poder probarse. No basta con un permiso futuro.

Con esa responsabilidad vienen obligaciones. Hace falta una base jurídica para los datos que se recogen. Hay que informar a las personas afectadas (o a sus padres, en el caso de los niños) sobre qué se hace y por qué. Los datos deben poder borrarse cuando se pida, borrarse tras un plazo de conservación razonable y mantenerse seguros.

Para las categorías especiales de datos, como la salud, hace falta consentimiento explícito por persona, no un alta genérica. La AEPD lo resume así: la regla general del RGPD es la prohibición de tratar categorías especiales de datos (artículo 9), y la primera excepción es el consentimiento explícito del interesado para el tratamiento de dichos datos personales. Ese consentimiento hay que documentarlo y poder demostrarlo.

Muchos entrenadores de fútbol base no han pensado en todo esto. No por dejadez, sino porque no sabían que estaban haciendo justo aquello que activa esas obligaciones. La app hizo que recoger datos pareciera rutina. La normativa lo considera tratamiento de datos personales.

Los datos de un menor, en España

Hay un detalle español que conviene conocer: en España la edad relevante para este consentimiento es de 14 años. La Ley Orgánica 3/2018 (LOPDGDD) sitúa en los catorce años la edad a partir de la cual un menor puede consentir por sí mismo el tratamiento de sus datos.

La propia AEPD lo explica: el tratamiento de los datos personales de un menor de edad únicamente podrá fundarse en su consentimiento cuando sea mayor de catorce años. Por debajo de esa edad, dice la Agencia, el tratamiento basado en el consentimiento solo será lícito si consta el del titular de la patria potestad o tutela.

Traducido a la banda: para casi todos los equipos de prebenjamines, benjamines y alevines, los niños están por debajo de los catorce años. El consentimiento no puede venir del niño, tiene que venir de quien ejerce la patria potestad. Y la AEPD añade que el responsable debe hacer esfuerzos razonables para verificar que esa autorización procede de verdad del padre, la madre o el tutor. Cuanto menos recoja la app, menos consentimientos hay que pedir, documentar y poder demostrar.

Qué significa realmente "privado"

Muchas apps dicen que sus datos son privados. Léelo con atención. Hay una diferencia entre privado (solo ciertas personas pueden verlos) y mínimo (no hay mucho que ver desde el principio).

Una app realmente privada recoge poco, lo guarda en tu dispositivo y nunca lo envía a un servidor. Los datos son privados porque no existen en ningún sitio salvo donde tú los pusiste.

Una app que suena a privada recoge mucho, lo guarda en un servidor, lo cifra con cuidado y te dice que solo las personas autorizadas pueden acceder. Los datos son privados gracias a los controles de acceso. Mientras los controles aguanten, la privacidad aguanta. Si los controles fallan, cada registro queda expuesto.

Ambas pueden venderse como "privadas". La primera reduce el riesgo desde el origen, porque hay menos datos que salgan de tu dispositivo.

Tres preguntas para hacerle a cualquier herramienta

Cuando elijas una app de entrenamiento, pregúntate:

1. ¿Qué recoge? Si la respuesta incluye algo más allá de los nombres y los datos de juego, pregunta por qué. Si la razón es "quizá te interese", eso no es una razón. Mejor dejarla fuera.
2. ¿Dónde guarda los datos? ¿Solo en tu dispositivo? ¿O en un servidor en algún sitio? Si es un servidor, ¿de quién es? ¿En qué país? ¿Qué pasa si la empresa cierra?
3. ¿Cómo borro a un jugador? Pruébalo. Si el camino es "ocultar" o "archivar" pero no "borrar", los datos siguen ahí. Quieres un solo botón que diga borrar y que de verdad borre.

Una buena herramienta debería responder a estas preguntas con claridad. Si todo suena a marketing, conviene mirar un poco más.

El cambio de mentalidad

Durante la última década, muchas apps han funcionado por defecto con un "recoge todo y ya preguntaremos por qué más adelante". Para las apps que buscan que las uses más, ha salido a cuenta. Para las herramientas que manejan datos sobre niños, es justo al revés.

El punto de partida correcto es no. Un dato no se recoge salvo que puedas explicar, en una sola frase, qué función concreta dejaría de funcionar sin él. Si la función funciona sin él, el dato no se recoge. Si la función sigue funcionando sin él pero funciona mejor con él, entonces se pide con claridad, por separado y solo con consentimiento explícito.

Esto no es un reglamento. Es una forma de diseñar herramientas que respeten a las personas para las que se hacen. Los niños, en especial, que no pueden dar un consentimiento real por sí mismos, merecen un punto de partida que los proteja recogiendo menos.

En resumen

La herramienta que eliges como entrenador les dice a los niños de tu equipo qué clase de relación tienes con sus datos. Una app que lo quiere saber todo los trata como un registro más en una base de datos. Una app que solo pide lo necesario los trata como jugadores.

Elige la segunda.