Política de Tratamiento de Datos Personales

El Responsable del Tratamiento de los datos personales descritos en esta política es Cristian Camilo Escandón García, persona natural con domicilio en Bogotá D.C., Colombia, que presta el servicio bajo el nombre comercial RemoteHub.

No hay sociedad constituida. No hay compañía inscrita, ni razón social, ni NIT: quien presta el servicio y responde por tus datos es la persona natural nombrada arriba. Si en algún documento nuestro leíste que RemoteHub es «una empresa» o «una sociedad», ese documento está mal redactado y esta política prevalece. Si el plural («nosotros») aparece en el texto es por comodidad de lectura: no describe ninguna estructura societaria.

El domicilio que se publica es la ciudad, no la dirección de la vivienda del Responsable, y tampoco se publica su número de cédula. La norma exige poder encontrarlo y escribirle, y para eso están los dos datos de arriba, cada uno para lo suyo: el teléfono sirve para localizarlo y resolver dudas, y el correo es el único canal para radicar una consulta o un reclamo — porque de la radicación tiene que quedar constancia con fecha, y de ella arrancan los plazos legales de respuesta que se detallan en la sección 14. Una llamada no deja esa constancia: si llamas, te pediremos que lo dejes por escrito en ese correo, y el plazo cuenta desde entonces. La dirección completa de notificaciones y el documento de identidad se entregan en los contratos con instituciones y ante cualquier requerimiento de autoridad.

Canal designado de protección de datos

Conforme al artículo 2.2.2.25.4.4 del Decreto 1074 de 2015 (antes art. 23 del Decreto 1377 de 2013), existe un canal único responsable de atender peticiones, consultas y reclamos sobre datos personales: administrador@remotehubtech.com. Todas las solicitudes de esta política se atienden por ese canal, y quien las atiende es el propio Responsable.

Qué norma nos aplica

El Responsable está domiciliado en Colombia y trata datos de personas en Colombia. Le rige la Ley Estatutaria 1581 de 2012 y el Decreto 1074 de 2015 (que compila el Decreto 1377 de 2013), con la SIC como autoridad. No nos rige el Reglamento General de Protección de Datos europeo, ni la Ley 1266 de 2008, que regula el habeas data financiero y crediticio y no tiene relación con este producto.

En palabras simplesSi alguna vez lees en nuestra web que cumplimos el «GDPR», está mal escrito. La ley que nos obliga es la colombiana, y ante quien puedes quejarte es ante la Superintendencia de Industria y Comercio.

El Registro Nacional de Bases de Datos (RNBD)

El deber de inscribir las bases de datos en el RNBD de la Superintendencia recae sobre las personas jurídicas de naturaleza privada cuyos activos superen el umbral fijado por la norma y sobre las entidades de naturaleza pública. El Responsable de esta política no es ni lo uno ni lo otro: es una persona natural. Por eso no está inscrito en el RNBD y no afirmamos estarlo.

En palabras simplesNo estar obligado a ese registro no exime de nada más. Todos los demás deberes de la Ley 1581 —pedir autorización, informar, atender tus consultas y reclamos en los plazos, cuidar la seguridad, responder ante la SIC— se aplican igual, y este documento los asume uno por uno. Si tu universidad necesita el dato para su propio registro, escríbenos y te damos por escrito finalidades, medidas y transferencias.

El artículo 18 de la Ley 1581 de 2012 prevé que quien trata datos concurra a la vez como Responsable y como Encargado, y en ese caso le son exigibles los deberes de ambos. Es nuestro caso, y es la clave para entender quién decide qué sobre tus datos.

En palabras simplesCuando un estudiante pregunta «¿por qué me están vigilando?», la respuesta honesta casi siempre es: la decisión de vigilar la tomó su universidad, no RemoteHub. Nosotros ponemos la herramienta, los límites técnicos y el aviso en pantalla, y los derechos sobre esos datos se ejercen ante la institución; si nos escribes a nosotros, trasladamos la solicitud y te decimos a quién. Pero hay un caso en que no hay ninguna institución detrás —un equipo de una cuenta particular— y entonces la puerta somos nosotros, sin reenviarte a nadie.

Ser Encargado no nos deja al margen. Respondemos por la seguridad de las bases de datos, la confidencialidad, la minimización de lo que se captura y la trazabilidad del consentimiento. Con cada institución cliente firmamos un contrato de transmisión en los términos del artículo 2.2.2.25.5.2 del Decreto 1074 de 2015.

La institución, por su parte, es quien debe haber informado previamente a estudiantes y trabajadores y conservar la prueba de esa autorización. Nosotros no podemos hacerlo por ella, y contratar RemoteHub no la exime de hacerlo.

Esta no es una lista genérica. Es el inventario real de lo que el producto escribe en base de datos, categoría por categoría.

3.1 Cuenta e identidad

Dos ausencias que tienes derecho a conocer. (1) No verificamos el correo electrónico: si te registras con correo y contraseña, nadie comprueba que esa dirección sea tuya. Si creas la cuenta con Google o Microsoft, el correo es el que nos da ese proveedor: en Google, solo si nos asegura que está verificado; en Microsoft, solo si confirma que su dominio pertenece a la organización de esa cuenta, o si es una cuenta personal (apartado 3.7). Esa comprobación, cuando la hay, es suya, no nuestra. (2) No existe «olvidé mi contraseña»: la plataforma no envía correos, así que no hay recuperación automática. Si pierdes la contraseña, solo un administrador puede intervenir. Y si tu cuenta no tiene contraseña y pierdes el acceso a tu cuenta de Google o Microsoft, estás en la misma situación: por eso conviene crear también una contraseña en Ajustes. Los códigos de recuperación de 2FA sirven únicamente para saltarse el segundo factor, no para recuperar la contraseña.

3.2 Datos de conexión

• Dirección IP, siempre truncada a su red (/24 en IPv4, /48 en IPv6) antes de tocar la base de datos. El truncado es irreversible: no es un cifrado ni un hash con clave, la parte que identifica el equipo concreto se descarta y no se puede recuperar. Se guarda para frenar ataques de fuerza bruta y dar trazabilidad de seguridad.
• Navegador y sistema operativo (cadena «User-Agent»), recortada a 200 caracteres, para que reconozcas tus propias sesiones abiertas.
• Sesiones abiertas: el token que mantiene tu sesión se guarda solo como huella sha256, con rotación y detección de reutilización.

En palabras simplesNo guardamos tu dirección IP exacta en ningún sitio de la base de datos. Guardamos el barrio, no la casa. La IP completa sí se usa unos minutos (hasta cinco) en memoria para contar peticiones y frenar los intentos a repetición, y caduca sola.

3.3 Equipos

De cada equipo registrado guardamos el nombre que le pones, un identificador público de 9 dígitos, el nombre de red de la máquina, una cadena de sistema operativo (por ejemplo «win32 10.0.19045 x64»), un identificador estable generado aleatoriamente y sus opciones de acceso.

• No guardamos la dirección IP de los equipos remotos. No existe esa columna.
• No hacemos huella de hardware. El identificador de máquina es un número aleatorio que el programa genera la primera vez y guarda en un archivo. No leemos el número de serie, ni el procesador, ni el registro de Windows.
• La dirección física (MAC) de un equipo nunca llega a nuestros servidores. No existe esa columna. Y hay que explicar por qué esta frase dice «no llega a nuestros servidores» y no «no la leemos», que es lo que decía antes: desde que existe el encendido a distancia, un equipo puede necesitar esa dirección. Encender un computador dormido por la red consiste exactamente en enviarle un aviso hecho con su dirección física repetida dieciséis veces; no hay otra forma. Así que el programa instalado, y solo cuando alguien activa esa función en ese equipo, comunica su dirección a los otros equipos de RemoteHub que estén en su misma red local, y ellos la guardan en su propio disco para poder despertarlo. Esa dirección no viaja por internet, no pasa por nosotros y no se guarda en ninguna base de datos nuestra: nuestro servidor solo sabe pedir «que alguien encienda a este equipo» y son los equipos de esa red los que saben cómo.
• El encendido a distancia nace desactivado en cada equipo y se activa uno por uno, desde su ficha. No lo activa el plan, ni la institución, ni nosotros. Mientras esté desactivado, el equipo no cuenta su dirección a nadie. Lo que sí funciona sin activarlo es la comprobación de si ese equipo podría encenderse por red —una revisión que no recoge ninguna dirección— para que quien administra el parque sepa qué equipos servirían antes de decidir si lo activa.
• Ninguna credencial de equipo se guarda en claro: el PIN de acceso desatendido va con argon2id, el secreto de la contraseña diaria va cifrado, y la credencial del programa instalado se guarda como hash.

