Anexo de tratamiento de datos para instituciones

Conforme a la Ley Estatutaria 1581 de 2012 y al Decreto 1074 de 2015 (que compila el Decreto 1377 de 2013), la institución actúa como Responsable del Tratamiento, por ser quien decide sobre la base de datos y sobre las finalidades y medios del tratamiento; RemoteHub actúa como Encargado del Tratamiento, por realizar el tratamiento por cuenta del Responsable. No hay sociedad constituida: RemoteHub lo presta una persona natural —la cláusula 12 la identifica—. Si el plural («nosotros») aparece en el texto es por comodidad de lectura: no describe ninguna estructura societaria.

Esto no es una etiqueta: en el producto, encender la supervisión es una acción que solo puede ejecutar el dueño del equipo o el dueño o administrador del plan de su institución. El servidor lo comprueba en cada llamada y devuelve un error de permiso a cualquier otro, incluida por esa vía la cuenta de administrador de plataforma de RemoteHub. Hay dos palancas y las dos son de la institución: una por equipo y otra de empresa — monitorAllDevices, «siempre activa en todos mis equipos, presentes y futuros» — que manda sobre la individual.

Respecto de sus propios datos — la cuenta con la que el personal de la institución entra a la web, incluida su vinculación con Google o Microsoft cuando entra así, la facturación y nuestros registros de auditoría de plataforma — RemoteHub es Responsable. La ley prevé expresamente que ambas calidades concurran en la misma persona y exige cumplir los deberes de cada una (Ley 1581, art. 18, parágrafo).

Estas son las categorías reales, no una lista genérica:

• Cuentas (de estos datos RemoteHub es Responsable, cláusula 1; se listan aquí para que el inventario de la institución quede completo). Correo, nombre, rol y, si la cuenta tiene contraseña, la contraseña guardada solo como hash (argon2id). Nadie, tampoco nosotros, puede leer una contraseña. Una cuenta creada entrando con Google o Microsoft no tiene contraseña hasta que la persona la crea. Si alguien entra con Google o Microsoft se guarda además la vinculación: el proveedor, el identificador de su cuenta allí (en Microsoft, el de su organización y el suyo dentro de ella), la organización o el dominio si vienen, el correo que dio el proveedor al vincular y las fechas de vinculación y de último uso. Solo se piden los permisos «openid», «email» y «profile», y no se guarda ninguna credencial de acceso del proveedor. De la cuenta, incluida esa vinculación, RemoteHub es Responsable.
• Sesión de control remoto. La imagen de la pantalla viaja en vivo y no se guarda. De la sesión sí quedan metadatos: identificador, equipo, operador, inicio, fin, duración, calidad de conexión, dirección IP del operador reducida a su red, y el registro de quién autorizó, cuándo, por qué método y con qué permisos.
• Chat y archivos de la sesión. Los mensajes de chat sí se guardan en texto en la base de datos. De los archivos solo se guarda nombre, tamaño, dirección y resultado: el contenido viaja cifrado de un equipo al otro, no pasa por nuestros servidores y no se guarda en ningún servidor. En las sesiones abiertas desde la web, ese tráfico cifrado pasa por el relevo de Cloudflare, que no puede descifrarlo (cláusula 8).
• Actividad supervisada, cuando la institución la enciende y únicamente mientras dura una conexión de control remoto que quien se conectó aceptó: programa en primer plano, título de la ventana, tiempo activo e inactivo, nombre de usuario de Windows, dirección del sitio web abierto (dominio y ruta recortada), inventario de aplicaciones abiertas y, si la institución lo activa y su política de Windows lo audita, comandos de PowerShell. Fuera de una conexión no se captura ninguna de estas categorías, y cada tramo registrado queda atado al identificador de la sesión durante la que se capturó. En un Mac se registran las mismas categorías salvo los comandos, que en macOS no se registran; y donde este anexo dice «usuario de Windows», en un Mac se entiende la cuenta de macOS, que es lo que lleva esa columna en las descargas.
• Decisiones sobre el aviso de supervisión. Por cada conexión a un equipo supervisado se guarda quién decidió (la cuenta de RemoteHub de quien se conectaba), sobre qué sesión, qué versión del texto se mostró, la vía de acceso que usó, qué alcance exacto estaba configurado en ese momento y si aceptó, si rechazó o si dejó vencer el plazo. La negativa se guarda igual que la aceptación: es la prueba de que se respetó.
• Reservas de salas. Quién reservó, qué equipo, la franja horaria, un motivo de texto libre opcional y los códigos de acceso, guardados como huella criptográfica y nunca en claro. Si la aplicación de la institución reserva salas completas por API, además: la sala, el profesor a cuyo nombre se reservó, la llave 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, guardado como huella y, además, cifrado —nunca en claro— para poder volver a mostrárselo a esa aplicación. De cada entrada con el código queda quién entró, en qué equipo y en qué sesión.
• Registros de auditoría. Qué pasó, quién lo hizo y cuándo: accesos —también la vinculación y la desvinculación de cuentas de Google o Microsoft, y los intentos fallidos de entrar con ellas, que se anotan sin correo y sin el identificador del proveedor—, inicios de sesión remota, cambios de permisos, encendido y apagado de la supervisión, reservas y llaves de API. De las reservas de sala por API se registran su creación y su cancelación, la emisión, cada lectura y cada reemisión del código de clase y cada entrada con él, con la persona que entró; ni el código, ni su huella, ni su cifrado entran en esas filas.
• Encendido a distancia, solo en los equipos donde se active, uno por uno (nace desactivado). La dirección física (MAC) del equipo se comunica a los otros equipos de RemoteHub de su misma red local, que la guardan en su propio disco para poder despertarlo. Esa dirección no viaja por internet ni llega a nuestros servidores.

El detalle completo de la supervisión, con la misma redacción que ve quien se conecta en el momento de aceptar, está en la página pública de supervisión.

Estas no son promesas de folleto: son cosas que el producto no tiene. Si algún día alguna cambia, cambia este anexo antes.

