RGPD e IoT industrial: lo que los equipos de mantenimiento predictivo necesitan saber

El punto ciego en el cumplimiento normativo

Sus sensores de vibración no recogen datos personales — ¿o sí lo hacen?

La mayoría de los ingenieros de planta considera el RGPD un problema de marketing y de recursos humanos. Sin embargo, en el momento en que su sistema de mantenimiento predictivo registra acciones de operadores, patrones de turno, asignaciones de equipos vinculadas a personal o incluso direcciones IP de gateways IoT, usted está tratando datos personales según el Artículo 4 del RGPD.

Una encuesta de 2025 del Comité Europeo de Protección de Datos concluyó que el 43 % de las instalaciones industriales de IoT tenían al menos una brecha de cumplimiento del RGPD de la que no eran conscientes. Las multas no son teóricas: en 2025 se impuso a un fabricante alemán una sanción de 1,2 M€ por disponer de un sistema de monitorización que registraba el rendimiento individual de los operadores sin el consentimiento adecuado.

Dónde se encuentran el mantenimiento predictivo y los datos personales

Lo que realmente cuenta como dato personal en el contexto del mantenimiento predictivo:

Claramente personales

• Credenciales de inicio de sesión y registros de sesión de los operadores
• Registros de asignación de turnos vinculados a personas concretas
• Asignaciones de órdenes de trabajo ("El operador Schmidt reemplazó el rodamiento en el Activo 41")
• Tokens de notificación push de la aplicación móvil
• Direcciones de correo electrónico para el enrutamiento de alertas

La zona gris

• Parámetros de operación de máquinas durante turnos concretos (pueden identificar operadores de forma indirecta)
• Registros de mantenimiento con nombres de técnicos
• Registros de control de acceso correlacionados con eventos de equipos
• Grabaciones de vídeo de zonas de maquinaria (aunque estén destinadas a la monitorización de equipos)

No son datos personales

• Lecturas brutas de vibración, temperatura y presión procedentes de sensores
• Predicciones de modelos de ML y puntuaciones de anomalías
• Índices de salud de equipos
• Métricas de producción agregadas

Seis principios para un mantenimiento predictivo conforme al RGPD

1. Minimización de datos — recoja solo lo necesario

El principio: Únicamente deben tratarse los datos personales que sean adecuados, pertinentes y limitados a lo necesario (Artículo 5(1)(c)).

En la práctica:

• Los datos de sensores no necesitan atribución al operador. Una lectura de vibración de la Bomba 7A está referida a la bomba, no a la persona que la opera.
• Si su integración con el CMMS importa nombres de operadores en las órdenes de trabajo, decida: ¿necesita el nombre para el mantenimiento predictivo, o basta con el hecho de que se realizó el mantenimiento?
• Elimine las direcciones IP de los registros de conexión MQTT/OPC-UA a menos que las necesite para auditorías de seguridad.

El enfoque de Prevly: Las lecturas de sensores se almacenan únicamente con asset_id y tenant_id. No se asocia ninguna identidad de operador a los datos de series temporales. Las órdenes de trabajo hacen referencia a roles, no a personas, salvo que el cliente active expresamente el seguimiento de personal.

2. Limitación de la finalidad — defina el porqué

Los datos de sensores recogidos con fines de mantenimiento predictivo no pueden reutilizarse para monitorizar el rendimiento de los operadores sin una base jurídica independiente. Esto parece evidente, pero ocurre constantemente cuando:

• Un responsable de planta pregunta: "¿qué turno registra más fallos de equipos?"
• Recursos Humanos solicita registros de mantenimiento para evaluar los tiempos de respuesta de los técnicos
• Una aseguradora pide datos de incidentes a nivel de operador

Buena práctica: Documente sus finalidades de tratamiento en un Registro de Actividades de Tratamiento (RAT) antes de la puesta en marcha. El acuerdo de tratamiento de datos (ATD) de Prevly limita expresamente el tratamiento a la predicción del estado de los equipos y a la optimización del mantenimiento.

3. Limitación del plazo de conservación — no acumule datos

El principio: Los datos personales no deben conservarse durante más tiempo del necesario (Artículo 5(1)(e)).

El reto en el mantenimiento predictivo: Los modelos de ML mejoran con más datos históricos. Un Weibull-RNN para la predicción de vida útil restante se beneficia de más de dos años de historial de fallos. Pero, ¿necesita dos años de registros de operadores?

Estrategia de retención por niveles: | Tipo de dato | Almacenamiento en caliente | Archivo en frío | Eliminación | |---|---|---|---| | Lecturas de sensores | 90 días | 2 años (S3 Parquet) | Tras vencimiento del archivo | | Predicciones de ML | 1 año | 3 años | Tras vencimiento del archivo | | Registros de auditoría (con IDs de usuario) | 90 días | 1 año | Eliminación obligatoria | | Órdenes de trabajo de operadores | 30 días | Según requisito legal | Según política | | Estadísticas agregadas | Indefinido | — | Nunca (anonimizadas) |

