Privacidad y datos dentro de las aplicaciones

Para crear una cuenta, contratar, cobrar y atender soporte, Alejandro García Corte, bajo la marca bynotek, trata los datos de la relación comercial como responsable. Ese tratamiento se explica en el aviso general. Contacto: legal@bynotek.com. Domicilio del responsable: pendiente antes de la edición definitiva.

Cuando una escuela, docente, empresa o institución incorpora información de su propia actividad a una aplicación, esa persona u organización normalmente determina las finalidades y actúa como responsable. bynotek actúa como encargado en las operaciones que realiza por cuenta de ese cliente y bajo instrucciones documentadas. La clasificación depende del tratamiento real, no solo del nombre del contrato.

El papel se decide por finalidad: administrar la contratación, cobrar y proteger la cuenta comercial son usos propios de bynotek. Organizar evaluaciones o recibir consultas de un negocio mediante su sitio son finalidades del cliente. Compartir infraestructura no fusiona todos esos tratamientos.

Si una instrucción supone un uso propio nuevo del proveedor, se analiza antes y no se oculta dentro del encargo. Los titulares deben poder identificar quién decide sobre su información. Un contrato de desarrollo que solo entrega software, sin acceso operativo a datos, puede tener un ámbito diferente de uno con hosting, soporte o migración de producción.

Las últimas dos filas son un marco previsto, no un inventario de una aplicación activa. Antes de su lanzamiento deberán precisarse módulos, datos, permisos y conservación. No se autoriza automáticamente información médica o biométrica.

El inventario debe describir datos realmente habilitados, no todos los que un producto podría almacenar. En HeyAula el esquema revisado incluye nombres, pertenencia a aula, entregas, respuestas, calificaciones, asistencia, participación, mensajes y adjuntos; también ciertos registros de acceso y credenciales protegidas cuando se configuran.

Los archivos pueden incluir categorías adicionales por decisión del usuario; no deben utilizarse para introducir datos ajenos al propósito. Fotografías, nombres y registros aparentemente cotidianos siguen siendo datos personales si identifican a alguien. El contenido público de un negocio no deja de tener titulares y derechos de imagen.

El cliente define una finalidad legítima, determina qué datos necesita, informa a los titulares, atiende sus derechos y verifica las autorizaciones o excepciones legales aplicables. Debe evitar datos excesivos y establecer permisos adecuados para su personal.

Un docente no puede asumir facultades ilimitadas para tratar datos de toda una institución. Si el cliente es una entidad pública, debe atender también el régimen de datos en posesión de sujetos obligados y las normas que le correspondan; este documento no sustituye su aviso institucional ni sus obligaciones.

El cliente debe identificar su responsable, canal de derechos, usuarios autorizados y reglas de representación. Debe separar finalidades obligatorias de opcionales y obtener las autorizaciones necesarias; contratar infraestructura no acredita esas bases.

Las escuelas públicas y otros sujetos obligados deben analizar su régimen propio, incluidos requisitos institucionales de encargo y ubicación. No se afirma que una aceptación privada de este texto satisfaga por sí sola sus procedimientos. Un docente debe conocer si puede contratar y cargar datos de su institución.

El cliente configura permisos y conservación de acuerdo con sus obligaciones, evitando archivos excesivos. bynotek debe comunicar las limitaciones del producto y no ofrecer como compatible un requerimiento que no puede cumplir.

El encargo puede comprender almacenamiento, organización, presentación, transmisión autorizada, soporte y operaciones técnicas necesarias para las funciones contratadas. Se limita al servicio y a las instrucciones documentadas.

bynotek no adquiere la propiedad de los datos ni un permiso para utilizarlos en su publicidad, venderlos o reutilizarlos en otro cliente. Los usos propios, como la seguridad de la cuenta o una obligación legal, deben tener su fundamento y aviso correspondientes. El detalle contractual se recoge en el anexo de tratamiento.

Las operaciones pueden comprender almacenamiento, acceso autorizado, transmisión necesaria, visualización, cálculo, exportación y supresión. Su extensión queda en la ficha del servicio. No se concede por defecto acceso del proveedor a cualquier dato o sistema que el cliente posea.

Una instrucción de la persona autorizada debe quedar documentada. Las configuraciones ordinarias pueden expresar instrucciones dentro del alcance; una petición extraordinaria necesita verificar facultades y riesgo. Si aparenta ser ilícita o excede el servicio, se solicita aclaración y puede suspenderse esa operación.