En un Mac guardamos lo mismo. La cadena de sistema empieza por «darwin» (por ejemplo «darwin 23.5.0 arm64»), y el identificador de máquina también es un número aleatorio, que genera el instalador y guarda en un archivo: no leemos el identificador de hardware del Mac, ni su número de serie, ni su dirección física (MAC). Lo que es distinto es dónde queda la credencial del programa instalado: en nuestro servidor se guarda como hash igual que la de cualquier equipo, pero en el propio Mac se guarda en un archivo sin cifrar que cualquier cuenta de ese Mac puede leer.

El acceso por contraseña diaria viene activado por defecto en cada equipo nuevo. Es una clave que rota sola cada día y que permite entrar al equipo sin que nadie acepte un diálogo en ese momento. La ve el dueño del equipo y el administrador del plan de su institución, y se puede desactivar desde la ficha del equipo.

3.4 Reservas de salas

De cada reserva guardamos quién reservó, qué equipo, la franja horaria, un motivo opcional de texto libre de hasta 280 caracteres, el estado, si la creó una persona o una aplicación externa, y quién la canceló.

Cuando la aplicación de tu institución reserva una sala completa para una clase, guardamos además la sala, el profesor a cuyo nombre se reservó, la llave de la institución que la creó, una referencia opcional de esa aplicación, la lista opcional de personas que pueden usar el código de clase y el propio código de clase, cifrado. Cuando entras con un código de clase, queda registrado que tú entraste, en qué equipo, en qué sesión y por qué reserva de sala.

• Entre compañeros hay anonimato. En el calendario y la rejilla, tus compañeros de institución ven la franja como ocupada, sin tu nombre y sin tu motivo.
• Ante el gestor de tu institución, no. El panel de gestión muestra nombre, correo electrónico y motivo de todas las reservas del parque de equipos. Lo que escribas en el motivo lo puede leer el responsable de informática de tu universidad.
• Nadie aprueba una reserva. Quien tiene derecho a reservar, reserva, y la franja queda confirmada al instante.

3.5 Registro de auditoría

Anotamos QUÉ pasó y QUIÉN lo hizo, nunca el contenido de lo que se vio o se escribió. Cada fila tiene una acción, la entidad afectada, un detalle en formato técnico, la IP ya truncada y la fecha. Se registran, entre otras, el alta y el inicio de sesión, los intentos fallidos, los cambios de contraseña y de 2FA, la vinculación y desvinculación de cuentas de Google o Microsoft, el inicio y el corte de cada sesión remota, los accesos desatendidos, los cambios de permisos, las transferencias de archivo, las reservas, la creación y la cancelación de una reserva de sala, la emisión, cada lectura y cada reemisión de un código de clase, cada entrada con un código de clase (con la persona que entró), el encendido y apagado de la supervisión y los movimientos de licencia. Ni el código de clase ni su huella ni su cifrado entran en esas filas.

Dos cosas incómodas y ciertas. (1) Cuando alguien falla al iniciar sesión, se guarda el correo que tecleó, aunque ese correo no pertenezca a ninguna cuenta de RemoteHub: puede quedar registrado el correo de alguien que nunca se registró. Ese dato no se muestra en ninguna pantalla y se borra a los 365 días. Un intento fallido con Google o Microsoft, en cambio, se anota sin correo y sin el identificador del proveedor: el proveedor, el paso, el motivo, la red (la IP truncada) y, si el intento llegó a apuntar a una cuenta concreta de RemoteHub, esa cuenta, aunque quien lo intentara no fueras tú. (2) Del registro de auditoría también se anota el nombre y el tamaño de los archivos transferidos en una sesión —no su contenido—, y un nombre de archivo puede revelar por sí solo de qué trata.

El registro de auditoría completo solo lo puede consultar el administrador de plataforma de RemoteHub: cubre todo el sistema, con todas las instituciones y todas las cuentas. Una institución no accede a ese registro completo; lo que sí puede consultar es la parte que le corresponde —los hechos de su propia empresa, sus equipos, sus salas y su gente—, y solo desde la cuenta titular del plan, una cuenta con perfil de administrador o la que tenga perfil de auditor (sección 5). Los hechos que no se pueden atribuir con certeza a esa institución quedan fuera de esa vista, y la propia pantalla enumera cuáles. En tu descarga de datos personales obtienes dos listas: las filas que registraste tú —con su detalle completo— y las filas que otra persona provocó sobre tu cuenta (por ejemplo un cambio de rol hecho por un administrador), estas últimas con la acción, la fecha y la red, pero sin el detalle interno de la fila: ahí el actor es otra persona y ese detalle puede contener sus datos, no los tuyos.

Este registro NO es el historial de conexiones de tu institución. Son cosas distintas y conviene no mezclarlas. Este registro de auditoría es nuestro y cubre todo el sistema (altas, inicios de sesión, cambios de permisos, movimientos de licencia…); completo, solo lo consulta el administrador de plataforma de RemoteHub. El historial de conexiones es otra tabla: solo las sesiones de control remoto y sus metadatos, y de esa sí puede ver el conjunto la cuenta titular del plan de tu institución, un administrador de ese plan o quien tenga perfil de auditor, con el alcance y los límites que detalla la sección 5. Y tu institución puede consultar además la parte de este registro que le corresponde: los hechos de su propia empresa, sus equipos, sus salas y su gente. Lo que no puede ver, en ningún caso, es el registro del resto del sistema ni el de otras instituciones.

3.6 Pagos

RemoteHub no toca nunca datos de tarjeta. No guardamos ni el número, ni la fecha de vencimiento, ni el código de seguridad, ni siquiera los cuatro últimos dígitos.

Hoy la pasarela de pago no está en funcionamiento (ver la sección 11): la única vía viva para contratar un plan de pago es la licencia por transferencia bancaria. Cuando la pasarela se active, contratar un plan te llevará fuera de nuestra web hacia el sitio de la pasarela y los datos del medio de pago los teclearás allí; lo único que le enviaríamos es tu correo electrónico, junto al nombre del plan, el importe y la moneda.

De la suscripción guardamos su estado actual: plan, estado, importe, moneda, capacidad contratada y fecha de fin del periodo pagado. No emitimos ni conservamos facturas ni recibos: quien documenta cada cobro es la pasarela.

En los contratos por transferencia bancaria (el camino habitual de las universidades) solo registramos la referencia comercial: importe pactado, moneda, fecha de la transferencia y número de factura, contrato u orden de compra. No pedimos ni guardamos NIT, razón social como campo aparte, cédula del representante, dirección fiscal, número de cuenta bancaria, banco emisor ni comprobante escaneado.

El artículo 4 del Decreto 1074 de 2015 limita la recolección a lo pertinente y adecuado para la finalidad. Estas son todas nuestras finalidades, sin cláusulas de cajón:

• Prestar el servicio: crear tu cuenta, autenticarte —también con Google o Microsoft, si lo eliges (apartado 3.7)—, poner tus equipos en línea, establecer las sesiones de control remoto y gestionar las reservas de equipos y de salas completas, incluido el código de clase con el que entran los participantes de una clase.
• Seguridad: frenar la fuerza bruta, detectar credenciales copiadas o robadas, y poder reconstruir quién entró a qué equipo, cuándo y con qué autorización. En un producto que inyecta teclado y ratón, esa trazabilidad es la contrapartida obligatoria del poder que da. Ese registro lo puede consultar, además de cada persona sobre lo suyo, el dueño o administrador del plan de la institución respecto de los equipos y las personas de esa institución — quién accede, a qué y con qué límites está en la sección 5.
• Facturación y control de capacidad: saber qué plan tiene contratado cada institución y cuántos equipos y personas caben en él.
• Supervisión de actividad, únicamente cuando la enciende quien puede hacerlo: el dueño del equipo, o la institución dueña del equipo. Cuando la enciende una institución, la tratamos por cuenta de ella; cuando la enciende el dueño de un equipo particular, el Responsable somos nosotros. Ver la sección 6.
• Diagnóstico técnico: entender por qué falla una conexión.

No usamos tus datos para ninguna otra cosa. No hacemos perfiles comerciales, no vendemos ni cedemos datos a terceros, no hacemos publicidad y no entrenamos modelos de inteligencia artificial con el contenido de tus sesiones ni con los datos de actividad.

La imagen no se guarda

Durante una sesión, la pantalla se codifica y se transmite en vivo. El único destino de esa imagen es la conexión con el operador. No hay ninguna salida a fichero, no existe ninguna tabla de vídeo, capturas ni miniaturas en la base de datos, y en el navegador del operador no hay ningún mecanismo de grabación.

• No se graba vídeo. Ni completo, ni por fragmentos, ni en capturas sueltas.
• No se registra lo que tecleas. Las teclas y los clics del operador se inyectan en el sistema operativo y se descartan. Solo quedan contadores agregados (cuántos eventos se enviaron y cuántos se rechazaron) en los registros técnicos locales del propio equipo.
• No se captura audio ni micrófono. El codificador va explícitamente sin audio y no existe ninguna petición de micrófono.
• Los archivos que se transfieren no pasan por nuestro servidor: viajan directamente entre los dos equipos. En el equipo que los recibe se guardan en una carpeta de cuarentena que se vacía al terminar la sesión. De ellos solo conservamos nombre, tamaño, dirección y resultado.

