Arquitectura de cuentas familiares y UX de consentimiento — cómo lo hacen los mejores productos

Hallazgos

Apple: Family Sharing, cuentas infantiles, Ask to Buy y Declared Age Range API

Un organizador (padre, 18+, con su propio Apple ID) designa a los miembros de la familia, incluidos los niños. Las compras de un miembro infantil pasan por Ask to Buy: las compras en App Store/iTunes/Books, las compras dentro de las apps y las ampliaciones de almacenamiento de iCloud generan una solicitud que el organizador aprueba o rechaza antes de que se complete [1]. Las cuentas infantiles se crean y se administran dentro del grupo familiar del organizador, nunca por autorregistro.

La más reciente Declared Age Range API (iOS/iPadOS/macOS 26, presentada en avance en WWDC 2025) permite a una app leer una categoría de edad que preserva la privacidad (menor de 13 / 13–17 / 18+) en lugar de una fecha de nacimiento. La edad se define una sola vez, al crear la cuenta o mediante Screen Time/Family Sharing, y las apps la leen mediante una API de Swift sin ver la fecha de nacimiento subyacente [2][3]. Se entrega junto con un mecanismo de Significant Change (PermissionKit) para volver a pedir consentimiento cuando cambia el conjunto de funciones de una app, y Server Notifications cuando un padre revoca el consentimiento. Apple lo presenta como herramienta de cumplimiento para las leyes de verificación de edad de 2025–2026 (Texas, Luisiana, Utah, Brasil, Australia, Singapur): una señal de edad agnóstica a la jurisdicción, no un método de VPC en sí mismo.

Google Family Link

Un padre mayor de 18 crea una Cuenta de Google para un niño menor de 13 (o la edad de consentimiento local) mediante Family Link, en el mismo país que el niño [4]. La cuenta queda marcada como supervisada: el padre aprueba/bloquea instalaciones y compras de Play, define límites de tiempo de pantalla y horarios de dormir, filtra contenido para adultos y ve la ubicación del dispositivo. El inicio de sesión es el de una Cuenta de Google normal; en un dispositivo compartido, las cuentas del padre y del niño coexisten y el niño cambia mediante el selector de cuentas estándar de Android. La mecánica exacta de «graduación» de Google a los 13+ no se pudo confirmar contra una fuente primaria consultada en esta sesión y debe verificarse por separado.

Microsoft Family Safety / Xbox / Minecraft

Family Safety agrupa la Microsoft Account de un padre con cuentas infantiles, y ofrece límites de tiempo de pantalla, filtrado de contenido y resúmenes de actividad en Windows, Xbox y Android [5]. Minecraft se autentica mediante el mismo sistema de Microsoft Account, así que su superficie parental es el grupo familiar de Xbox/Microsoft: la propia Microsoft Account del niño inicia sesión, y la configuración familiar controla el acceso a multijugador/Realms, el chat y las clasificaciones. La mecánica exacta del flujo de creación y de la transición a los 13/18 no se pudo recuperar de las páginas consultadas en esta sesión (solo cargó contenido general) y debe reverificarse antes de citar detalles.

Controles parentales de Nintendo Switch

Un padre (18+) necesita una Nintendo Account y vincula la app gratuita Nintendo Switch Parental Controls a la(s) consola(s) del hogar [6]. Controles: filtrado de juegos basado en ESRB, límites diarios/nocturnos de tiempo de juego, restricción de mensajería/GameChat a contactos aprobados, exigencia de aprobación para videochat con menores de 16, bloqueo de compartir capturas de pantalla en redes sociales y límites de gasto en eShop. Esto es restricción de perfil a nivel de consola, más que una identidad infantil con sesión propia: no se necesita una cuenta separada protegida con contraseña para jugar; un PIN de padre anula las restricciones en la consola compartida.

Perfiles infantiles de Netflix y Disney+

Ambos usan perfiles bajo una sola cuenta de hogar de pago, no cuentas infantiles separadas. El perfil Kids de Netflix oculta contenido por encima de una clasificación de madurez configurable y puede quedar detrás de un PIN numérico de Profile Lock; Disney+ ofrece un Junior Mode similar más PIN de perfil. Es el patrón más ligero de los estudiados: ninguna identidad infantil persiste fuera de la cuenta del hogar, nada que migrar a los 13/18, y la frontera de «consentimiento» es una frontera de compra del hogar, no una frontera de recolección de datos de un menor: ninguno es un operador COPPA que recolecte PII de un menor para crear una cuenta, y por eso los perfiles bastan. (Las páginas del centro de ayuda no fueron accesibles en esta sesión por bloqueo de bots; son funciones estables y bien establecidas, no resumidas desde una fuente en vivo: verificar puntualmente si se necesita el texto exacto de la interfaz.)