La información no se utiliza para campañas del proveedor, venta de bases, demos o entrenamiento de modelos por el hecho de estar alojada. Los registros necesarios de seguridad se limitan a su función y se distinguen de expedientes educativos o comerciales.

El aula puede contener nombres, pertenencia a un grupo, respuestas, tareas, archivos, resultados y comunicación con el docente. Son datos personales cuando permiten identificar a un alumno. El cliente decide qué información incorpora y debe configurar el acceso con ese contexto.

Un código, un enlace o una selección de nombre facilitan el acceso, pero no deben tratarse por sí solos como prueba suficiente de identidad para divulgar información sensible o de otra persona. El docente o institución debe limitar la información visible y validar los accesos según el riesgo.

El titular de suscripción puede vincular su organización mediante la cuenta de bynotek. Los docentes locales tienen sus mecanismos de acceso; los alumnos se vinculan a aulas y pueden contar con protección por contraseña según la función. Ninguno de esos mecanismos acredita automáticamente representación legal.

El docente decide qué módulos habilita, cuándo permite incorporación y qué información se muestra. Debe cerrar ventanas de registro que ya no sean necesarias, proteger códigos y verificar listas cuando haya riesgo de suplantación.

La plataforma no certifica autoría de una respuesta por el hecho de registrarla. El docente mantiene supervisión y corrección de errores de identidad o asignación. Enviar una captura al soporte debe limitarse al dato necesario y evitar mostrar todo el grupo si basta un caso.

Cuando participen menores, el cliente debe evaluar la representación de madres, padres o tutores, la información que corresponde dar al menor según su edad y la base jurídica del tratamiento educativo. No se presume que la aceptación comercial del docente sustituya toda autorización del representante.

No debe publicarse una imagen, resultado o conversación privada de un menor mediante un permiso genérico de uso de la plataforma. Se deben considerar su privacidad e interés superior. Una solicitud de datos de un menor requiere verificar la identidad y facultades de quien la formula.

La institución informa en lenguaje adecuado a alumnos y representantes sobre módulos, visibilidad, comunicaciones supervisadas y conservación. Debe determinar cómo se acredita tutoría o representación para solicitudes. Una cuenta pagada por un adulto no sustituye esos deberes respecto de todos los menores del aula.

No se explotan expedientes de menores para publicidad o perfiles comerciales bajo una aceptación genérica. Las imágenes, salud, discapacidad, sanciones y situación familiar requieren particular evaluación de necesidad y base.

Si bynotek recibe una solicitud de un menor o representante, protege la información mientras identifica al responsable y verifica el cauce. No revela respuestas de un alumno porque el solicitante conozca su nombre. Las medidas deben ser proporcionales sin impedir injustificadamente sus derechos.

La aplicación puede ayudar a organizar o calcular resultados conforme a la configuración del docente. Esos resultados deben revisarse antes de adoptar decisiones académicas relevantes.

El cliente conserva sus obligaciones de explicar criterios, corregir errores y atender inconformidades. El contrato de la aplicación no otorga a bynotek competencia para decidir admisiones, sanciones o derechos del alumno en nombre de la institución.

Se diferencian respuestas entregadas, respuestas en progreso, puntajes calculados, correcciones manuales y calificación final adoptada por el docente. La revisión puede necesitar esos antecedentes; eliminarlos debe considerar el plazo de reclamación o archivo de la institución.

Un error técnico se reporta por soporte; una inconformidad sobre criterio pedagógico se dirige al docente o institución. bynotek coopera para localizar información dentro de su alcance, sin sustituir una decisión académica.

No se promete que toda encuesta sea irreversiblemente anónima. El código distingue encuestas identificadas y otras que limitan la identidad en la exportación; el contexto puede seguir haciendo identificable a una persona. La institución no debe anunciar anonimato absoluto sin revisar la configuración y operación.

El administrador decide qué publica y debe tener derechos y legitimación para utilizar fotografías, testimonios, listados, datos de contacto u otros materiales. Publicar un dato en un sitio no hace lícita cualquier reutilización posterior.

Si se habilitan formularios, cookies o integraciones para visitantes, el titular del sitio debe incorporar su propio aviso y los mecanismos que correspondan. El aviso de bynotek sobre una cuenta del administrador no sustituye el del negocio que recaba los datos de sus clientes.