Por dónde viaja y cómo va protegido

La imagen y los eventos de teclado y ratón viajan punto a punto entre el navegador del operador y el equipo, mediante WebRTC, que impone cifrado obligatorio del medio (DTLS-SRTP) y no permite desactivarlo. Nuestro servidor solo intercambia los datos necesarios para que los dos extremos se encuentren, y guarda metadatos, no medios.

Cuando la conexión directa no es posible —redes distintas, aislamiento de clientes en la wifi universitaria, cortafuegos— el flujo pasa por un servidor de retransmisión (TURN). Ese servidor reenvía paquetes ya cifrados y no puede descifrarlos, pero sí ve las direcciones IP de ambos extremos, el volumen y los tiempos. Está identificado en la sección 11.

Precisión honesta: ese cifrado es una propiedad del protocolo que usamos, no un cifrado propio adicional que hayamos programado nosotros. No afirmamos tener más de lo que tenemos.

Consentimiento: cuándo hay diálogo y cuándo no

De cada sesión guardamos quién autorizó el acceso, cuándo, por qué método y qué permisos concretos concedió (pantalla, teclado y ratón, archivos, chat). Hay cuatro métodos —el código de clase, en la última fila, es una forma de entrar por reserva de sala— y en tres de ellos no aparece ningún diálogo en el momento:

Cuando alguien entra por reserva, el consentimiento del ACCESO que queda registrado es el del dueño del equipo, no el de quien pueda estar delante. Es la situación normal en una sala de informática vacía que un estudiante reserva desde casa, y es la razón por la que el aviso en pantalla durante la sesión no es opcional: es lo que sostiene la legalidad de ese acceso. Con un código de clase pasa lo mismo, con una diferencia: el código no es tuyo, es de la clase. Lo entrega tu institución y, durante la franja, lo puede usar cualquier cuenta de ella (o solo las personas de la lista, si la aplicación mandó una), en un solo equipo a la vez; por eso en cada entrada queda registrado con qué cuenta se usó. Ojo con no confundir ese consentimiento del acceso con el de la supervisión de actividad, que es otra cosa y lo da otra persona: lo acepta quien se conecta, en su propio equipo y antes de entrar, porque es a esa persona a la que se va a registrar. Ver la sección 6.

En todos los casos, mientras dura la sesión el equipo muestra un aviso en pantalla con su estado, el nombre del operador, los permisos concedidos y la hora de inicio. Y los controles del usuario son reales, no cosméticos: quitar el permiso de pantalla apaga el codificador —no lo oculta— y sin permiso de pantalla el operador no puede actuar a ciegas, porque el teclado y el ratón se descartan antes de interpretarse.

Quién puede consultar el historial de conexiones

De cada sesión guardamos metadatos —no contenido— y hasta hace poco cada persona solo veía los de las sesiones en las que participó. Eso cambió: la cuenta titular del plan de una institución, un administrador de ese plan o quien tenga perfil de auditor puede consultar el historial completo de conexiones de sus equipos y de su gente, filtrarlo por fechas, equipo y persona, y descargarlo en un archivo. Y si esa institución está dividida en áreas, quien dirige un área puede consultar el de su área —las conexiones de su gente y las hechas a sus equipos—, con los mismos filtros y nada de las demás áreas.

Las dos mitades, y el equipo personal registrado con la cuenta del trabajo. Ese historial responde a dos preguntas, porque una auditoría hace las dos: quién entró a los equipos de la institución y a dónde entró la gente de la institución. En el segundo caso, si el equipo al que se entró no es de la institución, no se publican su nombre ni su ID de 9 dígitos: la fila conserva que esa persona se conectó, cuándo y cuánto. Y el punto incómodo: un equipo cuenta como equipo de la institución cuando lo registró alguien de ella. Es así como el producto sabe de quién es un equipo —el mismo criterio con el que se cuenta el cupo de computadores que la institución paga—, y significa que un equipo personal registrado con la cuenta que te dio tu universidad o tu empresa aparece en ese historial. Si no quieres eso, regístralo con una cuenta propia.

Ese historial no alcanza más atrás de lo que se conservan las propias sesiones: 90 días (sección 12). Pero los 90 días no son el único límite, y conviene saberlo antes de apoyarse en este registro:

• La baja de una persona ya no borra su pasado. Un equipo cuenta como de la institución si lo registró alguien que pertenece a ella. Al dar de baja a una persona su pertenencia se conserva para auditoría durante el mismo plazo que las sesiones, así que las conexiones ya ocurridas a sus equipos siguen apareciendo, y después se purgan junto con ellas. Esa conservación no le devuelve ningún acceso ni ocupa cupo del plan. El límite: de las bajas ocurridas antes de que esto se pusiera en marcha no existe registro de pertenencia, así que las conexiones de sus equipos no aparecen y no se pueden recuperar.
• Las filas pueden irse antes de los 90 días. Si se borra el equipo o la cuenta, sus sesiones se borran con él en cascada. El dueño de un equipo puede darlo de baja, y cualquiera puede borrar su cuenta, sin que el administrador de la institución pueda impedirlo ni quede una marca de que ocurrió.
• Y alcanza hacia atrás más de lo que se espera. No hay fecha mínima: cuando una cuenta que ya usaba RemoteHub entra en una institución, las sesiones que ya estaban guardadas —hasta 90 días— pasan a verse en ese historial. El consejo de registrar tu equipo personal con una cuenta propia no cubre este camino, porque aquí lo que entra es la cuenta.
• Y una sesión colgada no se purga a los 90 días. La purga automática se lleva las sesiones terminadas o rechazadas. Una sesión que se quedó a medias sin cerrarse —por ejemplo si el servidor se reinicia entre la petición y la aceptación— no entra en esa purga y puede seguir apareciendo pasado el plazo. No lo presentamos como una decisión: es un hueco del producto, y decirlo es preferible a afirmar un borrado que no ocurre.

Lo que sí podemos afirmar sin matices: no guardamos una copia paralela de este historial. Lo que se borra de esa tabla no lo tenemos en otro sitio. Una institución que necesite conservar el registro de accesos por más tiempo —o protegerse de las tres vías de arriba— tiene que descargarlo periódicamente y custodiarlo ella; desde ese momento es Responsable de esa copia.

Ojo con no confundirlo con el registro de auditoría (sección 3.5): ese es otro registro y cubre todo el sistema. Una institución no accede a él completo —eso es solo del administrador de plataforma de RemoteHub—, pero sí puede consultar la parte que le corresponde: los hechos de su propia empresa, sus equipos, sus salas y su gente.

El perfil de auditor de una institución

Las instituciones pidieron poder designar a alguien para auditar el uso del servicio sin participar en su administración. Ese es el perfil de auditor, y solo lo puede conceder la cuenta titular del plan.

Al auditor no se le muestra la actividad de las conexiones anteriores a esta versión del aviso. El aviso de supervisión que cada persona lee y acepta antes de conectarse enumera quién verá lo registrado, y hasta ahora nombraba al propietario del equipo y a los administradores de su organización, no a un auditor. Por eso, de las conexiones autorizadas bajo un aviso anterior el auditor ve el expediente —quién, cuándo, qué equipo, cuánto duró, con qué método de autorización y los acuses— pero no la actividad registrada: ni las aplicaciones, ni los títulos de ventana, ni las direcciones web. No se corrige cambiando el texto hacia atrás. Si aceptaste el aviso anterior, tu actividad de entonces se conserva con las mismas reglas de siempre y no se le abre a este perfil.

Registros técnicos en tu propio equipo

El programa instalado escribe tres archivos de diagnóstico en el equipo para poder averiguar por qué el teclado y el ratón no llegan a la pantalla de bloqueo. No contienen imágenes ni teclas: solo contadores, nombres de escritorio y códigos de error de Windows. Uno de ellos incluye el nombre de usuario de Windows y, hoy, no rota ni se limita en tamaño. No se suben a ningún servidor: son locales.

Es la parte más sensible del producto y por eso tiene sección propia. Existe una página pública dedicada, que reproduce palabra por palabra el mismo aviso que muestra la aplicación de escritorio en el equipo supervisado: aviso de supervisión, versión 6. La licencia que se acepta al instalar no lo reproduce entero: lleva un resumen más corto que remite a esa página —no incluye el número de versión del aviso ni el plazo de borrado, y nombra las direcciones web y el inventario de aplicaciones sin explicar que esas dos necesitan la aceptación de la persona—.

Está apagado por defecto, y lo enciende el dueño del equipo o su institución

