Aviso de Privacidad

1. Responsable e identificación institucional

Este aviso corresponde al tratamiento de datos personales relacionado con SIG_V1 por STRONGEST GENERAL SERVICE SAC. Cuando intervengan otras empresas, debe identificarse cuál determina las finalidades y cuál actúa por encargo en cada operación; pertenecer a un grupo no otorga acceso general a sus datos.

El aviso anterior incluía datos de ejemplo y afirmaba inscripción de bancos sin documentación comprobada. Esta revisión no presenta esos datos como reales. La identificación completa y los canales operativos deben validarse antes de aprobar el aviso final.

2. A quiénes y a qué operaciones comprende

Comprende datos de trabajadores, extrabajadores, postulantes, personas de contacto de proveedores y clientes, contratistas, usuarios y personas identificadas en registros de gestión. Los visitantes de la pantalla de acceso también pueden generar información técnica relacionada con el servicio.

Se aplica a captura, consulta, modificación, exportación, archivo, respaldos, sincronización y funciones de IA autorizadas. Un aviso para usuarios no sustituye la información que deba entregarse directamente a postulantes, trabajadores o terceros cuyos datos cargue otra persona.

3. Conceptos para comprender el aviso

• Dato personal: información que identifica o permite identificar a una persona, incluso por combinación con otros datos.
• Dato sensible: información que necesita protección reforzada, por ejemplo salud, ingresos económicos o biometría, según la categoría legal aplicable.
• Responsable: quien decide finalidades y medios del tratamiento; encargado: quien actúa por cuenta y bajo instrucciones del responsable.
• Anonimización: tratamiento que impide identificar de manera efectiva. Retirar el nombre no basta si el contexto permite reconocer a la persona.
• Seudonimización o disociación reversible: reduce identificación directa, pero conserva la posibilidad de vinculación y las obligaciones de protección.
• Salida de IA: texto, análisis, imagen, código o recomendación generado; puede contener datos personales y errores.

4. De dónde procede la información

La información puede obtenerse directamente del titular mediante formularios y documentos, a través de personal autorizado que registra procesos, de proveedores vinculados a una gestión legítima y de registros técnicos del aplicativo. Cada área debe registrar su origen y verificar la habilitación correspondiente.

Que un dato esté disponible en internet o en un documento compartido no habilita cualquier reutilización. Si se incorporan fuentes externas o nuevos conjuntos de información, debe evaluarse su compatibilidad con lo informado y evitar información obtenida de manera ilícita o innecesaria.

5. Categorías de datos y límites

Los ejemplos describen categorías y no autorizan recoger todos los campos para todas las personas. Funciones de biometría, localización continua o nuevas inferencias personales requieren evaluación e información específica antes de habilitarse.

6. Finalidades principales

Las áreas deben validar esta matriz contra los procesos efectivamente operativos. Una nueva finalidad no se incorpora por el solo hecho de que el aplicativo permita ejecutarla.

7. Habilitación de cada tratamiento

Cada operación debe asociarse a consentimiento válido o a una excepción legal concreta que permita el tratamiento sin él, según la Ley 29733. Para gestión contractual, laboral y cumplimiento de obligaciones debe documentarse por qué los datos son necesarios y qué disposición resulta aplicable.

Se retira la referencia genérica a interés legítimo como autorización autónoma para todos los registros. Tampoco se presume que el vínculo laboral, la aceptación de términos o el acceso a una cuenta legitimen cualquier finalidad o transferencia.

Las referencias a contrato u obligación legal deben comprobarse por operación. No reemplazan el consentimiento cuando este sea necesario ni eximen de informar al titular.

8. Finalidades opcionales y usos excluidos

No se contempla la venta de datos personales como finalidad de SIG_V1. Este aviso tampoco autoriza publicidad, difusión pública de fotografías, reutilización de expedientes para entrenar modelos o creación de perfiles ajenos a la gestión informada.