El titular revisa qué material será público, permisos de empleados y finalidad de consultas recibidas. Si habilita formularios, debe informar responsable, datos, propósito y canal de derechos en su propio sitio. La marca de una plataforma no reemplaza su aviso.

No se presume que exista comercio electrónico, pasarela, seguimiento publicitario o un módulo específico de leads en todos los planes. Se documenta el flujo que realmente tenga el servicio contratado, destinatarios de mensajes, ubicación y conservación.

Publicar nombres, teléfonos o fotos requiere derechos suficientes. Recibir una consulta no autoriza suscribir al visitante a promociones. Un cambio de dominio o plantilla no debe exponer automáticamente información antes privada. Las integraciones de terceros deben revisarse antes de activarlas.

No se deben cargar datos de salud, biométricos, documentos de identidad completos u otras categorías de mayor riesgo por comodidad. Antes de incluirlos se necesita determinar finalidad, necesidad, funciones efectivamente habilitadas y protección adecuada.

El cliente y bynotek deben acordar expresamente ese tratamiento y las medidas del encargo. Cuando corresponda, se requiere consentimiento expreso y por escrito. Un producto de gimnasio no implica por definición el uso de reconocimiento facial ni historiales médicos.

Una categoría sensible se identifica por contenido y riesgo, no por la etiqueta del archivo. Debe especificarse necesidad, base, accesos y seguridad, y obtener consentimiento expreso escrito cuando corresponda, sin convertir la firma del suscriptor en consentimiento de todos los titulares.

Los futuros productos de gimnasio o gestión escolar podrían tener escenarios de riesgo distinto si se diseñan funciones de salud, biometría, vigilancia o acceso físico. Esos escenarios no se autorizan con este marco general. Necesitan evaluación y documentación antes de usar datos reales.

Si una exigencia institucional no puede satisfacerse, debe comunicarse y acordarse alternativa antes del encargo. No se afirma certificación sectorial o cumplimiento automático por alojar datos en la plataforma.

Los accesos deben asignarse según las funciones de administración, docencia, atención o participación. El cliente debe retirar los permisos de personas que ya no están autorizadas y evitar cuentas compartidas que dificulten atribuir actuaciones.

El soporte de bynotek accede solo a la información necesaria para atender la incidencia y conforme al encargo. No se deben enviar listas completas, contraseñas o evidencias privadas por canales abiertos cuando basta una descripción o un ejemplo disociado.

El acceso a soporte se limita a verificar y resolver el asunto. No debe entregar contraseñas en texto claro ni permitir consultar otras organizaciones. Se comprueba quién pide exportar, borrar un aula o cambiar administradores.

Las exportaciones amplias se tratan con el mismo cuidado que la base activa: una hoja descargada puede incluir nombres, mensajes y registros de acceso. El cliente decide quién la recibe y cómo la protege. No debe publicarla mediante un enlace abierto.

La visibilidad de un módulo no acredita legitimación para todos sus datos. Los avisos y controles deben reflejar permisos reales de docentes, alumnos y administradores. Un enlace firmado tiene caducidad técnica; reenviarlo puede permitir acceso durante su validez y requiere precaución.

El tratamiento puede requerir infraestructura o proveedores externos. El servicio concreto debe identificar sus funciones y ubicaciones y establecer las autorizaciones y medidas pertinentes antes de utilizar datos reales.

No se promete almacenamiento exclusivamente mexicano ni se presume un permiso ilimitado para enviar datos al extranjero. Los subencargados deben quedar sujetos a obligaciones compatibles con el encargo. Los pagos, canales de comunicación o integraciones que actúen como terceros independientes pueden tener sus propios avisos.

El código revisado identifica PostgreSQL para datos y un adaptador de almacenamiento compatible con Cloudflare R2 para objetos. Eso no demuestra por sí solo quién contrata cada servicio, región efectiva, residencia de todos los datos o ejecución del mismo código en producción. Esos datos deben verificarse en el inventario.

No se promete almacenamiento exclusivo en México ni se copia un listado de SoloEnlace que corresponde a otra operación. El inventario del encargo debe incluir nombre de entidad, función, categorías, países o accesos pertinentes y reglas de cambio.

Un servicio de IA que reciba contenido del cliente debe incorporarse antes al análisis; no se presume activado. Un proveedor con fines propios se diferencia de un subencargado que actúa siguiendo instrucciones.