• No grabamos la pantalla. No hay grabación, ni capturas guardadas, ni miniaturas. El único destino del vídeo es la conexión en vivo con el operador; no existe salida a archivo ni tabla donde guardarlo.
• No registramos lo que la persona teclea. No hay ningún tipo de dato «teclas» en el sistema. Las pulsaciones que envía el operador se ejecutan en el equipo y se descartan; de ellas solo quedan contadores agregados en los registros técnicos del propio equipo.
• No capturamos audio ni micrófono. Todos los capturadores de vídeo del producto —los de Windows y los de Mac— van con el audio desactivado y no existe ninguna captura de micrófono en el producto.
• Nunca guardamos la parte secreta de una dirección web. Ni lo que va después de «?» ni después de «#» — donde viven los enlaces mágicos y los restablecimientos de contraseña. No es un filtro que se pueda fallar: esos trozos no se llegan a leer. La ruta se recorta a dos tramos y los que parecen un secreto se sustituyen por «oculto».
• No usamos los datos de la institución para fines propios. Nos obligamos a no emplearlos para analítica de producto, elaboración de perfiles, entrenamiento de modelos, publicidad, venta ni cesión a terceros distintos de los subencargados de la cláusula 8. La web pública, además, no lleva ni una herramienta de analítica ni de seguimiento.
• No guardamos los archivos en la nube. No hay ningún almacenamiento de archivos: el contenido viaja cifrado de un equipo al otro sin guardarse en ningún servidor. En las sesiones abiertas desde la web pasa, cifrado, por el relevo de Cloudflare (cláusula 8).

RemoteHub trata los datos únicamente para prestar el servicio contratado, mantenerlo, protegerlo frente a abuso y atender el soporte que la institución pida, y siempre conforme a las instrucciones de la institución. Cualquier finalidad nueva requiere su instrucción previa por escrito.

RemoteHub se obliga a dar aplicación a las obligaciones de la institución bajo la política de tratamiento de la información que ella haya fijado y le entregue, y a tratar los datos solo para las finalidades que los titulares hayan autorizado y conforme a las leyes aplicables (art. 2.2.2.25.5.2 del Decreto 1074 de 2015).

Es la cláusula más importante del anexo. La autorización del titular debe ser previa, expresa e informada (Ley 1581, arts. 4 y 9). Puede manifestarse por escrito, de forma oral o mediante conductas inequívocas, y el Decreto 1377, art. 7, es literal: «en ningún caso el silencio podrá asimilarse a una conducta inequívoca». Además, el Responsable «deberá conservar prueba de la autorización otorgada» (art. 8).

Al firmar, la institución declara y garantiza que, antes de encender la supervisión:

• Informó de forma previa y clara a las personas afectadas — estudiantes, docentes o trabajadores — sobre qué se registra, para qué, quién lo consulta y qué derechos tienen.
• Obtuvo su autorización cuando corresponde y conserva la prueba, disponible si la autoridad la pide.
• Documentó por qué la medida es necesaria y proporcionada, y por qué no bastaba una alternativa menos invasiva. La Sentencia T-170 de 2025 encontró vulnerados el habeas data y la intimidad por una vigilancia en aulas, entre otras razones porque no se evaluaron alternativas menos invasivas.
• No usará el producto para vigilancia oculta, ni en espacios de intimidad, ni en equipos personales de la persona sin su autorización específica.
• No desactivará ni ocultará el indicador que aparece durante la sesión, ni el aviso que se le muestra a quien se conecta antes de entrar, ni el aviso informativo de la aplicación de escritorio.

Qué aporta RemoteHub como apoyo

El producto trae mecanismos que ayudan a cumplir eso y dejan prueba. Son apoyo, no sustituto:

• Sin aceptación no hay captura, y sin captura no hay conexión. Antes de que el equipo supervisado se entere de que alguien quiere entrar, el servidor le muestra el aviso a quien se está conectando. Si acepta, la conexión sigue y se registra lo que el aviso describe. Si rechaza o deja vencer el plazo, la conexión se cierra y no se registra ninguna actividad suya. El servidor vuelve a comprobarlo por su cuenta sobre cada tramo que le llega del equipo y descarta lo que no pertenezca a una sesión con acuse vigente: no se fía del cliente.
• Indicador mientras se captura. Mientras se está registrando, el equipo muestra en pantalla una insignia que no se puede cerrar, con cronómetro, resumen de qué se registra y un enlace a la página pública. Aparece y desaparece a la vez que el registro —lo decide la misma comprobación—, así que si la insignia no está, no se está capturando nada. Si el indicador no se puede mostrar, la captura no arranca. Y cuando el sistema tapa la pantalla —en Windows, un aviso de permisos del sistema o la pantalla de bloqueo; en un Mac, la pantalla dormida— la insignia se esconde y la captura se pausa con ella: las dos vuelven juntas al destaparse. En un Mac, si la pantalla se bloquea o pasa a primer plano otra cuenta, la conexión remota se cierra. Nadie puede ocultar el indicador para seguir registrando, que es la garantía que la institución necesita poder afirmar; lo que no se puede prometer es que el sistema operativo nunca lo tape. En un Mac este comportamiento está construido así, pero nunca se ha visto funcionar en un Mac real.
• Aviso versionado, y una sola fuente. El texto tiene número de versión (hoy la 6) y sale de un único sitio en el código. El aviso que autoriza la captura se le muestra a quien se conecta, en su propio visor —web o aplicación de escritorio—, y ese texto lo envía el servidor ya resuelto: los visores no llevan copia propia, precisamente para que el acuse acredite lo que el servidor mostró y no lo que el programa de esa persona tuviera guardado. La aplicación de escritorio del equipo supervisado muestra otra ventana, con los mismos hechos pero redactada para quien está físicamente delante de esa máquina —a quien no se le pide permiso, porque no es quien decide: se le informa de que su actividad puede quedar en el registro de la sesión de otra persona—. Y la licencia que se acepta al instalar en Windows lleva un resumen más corto que remite a la página pública: no reproduce el número de versión ni el plazo de conservación, así que no sirve por sí sola como prueba de haber mostrado el aviso completo. En un Mac la instalación se hace con una orden en la Terminal y no muestra ni licencia ni resumen, así que allí no hay nada que acepte quien instala. El aviso que ve quien se conecta a un Mac es la misma versión del texto, que conserva frases escritas para Windows; el alcance que lo acompaña sí dice que en macOS no se registran comandos. Cambiar esas frases exige una versión nueva del aviso que todos vuelvan a aceptar, y está pendiente. Cuando se propone o se integra un cambio en la rama principal corre una comprobación automática que avisa si alguna de las dos frases clave —la que anuncia el registro de las direcciones web y la que dice que fuera de una sesión remota no se registra nada— desaparece de la fuente, de la ventana del escritorio de Windows o de ese resumen. Es un aviso, no un freno, y no compara letra por letra. La ventana informativa y la insignia del Mac llevan su propia copia del texto y no entran en esa comprobación.
• Acuse por sesión, por persona y por versión. De cada conexión a un equipo supervisado queda una fila escrita por el servidor, no por el equipo: qué sesión, qué cuenta de RemoteHub decidió, qué versión del texto se mostró, cuándo, por qué vía de acceso entró, qué alcance exacto estaba configurado y si aceptó, rechazó o dejó vencer el plazo. Esa es la fila que acredita la autorización. Existe una segunda clase de fila, indexada por usuario de Windows, que sólo deja constancia de que a quien estaba delante del equipo se le mostró el aviso informativo: esa no autoriza ninguna captura y el producto la rechaza si alguien intenta usarla como tal. Si el servidor no reconoce la versión, rechaza el acuse: no queremos fabricar una prueba de un texto que nunca se mostró.
• Dos llaves distintas, y hacen falta las dos. El acuse de quien se conecta abre la captura; lo que se captura dentro lo decide la institución. Direcciones web, inventario de aplicaciones y comandos vienen apagados de fábrica y los enciende la institución, uno a uno, con cada cambio auditado; el título de la ventana, el nombre del programa, el tiempo de uso y el usuario de Windows vienen encendidos, pero ninguna de esas categorías se registra sin el acuse de la sesión. Aceptar no enciende nada que la institución no haya encendido, y encender no registra nada que quien se conecta no haya aceptado. Si una configuración guardada no dice nada sobre las direcciones web o el inventario, se quedan apagados en vez de heredar ningún valor nuestro; cuando la institución los enciende expresamente, quedan encendidos hasta que ella los apague.