RemoteHub no enciende la supervisión de nadie. La activa el dueño del equipo o el dueño o administrador de la organización, equipo por equipo, o bien con una política de empresa que la deja activa en todos sus equipos presentes y futuros. Cada encendido y cada cambio de configuración quedan registrados en auditoría.

Qué se enciende con ese interruptor, exactamente. El interruptor de la institución no enciende ningún registro por sí solo: lo que hace es que, cuando alguien se conecte en remoto a ese equipo y acepte el aviso, durante esa sesión se registren cuatro cosas: el programa en primer plano, el título de la ventana, el nombre de usuario de Windows con el que se está usando el equipo y el tiempo de uso e inactividad. Fuera de esa sesión no se registra ninguna de las cuatro. Y siguen apagados, con un interruptor propio cada uno, los comandos de PowerShell, las direcciones web y el inventario de aplicaciones abiertas.

De esas cuatro, el nombre de usuario de Windows no tiene interruptor propio en la configuración: viene con el resto o no viene nada. En una sala de informática suele ser una cuenta compartida y no identifica a nadie en particular; quien queda identificado sin ambigüedad es quien se conectó, por su cuenta de RemoteHub, que es la misma con la que aceptó el aviso.

Sobre esos dos últimos, con precisión, porque la redacción anterior se prestaba a entenderlo al revés: cuando la institución los enciende expresamente, quedan encendidos hasta que ella los apague. Lo que ocurre es que, si una configuración guardada no dice nada sobre ellos, se resuelven como apagados en vez de heredar ningún valor por defecto nuestro: así, un cambio en el producto no puede encenderlos en silencio en equipos que ya estaban supervisados.

En palabras simplesDentro de la sesión, la supervisión no empieza por lo mínimo: el título de la ventana entra desde el primer segundo de la conexión y es el más revelador de los cuatro. Fuera de la sesión, en cambio, no entra nada en absoluto. Y lo que no entra sin una decisión adicional de la institución son las páginas que se abren, el inventario de aplicaciones y los comandos.

Qué se registra durante una sesión consentida

Ahora la última columna dice «Sí» en todas las filas, y eso es nuevo. Hasta la versión anterior de este documento la compuerta de consentimiento solo cubría las direcciones web y el inventario de aplicaciones: el título de la ventana, el nombre del programa, el tiempo de uso y el usuario de Windows se registraban en cuanto la institución encendía la supervisión, sin que nadie aceptara nada. Por eso aquí decía, con todas las letras, que no podíamos afirmar «no registramos nada sin tu consentimiento». Ahora sí podemos: no hay ninguna categoría que se registre fuera de una sesión, y no hay sesión sin que quien se conecta haya aceptado el aviso. Lo que aceptar no hace es encender nada: las direcciones, el inventario y los comandos siguen necesitando además que la institución los active.

Qué NO se registra, verificado en el código

• Nunca la parte de la dirección después de «?» o de «#». No es un filtro que pueda fallar: esos trozos de la dirección directamente no se leen. La ruta se recorta siempre a dos tramos y los que parecen un secreto se sustituyen por la palabra «oculto».
• No se lee tu historial del navegador, no se instalan extensiones, no se inyecta nada en las páginas y no se lee la memoria de otros programas. La dirección se lee de la barra de direcciones, en una lista cerrada de 13 navegadores.
• No hay captura de teclas. El tipo de evento «teclas» ni siquiera existe en el formato de datos.
• No hay grabación de pantalla, cámara ni micrófono en este módulo.
• El dueño puede excluir hasta 50 sitios web: en esos, la dirección se descarta entera. Hay además una lista base de sitios delicados en los que solo se guarda el dominio.
• El contenido del portapapeles no se guarda, en ningún sitio ni en ninguna forma —tampoco una huella ni un resumen suyo—. Sí cruza entre los dos equipos mientras dura la sesión, que es la única excepción a esta lista y está explicada justo debajo.

El portapapeles durante una sesión, y por qué es la única excepción

Para poder copiar en un equipo y pegar en el otro, el portapapeles se comparte en los dos sentidos mientras dura la sesión remota: lo que copia quien se conectó puede pegarse en el equipo, y lo que se copia en el equipo puede llegar a la máquina de quien se conectó —aunque lo haya copiado otra persona que estuviera sentada delante—. Sólo texto: ni imágenes ni archivos.

Ese contenido no se guarda en ningún sitio: se retransmite en el momento y se olvida. Ni en el registro de actividad, ni en la auditoría, ni en un archivo, ni en un mensaje de error, ni en una traza de diagnóstico. Tampoco su huella: la huella de una contraseña sigue sirviendo para adivinarla. De una transferencia queda, como mucho, el hecho —cuándo, en qué sentido y cuántos caracteres— y ni una letra de lo que iba dentro.

El sentido equipo → persona conectada sólo funciona si la sesión se autorizó con un aviso que lo nombraba. No es una promesa de buena voluntad: el producto compara la versión exacta del texto que se aceptó, y si esa versión está vacía, es anterior o no se reconoce, no se envía nada. Un equipo sin supervisión activada no muestra ningún aviso y por tanto no tiene versión que comparar, así que en esos equipos ese sentido no funciona nunca. Fuera de la sesión el portapapeles no se toca, y lo copiado antes de que empezara no se va a buscar.

Nunca hay supervisión invisible

El equipo no captura absolutamente nada si la insignia de supervisión no está visible. Si el programa falla al mostrarla, la captura se queda apagada. La insignia se puede mover, pero no cerrar, se reafirma por encima de las demás ventanas, lleva un cronómetro, resume qué se está registrando y tiene un botón a la página pública.

La invariante no se ha relajado, se ha estrechado: insignia y registro siguen empezando y terminando exactamente a la vez, y ahora las dos cosas ocurren solo dentro de la sesión. El cronómetro, por eso, mide justo lo que se espera que mida: lo que lleva la conexión.

Límites que asumimos: la insignia puede quedar tapada por una aplicación a pantalla completa exclusiva. La etiqueta de «ventana de incógnito» se deduce del título de la ventana y puede fallar; en incógnito las direcciones se registran igual.

El aviso y su acuse

Antes de que la conexión se establezca, el servidor le muestra a quien se está conectando el aviso completo y espera su decisión. El texto lo pone el servidor, no el programa de esa persona: si lo pusiera el cliente, el acuse acreditaría lo que el cliente quisiera. El acuse se guarda como prueba con la versión exacta del texto que se mostró, si se aceptó o no, la fecha, la cuenta de RemoteHub que decidió, la sesión concreta, la vía de acceso por la que entró (reserva, contraseña del equipo, PIN o petición al dueño) y el alcance que estaba configurado en ese momento.

La prueba se escribe antes de dar luz verde. Si no se puede guardar, la sesión no continúa: preferimos un reintento a una sesión que parece consentida y no lo está.

Si no aceptas, la conexión se cierra y no se registra ninguna actividad tuya —el equipo ni llega a enterarse de que alguien lo intentaba—. Queda constancia únicamente de que se te mostró el aviso y de que no lo aceptaste, que es lo que permite acreditar que se respetó tu negativa. No responder dentro del plazo tiene el mismo efecto, pero se registra aparte: el silencio no es un rechazo.

En el equipo hay además una ventana informativa dirigida a quien esté físicamente delante de él, con los mismos hechos. Ésa no pide permiso —no es quien decide— y sirve para que esa persona sepa que su actividad puede quedar en el registro de la sesión de otra. Si el programa instalado no sabe mostrar la versión vigente del texto, no se guarda ningún acuse: preferimos no acreditar nada antes que fabricar la prueba de un texto que nunca se enseñó.

Quién ve estos datos

El dueño del equipo; si el equipo pertenece a una organización, el titular del plan y sus administradores; la persona a la que esa organización haya dado el perfil de auditor; y, si esa organización está dividida en áreas, quien dirige el área que corresponda —y quien la sustituye cuando falta—. Los dos últimos, con la restricción de los dos párrafos siguientes. Nadie más: cualquier otra cuenta recibe un rechazo del servidor, no una vista recortada.

Qué alcanza quien dirige un área y qué no. Ve únicamente lo de su propia área, y por dos caminos: las conexiones que hacen las personas de su área, y las conexiones que cualquiera hace a los equipos de su área —tanto los que están asignados a ella como los que esa área instaló, aunque hoy estén en otro sitio—. De las demás áreas no ve nada, y no puede modificar ni borrar nada de lo registrado. Si alguien de un área se conecta a un equipo de otra, esa conexión la ven los dos jefes: cada uno esa conexión, y no el resto de lo que ocurre en el área ajena.