4. Aislamiento multi-tenencia — sus datos permanecen suyos

En el SaaS multi-tenencia, el mayor riesgo para el RGPD no es un atacante externo, sino un error de software que filtra los datos del Inquilino A al Inquilino B.

Requisitos para un aislamiento conforme al RGPD:

• Row-Level Security (RLS): Cada consulta a la base de datos queda automáticamente circunscrita al inquilino autenticado. No es un filtrado a nivel de aplicación, sino una restricción impuesta por la propia base de datos.
• Cifrado en reposo: Claves de cifrado por inquilino (o, como mínimo, aislamiento lógico por inquilino con AES-256).
• Aislamiento de red: Los inquilinos de nivel premium pueden requerir infraestructura dedicada (el RGPD no lo exige, pero los sectores con mayor aversión al riesgo sí lo demandan).
• Pista de auditoría: Quién accedió a qué dato y cuándo. El SOC 2 Type II proporciona esto como consecuencia natural.

5. Transferencias transfronterizas — ¿dónde residen sus datos?

Tras Schrems II, transferir datos personales fuera de la UE exige Cláusulas Contractuales Tipo (CCT) o una decisión de adecuación.

En el ámbito del IoT industrial, esto es relevante cuando:

• Su proveedor de nube dispone de centros de datos fuera de la UE
• Su proveedor de mantenimiento predictivo trata datos en una región no perteneciente a la UE
• Los dispositivos edge transmiten diagnósticos al sistema de soporte de un proveedor ubicado en EE. UU.

Solución: Elija una plataforma con opciones de residencia de datos en la UE. La infraestructura de Prevly opera por defecto en regiones de la UE, con garantías de residencia de datos recogidas en el ATD.

6. Derechos de los interesados — sí, también para los ingenieros

Sus ingenieros de mantenimiento tienen derecho a:

• Acceso a sus datos personales (Artículo 15)
• Rectificación de datos inexactos (Artículo 16)
• Supresión ("derecho al olvido") de sus datos (Artículo 17)
• Portabilidad de datos — exportación de sus datos en un formato legible por máquina (Artículo 20)

Si un ingeniero abandona la empresa y solicita la supresión, ¿puede su sistema de mantenimiento predictivo eliminar su nombre de las órdenes de trabajo históricas preservando al mismo tiempo el historial de mantenimiento?

Diseñe esto desde el primer día. Es mucho más difícil incorporar el cumplimiento del RGPD a posteriori que integrarlo desde el principio.

La lista de verificación

Antes de desplegar mantenimiento predictivo en la UE:

• [ ] Entrada en el RAT para el tratamiento de datos de mantenimiento predictivo. Cree una entrada específica en su Registro de Actividades de Tratamiento que abarque todos los datos relacionados con el mantenimiento predictivo: lecturas de sensores, predicciones de ML, órdenes de trabajo y cualquier dato vinculado a operadores. Incluya la base jurídica (típicamente interés legítimo para la monitorización de equipos, consentimiento para el seguimiento de operadores), las categorías de datos, los destinatarios y los plazos de conservación. Esto es obligatorio en virtud del Artículo 30 para organizaciones con 250 o más empleados, y se recomienda encarecidamente a las más pequeñas.

• [ ] ATD firmado con su proveedor de mantenimiento predictivo. Su Acuerdo de Tratamiento de Datos debe especificar el rol del proveedor (encargado del tratamiento), los tipos de datos tratados, las medidas de seguridad, la divulgación de subencargados y los procedimientos de eliminación de datos a la finalización del contrato. En virtud del Artículo 28, usted está obligado a utilizar únicamente encargados que ofrezcan garantías suficientes. Solicite el informe SOC 2 Type II más reciente o el certificado ISO 27001 como evidencia.

• [ ] Mapa de flujo de datos que muestre por dónde circulan los datos de sensores y los personales. Trace cada salto: sensor → gateway edge → ingesta en la nube → base de datos → pipeline de ML → motor de alertas → canales de notificación. Para cada salto, indique si hay datos personales presentes, qué cifrado se aplica en tránsito (TLS 1.2+) y si los datos cruzan fronteras nacionales. Este mapa es esencial tanto para la EIPD como para responder a consultas de la autoridad de control.