Menores de edad

La Ley 1581, art. 7, proscribe el tratamiento de datos de niñas, niños y adolescentes salvo los de naturaleza pública, y el Decreto 1377, art. 12, exige que responda a su interés superior, que respete sus derechos fundamentales y que la autorización la otorgue el representante legal tras escuchar al menor.

RemoteHub no tiene hoy ningún flujo que recoja la autorización de un acudiente ni que deje constancia de que se escuchó al menor. Mientras no exista, la institución no debe activar la supervisión sobre equipos usados por menores de edad. Preferimos prohibirlo a fingir un procedimiento que el producto no tiene.

Por la misma razón, la institución no puede crear cuentas de RemoteHub para menores de 18 años ni entregarles códigos de clase, PIN o contraseñas diarias mientras rija la restricción de los Términos (sección 3).

Equipos Mac

El programa para Mac no se ha comprobado todavía en un Mac real, y el aviso que ve quien se conecta a un Mac conserva frases escritas para Windows. Hasta que el programa se haya comprobado en un Mac real y el aviso tenga una versión redactada para macOS, la institución no debe activar la supervisión en equipos Mac. RemoteHub le comunicará por escrito cuándo deja de aplicarse esta restricción. El control remoto de un Mac, sin supervisión, no queda afectado por ella.

El producto no lo impide. La opción de supervisar todos los equipos de la institución también alcanza a los Mac que pertenezcan a ella, sin que nadie active su supervisión a mano. Por eso, mientras dure esta restricción, una institución con equipos Mac no debe usar esa opción: tiene que activar la supervisión equipo por equipo, solo en sus equipos Windows.

Reparto de consecuencias

Si la institución activa la supervisión sin haber informado ni recogido la autorización, o desactiva u oculta el indicador, responde ella frente a las personas afectadas y mantiene indemne a RemoteHub por las reclamaciones que se deriven de ese incumplimiento.

Medidas efectivamente implementadas, no un catálogo de intenciones (Ley 1581, arts. 4.g y 18.b), que sirven además a la institución para demostrar su responsabilidad (Decreto 1377, art. 26):