Ni al auditor ni a quien dirige un área se le muestra la actividad de las conexiones autorizadas bajo un aviso que todavía no lo nombraba, y cada uno tiene su propia lista. El aviso que cada persona lee y acepta antes de conectarse enumera quién verá lo registrado. El perfil de auditor se añadió a esa enumeración en una versión de ese aviso, y el jefe de área en otra posterior; las dos listas se llevan por separado a propósito, de modo que un aviso que nombraba al auditor y todavía no al jefe de área no le abre nada a este último. De las conexiones anteriores a la versión que lo nombra, cada uno ve el expediente —quién, cuándo, qué equipo, cuánto duró, con qué autorización— y no la actividad. No es una tabla vacía: la pantalla dice el motivo. Y no se corrige reescribiendo hacia atrás un texto ya aceptado: a esas personas se les dijo quién lo vería, y el servidor lo hace cumplir.

Y la actividad de un equipo que no es de la institución no se le muestra a esa institución. Cuando alguien de una organización se conecta a un equipo ajeno, ese acceso aparece en su historial —es su propia gente— pero la actividad registrada en la máquina es un dato del equipo y de quien lo tenga delante, no de quien se conectó: no se publica ni en pantalla ni en los archivos, ni al auditor ni al administrador ni al titular del plan. Tampoco el nombre de ese equipo. Quien puede consultarla es su propietario, o quien administre la empresa del propietario.

La persona supervisada no tiene acceso a sus propios datos dentro del producto. La actividad se indexa por nombre de usuario de Windows y, normalmente, la persona supervisada ni siquiera tiene cuenta de RemoteHub. La descarga de datos de la sección 16 no incluye la actividad supervisada. Para conocer, corregir o pedir el borrado de esos datos: si el equipo es de una universidad o de una empresa, hay que dirigirse a esa organización, que es quien decidió capturarlos; nosotros la asistimos y ejecutamos lo que ella instruya. Si el equipo es de una cuenta particular y no hay ninguna organización detrás, el Responsable somos nosotros: escribe a administrador@remotehubtech.com y lo tramitamos por el procedimiento de la sección 14, sin reenviarte a nadie.

Cada línea de esta lista se comprobó en el código antes de escribirla. Son afirmaciones negativas verificables, no promesas de marketing.

• No grabamos la pantalla. No hay vídeo, ni capturas guardadas, ni miniaturas.
• No registramos lo que tecleas. No existe ningún captador de teclado en ninguna parte del producto.
• No capturamos audio ni activamos el micrófono.
• No usamos la cámara ni hacemos reconocimiento facial, ni ningún tipo de dato biométrico.
• No guardamos la dirección IP exacta en la base de datos: siempre truncada a su red.
• No guardamos la dirección IP de los equipos remotos.
• No hacemos huella de hardware: ni número de serie, ni procesador, ni registro de Windows.
• No guardamos la dirección física (MAC) de ningún equipo: no existe esa columna en ninguna tabla. Si se activa el encendido a distancia, esa dirección se queda en la red local del equipo y no llega a nosotros.
• No guardamos datos de tarjeta, ni cifrados, ni tokenizados, ni truncados.
• No pedimos NIT, cédula, dirección fiscal ni cuenta bancaria de la institución.
• No tenemos analítica ni telemetría en la web: ni Google Analytics, ni Meta, ni ninguna herramienta de seguimiento. Ninguna.
• No cargamos tipografías desde servidores de Google en tiempo de ejecución: van dentro de nuestra propia web.
• No enviamos correos: no hay proveedor de correo transaccional en el sistema.
• Si entras con Google o Microsoft, no vemos tu contraseña de allí ni guardamos las credenciales de acceso que esos proveedores emiten: las recibimos al final del inicio de sesión, comprobamos la que acredita quién eres y las descartamos en el acto. Y no pedimos permiso para leer tu correo, tus contactos ni tus archivos de allí.
• No guardamos en la nube el contenido de los archivos que se transfieren.
• No vendemos, alquilamos ni cedemos datos personales a terceros, y no los usamos para entrenar modelos de inteligencia artificial.

El artículo 5 de la Ley 1581 de 2012 define como sensibles los datos que afectan la intimidad del Titular o cuyo uso indebido puede generar discriminación, y da una lista enunciativa: origen racial o étnico, orientación política, convicciones religiosas o filosóficas, pertenencia a sindicatos y organizaciones, salud, vida sexual y datos biométricos.

RemoteHub no pide, ni necesita, ni tiene ningún campo para ninguna de esas categorías. No hay datos de salud, ni biométricos, ni de origen étnico, ni de afiliación, ni políticos, ni religiosos.

Ahora la parte honesta: una pantalla y un historial de dominios pueden contener incidentalmente información de esa naturaleza. Si en el equipo se abre la web de un hospital, la de un partido o la de una iglesia, ese dominio puede quedar registrado cuando la supervisión de direcciones web está activa. Por eso tratamos esa información con el cuidado propio de un dato sensible, aunque no la recojamos deliberadamente, y por eso el producto está construido para minimizarla: dominios sin la parte identificable de la dirección, lista de exclusión del dueño y lista base de sitios delicados en los que solo se conserva el dominio.

Cuando un tratamiento pueda alcanzar datos sensibles, aplican tres reglas del artículo 2.2.2.25.2.3 del Decreto 1074 de 2015 que queremos dejar escritas:

• No estás obligado a autorizarlo. Tratándose de datos sensibles, tu respuesta es facultativa.
• Te tenemos que decir cuáles son y para qué. Eso es la sección 6 y el aviso que muestra el equipo antes de capturar.
• Ninguna actividad puede condicionarse a que entregues datos sensibles. Es la regla que este producto tiene más difícil, y está tratada aparte justo debajo: bajo el modelo por sesión, no aceptar el aviso significa no conectarse a ese equipo.

Dónde aprieta esta tercera regla, y hay que decirlo. Hasta la versión anterior de este documento aquí se confesaba lo contrario: que la captura base —incluido el título de la ventana— se encendía con la supervisión y no se podía rechazar, de modo que usar el equipo sí obligaba a entregarla. Eso se ha corregido: hoy no se registra nada sin que quien se conecta acepte.

A cambio aparece la tensión contraria, que es más visible. Si no aceptas el aviso, no te conectas a ese equipo. O sea que usar el equipo sí queda condicionado a autorizar un registro que puede alcanzar datos sensibles, y eso es precisamente lo que la regla mira con lupa. Por qué entendemos que se sostiene, dicho sin adornos para que puedas discutirlo:

• El equipo no es tuyo. La supervisión la activa el propietario sobre una máquina suya, y lo que se condiciona no es un servicio esencial ni un derecho, sino el acceso remoto a un recurso ajeno. La regla protege frente a quien te exige datos para darte algo a lo que ya tienes derecho; aquí no hay tal derecho previo.
• La alternativa existe y no cuesta nada. No aceptar te deja exactamente donde estabas: sin conexión y sin un solo dato registrado. No se te penaliza, no se te retiene nada y no queda constancia de más que del hecho de que se te preguntó y dijiste que no.
• Lo que se pide es mucho menos que antes. El registro se acota a lo que ocurre durante tu sesión: fuera de ella no se recoge nada, ni tuyo ni de nadie. La versión anterior recogía todo el día y sin preguntar.

Aun así, esta es una valoración nuestra y no una calificación de la autoridad: si el título de la ventana llegara a considerarse dato sensible —esta política no lo afirma, pero tampoco lo descarta, porque es el dato más revelador del módulo— la discusión seguiría viva. Lo que puedes hacer hoy: no aceptar (y no conectarte), pedirle a la institución que apague la supervisión de ese equipo, y ejercer tus derechos de la sección 13 sobre lo que ya se haya registrado.

El artículo 7 de la Ley 1581 de 2012 y el artículo 2.2.2.25.2.9 del Decreto 1074 de 2015 someten el tratamiento de datos de menores a requisitos reforzados: que responda a su interés superior, que se respeten sus derechos fundamentales y que autorice su representante legal, previo ejercicio del derecho del menor a ser escuchado.

RemoteHub no tiene hoy implementado ese flujo: no existe recolección de autorización del acudiente, ni constancia de que se escuchó al menor, ni distinción alguna por edad en el registro. Por eso, y para no prometer un procedimiento que el producto no tiene, el servicio está dirigido a personas mayores de edad, y las instituciones cliente no deben desplegarlo sobre equipos usados por menores de 18 años hasta que ese flujo exista.

Si detectamos que hemos recogido datos de un menor sin la autorización de su representante, los suprimimos. Si crees que es tu caso, escríbenos a administrador@remotehubtech.com.