Controles parentales y verificación de edad de Roblox

Roblox exige una cuenta para jugar (el juego como invitado se eliminó en 2017); desde una reestructuración de noviembre de 2024, un padre puede crear una cuenta de padre separada y vinculada que controla tiempo de pantalla, mensajería privada y configuración de comunicación. Desde diciembre de 2025 (primeros mercados)/enero de 2026 (global), Roblox exige verificación de edad para cualquier comunicación dentro de la plataforma, mediante el proveedor Persona: subir una identificación gubernamental o un video de estimación facial de edad, con corrección manual si la estimación es errónea; los usuarios verificados se agrupan en bandas de edad (p. ej., un niño de 12 años solo puede enviar mensajes a edades de 9–15) [7]. Es un ejemplo vivo y actual de estimación facial de edad desplegada a escala de consumo para controlar la comunicación y no la creación de cuentas: relevante si Math Challenge considera alguna vez funciones de chat/sociales.

Khan Academy, Duolingo, Prodigy

Khan Academy Kids (edades 2–7) es una app gratuita separada; Khan Academy propiamente usa un modelo coach-estudiante donde un profesor crea un aula y un flujo separado permite a un padre ver el progreso: la mecánica exacta de inicio de sesión infantil no se pudo confirmar desde una fuente en vivo en esta sesión. Duolingo ABC (2020, pre-lectores, sin anuncios/compras dentro de la app) es totalmente separado del producto principal; el Super Duolingo Family Plan agrupa suscripciones del hogar, pero la mecánica exacta de vinculación padre-hijo no se pudo verificar desde una fuente primaria y debe comprobarse directamente antes de usarla como referencia de diseño.

Prodigy separa la cuenta de juego del niño (creada típicamente a través de la escuela para uso en el aula) de una cuenta de padre que el padre crea de forma independiente y vincula al niño, desbloqueando un panel de Membership: reportes de progreso en tiempo real y mensuales, definición de metas, recompensas dentro del juego y hojas de trabajo imprimibles [8]. Es el análogo existente más cercano al modo profesor de Math Challenge: la identidad de aula del niño existe primero, y un padre después adjunta su propia cuenta para monitorearla y autorizarla, en lugar de crear al niño desde cero.

Consentimiento parental verificable (VPC) bajo COPPA

La FTC ha certificado programas de safe harbor cuyos miembros diseñan su propio flujo de VPC aprobado: TrustArc, ESRB, CARU, PRIVO, Samet Privacy/kidSAFE, iKeepSafe (Aristotle Inc. se retiró en agosto de 2021) [9]. Fuera del safe harbor, COPPA §312.12 permite a cualquier operador solicitar la aprobación de un método novedoso: el proceso que PRIVO usó en 2023 para lograr que un método de estimación facial de edad (construido sobre tecnología de Yoti) fuera aprobado como herramienta de verificación del otorgante del consentimiento. Métodos enumerados de base: un formulario firmado (correo/fax/escaneo), una transacción monetaria (cargo a tarjeta), un número gratuito con personal capacitado, una videoconferencia con personal capacitado, y verificación de ID gubernamental cotejada contra una foto en vivo: este último, “face match to verified photo ID” (FMVPI), fue en sí mismo una aprobación de la FTC fechada el 19 de noviembre de 2015 [9][10]. Nota de verificación: las enmiendas finales de la Regla COPPA de enero de 2025 (según se reporta, vigentes desde junio de 2025) se describen ampliamente como añadidoras de nuevos métodos enumerados y endurecedoras del consentimiento de divulgación a terceros, pero las páginas de regla/comunicado de ftc.gov devolvieron 403/404 a la consulta automatizada en esta sesión: solo como contexto, confirmar antes de confiar en ello.

Proveedores de verificación de edad: k-ID y Yoti

k-ID es una plataforma de cumplimiento: AgeKit (clasificación gruesa de edad gratuita), AgeKit+ (verificación de mayor garantía mediante estimación facial, verificación de ID o credenciales reutilizables), Family Connect (un portal de consentimiento parental con aprobación a nivel de portafolio entre títulos del cliente, que afirma tasas de finalización de hasta 96%), AgeKey (credencial de edad reutilizable multiplataforma) y neimo (seguimiento regulatorio): afirma cobertura en más de 200 jurisdicciones incluyendo COPPA, el Artículo 8 del GDPR, el Age Appropriate Design Code/Online Safety Act del Reino Unido, la ley de menores de 16 de Australia y los equivalentes de Brasil/India [11]. El producto de estimación facial de edad de Yoti no se pudo consultar directamente en esta sesión (403): sus afirmaciones de precisión y certificaciones deben verificarse directamente en yoti.com antes de citar cifras.

