Política de tratamiento de datos personales

La entidad jurídica responsable de operar la Extranet deberá identificarse aquí con su razón social, RUT, domicilio y un canal permanente para titulares y para la Agencia de Protección de Datos Personales.

El borrador cubre la Extranet, sus módulos, autenticación, SSO, APIs, integraciones, formularios y archivos asociados. Comprende las siguientes categorías de titulares:

• Usuarios y administradores de la Extranet Belator.
• Representantes y contactos de empresas clientes.
• Personas que solicitan acceso mediante el formulario público.
• Personas mencionadas en comprobantes, adjuntos o evidencias cargadas por usuarios autorizados.

• Identificación y contacto: nombre, apellidos, RUT, correo, teléfono y datos de representantes.
• Laborales y organizacionales: tenant, empresa, rol, privilegios, módulos y vinculaciones.
• Autenticación y seguridad: hashes de credenciales, MFA, passkeys, sesiones y equipos confiables.
• Técnicos y de auditoría: IP, dispositivo, navegador, eventos, cambios, fechas y resultados.
• Geolocalización: país o ciudad aproximada por IP y, con autorización específica, ubicación exacta.
• Operacionales y financieros: uso de módulos, estados de cobro, comprobantes y reportes.
• Contenido no estructurado: mensajes, adjuntos, evidencias, avatares y documentos cargados.

Cada finalidad proviene del catálogo técnico LPDP-DOC-01. Las bases todavía requieren aprobación jurídica y pueden ajustarse antes de la publicación definitiva.

• Existe un registro interno LPDP-DOC-10 para clasificar encargados, subencargados, responsables independientes, destinatarios y aplicaciones conectadas.
• La inclusión técnica en whitelist, SSO o APP to APP no determina por sí sola la relación jurídica del tercero.
• Cada transferencia internacional debe identificar países y acreditar un mecanismo aplicable antes de aprobar el servicio.
• La publicación definitiva deberá basarse exclusivamente en proveedores, contratos, ubicaciones y garantías confirmados.

• Sesiones, códigos, desafíos y equipos confiables tienen vencimientos técnicos configurables.
• Códigos SSO se depuran después de una ventana técnica y las sesiones SSO vencidas o revocadas tienen mantenimiento programable.
• La auditoría activa se archiva después de 90 días; el plazo final del archivo aún debe aprobarse.
• La ubicación exacta se registra solo en el evento de login autorizado y no se replica durante la renovación de sesión; su supresión o generalización final aún debe automatizarse.
• Cuentas, contactos, correos, comprobantes, evidencias, logs y respaldos aún requieren plazos formales por finalidad.
• Los datos precontractuales deben suprimirse o anonimizarse cuando termine la gestión, salvo otra base aplicable.

Los plazos indicados describen reglas técnicas actuales, no una política legal aprobada. La versión publicada deberá informar periodos definidos o criterios claros para determinarlos.

• Acceso a los datos personales tratados y a información sobre su tratamiento.
• Rectificación de datos inexactos, incompletos o desactualizados.
• Supresión cuando concurra una causal legal.
• Oposición al tratamiento en los casos previstos por la ley.
• Portabilidad cuando resulte aplicable y técnicamente procedente.
• Bloqueo temporal durante una revisión o controversia cuando corresponda.
• Retiro del consentimiento sin afectar la licitud del tratamiento anterior a su retiro.

El canal, verificación de identidad, plazos y procedimiento de reclamación se implementarán en el bloque LPDP-DOC-04. Mientras estén pendientes, este borrador no debe presentarse como mecanismo vigente.

• Control de acceso por rol, tenant, empresa y privilegio de módulo.
• Contraseñas y tokens protegidos mediante hash, y secretos críticos mediante cifrado cuando corresponde.
• MFA, TOTP, passkeys, equipos confiables y Step-up MFA para acciones configuradas como críticas.
• Cookies seguras, sesiones revocables, PKCE, scopes, whitelist y controles APP to APP.
• Auditoría, respaldos, validación de uploads y medidas de monitoreo e investigación.

Por seguridad, la política pública describe categorías de controles y no revela secretos, claves, configuraciones internas ni procedimientos que faciliten eludirlos.

• La Extranet está orientada a relaciones empresariales. Antes de publicar debe definirse cómo se impedirá o regulará el acceso de menores de edad.
• El catálogo actual no identifica decisiones automatizadas que produzcan efectos jurídicos o significativamente similares; esta declaración debe verificarse en cada nuevo módulo.
• La ubicación aproximada por IP puede incluir país, región, ciudad y coordenadas estimadas para seguridad del acceso; su base definitiva y test de ponderación siguen pendientes de aprobación.
• La ubicación exacta no es necesaria para ingresar. La decisión afirmativa o negativa se guarda de forma versionada en el navegador hasta que la persona la cambie; solo se registra ubicación exacta en un login cuando existe autorización y el navegador entrega las coordenadas.
• OpenStreetMap recibe coordenadas únicamente cuando una persona autorizada abre la visualización de mapa; no recibe automáticamente cada inicio de sesión.
• Una passkey puede validar biometría localmente, pero la Extranet recibe clave pública y prueba criptográfica, no la huella o el rostro del usuario.
• Los módulos externos pueden tener finalidades propias y deberán entregar información adicional cuando actúen como responsables independientes.

Versión del borrador

0.4

Publicación y vigencia

Pendientes de aprobación jurídica.

La política aprobada deberá conservar un historial de versiones y comunicar cambios relevantes antes de que produzcan efectos. El texto oficial de la Ley 21.719 puede consultarse en la Biblioteca del Congreso Nacional.