La web de RemoteHub usa dos cookies de sesión, ambas estrictamente necesarias: una que mantiene tu sesión iniciada y otra que protege los formularios frente a peticiones falsificadas. Si eliges entrar con Google o Microsoft, se suman otras dos, también estrictamente necesarias, que solo sirven mientras dura ese paso —el paso caduca a los 10 minutos como máximo y, desde entonces, esas cookies ya no sirven para nada aunque tu navegador tarde un poco más en borrarlas—: una protege el viaje de ida y vuelta al proveedor contra falsificaciones y la otra señala el paso que quede pendiente. Además guarda cinco claves en el almacenamiento local de tu navegador: tres preferencias de interfaz (el lado del panel de la sesión, el tipo de puntero y si ya viste una pista de uso), tus ajustes de la barra de accesibilidad (tamaño del texto, contraste, espaciado, enlaces subrayados y animaciones; la barra la escribe al cargar la web aunque no la toques, y entonces solo guarda los valores de fábrica) y el registro de tu propia decisión sobre esas preferencias, con la versión del aviso y la fecha, para no volver a preguntártelo y para poder demostrar qué acusaste y cuándo. Y si pausas la animación de la página de inicio de sesión o la actualización en vivo de los paneles, esa pausa se anota en el almacenamiento de la pestaña («sessionStorage»), que se olvida al cerrarla. Ninguna de estas claves lleva tu nombre, tu correo ni un identificador, y ninguna se envía a nuestro servidor.

No hay ni una sola cookie de analítica, de publicidad o de seguimiento, ni de terceros. Por eso no verás un panel de «analítica / marketing / personalización»: fingir una elección que no existe sería tan deshonesto como esconder una que sí. Si algún día añadimos analítica, verás un aviso de verdad, con rechazar tan fácil como aceptar y nada activado de antemano.

Lo que sí puedes desactivar son las tres preferencias de interfaz, porque el servicio funciona sin ellas. El interruptor está aquí: panel de control del almacenamiento. Rechazarlas las borra en el acto y las sigue borrando en cada carga, así que no llegan a tu siguiente visita. Las cookies no aparecen en ese panel porque no admiten alternativa: sin las de sesión no hay sesión, y sin las temporales no se puede entrar con Google o Microsoft de forma segura.

El detalle completo, clave por clave, está en la página de cookies.

Nos apoyamos en proveedores de infraestructura que tratan datos por nuestra cuenta. Todos están constituidos fuera de Colombia, así que todo el tratamiento implica una transferencia internacional, y tienes derecho a saber quién es cada uno y qué toca.

La Circular Externa 005 de 2017 de la SIC incluye a Estados Unidos entre los países con un nivel adecuado de protección. Además, con las instituciones cliente firmamos el contrato de transmisión previsto en el artículo 2.2.2.25.5.2 del Decreto 1074 de 2015, que es la vía legal para estas transmisiones.

Precisión: la región concreta del centro de datos de cada proveedor no está fijada en nuestra configuración; declaramos el país de constitución del proveedor y no inventamos una región que no podamos acreditar.

Google y Microsoft, cuando entras con ellos

No están en la tabla por el inicio de sesión porque, en eso, no tratan datos por nuestra cuenta: son la fuente de la que recibimos tu identificador, tu organización, tu correo y tu nombre cuando eliges sus botones, y lo que ellos hacen con tu cuenta se rige por sus propias políticas. Qué recibimos, qué no y cuánto se guarda está en el apartado 3.7.

Y quién accede desde dentro

A los proveedores de arriba hay que sumar a las personas que pueden mirar los datos desde dentro. Hoy la cuenta de administrador de plataforma la usan dos personas y no hay más: el propio Responsable, Cristian Camilo Escandón García, que presta el servicio a título personal, y el desarrollador que colabora con él. No hay sociedad, ni nómina, ni personal contratado. Esa cuenta puede consultar el registro de auditoría de todo el sistema, ver la lista de correos de las cuentas y abrir la ficha de una institución con su plan y sus equipos; abrir esa ficha deja constancia en el registro de auditoría, con el alcance consultado y el número de registros vistos. Lo que esa cuenta no puede hacer es encender la supervisión de un equipo: el servidor le devuelve error de permiso igual que a cualquier otro.

Un servicio integrado pero apagado

Nuestro sistema tiene integrado un servicio de reporte de errores técnicos (Sentry, Estados Unidos), pero está inactivo: sin la clave de configuración no envía absolutamente nada. No decimos «no lo usamos» porque el código existe; decimos que hoy no envía ni un solo evento. Si algún día lo activamos, actualizaremos esta política antes.

Un proceso automático borra lo vencido todos los días a las 3:00 UTC, que en Colombia son las 10:00 de la noche del día anterior. La hora es la del servidor, no la de Bogotá, y lo decimos con su zona porque una hora sin zona no se puede comprobar. Si el servidor está caído a esa hora, ese día no se purga y se espera al siguiente.

Estas filas sin plazo de purga merecen explicación, no letra pequeña. El rastro de los contratos de licencia se conserva porque un contrato universitario puede durar más de un año y sobreviviría al barrido de 365 días; solo contiene datos comerciales, no correos. El acuse de consentimiento no tiene plazo de purga porque es la prueba de que se informó a la persona, pero sí desaparece al borrar el equipo al que está atado, y con él la prueba de ese consentimiento: es una consecuencia del diseño de la base de datos, no una decisión, y significa que dar de baja un equipo borra también la constancia de que se avisó a quien lo usaba. Está identificado para corregirse. El historial de reservas no tiene hoy plazo de purga y eso es un hueco del producto, no una decisión; solo desaparece cuando se borra el equipo o la cuenta. Preferimos decirlo a prometer un plazo que no se cumple.

Los plazos de 90 y 365 días son los valores vigentes por defecto y pueden ajustarse en la configuración del servidor. Cuando se cumple la finalidad, o cuando lo pides y no existe un deber legal o contractual de conservar, suprimimos el dato.

Son los del artículo 8 de la Ley 1581 de 2012, con el nombre exacto que les da la ley colombiana:

• Conocer, actualizar y rectificar tus datos personales frente a nosotros o frente a la institución que corresponda. Puedes pedir la corrección de datos parciales, inexactos, incompletos, fraccionados o que induzcan a error.
• Solicitar prueba de la autorización que otorgaste, salvo en los casos que la ley exceptúa.
• Ser informado, previa solicitud, del uso que hemos dado a tus datos.
• Presentar quejas ante la Superintendencia de Industria y Comercio por infracciones a la ley.
• Revocar la autorización y solicitar la supresión del dato cuando no se respeten los principios, derechos y garantías legales y constitucionales.
• Acceder de forma gratuita a tus datos personales que hayan sido objeto de tratamiento.

El acceso es gratuito al menos una vez cada mes calendario y cada vez que haya cambios sustanciales en esta política. Por encima de esa frecuencia solo podríamos repercutir gastos reales de envío o reproducción, nunca un cobro por el derecho en sí.

Qué derechos NO existen todavía en Colombia

No te vamos a ofrecer un «derecho al olvido», ni «portabilidad», ni «oposición»: esos derechos no están hoy en la ley colombiana. Figuran en un proyecto de reforma que a la fecha de esta política no es derecho vigente. Escribirlos aquí sería inventar un derecho, y si algún día se aprueban, actualizaremos esta sección.

Quién puede ejercerlos

El propio Titular acreditando su identidad, sus causahabientes acreditando tal calidad, su representante o apoderado, y quien actúe por estipulación a favor de otro. En el caso de menores, quienes estén facultados para representarlos.

En palabras simplesTraducido: puedes ejercerlos tú, demostrando que eres tú. También tus herederos («causahabientes»), demostrando que lo son. También alguien a quien hayas autorizado por escrito —un apoderado, o tu representante legal si eres menor de edad o estás bajo tutela—. Y también, si alguien contrató algo a tu favor y en ese contrato quedó pactado que tú puedes ejercer estos derechos, esa persona designada («estipulación a favor de otro»). En todos los casos hay que acreditar el vínculo: no basta con afirmarlo.

Cuándo la supresión no procede

La supresión no procede cuando exista un deber legal o contractual de permanecer en la base de datos. En la práctica esto afecta sobre todo a los registros de auditoría que una institución cliente necesita conservar por contrato, y al rastro comercial de un contrato de licencia. Cuando no podamos suprimir algo, te diremos exactamente qué y por qué.

El canal

Escribe a administrador@remotehubtech.com. Es el único canal de atención y lo atiende el propio Responsable. Indica:

• Tu nombre completo y un documento que acredite tu identidad (o la de quien representas).
• El correo con el que usas RemoteHub, o el nombre del equipo y la institución si te supervisan sin tener cuenta.
• Qué pides: conocer, actualizar, rectificar, suprimir, revocar la autorización o pedir prueba de ella.
• Los hechos, si se trata de un reclamo, y cualquier documento que quieras aportar.
• La dirección de respuesta.

Los plazos, que son los de la ley

Estos plazos son de ley y los asumimos: al publicarlos quedamos obligados a cumplirlos. Decimos «de forma manual» porque es la verdad —los atiende una persona leyendo un buzón, no un sistema— y porque un trámite manual se puede cumplir perfectamente si se atiende; lo que no se puede es prometer un automatismo que no existe.

Si no te resolvemos

