Datos del documento
Directiva de privacidad y tratamiento de datos de HubBound
- Version
- 1.0
- Última actualización
- 2026-09-04
- Fecha de entrada en vigor
- 2026-09-01
- Responsable
- HubBound SAS
- URL pública prevista
- https://hubbound.net/privacy
1Resumen
HubBound es una aplicación para Windows, junto con sus servicios asociados, que ayuda a equipos de ingeniería a gestionar artefactos y distribuciones, conectar herramientas de desarrollo, observar actividad técnica y generar analítica operativa. Esta Directiva explica qué datos podemos acceder, recopilar, recibir, generar, almacenar o transmitir; para qué los usamos; con quién podemos compartirlos; cuánto tiempo los conservamos; y qué controles tienen las personas usuarias.
HubBound no vende datos personales y no utiliza los datos descritos en esta Directiva para publicidad comportamental. No solicitamos datos de salud, datos financieros, ubicación precisa, documentos oficiales de identidad ni contraseñas para la funcionalidad principal. La persona usuaria no debe subir secretos, credenciales, claves privadas, información de salud, datos financieros ni datos personales innecesarios dentro de archivos, código, prompts, configuraciones, comentarios o artefactos.
Cuando una cuenta es creada o administrada por una organización, la organización puede determinar qué datos se procesan, quién tiene acceso a ellos y cuándo deben eliminarse. En esos casos, HubBound puede actuar como proveedor o encargado del tratamiento por cuenta de la organización, y la organización puede ser el responsable o controlador correspondiente. Las solicitudes relacionadas con una cuenta corporativa también pueden dirigirse al administrador de la organización.
Para las operaciones en Colombia, HubBound SAS aplica como marco principal la Ley Estatutaria 1581 de 2012 y sus normas reglamentarias, incluido el Decreto 1074 de 2015. La autoridad colombiana competente para protección de datos personales es la Superintendencia de Industria y Comercio. Cuando el servicio se ofrezca en otros países, también se aplicarán las normas imperativas que correspondan a la persona usuaria, la organización y el tratamiento concreto.
2A quién se aplica
- la aplicación de HubBound distribuida por Microsoft Store;
- el CLI, daemon, agente local y herramientas de integración de HubBound que la aplicación instala o utiliza;
- la API y los servicios cloud de HubBound;
- la consola web, el registro público y los servicios de distribución de artefactos vinculados a la cuenta;
- las integraciones que la persona usuaria u organización habilite, como proveedores de IA, GitHub, GitLab, Bitbucket Cloud, Azure DevOps, Jira, Linear, CI/CD, observabilidad, seguridad y otros conectores compatibles.
No controla el tratamiento que Microsoft, Google, GitHub, un proveedor OIDC, un proveedor de IA o cualquier otro tercero realice bajo sus propias políticas. Consulta también las políticas de esos servicios antes de conectarlos.
3Datos que tratamos
La tabla siguiente resume las categorías que pueden tratarse. No todas se recopilan en todas las instalaciones: algunas dependen de la función habilitada, del plan, de la configuración de la organización, de los permisos concedidos y de la integración elegida.
| Categoría | Ejemplos | Origen y condición | Finalidad principal |
|---|---|---|---|
| Solicitud de demo | correo electrónico, nombre, teléfono, empresa, rol, plan de interés, mensaje y fechas | Se recibe cuando una persona envía una solicitud de demo, sin autenticación | Responder la solicitud y comunicar novedades relacionadas con HubBound |
| Cuenta y autenticación | correo electrónico, nombre, nombre de usuario, identificadores de Google u OIDC, avatar, etiquetas, estado de onboarding, rol y organización | Se recibe al registrarse, iniciar sesión o ser invitado | Crear y proteger la cuenta, autenticar, mostrar el perfil y aplicar permisos |
| Organización y colaboración | nombre y etiqueta de la organización, equipos, membresías, invitaciones, comentarios, configuraciones, autoría y cambios | Se genera al usar espacios de trabajo y funciones colaborativas | Administrar el espacio de trabajo, compartir contenido y mantener historial operativo |
| Sesión y seguridad | hashes de tokens de sesión, códigos de un solo uso, expiraciones, revocaciones, intentos, nonce, estado OAuth y datos de recuperación | Se genera durante el login, SSO, OTP, logout y renovación de sesión | Prevenir fraude, abuso, replay y acceso no autorizado |
| Planes y facturación | organización, plan, ciclo de renovación, estado, descuentos, importe, moneda, descripción e historial de cambios | Se genera cuando una organización consulta o administra un plan o contrato | Aplicar entitlements, límites, beneficios y administración del contrato |
| Dispositivos y CLI | identificador del dispositivo, identificador de clave, clave pública o huella JWK, nombre del dispositivo, plataforma, versión, scopes, fechas de uso y, si se configura, nombre y correo de Git | Se genera al registrar o utilizar un dispositivo autorizado | Vincular cargas al dispositivo y a la cuenta correctos, controlar scopes y proteger la ingestión |
| Telemetría de uso | identificadores de sesión, proveedor, herramienta, producto, modelo y versión; eventos, métricas, spans, duración, estado, consumo de tokens, coste reportado y snapshots de recursos | La recopilación local está activa por defecto; la entrega y sincronización cloud pueden ser restringidas por la configuración local y por el administrador o entitlement de la organización | Diagnóstico, confiabilidad, capacidad, medición de uso y analítica agregada |
| Procedencia de desarrollo | rama, commit, repositorio, remoto, directorio de trabajo, estado de Git, rutas, rangos de líneas, hashes, conteos de líneas, identidad de autor/committer y señales de procedencia | Se genera mediante integraciones o hooks habilitados por la persona usuaria u organización | Reconstruir evidencia técnica y distinguir resultados conocidos, desconocidos, ambiguos o en conflicto |
| GitHub | instalación y cuenta, repositorios autorizados, nombres y ramas, miembros y equipos, logins, correos públicos observados, pull requests, commits, pushes, webhooks, estados, estadísticas de diff y notas estructuradas | Solo después de conectar GitHub y conceder los permisos correspondientes | Métricas de ingeniería, sincronización, salud de webhooks y analítica histórica |
| Artefactos y archivos | código, skills, hooks, subagentes, reglas, configuración, manifests, descripciones, nombres y rutas de archivos, tipo, tamaño, SHA-256, contenido, versiones, imágenes, comentarios y eventos de historial | Se recibe cuando la persona usuaria u organización crea, sube, publica, distribuye o modifica contenido | Versionar, almacenar, analizar, distribuir y mostrar el contenido según su visibilidad |
| Analítica derivada | métricas agregadas, conteos, tiempos, dimensiones de equipo/proyecto/proveedor/modelo, atribución de usuario u organización, estados de identidad y metadatos de medición | Se calcula desde cargas autenticadas, GitHub y telemetría habilitada | Dashboards, informes, consultas operativas, seguridad y mejora del producto |
| Auditorías de seguridad | contenido de un artefacto o fragmentos necesarios, digest del manifest, hallazgos, severidad, puntuación, veredicto y metadatos del motor | Se genera cuando se solicita o aplica la auditoría de seguridad de un artefacto | Detectar riesgos en skills y artefactos antes de usarlos o distribuirlos |
| Comunicaciones y soporte | correo de verificación, invitaciones, alertas operativas y mensajes de soporte; logs o metadatos de un paquete de diagnóstico iniciado por la persona usuaria | Se genera al pedir la comunicación o soporte correspondiente | Entregar el servicio, avisar de eventos de seguridad y resolver incidencias |
| Datos técnicos de solicitudes | dirección IP, user-agent, ruta, método, estado, duración, request ID, trace ID, span ID, errores y datos de autenticación necesarios para el registro | Se genera al usar la API y los servicios web | Seguridad, rate limiting, auditoría, diagnóstico y prevención de abuso |
| Registro público y distribución | identificadores de versión, publisher, nombres, descripciones, iconos, etiquetas, conteos agregados de descargas y metadatos de distribución | Se genera al publicar o descargar contenido público | Operar el registro y mostrar contenido público |
3.1 Telemetría, prompts y contenido raw
La configuración predeterminada de la telemetría aplica una lista permitida y redacción a los atributos enviados. La procedencia normal conserva metadatos técnicos y evidencia estructurada; no copia por defecto el texto completo de prompts, transcripciones ni el código fuente completo.
Algunos identificadores, rutas, nombres de ramas, directorios de trabajo, correos de Git y nombres de repositorios pueden revelar información personal, de la empresa o del equipo. Por eso deben tratarse como datos potencialmente confidenciales aunque no sean el contenido de un prompt o de un archivo.
Una carga raw de diagnóstico puede habilitarse únicamente mediante una configuración explícita del administrador u operador autorizado, con una política reconocida y una fecha de expiración limitada. Si una organización habilita esa opción, los datos enviados pueden incluir atributos adicionales de proveedor, herramienta, sesión, conversación, modelo, paths, tokens, costes, eventos o payloads de hooks. La organización debe informar a sus personas usuarias y aplicar su propia base legal y controles antes de activar esa modalidad.
3.2 GitHub, conectores y procedencia AI/humana
GitHub es una integración opcional que se conecta mediante una GitHub App de HubBound. La desconexión se realiza actualmente desde la consola. Cuando se conecta, HubBound procesa los metadatos necesarios para sincronizar instalaciones, repositorios, equipos, miembros, pull requests, commits, pushes y entregas webhook. La analítica puede incluir identidad de autor, estadísticas de cambios, rutas o rangos y evidencia estructurada de herramientas, modelos o sesiones.
La plataforma puede recibir datos de los conectores que la organización active, incluidos Cursor; Claude Cowork y Claude Code; ChatGPT Work y Codex CLI; Gemini CLI y Google Antigravity; GitHub Copilot; GitHub, GitLab, Bitbucket Cloud y Azure DevOps; Jira y Linear; pipelines CI/CD; proveedores de incidentes y observabilidad; scanners de calidad y seguridad; y fuentes internas de facturación, encuestas, roster o identidad. Cada conector solo debe habilitarse con los permisos necesarios y queda sujeto también a la política del proveedor correspondiente.
Los resultados de procedencia pueden indicar AI, human, unknown, overlap o conflict, junto con el método y el nivel de evidencia. Estas etiquetas son mediciones técnicas y no constituyen una determinación infalible sobre la conducta de una persona, su productividad, su desempeño laboral o la autoría jurídica de una obra. HubBound no debe convertir un estado unknown o conflict en una conclusión de autoría por inferencia temporal.
La integración no está diseñada para almacenar el contenido completo de todos los archivos o parches de GitHub. Aun así, la persona usuaria debe revisar los permisos, payloads y datos que su configuración de GitHub haga accesibles, y no debe conceder más permisos de los necesarios.
3.3 Artefactos, archivos y contenido proporcionado por la persona usuaria
Los artefactos pueden ser privados, restringidos a una organización, compartidos con un equipo o publicados. La visibilidad elegida determina quién puede ver el contenido y sus metadatos dentro de HubBound. Un artefacto público, su manifest, sus versiones publicadas y los metadatos del publisher pueden quedar accesibles a otras personas y pueden ser indexados, almacenados en cachés o copiados por terceros.
La persona usuaria conserva la responsabilidad de no incluir secretos, credenciales, tokens, claves privadas, datos personales de terceros, información regulada o material que no tenga derecho a compartir. La auditoría de seguridad ofrece hallazgos orientativos y no garantiza que un artefacto sea seguro o que no contenga secretos.
La información de planes y facturación descrita en esta Directiva es metadato de contrato, entitlement e historial. Esta aplicación no necesita recibir datos completos de tarjetas o cuentas bancarias para esas funciones. Si una compra se realiza a través de Microsoft Store o de otro procesador, ese proveedor puede tratar los datos de pago bajo sus propios términos y políticas.
4Cómo usamos los datos
Usamos los datos para las siguientes finalidades:
- prestar las funciones solicitadas, incluidas cuentas, autenticación, organizaciones, equipos, artefactos, distribución, registro, analítica y soporte;
- validar permisos, aplicar aislamiento por organización, controlar scopes de dispositivos y prevenir accesos no autorizados;
- sincronizar una integración habilitada, como GitHub, y devolver al usuario métricas o estado de sincronización;
- procesar telemetría habilitada, generar métricas agregadas y detectar errores de rendimiento o disponibilidad;
- crear evidencia de procedencia técnica y mantener historiales e idempotencia de cargas;
- analizar artefactos enviados para generar hallazgos de seguridad cuando la función esté activa;
- enviar correos transaccionales de autenticación, invitación, seguridad y operación;
- mantener la seguridad, investigar abuso, aplicar rate limits, depurar fallos y cumplir obligaciones legales;
- mostrar contenido que la persona usuaria haya hecho público y medir descargas agregadas del registro;
- mejorar la confiabilidad, documentación y funcionalidad del producto usando información agregada o desidentificada cuando sea razonablemente posible.
No usamos el contenido para publicidad dirigida ni vendemos perfiles personales. No tomamos decisiones legales, de crédito, de empleo, de vivienda o de seguros basadas únicamente en una salida automatizada de HubBound.
5Bases jurídicas
Cuando la ley aplicable exija identificar una base jurídica, la base concreta dependerá del producto contratado, la configuración, el país y el rol de HubBound frente a la organización. En general, podemos apoyarnos en:
| Base posible | Ejemplos |
|---|---|
| Ejecución de un contrato o medidas precontractuales | Crear la cuenta, autenticar, prestar el servicio, gestionar organizaciones, almacenar artefactos y entregar funciones solicitadas |
| Consentimiento | Habilitar telemetría opcional, cargas raw, una integración externa o comunicaciones no esenciales cuando la ley exija consentimiento |
| Interés legítimo | Seguridad, prevención de fraude y abuso, disponibilidad, soporte, auditoría operativa y mejora del servicio, equilibrados con los derechos de la persona |
| Obligación legal | Atender requerimientos válidos, mantener registros exigidos y ejercer o defender reclamaciones |
| Instrucciones de la organización cliente | Cuando HubBound procesa datos por cuenta de una empresa, equipo u otra organización |
Cuando el tratamiento se base en consentimiento, la persona usuaria puede retirarlo mediante el control correspondiente o escribiendo al contacto de privacidad. Retirar el consentimiento no afecta la licitud del tratamiento realizado antes de la retirada.
En Colombia, el tratamiento de datos personales se realizará con autorización previa, expresa e informada cuando sea exigible, o bajo otra base permitida por la Ley 1581 de 2012. Enviar una solicitud de demo no implica autorización para marketing: las novedades comerciales requieren consentimiento separado y deben incluir un mecanismo para retirar la suscripción. La persona puede retirar ese consentimiento escribiendo a support@hubbound.net.
7Almacenamiento y conservación
7.1 Dónde se almacenan
Los datos pueden almacenarse en la base de datos de HubBound, almacenamiento de objetos, colas de procesamiento, almacenes analíticos, logs y cachés operativas. La aplicación local también puede conservar temporalmente una cola segmentada para entregar telemetría cuando la conectividad no está disponible.
La cola local no es un archivo histórico de analítica. Después de una entrega exitosa, el payload local se elimina. Los detalles y manifests de fallos terminales se conservan hasta 20 días; la auditoría operativa local se conserva hasta 7 días; algunos contadores de operación pueden conservarse durante la vida de la instalación. Estos plazos pueden modificarse para corregir incidentes, cumplir obligaciones o adaptarse a una nueva versión.
Los datos cloud se conservan por el tiempo necesario para prestar la función, mantener seguridad e integridad, cumplir obligaciones legales, resolver disputas y recuperar el servicio. Los valores operativos actualmente definidos son:
| Dataset o componente | Conservación operativa observada |
|---|---|
| Payloads analíticos de puntero en S3 | 7 días |
| Eventos, historial de deltas y payloads raw analíticos en S3 | 365 días |
| Mensajes de las colas analíticas, GitHub y auditoría de skills | 14 días |
| Logs de CloudWatch de workers y receptores | 30 días como valor de infraestructura |
| Blobs CAS de artefactos sin referencias | Elegibles para GC después de una gracia mínima de 7 días |
| Bundles cacheados sin referencias | Elegibles para GC después de una gracia mínima de 7 días |
| Cola local de telemetría | Entrega exitosa: eliminación inmediata; fallos terminales: hasta 20 días; auditoría operativa: hasta 7 días |
Las cuentas, organizaciones, historiales de facturación, entregas webhook, jobs de auditoría, artefactos y versiones se conservan mientras sean necesarios para la cuenta, el contrato, la integridad del servicio, la seguridad o una obligación legal. Actualmente no existe un único job de expiración para todos esos registros. Las solicitudes de demo se conservan mientras sean necesarias para responder y gestionar las comunicaciones consentidas, o hasta que se solicite su eliminación.
7.2 Casos de conservación
- Los registros de autenticación, tokens y desafíos tienen expiraciones, revocaciones y controles de rotación. Los tokens de acceso no se conservan como texto visible en los registros de negocio; los mecanismos de sesión usan hashes o valores protegidos cuando corresponde.
- Al cerrar sesión, se invalida la sesión y su lineage de refresh. Esto no elimina automáticamente todos los datos de la cuenta, organización, artefactos, logs o analítica histórica.
- Desconectar GitHub desde la consola detiene futuras lecturas y sincronizaciones de esa instalación. Los datos ya sincronizados, las métricas derivadas, los historiales y los registros de seguridad pueden conservarse mientras sean necesarios o hasta que se atienda una solicitud válida de eliminación.
- Eliminar un comentario o artefacto puede ser una eliminación lógica. Las versiones, referencias, objetos de almacenamiento, copias de respaldo, caches o evidencias de auditoría no necesariamente desaparecen de forma instantánea.
- Los artefactos públicos pueden continuar siendo visibles en copias, cachés o repositorios de terceros que no controla HubBound.
- Los backups, logs de seguridad, ledgers de entrega y registros necesarios para la integridad del sistema pueden mantenerse durante ciclos adicionales limitados, incluso después de la eliminación de la cuenta. El plazo concreto de backups depende de la política de infraestructura aplicable y no debe interpretarse como eliminación inmediata de todas las copias.
8Controles de la persona usuaria
Según la función y la jurisdicción, la persona usuaria puede:
- desactivar la telemetría local cuando el control esté disponible o solicitar que el administrador de la organización desactive la analítica y su sincronización cloud;
- cerrar sesión y revocar sesiones activas;
- desconectar GitHub y otras integraciones autorizadas;
- consultar, corregir y actualizar los datos de perfil que estén disponibles en la aplicación;
- controlar la visibilidad, los miembros y los permisos de los artefactos y espacios de trabajo;
- eliminar comentarios, artefactos u otros contenidos cuando la función y los permisos lo permitan;
- solicitar acceso, rectificación, eliminación, limitación, oposición, portabilidad o retiro del consentimiento, cuando esos derechos estén disponibles bajo la ley aplicable;
- solicitar información sobre los datos derivados, el origen de una integración y las categorías de proveedores que los reciben.
Para ejercer derechos, escribe a support@hubbound.net con el asunto “Solicitud de privacidad”. Incluye la cuenta, organización o recurso al que se refiere la solicitud, pero no envíes contraseñas, tokens ni claves privadas. Podemos solicitar información razonable para verificar la identidad, proteger a otras personas y evitar solicitudes fraudulentas.
Si la cuenta pertenece a una organización, algunos datos solo pueden ser modificados o eliminados por el administrador de esa organización. HubBound puede conservar información cuando sea necesario para seguridad, prevención de fraude, cumplimiento legal, resolución de disputas o integridad de una transacción.
En Colombia, las consultas de información personal se atienden en un máximo de diez (10) días hábiles; si no es posible responder en ese plazo, se informará la demora y la fecha de respuesta, que no puede superar cinco (5) días hábiles adicionales. Los reclamos de corrección, actualización, supresión o revocatoria se atienden en un máximo de quince (15) días hábiles contados desde el día siguiente a su recepción; la prórroga informada no puede superar ocho (8) días hábiles adicionales. Si consideras que el tratamiento infringe la normativa, puedes presentar una reclamación ante la Superintendencia de Industria y Comercio o la autoridad de protección de datos de tu país.
9Seguridad
Aplicamos medidas técnicas y organizativas razonables y proporcionales al riesgo, que pueden incluir:
- cifrado moderno durante el transporte y controles de acceso por identidad, organización, equipo, recurso y scope;
- rotación, expiración, revocación y almacenamiento protegido de credenciales de sesión;
- tokens de dispositivo vinculados criptográficamente y almacenamiento del material público necesario para validar la prueba;
- URLs de acceso a objetos con expiración corta y permisos limitados;
- separación entre contenido raw, metadatos de procedencia y proyecciones analíticas;
- redacción y listas permitidas para la telemetría predeterminada;
- controles de idempotencia, auditoría, rate limiting, logs de seguridad y monitorización operativa;
- revisión de contenido de artefactos para encontrar riesgos cuando se solicita la auditoría de seguridad.
Ningún sistema puede garantizar seguridad absoluta. La persona usuaria debe mantener actualizado Windows y las herramientas conectadas, proteger sus credenciales y claves privadas, revisar los permisos de GitHub y no subir secretos o información que no sea necesaria.
Si detectas un incidente de seguridad, contacta con support@hubbound.net. No incluyas credenciales ni secretos en el primer contacto.
10Transferencias internacionales
HubBound SAS está constituida en Colombia y utiliza infraestructura principal de AWS en us-east-1. HubBound y sus proveedores pueden procesar datos en países distintos del país de residencia de la persona usuaria. Cuando la ley aplicable lo exija, utilizaremos un mecanismo válido para la transferencia internacional, como una decisión de adecuación, cláusulas contractuales estándar, medidas suplementarias u otro mecanismo reconocido. El DPA empresarial y los contratos aplicables detallarán el mecanismo concreto cuando sea necesario.
La región y la ubicación efectiva pueden variar según el entorno cloud, la organización y el proveedor conectado. La información contractual específica aplicable a una organización puede estar disponible en el acuerdo de servicios o en un anexo de tratamiento de datos.
11Datos locales, cookies y tecnologías similares
La aplicación y el agente local pueden guardar en el dispositivo configuración, credenciales protegidas, claves públicas, identificadores, logs y una cola temporal de entrega. Parte de esa información es necesaria para iniciar sesión, mantener la integración o entregar datos cuando el dispositivo vuelve a estar conectado. El acceso local está sujeto a los controles del sistema operativo y a los permisos de la cuenta que ejecuta la aplicación.
La consola web puede utilizar cookies, almacenamiento local u otras tecnologías estrictamente necesarias para autenticación, seguridad, preferencias y continuidad de sesión. No usamos estas tecnologías para vender datos ni para publicidad comportamental. Si en el futuro incorporamos tecnologías no esenciales, proporcionaremos los controles y avisos exigidos por la ley aplicable antes de activarlas.
12Menores
HubBound es una plataforma para equipos de ingeniería y organizaciones. La clasificación definitiva de edad para la publicación de Microsoft Store debe confirmarse antes de publicar esta versión: si HubBound no está dirigido a menores de 13 años, no se recopilarán deliberadamente datos personales de menores de esa edad; si alguna versión sí se dirige a menores de 13 años o a una edad superior fijada por la ley local, se aplicarán los avisos, controles y consentimientos parentales correspondientes. Si crees que un menor nos proporcionó datos, escribe a support@hubbound.net para que podamos investigarlo y tomar las medidas apropiadas.
13Cambios a esta Directiva
Podemos actualizar esta Directiva cuando cambien las funciones, integraciones, proveedores, requisitos legales o prácticas de conservación. Publicaremos la nueva versión en la URL indicada en Microsoft Store y actualizaremos la fecha de última modificación. Si el cambio es material, mostraremos un aviso dentro del producto o por un canal razonable antes de que sea aplicable cuando la ley lo exija.
La Directiva publicada debe mantenerse coherente con la aplicación, el listado de Microsoft Store, los permisos declarados y la configuración efectiva de producción.
14Contacto
Responsable: HubBound SAS
Contacto legal y de cumplimiento: Angel Eduardo Lindarte Lopez, angel@hubbound.net
Domicilio: Dg 40Sur #34D-23, Bogotá, Colombia
Privacidad: support@hubbound.net
Seguridad: support@hubbound.net
Soporte: support@hubbound.net
Delegado de Protección de Datos: Angel Eduardo Lindarte Lopez, angel@hubbound.net