• Las contraseñas se guardan como hash argon2id y se comparan en tiempo constante. Nunca se muestran ni se devuelven por la API, ni a un administrador.
• El secreto del segundo factor y el de la contraseña diaria del equipo se guardan cifrados con AES-256-GCM. El PIN desatendido, como hash argon2id. Los códigos de reserva, como huella con una clave que no vive en la base de datos. Los códigos de clase de las reservas de sala, como huella y, además, cifrados con AES-256-GCM, para poder volver a mostrárselos a la aplicación de la institución que los pidió; nunca en claro. Cada lectura de un código de clase queda auditada antes de entregarse, y las respuestas que lo llevan piden no guardarse en cachés intermedias.
• Las sesiones abiertas se guardan solo como huella. Rotan, y si llega una ya usada se revoca la familia entera y se registra el intento: es detección de robo de sesión.
• La dirección IP se recorta a su red antes de tocar la base de datos — /24 en IPv4, /48 en IPv6 — y el recorte es irreversible: no es un hash, no hay clave que lo revierta.
• El segundo factor es obligatorio para los administradores de plataforma, que no pueden entrar con Google o Microsoft sin tenerlo activo. La institución puede pedirlo a todos sus miembros, también cuando entran con Google o Microsoft: 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. Un miembro que no lo configure puede seguir usando el panel, las reservas y las conexiones.
• El inicio de sesión con Google o Microsoft usa OpenID Connect con valores de un solo uso y PKCE, comprueba la firma del documento de identidad que emite el proveedor e identifica a la persona por el identificador de su cuenta allí, nunca solo por el correo. Una cuenta de RemoteHub 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 se entra.
• El vídeo y los eventos de teclado y ratón viajan por WebRTC, que impone cifrado DTLS-SRTP y no permite desactivarlo. Precisión que nos importa: ese cifrado lo aporta el protocolo, no es un cifrado propio nuestro añadido encima.
• Los registros técnicos del servidor van depurados: se ocultan las cabeceras de autorización, las cookies y las cabeceras de IP reenviada, el serializador no emite la dirección del cliente y, 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). Salvedad declarada: hoy la dirección IP queda escrita dentro del mensaje que se registra al rechazar una llave de API inválida. Está en el plan de corrección y se comunicará cuando se cierre. Estos registros se guardan en AWS durante 30 días (cláusulas 7 y 8).
• La actividad de un equipo se puede consultar por dos rutas y cada una tiene su propia comprobación. Por la ruta del equipo: solo su dueño, o el dueño o un administrador de la empresa del dueño; cualquier otro recibe un error de permiso, y esa ruta no se le abre a un jefe de área. Por la ruta de auditoría de la institución: además el perfil de auditor, y quien dirige un área acotado a su área —las conexiones de las personas de su área y las hechas a los equipos de su área, sean los asignados a ella o los que ella instaló—; en los dos casos, solo de las conexiones autorizadas bajo un aviso de supervisión que ya nombraba a esa figura, y cada figura tiene su propia lista de versiones, 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 anteriores ve el expediente pero no la actividad—. En las dos rutas, la actividad de un equipo que NO es de la institución queda fuera, incluso cuando la conexión la hizo alguien de la institución: en ese caso no se publica ni la actividad ni el nombre de ese equipo.
• El portapapeles se comparte entre los dos equipos durante la conexión, en los dos sentidos y sólo con texto. El contenido no se guarda en ninguna parte —ni en el registro de actividad, ni en la auditoría, ni en los registros técnicos, ni como huella o resumen—: nuestro servidor lo retransmite y lo olvida —no pasa por el relevo de la cláusula 8—, y de la transferencia queda a lo sumo el hecho, el sentido y el número de caracteres. El sentido equipo → persona conectada está cerrado por omisión y sólo se abre cuando esa sesión se autorizó bajo una versión del aviso de supervisión que nombra el portapapeles: versión vacía, anterior o desconocida, o equipo sin supervisión activada, significan que no se envía nada. Quien está físicamente delante del equipo NO autoriza esa sesión, así que informarle de que lo que copie puede salir del equipo es obligación de la Institución; el producto se lo advierte en la insignia y en la ventana informativa de la aplicación.

Una tarea automática se ejecuta todos los días a las 3:00 UTC —las 10:00 de la noche del día anterior en Colombia— y borra lo vencido. Aviso honesto: esa tarea no recupera ejecuciones perdidas, así que si el servidor está caído a esa hora, ese día no se purga y se espera al siguiente.

Actividad supervisada e inventario de aplicaciones

90 días desde su creación.

Sesiones de control remoto terminadas o rechazadas

90 días. Al borrarse arrastran su chat y los metadatos de sus transferencias. Dos salvedades: desaparecen antes de ese plazo si se borra la cuenta del dueño del equipo o la de quien se conectó, y una sesión que quedó colgada sin terminarse ni rechazarse no entra en esta purga y puede seguir existiendo después. Retirar un equipo del inventario no las borra.

Registros de auditoría

365 días, con una excepción: las acciones de licencia por transferencia bancaria no caducan, porque son el rastro comercial de un contrato que puede durar más de un año.

Sesiones abiertas (tokens)

Cada token vale 7 días, pero la sesión se renueva sola mientras se usa y no tiene tope: solo caduca tras 7 días sin uso, o al salir o revocarla. Los tokens se borran un día después de expirar o revocarse.

Cuenta de Google o Microsoft vinculada

Mientras exista la cuenta y no se desvincule. Al desvincularla se borra en el acto, y al borrar la cuenta, con ella.

Paso pendiente de un inicio de sesión con Google o Microsoft

10 minutos como máximo, y 5 minutos la confirmación de identidad con el proveedor que se pide desde Ajustes. Los dos en memoria temporal; no se escriben en la base de datos.

Decisiones sobre el aviso de supervisión (aceptar, rechazar, no responder)

Indefinida. Es la prueba del consentimiento — y de la negativa — y no se purga por antigüedad. Desaparece si se borra la cuenta del dueño del equipo, que arrastra sus equipos; retirar el equipo del inventario no la borra. Dos salvedades honestas: a los 90 días se purga la sesión a la que apunta y el vínculo queda vacío, así que la fila sigue acreditando qué texto se mostró, a qué cuenta y cuándo, pero deja de poder cruzarse con los metadatos de esa sesión; y si quien se conectó borra su propia cuenta, la fila se conserva pero deja de decir a quién acreditaba.

Reservas (de equipos y de salas), códigos de reserva, códigos de clase y equipos

Indefinida. Hoy no existe purga por antigüedad para el histórico de reservas; solo desaparece al borrar la cuenta del dueño del equipo o la de quien reservó. Un equipo retirado del inventario se conserva, con sus reservas, y lo pueden reactivar quienes podían retirarlo. La reserva de sala en sí —la que agrupa las reservas de sus equipos—, con su lista de personas y sus códigos de clase, desaparece al borrar la sala, la institución o la cuenta del profesor a cuyo nombre se hizo; las reservas de cada equipo siguen la regla anterior. Los códigos de clase dejan de abrir nada al terminar la franja, pero hoy su cifrado se conserva mientras exista la reserva de sala, aunque ya no sirve para nada: el producto no vuelve a mostrar un código vencido o revocado. RemoteHub se obliga a borrar ese cifrado al terminar la franja y a conservar solo la huella del código, que no permite recuperarlo; mientras no lo haga, lo declara aquí. Las filas de auditoría de sus lecturas y de cada entrada siguen el plazo de los registros de auditoría.

Historial de pertenencia a la institución y a sus áreas

Indefinida. Cada fila dice quién perteneció, desde cuándo, hasta cuándo, con qué rol y, en las áreas, a cuál y con qué papel. La tarea diaria no la alcanza. El de la institución sirve solo para decidir qué conexiones de quien ya se fue siguen en el historial, y esas conexiones sí se purgan a los 90 días. El de las áreas guarda de qué área era cada persona en cada momento y hoy no se usa para mostrar ni decidir nada; al dar de baja a alguien de la institución, su último tramo de área se queda sin fecha de fin. Si la persona borra su cuenta, la fila deja de decir de quién era. La pertenencia a la institución se borra con la institución; la pertenencia a las áreas, no (cláusula 11).