Puedes presentar queja ante la Superintendencia de Industria y Comercio. Es requisito de procedibilidad haber agotado antes el trámite de consulta o reclamo ante nosotros (o ante la institución responsable, según el caso), conforme al artículo 16 de la Ley 1581 de 2012. No es una traba: es el orden que la ley establece y hace que la queja prospere.

Si te supervisan y no tienes cuenta de RemoteHub

Si el equipo es de una universidad o de una empresa, escríbele a esa organización: ella es la Responsable de esos datos y quien decidió capturarlos. Si nos escribes a nosotros, te lo trasladamos, te decimos ante quién debes dirigirte y ejecutamos lo que la institución nos instruya.

Si el equipo es de una cuenta particular y no hay ninguna organización detrás, el Responsable somos nosotros: escribe a administrador@remotehubtech.com y lo tramitamos por este mismo procedimiento y con estos mismos plazos, sin reenviarte a nadie. Para acreditar que la actividad registrada es tuya, dinos con qué cuenta de RemoteHub te conectaste y en qué fechas: es la forma en que la actividad de cada sesión queda atada a una persona. Si además usaste el equipo estando físicamente delante mientras otra persona lo controlaba, dinos también el nombre del equipo y tu usuario de Windows, porque en ese caso tu actividad quedó dentro de la sesión de esa otra persona.

En palabras simplesDebajo hay nombres de algoritmos que no hace falta conocer. Lo que dicen, resumido: tu contraseña no se guarda —se guarda un resultado del que no se puede volver atrás—, el secreto de tu segundo factor sí se guarda cifrado, los códigos de acceso de reserva se guardan transformados con una clave que no está en la base de datos —y los códigos de clase, además, cifrados con una clave que tampoco está en ella, para poder volver a enseñárselos a la aplicación de tu institución—, y el flujo de pantalla y de control viaja cifrado. La consecuencia práctica de todo eso es una sola: quien consiguiera una copia de la base de datos no podría entrar con ella a ninguna cuenta. Justo después está la lista de lo que NO está protegido, que es la parte que conviene leer con más calma.

Medidas que existen de verdad hoy en el producto:

• Contraseñas guardadas con argon2id. Verificación en tiempo constante. Los hashes antiguos se migran solos al algoritmo nuevo en el primer inicio de sesión.
• Segundo factor disponible para todos y obligatorio para los administradores de plataforma. Una institución puede pedírselo a todos sus miembros: al entrar, a quien no lo tenga se le lleva a configurarlo, pero hoy el servidor solo se lo impone a los administradores de plataforma. El secreto se guarda cifrado con AES-256-GCM.
• Los tokens de sesión se guardan solo como huella: un volcado de la base de datos no permite suplantar a nadie. Hay rotación con detección de robo: si aparece un token ya usado, se revoca la familia entera.
• El bloqueo por intentos fallidos se lleva por pareja de cuenta y red, no por cuenta global, para que nadie pueda dejarte fuera a propósito. El mensaje de error no revela si un correo existe.
• El inicio de sesión con Google o Microsoft usa el estándar OpenID Connect con sus protecciones contra la falsificación y el robo del código de vuelta (valores de un solo uso y PKCE), comprueba la firma del documento de identidad («id_token») que emite el proveedor y te identifica por el identificador de tu cuenta allí, nunca solo por el correo. Una cuenta que ya existe nunca se vincula sola: hay que demostrar su contraseña (o, desde Ajustes en una cuenta sin contraseña, volver a pasar por el proveedor con el que ya entras). Y si tienes activada la verificación en dos pasos de RemoteHub, se pide igual.
• Las direcciones IP se truncan a su red antes de tocar la base de datos.
• Los registros del servidor ocultan las cabeceras de autorización, las cookies y las cabeceras de IP reenviada, y el serializador no emite la dirección del cliente. De la dirección web de cada petición se conservan la ruta y los nombres de los parámetros, pero sus valores se sustituyen por «[oculto]» salvo los de una lista cerrada (fechas, paginación, identificadores que genera el propio producto y valores de listas cerradas como estado, alcance o rol). Esa depuración no es total y no lo fingimos: hoy queda en claro la dirección IP dentro del mensaje que se escribe cuando alguien usa una llave de API inválida. Está en la lista de arreglos.
• Los códigos de acceso de reserva se guardan con HMAC-SHA256 y una clave que no vive en la base de datos.
• Los códigos de clase de las reservas de sala se guardan con HMAC-SHA256, para poder buscarlos, y cifrados con AES-256-GCM, para poder volver a mostrárselos a la aplicación que los pidió, con claves que no viven en la base de datos. Nunca se guardan en claro ni entran en la auditoría. Cada lectura queda auditada antes de entregarse, y las respuestas que los llevan piden no guardarse en cachés intermedias.
• El flujo de pantalla y de control va cifrado con los mecanismos obligatorios de WebRTC.
• No se puede degradar ni borrar la última cuenta de administrador: hay un candado transaccional que lo impide.

Y los límites que también hay que decir:

• La contraseña exige 8 caracteres como mínimo, pero no exigimos mayúsculas, números ni símbolos.
• No hay verificación de correo ni recuperación de contraseña, por lo dicho en la sección 3.1.
• Quien obtuviera a la vez una copia de la base de datos y la clave de cifrado del servidor podría descifrar lo que se guarda cifrado: el secreto del segundo factor, el de la contraseña diaria de los equipos y los códigos de clase guardados (de ellos, solo abren algo los de las franjas que todavía no han terminado).
• Si entras con Google o Microsoft, tu cuenta de RemoteHub es tan segura como esa cuenta externa: quien la controle puede entrar como tú, salvo que tengas activada la verificación en dos pasos de RemoteHub.
• Salir de RemoteHub no cierra tu sesión de Google o Microsoft en ese navegador. En un equipo compartido hay que cerrarla también allí; la web te lo recuerda al salir.
• Desactivar o borrar tu cuenta de Google o Microsoft no cierra por sí solo una sesión de RemoteHub ya abierta: esa sesión dura 7 días y se renueva sola mientras se use. Lo que ya no se puede es volver a entrar con ese botón.
• Los archivos de diagnóstico que el programa escribe en tu propio equipo no rotan ni se limitan en tamaño en todos los casos, y uno de ellos se guarda en una carpeta que no está protegida por usuario. No contienen ni imágenes ni teclas.

Incidentes de seguridad

Si se produce una violación de nuestros códigos de seguridad que afecte a datos personales, lo informamos a la Superintendencia de Industria y Comercio conforme al artículo 17 literal n) de la Ley 1581 de 2012, y avisamos a la institución cliente afectada para que pueda cumplir sus propias obligaciones. No fijamos aquí un plazo contractual concreto porque cada contrato de transmisión establece el suyo.

No tenemos contratada ninguna certificación de seguridad externa y no vamos a afirmar lo contrario.

Descargar tus datos

Desde Ajustes puedes descargar en cualquier momento un archivo con tus datos personales. Incluye tu perfil, tus equipos, tus sesiones remotas con su registro de consentimiento, el registro de los archivos transferidos (nombre, tamaño y sentido del envío; no el archivo en sí), los mensajes de chat, los equipos que compartiste y los que te compartieron, tu registro de auditoría —tanto las filas que registraste tú como las que otra persona provocó sobre tu cuenta—, los metadatos de tus sesiones abiertas, tus membresías de grupo y las cuentas de Google o Microsoft vinculadas (proveedor, identificador, organización, correo y fechas). Excluye a propósito todos los secretos: hash de contraseña, secreto de 2FA, códigos de recuperación, huellas de token, secreto del programa instalado y PIN.

Dos precisiones sobre lo anterior, para que nadie descargue el archivo esperando otra cosa. De los archivos transferidos se entrega la ficha del envío y no su contenido, porque el contenido ya no existe: se borra del equipo al terminar la sesión (ver la sección 12). Y de las filas de auditoría en las que tú eres el sujeto de lo que hizo otra persona se entrega el qué y el cuándo, sin el campo de detalle, porque ese detalle puede contener datos de la persona que ejecutó la acción.

Qué NO incluye hoy esa descarga, dicho sin maquillar: el historial de reservas, los eventos del módulo de actividad, los acuses de consentimiento de supervisión y los datos de facturación (plan, importe, fechas). No prometemos «todos tus datos» porque hoy no lo son todos. Y lo que falta no se pide todo en el mismo sitio: los eventos de actividad, el inventario de aplicaciones y los acuses de consentimiento de supervisión los decidió capturar tu organización, así que esos se los pides a ella y nosotros la atendemos como Encargados. El historial de reservas y los datos de tu plan y facturación son nuestros: esos nos los pides a nosotros, al correo de la sección 1, y te los entregamos. Si el equipo supervisado es tuyo y no hay ninguna organización detrás, no hay a quién reenviarte: escríbenos y lo tramitamos nosotros.