Patrones de ingreso al aula

Google Classroom: cada clase tiene un código de clase autogenerado, que se puede volver a mostrar desde Configuración; un estudiante se une iniciando sesión en classroom.google.com e ingresándolo [12]. Workspace for Education tiene topes por clase (50 profesores, 1,000 miembros) vía Google Groups; las cuentas personales enfrentan límites de actividad, y las invitaciones entre dominios están restringidas salvo que se use un código/enlace compartible. Clever es una capa de rostering/SSO, no una capa de consentimiento: importa datos de roster del SIS de una escuela y proporciona un solo inicio de sesión entre herramientas ed-tech; la responsabilidad del consentimiento recae en la escuela (a menudo la excepción FERPA de “school official”, que permite a una escuela autorizar a un proveedor en su nombre) o en el flujo COPPA propio del proveedor. Kahoot usa un PIN de juego: organizar exige registro, pero unirse a un juego en vivo solo necesita el PIN, sin cuenta: el patrón de ingreso de menor fricción de los estudiados, construido para participación anónima y efímera sin identidad persistente ni estado de consentimiento.

Tabla comparativa de mecanismos de consentimiento

Método	Fricción (padre)	Costo por consentimiento	Aceptado por	Recomendación
Formulario firmado (correo/fax/escaneo)	Alta, lento	$ bajo, alta carga operativa	Enumerado por la FTC [9]	No: demasiado lento para el onboarding
Microcargo a tarjeta de crédito/débito	Media: necesita una tarjeta	Comisión del procesador + riesgo de fraude	Enumerado por la FTC [9]	Solo si MC cobra una suscripción
Número gratuito, personal capacitado	Alta: personal real	Alto (mano de obra)	Enumerado por la FTC [9]	No: no viable a escala PWA
Videoconferencia, personal capacitado	Alta: agendamiento	Alto (mano de obra)	Enumerado por la FTC [9]	No
ID gubernamental + cotejo con foto en vivo (FMVPI)	Media-alta	Comisión del proveedor (unverified)	Aprobado por la FTC en 2015 [9][10]	No: desproporcionado para una app de matemáticas
Estimación facial de edad (Yoti/k-ID/PRIVO)	Baja-media, segundos	Comisión del proveedor (unverified)	Aprobado por la FTC vía §312.12 (2023) [9][11]	No necesario para «¿es un padre?»; relevante solo para futuro control de chat/bandas de edad
Email + click-through	Baja	Casi cero	Piso COPPA más bajo (solo uso interno)	Buena capa base combinada con control exclusivo del padre
Creación de cuenta controlada por el padre, sin autorregistro infantil	Baja para el padre, cero para el niño	Casi cero	Esquiva el VPC: el detonante del consentimiento es recolectar PII de un niño, lo que nunca ocurre aquí	Patrón primario recomendado: coincide con Apple/Google/Microsoft/Prodigy
Credencial de edad reutilizable (k-ID AgeKey, Apple Declared Age Range)	Muy baja tras la primera verificación	Amortizado	Emergente; no es en sí un método de VPC	Monitorear, no necesario en el MVP

Implicaciones de diseño para Math Challenge