Registros técnicos del servidor

30 días, en AWS (cláusula 8). Van depurados con las salvedades de la cláusula 6.

Estos plazos son configuración del servidor, la misma para todo el sistema. No existe hoy la posibilidad de fijar un plazo distinto por institución; si el contrato necesita uno, hay que construirlo antes de prometerlo.

Y una excepción que se declara en vez de callarla: existe una copia de seguridad de la base de datos tomada el 7 de septiembre de 2026, al trasladarla de región (cláusula 8), guardada en Colombia, en un equipo de una de las dos personas con acceso que nombra la cláusula 4. Es una foto fija de ese día con los datos que existían entonces, también los de las instituciones que ya eran clientes. No se actualiza y la tarea automática no la alcanza, así que, mientras exista, los plazos de esta cláusula no se cumplen sobre lo que contiene.

Aparte de esa copia, Supabase hace copias de seguridad automáticas de la base de datos, que conservan durante su plazo de retención lo que la tarea diaria ya borró. Ese plazo lo fija el plan contratado con Supabase, y se le confirma por escrito a la institución que lo pida.

Ningún proveedor de RemoteHub está en Colombia, así que todo el tratamiento implica transmisión internacional, salvo la copia de seguridad que declara la cláusula 7, que está en Colombia. Se declara aquí de forma expresa. Este anexo es el contrato de transmisión entre la institución y RemoteHub (art. 2.2.2.25.5.2 del Decreto 1074 de 2015) y autoriza a RemoteHub a apoyarse en los subencargados de esta cláusula. RemoteHub se obliga a que sus condiciones con cada uno recojan, como mínimo, las obligaciones de ese artículo: tratar los datos solo por cuenta de la institución y para la finalidad autorizada, con seguridad y confidencialidad. Además, Estados Unidos figura en la lista de países con un nivel adecuado de protección de datos de la Superintendencia de Industria y Comercio (Circular Única, Título V, numeral 3.2, que viene de la Circular Externa 005 de 2017), y ese es el fundamento que queda para el servidor de descubrimiento de red de Google, con el que RemoteHub no tiene contrato.

Vercel · Estados Unidos

Aloja la web y, además, enruta hacia el backend todas las llamadas de la API. Es el subencargado con más alcance y el menos evidente.

Amazon Web Services (AWS) · Estados Unidos, región de Oregón

Ejecuta el servidor, la señalización de las sesiones y el almacén temporal en memoria: la presencia de los equipos, los contadores de límite de peticiones —que guardan la dirección IP completa durante minutos—, la lista de sesiones invalidadas y, cuando alguien entra con Google o Microsoft, el paso pendiente (hasta 10 minutos) y la confirmación de identidad (5 minutos). Guarda además los registros técnicos del servidor durante 30 días (cláusula 6). Sustituye a Render, donde corrió el servidor hasta el 6 de octubre de 2026.

Supabase · Estados Unidos, región de Oregón (sobre AWS)

Base de datos PostgreSQL. Aquí vive todo: cuentas, sesiones, chat, auditoría, reservas y el módulo de actividad. Corrección sobre la versión 2, que nombraba aquí a Neon: la base de datos nunca estuvo en Neon. Estuvo en Supabase, en la región de São Paulo (Brasil), hasta el 7 de septiembre de 2026, y desde ese día está en la de Oregón; el proyecto de São Paulo se eliminó ese mismo día.

Cloudflare · Estados Unidos, red global · activo

Servidor de relevo (TURN). Hoy el relevo está activo. Retransmite, ya cifrados, la pantalla, los eventos de teclado y ratón y el contenido de los archivos transferidos; no puede descifrarlos, pero ve las direcciones IP de ambos extremos, el volumen y los tiempos. El portapapeles y el chat no pasan por él: los retransmite nuestro servidor (cláusula 6). Desde el 13 de octubre de 2026, las sesiones que se abren desde la web pasan siempre por este relevo, también cuando los dos equipos están en la misma red: una sesión web entre dos equipos del mismo campus sale de la red de la institución hacia Cloudflare y vuelve, y Cloudflare ve las direcciones y los tiempos de todas las sesiones web. Si en algún momento el servidor no consigue credenciales del relevo, la web vuelve a intentar la conexión directa. La aplicación de escritorio lo usa solo cuando la conexión directa entre los dos equipos no es posible. Si se configurara un relevo distinto del de Cloudflare, el subencargado sería otro y se comunicaría antes de usarlo, como dice el final de esta cláusula.

Google · Estados Unidos

Servidor de descubrimiento de red. Se usa en cada intento de conexión y recibe la dirección IP pública de los dos extremos. Hoy no es opcional ni desactivable desde la interfaz. Lo decimos porque es el que más gente se sorprende de encontrar. No tiene nada que ver con Google como forma de entrar, que se explica debajo de esta lista.

GitHub · Estados Unidos