Si se propone una finalidad opcional, debe presentarse separadamente y recabarse la autorización que corresponda antes de utilizar datos identificables. Rechazar usos opcionales no debe impedir actividades necesarias ni generar represalias.

Para capacitación y estadísticas debe preferirse información anónima o agregada cuando sea suficiente. El cambio de finalidad no se resuelve llamando anónimo a un conjunto que todavía permite identificar personas.

9. Datos necesarios, opcionales y consecuencias

Los formularios deben diferenciar los datos necesarios de los opcionales y explicar el motivo de la obligatoriedad. No todos los documentos del expediente son necesarios para cada proceso y no debe pedirse información ajena al propósito.

Si no se facilita un dato realmente indispensable, puede no ser posible completar la gestión concreta, por ejemplo verificar identidad, pagar o acreditar un requisito legal. Debe explicarse esa consecuencia específica y evaluarse alternativas, sin bloquear indiscriminadamente el ejercicio de derechos o servicios no relacionados.

10. Lectura del aviso y consentimiento

Leer este aviso y aceptar los términos de uso son actos distintos de otorgar consentimiento para una finalidad que lo requiera. La casilla del login expresa lectura del aviso y aceptación de las reglas de uso; no es autorización general para tratamientos adicionales.

Cuando se necesite consentimiento, debe describir qué información, para qué finalidad y a quién se comunicará, mediante un mecanismo específico y verificable. La entrega de documentos tampoco equivale automáticamente a autorizar todos los usos posibles.

La revocación debe atenderse en el alcance que corresponda sin efectos retroactivos sobre actuaciones válidas. Puede subsistir un tratamiento por otra habilitación legal; en ese caso debe explicarse, limitarse y no reutilizarse para la finalidad revocada.

11. Salud, ingresos y otros datos sensibles

Los datos sensibles deben recibir protección reforzada y acceso restringido. Los responsables operativos deben recibir únicamente la información que necesitan para prevención, adecuación del trabajo o una obligación concreta; los diagnósticos no deben circular en reportes generales.

Los expedientes médicos corresponden a profesionales y responsables competentes. Una conclusión de IA no determina aptitud, diagnóstico ni restricción laboral. Cuando sea necesario consentimiento para datos sensibles, debe utilizarse el mecanismo escrito o equivalente legalmente válido.

Las fotografías o imágenes de firma no se describen automáticamente como identificación biométrica. Si se habilita reconocimiento técnico para identificar personas, debe evaluarse y comunicarse específicamente.

12. Menores y personas vulnerables

SIG_V1 es un aplicativo de uso interno y no se presenta como servicio dirigido a menores. Si un proceso legítimo requiere excepcionalmente sus datos, debe verificarse la representación o capacidad aplicable y ofrecer información comprensible, sin presumir una autorización universal del tutor.

No debe recopilarse por medio de menores información innecesaria sobre su entorno familiar. La carga de sus expedientes a IA exige evaluación y habilitación pertinentes; deben evitarse usos que exploten vulnerabilidades o produzcan efectos discriminatorios.

13. Quiénes pueden acceder

El acceso interno se debe limitar a personal autorizado según función, empresa, proyecto y sensibilidad del expediente. Ser administrador técnico no concede por sí solo competencia para usar datos médicos, económicos o laborales con cualquier propósito.

Podrán intervenir proveedores por encargo, destinatarios vinculados a una gestión habilitada y autoridades competentes cuando corresponda. Deben identificarse los receptores efectivos y limitarse campos y entregas; no se presume que todo destinatario actúe como encargado ni que exista un contrato verificado.

Las entregas a autoridades deben comprobar fundamento y alcance. Los usuarios no deben exportar expedientes por solicitudes informales o compartir enlaces públicos como sustituto de una entrega controlada.

14. Proveedores, nube y conectores

La revisión anterior mencionaba proveedores y contratos como hechos confirmados. Esta tabla los distingue de un inventario contractual todavía no validado. Las condiciones deben verificarse antes de habilitar flujos sensibles y comunicarse con el detalle que corresponda.