1. Tres entidades: Parent (credenciales, email verificado), ChildProfile (pertenece a exactamente un padre, sin credenciales independientes por omisión), Teacher (credenciales, crea Classroom). Un Classroom contiene muchas referencias a ChildProfile, cada una con su propio registro de autorización por padre: refleja la identidad infantil aula-primero de Prodigy más la cuenta de padre adjunta [8], y el flujo de ingreso por código de Google Classroom [12].
2. Sin autorregistro infantil, nunca: coincide con el diseño decidido y con Apple/Google/Microsoft [1][4][5]. Como el niño nunca suministra PII de forma independiente, esto cae en la fila más ligera de «creación controlada por el padre» de arriba, no en una ceremonia COPPA VPC completa por niño.
3. Inicio de sesión infantil en una tablet compartida, en menos de 5 segundos, sin leer: cuadrícula de avatares (ícono/color elegido por el padre) + teclado numérico para PIN de 4 dígitos, sin teclado: retoma el PIN de anulación de Nintendo [6] y el Profile Lock de Netflix, escalado para pre-lectores; más rápido y más agnóstico al dispositivo que QR o biometría.
4. Atajo de «último perfil» vinculado al dispositivo: en un dispositivo personal, recordar el último perfil usado e ir directo a «tocar para continuar», cayendo de vuelta a la cuadrícula de avatares solo cuando se detecta un segundo perfil: mantiene el caso común de un-niño-una-tablet en ~1 toque.
5. PIN de padre, separado de los PIN de los niños, para llegar a la configuración de la cuenta, añadir/quitar niños o aprobar un ingreso a aula: la misma forma que el PIN de anulación de Nintendo [6] y el Profile Lock de Netflix, aplicado a proteger acciones exclusivas del padre.
6. El profesor invita por código de clase, no por búsqueda de email: un código de 6 caracteres (evitando 0/O, 1/I) mostrado como texto/enlace/QR: refleja Google Classroom [12] y el PIN de Kahoot, pero a diferencia de la sesión efímera de Kahoot, debe persistir y quedar condicionado a la aprobación del padre.
7. El ingreso al aula es un apretón de manos de dos pasos: (a) el padre añade el código desde su propio panel, nunca desde el dispositivo del niño; (b) el estado pasa a pendiente o activo según el modelo de confianza; (c) el padre siempre conserva un control de «Quitar del aula», satisfaciendo «cualquier padre puede sacar a su hijo en cualquier momento».
8. Modelar la autorización como tabla de unión, no como booleano: ClassroomMembership(child_profile_id, classroom_id, parent_id, status: pending|approved|revoked, approved_at, revoked_at): una pista de auditoría gratis si alguna vez surge una disputa de consentimiento.
9. Lógica de bandas de edad a partir de la edad declarada por el padre, no de una fecha de nacimiento reingresada por el niño: guardar birth_year_month en ChildProfile, ingresado una sola vez por el padre; derivar «menor de 13»/«13+» solo del lado del servidor: retoma la filosofía de Declared Age Range de Apple de exponer una categoría, no una fecha [2][3].
10. A los 13 años: no es un muro duro para una app que recolecta PII mínima, pero definir un evento (child_profile.crossed_13) que deje de tratar el perfil como «niño» para cualquier práctica futura relevante a COPPA (chat, analítica de marketing) y ofrezca opcionalmente al padre un aviso de conversión de cuenta. Modelar la conversión como disparada por el padre, no automática: el patrón de graduación-a-la-edad-de-consentimiento de Google/Microsoft existe [4][5], pero su mecánica exacta no se confirmó independientemente en esta sesión, así que no copiarla a ciegas.
11. A los 18 años (o la mayoría de edad local): ofrecer un flujo explícito de «convertir a cuenta independiente» que exija al usuario ya adulto definir sus propias credenciales, tras lo cual el perfil se desvincula y el padre pierde la visibilidad por omisión: la forma general coincide con las salidas de grupo familiar de Apple/Google/Microsoft, aunque ninguna fuente de esta sesión dio un mecanismo preciso; validar contra la documentación vigente antes de implementar.
12. No construir estimación facial de edad ni consentimiento por ID gubernamental para el MVP. El diseño decidido ya pone todos los datos del niño detrás de una cuenta de padre registrada, así que la exposición está más cerca de «email + creación controlada por el padre» que de un operador COPPA que recolecta PII de un niño sin supervisión. Revisitar solo si una función futura permite a un niño dar PII a un tercero (p. ej., una tabla de posiciones pública con nombre real) o permite a un niño iniciar la creación de cuenta sin supervisión.
13. Reservar la vía §312.12/safe harbor solo si el asesor legal determina que el VPC completo de COPPA aplica en absoluto: Netflix, Disney+ y Nintendo usan perfiles en lugar de cuentas específicamente para evitar ser un “operator collecting PII from a child” bajo COPPA; el modelo padre-crea-perfil de Math Challenge debe aspirar a la misma forma legal.
14. El rostering Clever/ClassLink es Fase 2+, no MVP: resuelve la importación masiva desde el SIS y el SSO, relevante solo cuando Math Challenge tenga clientes institucionales/de distrito; el modelo de código de clase (punto 6) es suficiente para arrancar, igual que funcionan Kahoot y Google Classroom antes de que exista cualquier integración con SIS.

Preguntas abiertas para el dueño del proyecto

1. ¿El «PIN de padre para salir del modo infantil» debe ser compartido entre todos los hijos de un padre, o por niño?
2. ¿El ingreso a un aula debe requerir también confirmación del profesor (apretón de manos bilateral), o basta la aprobación del padre?
3. A los 13, ¿Math Challenge debe proponer activamente la conversión de cuenta, o dejarla indefinida hasta que el usuario/padre la inicie?
4. ¿Alguna función planeada (chat, tabla de posiciones con nombre real, contenido generado por el usuario) probablemente eleve el piso de COPPA/VPC más allá de la «creación de perfil controlada por el padre»? Esto cambia si los puntos 12–13 se sostienen.
5. ¿Las tablets de aula compartidas deben soportar varios niños mediante la cuadrícula de avatar+PIN, o se asume una-tablet-por-niño en el despliegue inicial?