Cada servicio y plan debe informar cuánto tiempo se conservan los archivos, cuándo se purgan y cómo pueden descargarse o solicitarse. El cliente debe considerar sus obligaciones de archivo y obtener la información que necesite antes de que expire el periodo comunicado.

Un cambio de plan, baja o purga no debe aplicar una regla inesperada que contradiga lo contratado. Una promesa comercial de almacenamiento amplio no exime al responsable de limitar el tratamiento a su finalidad. Este documento no inventa un periodo único para todas las aplicaciones.

La institución debe distinguir conservar el registro de una actividad de conservar cada adjunto, conversación o copia exportada. Un plan de retención extensa no evita las eliminaciones manuales ni garantiza recuperación de copias ya borradas.

Antes de una reducción de plan se informará el efecto material sobre límites y conservación; una regla nueva no debe purgar retrospectivamente sin considerar lo contratado. Los respaldos requieren ciclo propio, pendiente de validación: la fecha de vencimiento en una tabla no demuestra eliminación de todas las copias.

Los plazos de configuración descritos en las secciones siguientes son evidencia del código local revisado. Deben contrastarse con versión desplegada, trabajadores de limpieza y promesas comerciales antes de publicar una política operativa. Los plazos no demostrados de Sites se completan en su ficha y no se sustituyen con los de HeyAula.

En el repositorio local revisado se observan las siguientes reglas. No se acredita con esta revisión que todos los procesos estén desplegados o ejecutándose; la validación de producción sigue pendiente.

No se mezclan estas ventanas con el periodo de facturación. Mantener Business no impide que venza Cloud, un paquete exportado o un aula cuya eliminación se solicitó. Los adjuntos asociados a contenido eliminado pueden ser eliminados también. El ciclo de respaldos no está definido por estas constantes y debe documentarse aparte.

Antes de aplicar condiciones definitivas se verifica evento de inicio de cada plazo, avisos del módulo, capacidad de exportar y funcionamiento de limpieza. Un incumplimiento de configuración o proceso no se resuelve declarando que esta tabla ya demuestra borrado.

La acción de archivar desactiva el aula y programa eliminación. El código permite restaurarla antes de la fecha programada si la eliminación no inició; transcurrida la ventana, no se presume restauración. La opción de eliminación inmediata es una instrucción distinta que debe mostrarse y confirmarse claramente.

Cuando se elige exportar antes de eliminar, el flujo debe informar el estado del trabajo y permitir recuperar lo disponible. Un error de exportación no debe presentarse como una descarga completada. El cliente comprueba que el paquete se descargó y contiene la información necesaria.

Solicitar eliminación de aula afecta datos asociados conforme a su estructura. No elimina automáticamente facturación del suscriptor ni datos de otros productos. Solo la persona autorizada debe poder ordenar la operación. El responsable evalúa sus obligaciones de archivo y reclamación antes de ejecutarla.

El código identifica el proceso, no certifica su ejecución en producción. Se deben verificar permisos, avisos y trabajos de limpieza antes de utilizar estas reglas como compromisos operativos.

El código de exportación revisado contempla información legible del aula, registros educativos, mensajes y archivos que aún sean recuperables. Excluye hashes de contraseña y secretos de acceso; puede incluir datos operativos como IP, fecha o sistema de último acceso de alumnos. Por eso el paquete requiere permisos y protección, aunque se genere en una herramienta ordinaria.

Una exportación puede contener información de varias personas. No se entrega a cualquier alumno por pedir “mis datos”; ese trámite debe aislar lo que le corresponde y proteger a terceros. El docente responsable conserva el paquete conforme a su finalidad y obligaciones.

Los enlaces de descarga tienen validez técnica y deben tratarse como privados. Vencer el enlace no es necesariamente borrar el archivo de origen; vencer el paquete no significa borrar el aula. La devolución estándar no incluye transformar toda la plataforma ni exportar el código del servicio.

Una herramienta no puede recuperar contenido previamente purgado sin una copia legítima disponible. No se anuncia recuperación garantizada ni se utilizan respaldos para reactivar finalidades terminadas.

Si eres alumno, familiar, socio o visitante cuyos datos administra un cliente, solicita primero el ejercicio de tus derechos a la escuela, docente, gimnasio o titular del sitio responsable. Ese cliente decide la solicitud y puede instruir a bynotek para ejecutarla.