Distribuye el instalador y el archivo de versión. El equipo lo consulta por su cuenta para actualizarse —la aplicación y también el servicio del sistema, cada pocas horas e igualmente en los puestos que arrancan sin que nadie abra la aplicación—, de modo que contacta con GitHub periódicamente aunque nadie lo pida. Y no se limita a comprobar: cuando hay versión nueva, el servicio del sistema descarga el instalador desde aquí y lo instala él, con privilegios de sistema y sin pedir autorización a nadie en el puesto. Solo lo hace si el instalador está firmado con el certificado de RemoteHub para Windows —o con otro cuya huella haya añadido expresamente un administrador del equipo en el valor UpdateSignerThumbprints— y solo con el puesto libre: antes de instalar comprueba que no haya sesión de control —ni de entrada ni de salida—, que nadie esté esperando autorización y que no haya transferencias en curso. Nunca instala una versión anterior a la instalada. La institución lo puede apagar por completo sin desinstalar nada, y de dos formas: los valores AutoUpdate y Guardian a cero en HKLM\SOFTWARE\RemoteHub (desplegables por GPO), o desmarcando en la instalación la opción «Acceso bajo pantalla de bloqueo» —en cuyo caso las actualizaciones se instalan a mano—. Detener el servicio RemoteHubBridge a mano no es una de ellas: arranca con el sistema y vuelve en el siguiente reinicio. En un Mac, el programa se descarga e instala con una orden en la Terminal desde la publicación «mac-v1» de ese mismo repositorio, y un servicio del sistema con privilegios de administrador consulta allí cada pocas horas si hay versión nueva y la instala él, con los mismos límites: firmada con el certificado de RemoteHub para Mac, que es otro distinto del de Windows (o con uno que un administrador haya añadido en la preferencia del mismo nombre), con el equipo libre y nunca una versión anterior. La orden de instalación por Terminal no va firmada. La instalación automática se apaga sin desinstalar nada poniendo AutoUpdate a falso en /Library/Preferences/com.remotehubtech.agent.plist; con eso el Mac sigue comprobando si hay versión nueva, pero no la instala.

MercadoPago · país no verificado

Solo para pagos con tarjeta. Recibe el correo electrónico del titular, junto al nombre del plan, el importe y la moneda. RemoteHub no ve, no transmite y no guarda ningún dato de tarjeta, ni siquiera los últimos cuatro dígitos. Los clientes que pagan por transferencia bancaria no pasan por aquí. Hoy esta pasarela está inactiva: el cobro por pasarela no está en funcionamiento, de modo que no hay ningún dato viajando hacia este subencargado. País: no verificado. Grupo Mercado Libre, con entidades en varios países de América Latina; la entidad concreta se confirmará antes de activar el cobro.

Google y Microsoft, como forma de entrar, no son subencargados: no tratan datos por cuenta de RemoteHub ni de la institución. Son la fuente de la que recibimos el identificador, la organización, el correo y el nombre de quien elige sus botones (cláusula 2), y lo que hacen con esa cuenta se rige por sus propias políticas y, si la cuenta es de la institución, por la configuración de la propia institución (cláusula 4). Nuestro servidor solo habla con ellos para descargar su configuración pública y sus claves de firma, y para canjear el código de un solo uso con el que vuelve la persona.

Hay un servicio de reporte de errores integrado en el código pero inerte: sin su clave de configuración no envía absolutamente nada. Si algún día se activa, se comunica y se actualiza este anexo, porque las trazas de error pueden arrastrar datos personales.

Las tipografías de la web se sirven desde nuestro propio dominio: el navegador de quien visita la página nunca contacta con Google por ese motivo. No hay ninguna herramienta de analítica, de publicidad ni de seguimiento.

RemoteHub se obliga a tener aceptadas con cada subencargado de esta lista las condiciones de tratamiento de datos que ese proveedor ofrece a sus clientes, con el contenido mínimo que dice el primer párrafo de esta cláusula, y a entregárselas a la institución que las pida; en el caso de MercadoPago, antes de activar el cobro. La excepción es el servidor de descubrimiento de red de Google: es un servicio público y gratuito con el que RemoteHub no tiene contrato, y solo recibe las direcciones IP públicas de los dos extremos.

Cambios de subencargado. Antes de añadir o sustituir un subencargado, o de cambiar el país donde se tratan los datos, RemoteHub lo comunica por correo a la persona de contacto que figura en la carátula del contrato con al menos 30 días de antelación, salvo que el cambio sea necesario para atender un incidente de seguridad; en ese caso se comunica en cuanto se aplique.

Si la institución se opone. Puede oponerse dentro de ese plazo, por correo a administrador@remotehubtech.com. Si se opone, RemoteHub no aplica el cambio a sus datos mientras se busca un acuerdo; si no puede aplicarlo por separado, la institución puede terminar el contrato con efecto desde la fecha del cambio. Si en 15 días desde la oposición no hay acuerdo, puede terminar el contrato sin penalidad, con la devolución de lo que haya pagado por el periodo que ya no se le preste y la entrega y supresión de sus datos conforme a la cláusula 11. Si el cambio se aplicó para atender un incidente, puede oponerse dentro de los 30 días siguientes a la comunicación, con el mismo efecto.

Si su institución nombra a sus encargados en su política de tratamiento, o tiene esta base de datos inscrita en el Registro Nacional de Bases de Datos, debe actualizarla: la política, comunicando el cambio a los titulares (Decreto 1377, art. 13), y el Registro, en el plazo que fija la Superintendencia de Industria y Comercio para los cambios sustanciales.

Los derechos que reconoce el art. 8 de la Ley 1581 son, con su nombre exacto: conocer, actualizar y rectificar sus datos; solicitar prueba de la autorización otorgada; ser informado, previa solicitud, del uso que se les ha dado; presentar quejas ante la Superintendencia de Industria y Comercio; revocar la autorización y solicitar la supresión cuando no se respeten los principios y garantías; y acceder de forma gratuita a sus datos.

Las personas ejercen sus derechos ante la institución, que es la Responsable. RemoteHub la asiste: ejecuta las rectificaciones, actualizaciones y supresiones que la institución instruya dentro de los 5 días hábiles siguientes a recibir la instrucción (Ley 1581, art. 18, literales c y d), y le entrega la información que necesite para responder.

Sobre los datos de los que RemoteHub es Responsable —la cuenta, su vinculación con Google o Microsoft, la facturación y la auditoría de plataforma— la persona se dirige directamente a RemoteHub en administrador@remotehubtech.com; si la petición llega a la institución, esta se la traslada.

Plazos legales que la institución debe cumplir y para los que nos comprometemos a asistir:

• Consultas: 10 días hábiles, prorrogables 5 días hábiles más informando los motivos.
• Reclamos: 15 días hábiles, prorrogables 8 días hábiles más. Si el reclamo llega incompleto, se requiere al interesado dentro de los 5 días siguientes; si pasan 2 meses sin respuesta, se entiende desistido.
• La persona solo puede quejarse ante la Superintendencia una vez agotado este trámite.