Borrar tu cuenta

Puedes borrarla tú mismo desde Ajustes en la aplicación de escritorio de RemoteHub, confirmando con tu contraseña. Hoy esta web no tiene todavía ese botón: si solo usas la web, pídenoslo por correo y lo ejecutamos. Preferimos decírtelo a mandarte a buscar una opción que no vas a encontrar.

Si tu cuenta no tiene contraseña porque la creaste con Google o Microsoft, la aplicación de escritorio no te deja entrar: solo admite correo y contraseña. Tienes dos caminos. Uno: crear una contraseña en Ajustes de la web —«Crear contraseña», que antes te pide confirmar que eres tú volviendo a pasar por Google o Microsoft—, entrar con ella en la aplicación de escritorio y borrar la cuenta desde allí. Otro: escribirnos y lo ejecutamos nosotros. Cuando la cuenta se borra:

• Se anonimizan tus filas de auditoría: se quitan tu identificador, tu IP y el detalle. Queda constancia de que «alguien inició sesión el día X», no de quién.
• Éstas son las excepciones. Las filas de una licencia pactada con tu institución: si alguna vez registraste o modificaste una licencia manual, esas filas concretas quedan igualmente desligadas de ti (sin tu identificador y sin tu IP) pero conservan su detalle comercial —importe, moneda, fecha y capacidad concedida— y no se purgan nunca, porque son el respaldo de un contrato con un tercero. Si tu identificador aparecía dentro de ese detalle, de ahí también sale. Solo las ven los administradores de la plataforma de RemoteHub. Si nunca tocaste una licencia, esto no te afecta.
• Y las filas que dejan constancia de tu cobro: toda anotación del registro que documente tu cobro se queda, y no solo cuando algo salió mal. Se queda una baja que MercadoPago no aceptó, un borrado que se bloqueó por un cobro vivo, un pago pendiente que no conseguimos retirar o una ampliación que MercadoPago rechazó; y se queda igual el curso normal, que es lo más frecuente: cada pago que autorizaste y la cancelación de tu cobro al borrar la cuenta. De ti no queda nada en ellas: tu identificador se borra también de dentro del detalle, con el mismo barrido y da igual quién ejecute el borrado. Lo que se queda son los identificadores del cobro —el de tu suscripción, el del pago en MercadoPago y el de tu institución—, el estado en que la pasarela dejó ese cobro y lo que respondió, y los datos del importe: el que se te cobró, con su plan y su periodicidad, y el que se pretendía cobrar cuando el intento acabó rechazado; y, si era una ampliación de equipos, la capacidad que se pretendía añadir. Eso lo ve un administrador de plataforma de RemoteHub en el registro de auditoría y se borra con la purga normal a los 365 días. Sin esos identificadores no podríamos parar un cobro que siguiera vivo después de tu borrado, que es justo el daño del que te protege. Lo decimos como regla y no como lista a propósito: si mañana añadimos otra anotación de tu cobro, esta frase ya la cubre, y no depende de que alguien se acuerde de venir a apuntarla aquí.
• Se revocan todas tus sesiones abiertas y se invalidan tus accesos vivos.
• Se borra tu cuenta, y en cascada tus equipos, sesiones, chats, transferencias, reservas, suscripción, membresías, las cuentas de Google o Microsoft vinculadas y los acuses de consentimiento de supervisión de esos equipos.
• Antes de borrar nada comprobamos en MercadoPago si tu cobro recurrente sigue vivo y, si lo está, lo damos de baja. Si ya estaba cancelado, no hay nada que hacer y el borrado continúa. Solo si queda un cobro activo que no hemos podido parar —porque la pasarela lo rechaza, o porque no conseguimos hablar con ella— tu cuenta no se borra y te lo decimos: no queremos dejarte pagando algo que crees cancelado. Si es un problema temporal nuestro, reintentar en unos minutos funciona; si no se resuelve, escríbenos y completamos el borrado nosotros. Si tu licencia se contrató por transferencia o factura, no hay cobro recurrente que dar de baja y el contrato se gestiona con nosotros aparte.
• Un pago que hubieras dejado pendiente de autorizar se trata distinto: no frena el borrado, porque un pago sin autorizar no puede impedirte ejercer un derecho con plazos. Intentamos retirarlo igual y, si no lo conseguimos, te lo decimos con su identificador y con lo que sepamos de él: si borraste la cuenta desde la aplicación de escritorio, en un aviso que aparece al terminar, antes de volver a la pantalla de inicio de sesión; si nos lo pediste por correo, en nuestra respuesta a ese correo. Ese aviso te dice una de tres cosas, y no las damos por buenas de más: que seguía sin autorizar (entonces no se te está cobrando y no se te cobrará mientras no hagas nada); que MercadoPago ya lo tenía autorizado por su lado, y entonces puede llegar a cobrarse aunque ya no tengas ningún plan; o que MercadoPago nos respondió algo que no sabemos interpretar, y entonces no lo damos por retirado ni por inofensivo. En los tres casos: no lo autorices desde la pestaña o el correo que dejaras abiertos, y escríbenos con ese identificador —lo comprobamos y lo cancelamos nosotros—. Si lo autorizas tú, te lo cobrarán sin que tengas ya plan ni cuenta.
• Cuando la baja se confirma, el borrado es inmediato e irreversible.

Advertencia importante si eres dueño de una organización. Borrar tu cuenta borra la institución entera, con todas sus salas, sus llaves de API y sus membresías, y con ello la actividad registrada de todas las personas supervisadas en esos equipos. Hoy no existe ninguna comprobación que te avise antes ni que lo impida. Si eres dueño de una organización con más gente, escríbenos antes de borrarte.

Da igual quién ejecute el borrado —tú desde la aplicación, o nosotros a partir de tu solicitud por correo—: los registros de auditoría se limpian igual en los dos casos, con las excepciones descritas arriba.

Esta política entra en vigencia el 14 de octubre de 2026 y sustituye a cualquier versión anterior. Las bases de datos descritas se mantienen vigentes mientras RemoteHub preste el servicio; los plazos de conservación de cada categoría de dato son los de la sección 12.

Qué cambia en esta versión (2026-10-14): se añade el inicio de sesión con Google o Microsoft. Está explicado qué datos recibimos de ellos y cuáles no, y cómo nos das la autorización (apartado 3.7), las dos cookies temporales de ese paso (sección 10), cuánto se conserva cada cosa (sección 12), sus medidas y sus límites de seguridad (sección 15) y cómo se borra una cuenta que no tiene contraseña (sección 16). Además se completa el inventario de lo que la web guarda en tu navegador (sección 10), al que le faltaban tus ajustes de accesibilidad y las pausas de animación. Y en la sección 11 se corrigen los proveedores donde corren el servidor y la base de datos (Amazon Web Services y Supabase, los dos en Oregón, Estados Unidos) y se aclara que las sesiones que abres desde la web pasan siempre por el servidor de retransmisión. No cambia la finalidad de ningún dato que ya tratábamos: solo afecta a quien elige usar uno de esos botones, y para quien sigue entrando con correo y contraseña todo sigue igual. Y se describen las reservas de salas completas que la aplicación de una institución puede hacer para una clase, con el código de clase con el que entran sus participantes: qué guardamos (apartado 3.4), qué se registra (apartado 3.5), quién autoriza ese acceso (secciones 2 y 5), cuánto se conserva (sección 12) y cómo se protege el código (sección 15). Solo te afecta si tu institución las usa. Y se corrige lo que decíamos del segundo factor que una institución pide a sus miembros: al entrar se te lleva a configurarlo, pero hoy el servidor solo se lo impone a los administradores de plataforma (sección 15).

Si hacemos cambios sustanciales, te los comunicamos antes de implementarlos. Y si el cambio afecta a la finalidad del tratamiento, pediremos una nueva autorización: no daremos por hecho que sigues de acuerdo porque no digas nada. El silencio no es consentimiento, y así lo exige el artículo 2.2.2.25.2.4 del Decreto 1074 de 2015.

Para la supervisión de actividad, ese mecanismo ya está construido y es más fuerte que antes: el aviso tiene número de versión y no se captura absolutamente nada —ya no solo las direcciones web y el inventario— hasta que quien se conecta acepta la versión vigente del texto. La comparación de versiones es exacta: un acuse de una versión anterior no autoriza nada bajo la actual.

Es exactamente lo que acaba de ocurrir. El aviso pasó a su versión 3 porque cambió el modelo, no porque se añadieran categorías: antes se registraba todo el día mientras la supervisión estuviera activa y el aviso lo aceptaba quien estuviera delante del equipo; ahora solo se registra durante una conexión y lo acepta quien se conecta. Los acuses anteriores siguen guardados —son la prueba de lo que se autorizó en su momento— pero ninguno de ellos autoriza ya nada: hace falta aceptar el texto nuevo.