15. Otras empresas del grupo

Compartir una plataforma no permite acceso automático entre empresas. Deben identificarse responsables, finalidad y habilitación de cada comunicación, con permisos que eviten exponer expedientes de una empresa a otra por defecto.

Si existe encargo, gestión compartida o transferencia, debe documentarse esa relación y proporcionar la información necesaria a los titulares. La pertenencia al grupo no reemplaza la evaluación de consentimiento o excepción legal aplicable.

16. Transferencias internacionales

Puede existir flujo internacional si un proveedor o destinatario recibe, consulta o conserva información desde otro país. Deben identificarse destinatario, país o ubicación pertinente, finalidad y datos comunicados, incluyendo servicios de IA, soporte y respaldos.

Antes de la transferencia deben comprobarse habilitación y garantías aplicables. La nube no constituye por sí misma una excepción ni prueba protección adecuada. Si el país carece del nivel pertinente, se evaluarán las garantías exigibles y las excepciones legales.

Esta revisión no identifica destinos concretos como confirmados porque faltan contratos e inventario. El aviso final debe completarlos; el RGPD y el Reglamento europeo de IA se evaluarán únicamente cuando su ámbito resulte aplicable.

17. Conservación por tipo de registro

Se sustituye la regla general de cinco años posteriores al vínculo: no es válida para todas las categorías. La conservación depende de finalidad, obligación sectorial, defensa de derechos y categoría documental; cada área debe aprobar un calendario con evento de inicio y eliminación.

Como referencia específica, el artículo 35 del Reglamento de SST establece los plazos que figuran abajo para esos registros. No se extienden automáticamente a todos los exámenes médicos, archivos laborales, documentos contables o conversaciones IA.

Una investigación, reclamación u obligación vigente puede justificar conservar información limitada. Al terminar esa razón debe revisarse su eliminación; no debe transformarse una excepción temporal en conservación indefinida.

18. Eliminación, bloqueo y respaldos

Desactivar una cuenta o marcar un registro como eliminado no equivale a destruir archivos, exportaciones, copias o memoria de IA. Una solicitud debe analizar sus efectos sobre cada repositorio y comunicar qué se elimina, qué se conserva y por qué.

Si existe obligación de conservar, debe limitarse el acceso y tratamiento procedente. Las copias no deben reutilizarse para nuevas finalidades; el procedimiento de restauración debe contemplar las restricciones o supresiones ya atendidas.

La anonimización debe impedir identificación efectiva. Cambiar nombres por códigos o mantener una tabla de correspondencia no equivale automáticamente a anonimizar.

19. Protección y confidencialidad

La protección debe combinar permisos, gestión de cuentas, seguridad de equipos, comunicaciones protegidas, respaldos y procedimientos de incidentes según riesgo. Los usuarios deben custodiar credenciales y evitar enviar expedientes por cuentas personales o canales no autorizados.

Esta revisión no acredita cifrado de respaldos, certificaciones o acceso físico controlado. Se eliminan afirmaciones técnicas no verificadas y se exige contrastarlas con evidencia; no se promete ausencia absoluta de riesgos.

Los registros de operaciones se utilizarán para finalidades definidas de seguridad y trazabilidad, con acceso y conservación limitados. No deben convertirse en vigilancia indiscriminada ni contener contraseñas.

20. Cookies y sesión

En el código revisado, la cookie SIGSESSID identifica la sesión y está configurada con HttpOnly y SameSite=Lax. El atributo Secure se activa cuando el entorno usa HTTPS; por ello no debe afirmarse que opera siempre, incluido el acceso local por HTTP.

Bloquear las cookies necesarias puede impedir autenticación o continuidad de sesión. La lectura del aviso no constituye consentimiento para cookies publicitarias o de seguimiento que pudieran incorporarse.

No se da por concluido un inventario completo de cookies e integraciones externas. Antes de aprobar, deben verificarse recursos cargados, finalidades y duración; las tecnologías opcionales requerirán información y mecanismos pertinentes. Un token de protección de formularios no se describe automáticamente como cookie.