Como Encargado, RemoteHub mantiene un canal único de atención de peticiones, consultas y reclamos sobre datos personales, tal como exige el artículo 2.2.2.25.4.4 del Decreto 1074 de 2015 (antes art. 23 del Decreto 1377 de 2013). Lo atiende personalmente el Encargado, Cristian Camilo Escandón García, y su dirección es administrador@remotehubtech.com. Este canal no sustituye al que la institución, como Responsable, debe mantener frente a sus propios titulares.

El deber de informar a la Superintendencia de Industria y Comercio cuando se presenten violaciones a los códigos de seguridad y existan riesgos en la administración de la información de los titulares es del Responsable (Ley 1581, art. 17.n) y también del Encargado (art. 18.k). RemoteHub cumple el suyo, en la forma y el plazo que fijen las instrucciones de la Superintendencia, y, para que la institución pueda cumplir el propio, se obliga a comunicarle cualquier incidente de seguridad que afecte a sus datos tan pronto lo detecte y confirme, con lo que se sepa en ese momento y con actualizaciones a medida que se investigue.

El plazo máximo concreto en horas se fija en el contrato de servicio; este anexo no inventa una cifra que nadie haya acordado.

Esto es lo que ocurre de verdad hoy, paso por paso:

• Al apagar la supervisión de un equipo se borra de inmediato el inventario de aplicaciones abiertas de ese equipo. El histórico de actividad NO se borra en ese momento: se va con su plazo de 90 días.
• Al retirar un equipo del inventario no se borra nada: deja de poder conectarse y de reservarse, se cortan sus reservas y sesiones en curso, y se conservan su actividad (hasta su plazo de 90 días), sus acuses de consentimiento, sus sesiones y sus reservas. Queda constancia en el registro de auditoría, y quienes pueden retirarlo pueden reactivarlo. Un equipo solo se borra de verdad al borrarse la cuenta de su dueño, y entonces desaparecen en cascada su actividad, su inventario, sus acuses de consentimiento, sus sesiones, sus reservas y los códigos de esas reservas.
• Al borrar una cuenta desaparecen con ella sus equipos —con todo lo del punto anterior—, sus sesiones, sus reservas, sus membresías y las cuentas de Google o Microsoft vinculadas. Los acuses que esa persona dio al conectarse a equipos de otros se conservan, pero dejan de decir a quién acreditaban, y lo mismo pasa con los tramos de su pertenencia a la institución y a sus áreas.
• Si la institución se borra —lo que ocurre al borrar la cuenta titular del plan; ver el aviso de abajo—, con ella se van sus salas, sus llaves de API, sus membresías y el historial de pertenencia a la institución. El historial de pertenencia a sus áreas no está atado a la institución y no se borra solo: se borra a mano, cuando la institución lo instruya.
• Mientras el contrato siga vigente, los registros de auditoría siguen su plazo de 365 días, con la excepción ya descrita de las licencias por transferencia bancaria. Lo que pasa con ellos al terminar el contrato se dice más abajo.

No existe hoy una devolución certificada de datos en bloque para la institución. Si la institución necesita una copia completa al terminar, hay que pedirla y se prepara de forma manual, o acordar en el contrato construir esa vía. Preferimos decirlo a que aparezca el día de la baja.

Al terminar el contrato, y dentro de los 30 días siguientes, RemoteHub entrega a la institución la copia que pida y, en todo caso y aunque no la pida, la de los acuses del aviso de supervisión y la del historial de conexiones; después suprime los datos que trató por su cuenta —incluidos los que la cláusula 7 conserva sin plazo, el historial de pertenencia a sus áreas y lo que de ella contenga la copia de seguridad de la cláusula 7 si para entonces sigue existiendo—, salvo los que deba conservar por obligación legal, que identifica por escrito. Le confirma la supresión por escrito. Los registros de auditoría de la institución se suprimen con lo demás. Los de plataforma, de los que RemoteHub es Responsable (cláusula 1), siguen su plazo de 365 días. Los soportes de las licencias por transferencia se conservan como soporte contable durante el plazo legal y se identifican por escrito. Las copias automáticas de Supabase que describe la cláusula 7 lo conservan hasta que vence su plazo de retención.

Lo que sí puede descargar la institución por sí misma, desde la web y sin pedírnoslo, es su historial de conexiones: un archivo CSV con las sesiones de control remoto de sus equipos y de su gente —equipo, persona, inicio, fin, duración, estado, método y momento de la autorización, si entró por reserva y la IP recortada a su red—, filtrable por fechas, equipo y persona. Y, desde el apartado de reportes, la parte del registro de auditoría que le corresponde, los acuses del aviso de supervisión, el historial de reservas y la actividad de las conexiones supervisadas, cada uno en su archivo CSV o los cinco juntos en un expediente comprimido. El registro completo del sistema, con el resto de instituciones, sigue siendo solo del administrador de plataforma. Todo esto lo obtienen la cuenta titular del plan, una con perfil de administrador del plan o de auditor, y quien dirige un área acotado a su área; la actividad, con la restricción por versiones del aviso que explica la cláusula 4. Dos límites del historial de conexiones que conviene conocer antes de firmar: ese archivo no contiene actividad supervisada, ni chat, ni archivos, ni imagen —son metadatos de conexión—, y si el rango pedido excede el máximo por archivo la descarga se rechaza indicando el total, para no entregar un registro recortado en silencio que se presente como completo. La cláusula 4 dice quién lo ve.

Con cuatro límites de alcance que conviene planificar antes de necesitarlos, porque ninguno avisa cuando ocurre. Primero, el plazo: ese historial alcanza solo el periodo de conservación de las sesiones —hoy 90 días, cláusula 7—, porque a partir de ahí la purga automática borra las filas. Segundo, las bajas: el historial cubre los equipos y las conexiones de quien pertenece hoy a la institución y, de quien ya se fue, las conexiones del tiempo en que perteneció (cláusula 4). Dar de baja a una persona ya no retira del registro las conexiones que ya ocurrieron, como pasaba hasta septiembre de 2026; pero de las bajas anteriores a esa corrección no existe registro de pertenencia, y sus conexiones no se pueden recuperar. Tercero, las filas pueden desaparecer antes de los 90 días: si se borra la cuenta del dueño del equipo o la de quien se conectó, sus sesiones se borran con ella, y eso lo puede hacer el titular de esa cuenta —que puede ser la persona auditada— sin que la institución lo impida ni quede una marca. Retirar un equipo del inventario, en cambio, no borra sus sesiones y deja constancia. Y cuarto, por el otro lado: el historial alcanza las sesiones ya guardadas desde antes de que la cuenta perteneciera a la institución —hasta esos mismos 90 días—, porque no hay fecha mínima.

