Playio

Política de privacidad

Versión propuesta: pilot-v1 · Actualizada: 25 de septiembre de 2026 · Fecha de vigencia pendiente

Datos y finalidades

DatosFinalidadDestinatarios / revisión necesaria
Nombre, apellido, email, hash de contraseña o identificador Google/AppleCuenta, autenticación, soporteOperador y proveedores de infraestructura; no publicar hash ni tokens
Foto, ciudad, género, categoría deportivaPerfil y búsqueda de jugadores compatiblesOtros jugadores según interfaz; género y ubicación son opcionales
Teléfono y coordenadasCoordinación de reserva y ubicación elegidaTeléfono accesible al club en la gestión de una reserva; coordenadas personales no incluidas en perfiles de terceros
Participación, amistades, resultados y valoracionesOrganización y experiencia deportivaParticipantes según función; evitar datos de terceros en comentarios
Preferencias, búsquedas guardadas y alertasPersonalización y notificacionesUsuario y procesamiento interno
Token push y plataforma móvilEnvío de avisosExpo/proveedores push; verificar integración y región reales
Declaración 18+, versiones aceptadas, fechaControl de acceso y evidencia de aceptaciónAcceso restringido del operador
Bloqueos y reportesSeguridad y gestión de reclamosReportes visibles solo a administradores autorizados
Datos de solicitudes de clubes / emailsResponder consultas comerciales y operativasProveedor de email configurado; no reutilizar para marketing sin encuadre

No se piden datos de salud, DNI o fecha de nacimiento para este piloto. No subir datos sensibles ni datos personales de otras personas en campos de texto libre. La mayoría de edad es una declaración del usuario, no una certificación.

Identificar en el texto final cuáles datos son necesarios para cada prestación, la consecuencia de no aportarlos y su base legal. Las funcionalidades opcionales no deben condicionar el uso básico sin necesidad. Las preferencias de avisos del producto no equivalen a consentimiento para publicidad.

Proveedores y transferencias internacionales: inventario por completar

El código/documentación contiene integración con Railway, PostgreSQL/Neon, almacenamiento compatible S3, Google/Apple, Expo y Resend. La presencia en el código no acredita que todos estén activos ni el país efectivo de tratamiento.

Antes de publicar, registrar para cada proveedor activo: entidad contratada, datos enviados, función, países de procesamiento y backups, subencargados, contrato de tratamiento, mecanismo de transferencia internacional y retención. Incluir también SDKs, métricas, crash reporting y logs del frontend si existen.

El alojamiento fuera del país requiere analizar el art. 12 y mecanismos admitidos por la AAIP; no alcanza con decir genéricamente «usamos servicios en la nube».

Conservación y eliminación

Los datos de cuenta se conservan mientras sean necesarios para el servicio. La eliminación autenticada borra cuenta, accesos, relaciones, preferencias, valoraciones, aceptaciones y reportes asociados. Las estructuras de partidos compartidos pueden permanecer sin referencia al perfil eliminado. Se eliminan campos libres de partidos propios y datos de contacto de reservas asociadas.

Las fotos se encolan para eliminación física. La limpieza espera la expiración de URLs de carga más un margen para operaciones en curso, y reintenta fallas. La frecuencia del job y alertas deben estar operativas antes de prometer un plazo. Las URLs de lectura ya emitidas pueden seguir funcionando hasta su expiración.

Pendientes obligatorios del texto final: plazos reales para backups, logs, copias en proveedores y reportes; procedimiento para aplicar bajas tras una restauración; excepciones de conservación legal justificadas. No prometer borrado instantáneo de backups ni retenciones ilimitadas. Actualmente no se implementó un sistema de conservación especial por litigio; analizar antes del lanzamiento.

Derechos y contacto

Podés solicitar acceso, rectificación, actualización o supresión a [EMAIL]. Se verificará la identidad de manera proporcional sin pedir contraseñas. El backend ofrece un resumen autenticado en GET /me/data, edición del perfil y eliminación en DELETE /me; el frontend debe facilitar esos flujos. El resumen automático no sustituye una respuesta completa a una solicitud de acceso formal.

El texto final debe incorporar la información exigible sobre derechos, plazos, autoridad de control y vías de reclamo según la normativa aplicable. Para soporte, registrar vencimientos de solicitudes y escalar antes del plazo legal; no enviar datos a quien solo conozca un email o identificador.

Seguridad

Aplicar acceso por roles, secretos fuera del repositorio, cifrado en tránsito, almacenamiento privado, control de permisos, minimización de logs y respuesta a incidentes. Verificar configuración productiva: los tests no certifican su estado. En una revisión de perfil entre usuarios no deben aparecer email, teléfono, coordenadas personales, credenciales ni tokens. Los clubes solo acceden a las reservas bajo su administración. La ubicación pública de un club no es la ubicación privada de un jugador.

Fuentes: [Ley 25.326](https://www.argentina.gob.ar/normativa/nacional/64790/actualizacion), [AAIP: obligaciones](https://www.argentina.gob.ar/node/53779), [transferencias internacionales](https://www.argentina.gob.ar/transferencias-internacionales), [derechos](https://www.argentina.gob.ar/aaip/datospersonales/derechos).

## Contacto en reservas de cancha

El teléfono se solicita al completar el perfil, se valida su formato y no se verifica por SMS. Al reservar una cancha, se comparte tu nombre y teléfono con los administradores de ese complejo para coordinar la reserva y gestionar cancelaciones. No se muestra en los perfiles públicos ni a otros jugadores. La reserva conserva el contacto registrado al confirmarla; la eliminación de cuenta elimina esas copias conforme al flujo de baja.