21. Almacenamiento local y uso sin conexión

El código revisado contempla cachés de recursos y de la pantalla de la aplicación, además de reintentos de escrituras cuando falta conectividad. Aunque el service worker excluye las respuestas de determinadas API de su caché, las operaciones pendientes pueden contener datos introducidos por el usuario; no es correcto afirmar que el dispositivo nunca conserva datos personales.

Debe evaluarse el alcance real de los datos locales y sus mecanismos de limpieza, vencimiento y separación por cuenta. Cerrar sesión o desinstalar una PWA no debe presentarse como prueba suficiente de supresión sin verificación.

En equipos compartidos debe evitarse dejar operaciones y descargas accesibles a otra persona. El usuario debe comprobar sincronización y seguir el procedimiento interno para retirar datos locales; esta revisión no modifica el funcionamiento de la cola offline.

22. Privacidad en inteligencia artificial

Consulta el Aviso de Uso de Inteligencia Artificial para conocer su alcance, marco jurídico y condiciones específicas.

Las funciones de IA deben limitarse a tareas autorizadas, datos necesarios y permisos de la fuente. Las consultas, archivos y respuestas pueden contener datos personales; deben revisarse antes de enviar y retirarse secretos e identificadores innecesarios.

La interfaz interna puede utilizar componentes locales o servicios externos. Antes de cargar expedientes debe comprobarse quién recibe la información, su retención, posible entrenamiento y configuración efectiva; este aviso no garantiza que todos los proveedores excluyan entrenamiento.

La incorporación a búsquedas, memoria o índices requiere finalidad y conservación propias. Fragmentos, resúmenes y representaciones vectoriales deben mantener restricciones de empresa, proyecto y usuario; no pueden exponer una fuente a quien carezca de acceso.

No se autoriza con la casilla del login entrenar modelos con datos laborales o médicos. Un nuevo uso requiere evaluación y habilitación; las salidas deben revisarse por exactitud y posibles divulgaciones antes de incorporarlas a documentos o decisiones.

23. Perfiles y decisiones asistidas

Debe informarse de forma específica cuando se utilicen datos para elaborar perfiles o apoyar decisiones relevantes, identificando propósito, factores significativos y vías de revisión. Esta revisión no afirma que exista un módulo de decisión automática activo ni autoriza habilitarlo silenciosamente.

Conforme a la política propuesta en los términos, la IA no decidirá por sí sola contratación, despido, sanción, remuneración, aptitud médica o autorización de una tarea peligrosa. La revisión debe ser competente y permitir corregir resultados, no limitarse a confirmar una recomendación.

Las personas pueden solicitar revisión y ejercer el derecho al tratamiento objetivo dentro de su alcance legal. Deben examinarse sesgos, datos inexactos y consecuencias, con especial cuidado en salud y relaciones laborales.

24. Qué derechos puedes ejercer

• Información y acceso: conocer el tratamiento y obtener tus datos y la información que corresponda.
• Rectificación: corregir información inexacta o incompleta y actualizarla.
• Cancelación o supresión: solicitar eliminación cuando proceda, considerando obligaciones de conservación.
• Oposición: solicitar que no se realice o cese un tratamiento en los supuestos legales.
• Portabilidad: solicitar los datos comprendidos en su alcance y transmisión cuando corresponda y sea técnicamente posible; no supone exportación ilimitada de expedientes ajenos o todas las inferencias.
• Revocación del consentimiento y tratamiento objetivo: solicitar cese de usos consentidos y revisión en el alcance legal pertinente.

El ejercicio ante bancos privados es gratuito, salvo previsión especial aplicable. No debe condicionarse a aceptar nuevos usos ni a renunciar a otros derechos.

25. Cómo presentar una solicitud