Si no sabes quién es responsable, o la solicitud se refiere a tu cuenta o relación directa con bynotek, escribe a legal@bynotek.com. bynotek ayudará a identificar el canal sin divulgar datos de otra persona. La atención se realiza conforme al régimen y plazos legalmente aplicables; no se impide una solicitud porque el contrato esté en disputa.

El titular identifica escuela, aula, sitio u organización y acción solicitada sin enviar expedientes ajenos. El responsable verifica identidad, decide y pide a bynotek asistencia documentada. El acceso se limita a datos propios, no a todas las respuestas de un grupo.

Si bynotek recibe la solicitud directamente, la canaliza al cliente responsable sin demora indebida y conserva lo necesario para seguimiento. Si también hay datos propios de contratación, se tramita esa parte bajo el aviso general.

La deuda, baja de plan o falta de uso no extinguen derechos. Una exportación comercial completa y una solicitud ARCO son operaciones distintas. Se protege información de otras personas durante la búsqueda y entrega.

Ante un incidente relacionado con el encargo, bynotek comunica al cliente responsable la información disponible sin demora y coopera en la contención e investigación. El responsable evalúa e informa a los titulares o autoridades cuando la ley lo exige.

Si bynotek es responsable de un tratamiento propio afectado, atiende directamente esa obligación. Una cláusula de confidencialidad no debe impedir notificaciones legalmente exigibles. No se promete una certificación, plazo de recuperación o ausencia total de incidentes sin un acuerdo y evidencia que lo sustenten.

Se identifican hechos disponibles, módulos, categorías, periodo y medidas de contención. No se promete certeza antes de investigar ni se espera a conocer todos los detalles para cumplir una notificación urgente. Se preserva evidencia y se limita acceso a lo necesario.

El cliente responsable evalúa notificaciones a titulares y autoridades bajo su régimen. bynotek coopera, informa de lo ocurrido en su ámbito y no obstaculiza obligaciones legales por motivos comerciales. El encargo puede fijar un canal y plazo interno que no desplacen deberes más estrictos.

Un reporte de sospecha no acredita por sí solo una filtración. Debe recibirse, investigarse y responderse proporcionalmente sin divulgar datos a quien no está autorizado.

Al terminar el servicio se atienden las instrucciones válidas de devolución o eliminación y las obligaciones de conservación. Deben acordarse el formato, plazo, acceso y ciclo de respaldos antes de tratar información real; una migración adicional puede requerir servicios específicos.

Los respaldos retenidos por un ciclo técnico se protegen, se mantienen fuera del uso ordinario y se eliminan conforme a ese ciclo. La obligación de confidencialidad continúa. Los datos no se convierten en material de demostración por haber terminado la relación.

Se identifican las instrucciones de devolución o eliminación, recursos, formatos y fecha de corte. El cliente debe recibir información suficiente para decidir antes de perder acceso. La migración extraordinaria se separa de las funciones estándar y derechos legales.

No se promete conservar una cuenta indefinidamente después de baja. Tampoco se afirma una ventana de recuperación que el producto no implemente. Cada servicio necesita definirla y hacerla coherente con sus purgas y respaldos antes de la edición operativa.

Las copias conservadas por obligación legal se restringen y se eliminan al concluir su motivo. La confidencialidad continúa. Un cierre no convierte datos en propiedad del proveedor ni permite reutilizarlos como contenido de demostración.

Antes de activar los productos de gimnasios o gestión escolar deberán completarse el anexo de tratamiento, el inventario real de datos, permisos, proveedores, ubicaciones y retención. Si se añaden datos sensibles, funciones automatizadas de impacto o nuevas integraciones, se revisará su alcance antes de ponerlas en uso.

Este marco general no autoriza por anticipado todo tratamiento futuro. Las condiciones de una aplicación no modifican retroactivamente la relación aceptada en otra. Consulta también el aviso general y los términos de aplicaciones.

Antes de lanzar un producto se identifican módulos reales, titulares, categorías, sensibles, representación de menores, permisos y decisiones automatizadas. También se revisan proveedores, ubicaciones, seguridad, derechos, continuidad y cierre.

Los clientes de desarrollo que entregan software sin operación de datos se diferencian de quienes contratan soporte con acceso a producción. La ficha describe las tareas efectivas; no se firma un encargo abstracto como permiso para acceder a todo.

Esta documentación debe completarse y contrastarse con la operación. La revisión profesional del marco y la validación técnica no se sustituyen por la extensión del texto. Los anexos específicos prevalecen cuando sean válidos y no reduzcan derechos obligatorios.