Y una precisión sobre la purga, para que este anexo no diga algo distinto de la cláusula 7: lo que se borra a los 90 días son las sesiones terminadas o rechazadas. Una sesión que quedó colgada sin cerrarse —por ejemplo si el servidor se reinicia entre la petición de conexión y su aceptación— no entra en esa purga y puede seguir apareciendo en la vista y en la descarga pasado el plazo. Es un hueco del producto, no una decisión de diseño, y lo decimos en vez de afirmar un borrado que no se produce.

Con todo lo anterior a la vista: una institución que deba conservar el registro de accesos por más tiempo —o protegerse del borrado anticipado de cuentas, que la descarga periódica solo mitiga en parte— tiene que descargarlo con la frecuencia que su propia política exija y custodiarlo ella; a partir de ese momento es Responsable de esa copia. Nosotros no llevamos un archivo histórico paralelo de ese registro, y no vamos a decir que sí, con una salvedad: la copia de seguridad del 7 de septiembre de 2026 que declara la cláusula 7 contiene lo que había ese día, y no se actualiza.

RemoteHub, en calidad de Encargado, lo presta Cristian Camilo Escandón García, persona natural con domicilio en Bogotá D.C., Colombia, correo administrador@remotehubtech.com y teléfono 320 844 9766. No hay sociedad constituida, de modo que no existen razón social, NIT ni representante legal que consignar: el Encargado contrata a título personal. Su número de documento y su dirección física de notificaciones —que no se publican en la web— y los datos de la institución se consignan en la carátula del contrato de servicio, que forma un todo con este anexo. El canal permanente de protección de datos es administrador@remotehubtech.com. En lo relativo al tratamiento de datos y a la terminación prevista en las cláusulas 8 y 12, este anexo prevalece sobre el contrato de servicio.

Esta es la versión 3, publicada el 14 de octubre de 2026. Se mantiene vigente mientras dure el contrato de servicio y, después, mientras subsista cualquier obligación de conservación.

Desde cuándo rige. Para una institución que la firme a partir de esa fecha, desde su firma. Para una institución que firmó una versión anterior, esta versión no la sustituye por el hecho de publicarse: este anexo no prevé cambios por decisión de una sola de las partes, así que la versión 3 rige para ella desde que las dos partes la firmen, y hasta entonces sigue rigiendo la que firmó. RemoteHub le envía esta versión por correo a la persona de contacto que figura en la carátula de su contrato.

Lo que ya se aplicó. La versión que su institución firmó nos obligaba a comunicarle antes de aplicarlos los cambios sustanciales (cláusula 12) y la sustitución de un subencargado (cláusula 8). Los siguientes se aplicaron antes de esta comunicación: la actualización automática que instala el servicio del sistema (2 de septiembre de 2026); el historial de conexiones de toda la institución y el perfil de auditor (7 de septiembre de 2026); el traslado de la base de datos de São Paulo a Oregón (7 de septiembre de 2026); las áreas y el portapapeles compartido (15 de septiembre de 2026); el encendido a distancia (21 de septiembre de 2026); el acceso a la pantalla de inicio de Windows, que el instalador enciende (23 de septiembre de 2026); el servidor en AWS en lugar de Render (6 de octubre de 2026); el paso de todas las sesiones web por el relevo de Cloudflare y el programa para Mac (13 de octubre de 2026); y el inicio de sesión con Google y Microsoft (14 de octubre de 2026, el mismo día de esta versión).

Mientras su institución no firme esta versión, RemoteHub le reconoce que el tratamiento ya se hace con los subencargados y del modo que describe la cláusula 8 de esta versión, y no como lo describe la versión que firmó. Si su institución no está de acuerdo con alguno de esos cambios, puede comunicarlo a administrador@remotehubtech.com dentro de los 30 días siguientes a recibir esta versión o, si para entonces no la ha firmado, en cualquier momento mientras no la firme, y terminar el contrato de servicio sin penalidad, con la devolución de lo que haya pagado por el periodo que ya no se le preste y la entrega y supresión de sus datos conforme a la cláusula 11.

Lo que dicen este párrafo y el anterior obliga a RemoteHub desde que envía esta versión, sin necesidad de que la institución la firme: es una oferta irrevocable (Código de Comercio, art. 846), y la terminación que en ellos se prevé se rige por la cláusula 11 de esta versión.

Cambios futuros. Un cambio sustancial —añadir o sustituir un subencargado, cambiar el país donde se tratan los datos, empezar a tratar por cuenta de la institución una categoría de datos que la cláusula 2 no recoja, dar acceso a esos datos a un perfil o a una persona que la cláusula 4 no nombre, o cambiar lo que el producto hace en los equipos o en las sesiones de modo que la institución deba volver a informar a las personas (cláusula 5)— se comunica por correo a la persona de contacto de la carátula con al menos 30 días de antelación, salvo que sea necesario para atender un incidente de seguridad; en ese caso se comunica en cuanto se aplique. La institución puede oponerse, con los plazos y los efectos que fija la cláusula 8 para la oposición a un cambio de subencargado: mientras se busca un acuerdo el cambio no se aplica a sus datos y, si no se llega a él, puede terminar el contrato sin penalidad. Un cambio en la finalidad del tratamiento exige además nueva autorización de los titulares (Decreto 1377, art. 5).

Este documento describe cómo funciona el producto y reparte deberes entre las partes. No es asesoría jurídica y no sustituye la revisión por el área jurídica de la institución.

Las normas colombianas que aplican a lo que hace RemoteHub, qué exige cada una en lo que le toca y cómo se cumple. Cada fila remite a la cláusula de este anexo, o a la sección de los Términos o de la Política de Tratamiento, donde está el compromiso correspondiente.