El aviso anterior indicaba privacidad@ancosa.com.pe como canal. Debe confirmarse su operatividad y publicarse un canal alternativo válido; mientras se valida, utiliza el canal institucional conocido de STRONGEST GENERAL SERVICE SAC para que el responsable de privacidad reciba y registre tu petición.

• Indica nombre e información necesaria para acreditar identidad o representación, utilizando un canal seguro.
• Describe el derecho y los datos o tratamiento al que se refiere la solicitud; agrega sustento cuando sea pertinente.
• Indica una dirección de respuesta, la fecha y la firma conforme al mecanismo admitido.
• La normativa contempla acreditación con documento de identidad o equivalente; la firma digital válida puede sustituir la presentación de documento y copia. No envíes un DNI a un canal cuya identidad no hayas verificado.
• Solicita constancia de recepción. El responsable debe informar observaciones o pedidos adicionales que procedan y responder de forma clara, motivando cualquier denegatoria.

La atención presencial requiere completar domicilio y punto de recepción. La falta de un formato empresarial no debe impedir tramitar una petición que cumpla los requisitos aplicables.

26. Plazos de respuesta

Se cuentan desde el día siguiente de presentación, conforme a las reglas aplicables. La ampliación, cuando proceda, es por una sola vez y como máximo por plazo igual, con justificación comunicada oportunamente; no aplica al plazo de información.

Las observaciones, subsanaciones o documentación adicional deben tramitarse conforme al reglamento. Portabilidad se analiza dentro del acceso y su alcance; no se asignan veinte días a oposición como hacía el aviso anterior.

Referencia: Reglamento publicado por la ANPD.

27. Reclamaciones y autoridad competente

Si una solicitud no recibe respuesta en plazo, es denegada o se responde de manera insatisfactoria, puedes acudir a la tutela prevista ante la autoridad de protección de datos, siguiendo sus requisitos. Conserva solicitud, constancia de recepción y respuesta cuando exista.

La solicitud previa al responsable corresponde al cauce de tutela de derechos; no se presenta como requisito universal para toda denuncia, comunicación de incidentes o acción legal. Tampoco los canales internos impiden acudir a otras autoridades competentes.

Consulta trámites vigentes en la Autoridad Nacional de Protección de Datos Personales.

28. Incidentes y comunicación a afectados

Ante pérdida, acceso no autorizado o exposición de datos debe informarse inmediatamente al responsable interno por un canal verificado, sin difundir los expedientes. STRONGEST GENERAL SERVICE SAC debe documentar hechos, efectos y medidas y evaluar las comunicaciones exigibles.

El artículo 34 contempla notificación a ANPD dentro de 48 horas desde conocimiento o constancia en los supuestos previstos, como datos sensibles, grandes volúmenes o perjuicio evidente. La comunicación a titulares afectados también procede dentro de 48 horas en el supuesto legal correspondiente, considerando sus excepciones.

Cuando el incidente ocurra en el entorno digital, debe evaluarse además la notificación al Centro Nacional de Seguridad Digital conforme al régimen aplicable. Resolver internamente no elimina por sí solo la obligación de notificar; la información debe ser clara e indicar medidas y contacto.

29. Cambios, aprobación y contacto

Esta revisión documental 2.0 tiene fecha 13 de octubre de 2026 y conserva como antecedente el aviso versión 1.13 de 4 de septiembre de 2026. No cambia la versión del aplicativo ni acredita aprobación institucional.

Antes de su aprobación deben completarse identificación, canales, bancos, destinatarios y países, habilitaciones y calendario de conservación. Los compromisos internos y las condiciones técnicas deben contrastarse con procedimientos y funcionamiento reales.

Los cambios sustanciales se comunicarán identificando finalidad, datos o destinatarios afectados. Cuando haga falta nuevo consentimiento se recabará por separado; silencio o uso continuado no lo sustituyen.

Consulta los Términos y Condiciones y las fuentes oficiales. Canales heredados por validar: privacidad@ancosa.com.pe, seguridad@ancosa.com.pe y dpo@ancosa.com.pe. Su mención no acredita operatividad o designación.