• [ ] Política de retención con eliminación automatizada de datos personales. No confíe en la limpieza manual. Configure reglas de retención automatizadas: lecturas de sensores archivadas a los 90 días, registros de auditoría con IDs de usuario eliminados a los 12 meses, referencias a operadores en órdenes de trabajo anonimizadas en el momento del cese. Pruebe el proceso de eliminación — ejecútelo en un entorno de pruebas y verifique que los datos personales se eliminan efectivamente de las copias de seguridad dentro de un plazo definido (el RGPD no exige eliminación inmediata de copias de seguridad, pero sí un calendario documentado).

• [ ] RLS verificado — aislamiento multi-tenencia probado, no solo documentado. Realice pruebas de penetración dirigidas específicamente al acceso cruzado de datos entre inquilinos. Esto implica: autenticarse como Inquilino A e intentar consultar los datos del Inquilino B a través de cada endpoint de la API, conexión directa a la base de datos y función de exportación. La seguridad a nivel de fila en la base de datos debería hacer esto imposible con independencia de los errores de la aplicación. Documente los resultados de las pruebas.

• [ ] Consentimiento de cookies en cualquier panel web. Sí, el panel de mantenimiento también cuenta. Si se ejecuta en un navegador y establece cookies o utiliza analíticas (aunque sean internas), necesita un banner de consentimiento conforme al RGPD con opciones granulares de aceptación/rechazo. Las cookies "estrictamente necesarias" (autenticación de sesión) no requieren consentimiento; las cookies de analítica y seguimiento sí.

• [ ] Plan de notificación de brechas — comunicación a la autoridad de control en 72 horas. Defina la cadena de escalada: quién detecta la brecha, quién evalúa la gravedad, quién notifica al DPO, quién presenta la comunicación ante la autoridad de control. El plazo de 72 horas comienza cuando usted tiene "conocimiento" de la brecha, no cuando concluye la investigación. Tenga la plantilla de notificación redactada con los campos requeridos por su autoridad de control.

• [ ] EIPD completada si el tratamiento es a gran escala o incluye decisiones automatizadas. Una Evaluación de Impacto relativa a la Protección de Datos es obligatoria en virtud del Artículo 35 cuando el tratamiento crea un riesgo elevado — lo que incluye la monitorización a gran escala (miles de sensores, múltiples instalaciones) y las decisiones automatizadas que afectan a personas (por ejemplo, asignaciones de órdenes de trabajo, métricas correlacionadas con el rendimiento). La EIPD debe identificar los riesgos, las medidas de mitigación y la aceptación del riesgo residual.

Errores frecuentes que conviene evitar

Tres patrones causan sistemáticamente problemas de RGPD en instalaciones industriales de IoT:

Tratar todos los datos de sensores como no personales por defecto. Los datos brutos de vibración son efectivamente no personales. Sin embargo, en el momento en que se combinan con calendarios de turnos, registros de acceso de operadores o asignaciones de mantenimiento, pasan a ser datos personales por asociación. El enfoque más seguro: mantenga los datos de sensores y los datos de personal en almacenes de datos separados, que se combinen únicamente cuando sea explícitamente necesario y con una finalidad documentada.

Confiar en el control de acceso a nivel de aplicación. Si el aislamiento multi-tenencia se aplica en el código de la aplicación ("WHERE tenant_id = ?"), un único error expone a todos los inquilinos. La seguridad a nivel de fila en la base de datos es el estándar conforme al RGPD: impone el aislamiento en la capa de ejecución de consultas, con independencia de la lógica de la aplicación. Cada consulta, cada llamada a la API, cada exportación queda circunscrita por la propia base de datos.

No disponer de capacidad de eliminación de datos personales. Muchos sistemas de mantenimiento predictivo están diseñados para un almacenamiento de series temporales de solo adición, lo cual es excelente para el entrenamiento de modelos de ML pero problemático para el derecho de supresión del RGPD. Diseñe su esquema de forma que los identificadores de operadores en las órdenes de trabajo y los registros de auditoría puedan ser anonimizados (sustituidos por "deleted_user_<hash>") sin destruir el historial de mantenimiento que sus modelos de ML necesitan.

Conclusión

El RGPD no es antiinnovación. Es un marco que le obliga a reflexionar sobre la arquitectura de datos, algo que debería hacer de todos modos en cualquier sistema de mantenimiento predictivo en producción. Las empresas que tratan el cumplimiento normativo como una restricción de diseño (y no como algo secundario) obtienen arquitecturas más limpias, una mejor gobernanza de datos y sistemas en los que sus clientes confían realmente.

Prevly se desarrolló desde el principio pensando en el RGPD: seguridad a nivel de fila, retención por niveles, residencia de datos en la UE, analíticas con consentimiento y APIs de exportación de datos. Porque en el IoT industrial, la confianza no es opcional — es el requisito previo para su primer piloto.

Lecturas relacionadas: Mantenimiento predictivo on-premise vs. en la nube · Mantenimiento predictivo para la fabricación de dispositivos médicos · Monitorización OPC-UA de solo lectura