Las gafas inteligentes ya no son un gadget: son una cámara con IA pegada a la cara, y privacidad lo sabe

No hace falta que unas gafas inteligentes lean la mente para plantear un problema regulatorio serio. Basta con algo mucho menos cinematográfico: que incorporen cámara, micrófono, conexión a servicios en la nube y una interfaz diseñada para acompañar al usuario fuera del escritorio, en espacios públicos, reuniones, comercios o centros de trabajo. Ahí empieza el lío de verdad. No por ciencia ficción, sino por cumplimiento.

La conversación sobre wearables conectados suele caer en dos trampas. La primera es el entusiasmo de catálogo: productividad, asistencia contextual, manos libres. La segunda es el alarmismo fácil: vigilancia total, extracción masiva de datos, fin de la privacidad tal y como la conocíamos. La realidad regulatoria es menos melodramática y bastante más incómoda. El problema no es imaginar el peor escenario posible, sino identificar qué obligaciones legales se activan en cuanto un dispositivo portátil capta, transmite o inferiere información vinculada a personas físicas.

Si ese dispositivo se despliega en Europa, el análisis no se agota en el GDPR. Dependiendo del caso, entran también el AI Act, la Directiva de equipos radioeléctricos con sus requisitos de ciberseguridad delegados, el futuro encaje con el Cyber Resilience Act, normas laborales nacionales, reglas sectoriales y, si el uso afecta a entidades financieras o proveedores críticos, piezas como DORA o NIS2. El resultado es poco glamuroso y muy concreto: inventario de tratamientos, base jurídica, transparencia, contratos, evaluación de riesgos, seguridad, gobernanza del proveedor y límites al uso de funcionalidades especialmente intrusivas.

La pregunta útil no es si las gafas inteligentes son “legales” o “ilegales”. Esa pregunta sirve para un titular malo y para poco más. La que sí importa es otra: qué cambia, desde el punto de vista regulatorio y operativo, cuando un dispositivo portátil con capacidades de captura ambiental y procesamiento algorítmico sale del laboratorio y entra en la empresa, en el comercio o en la calle.

El punto ciego habitual: no es el hardware, es el tratamiento

La discusión pública sobre estos dispositivos suele concentrarse en el objeto. Las gafas. El diseño. La cámara visible o casi invisible. Pero el GDPR no regula “gadgets”; regula tratamientos de datos personales. Y ese desplazamiento importa mucho. Lo relevante no es si el dispositivo parece inocuo o futurista, sino si permite identificar directa o indirectamente a una persona, registrar su voz, asociar eventos a una cuenta, crear historiales de uso o alimentar sistemas que generen perfiles o recomendaciones automatizadas.

El artículo 4.1 del GDPR define dato personal de forma amplia: cualquier información sobre una persona física identificada o identificable. El artículo 4.2 hace lo mismo con “tratamiento”: recogida, registro, conservación, consulta, comunicación o supresión, entre otros actos. Traducido al terreno práctico: si un wearable conectado capta imágenes, audio u otros eventos asociados a un usuario o a terceros, lo decisivo no es el brillo del dispositivo, sino la cadena de tratamiento que activa detrás.

Ese matiz evita dos errores frecuentes. Primero, asumir que solo hay problema si existe reconocimiento facial. Falso. Puede haber tratamiento de datos personales sin biometría, sin identificación nominal y sin una base de datos espectacular detrás. Segundo, pensar que el riesgo desaparece porque el proveedor diga que cierta función “no está siempre activa” o que el procesamiento es “inteligente”. Tampoco. El análisis jurídico depende de qué datos se recogen, con qué fin, durante cuánto tiempo, con qué destinatarios y bajo qué medidas de seguridad y transparencia.

En otras palabras: el cumplimiento no empieza cuando alguien presume de IA multimodal. Empieza bastante antes.

Qué puede activar el GDPR aunque el proveedor venda comodidad

Una empresa que quiera introducir gafas inteligentes para asistencia remota, formación, soporte técnico o interacción comercial debería empezar por algo bastante menos sexy que una demo: mapear tratamientos. El artículo 30 del GDPR exige llevar un registro de actividades de tratamiento cuando aplique; incluso cuando una organización crea que entra en alguna excepción formal, apoyarse en un registro claro sigue siendo la única manera sensata de saber qué está ocurriendo.

En ese mapeo hay preguntas incómodas que no se pueden delegar al fabricante:

• Qué capta el dispositivo: imagen, sonido, comandos de voz, eventos de uso o telemetría asociada al servicio.
• Qué se procesa localmente y qué se envía al proveedor: no es lo mismo una función ejecutada en el dispositivo que una transmisión continua o diferida a infraestructura cloud.
• Quién decide los fines y medios esenciales: la clásica cuestión de responsable, corresponsable o encargado bajo los artículos 4.7, 4.8 y 28 del GDPR.
• Qué base jurídica sostiene cada tratamiento: ejecución de contrato, interés legítimo, consentimiento u otra base del artículo 6, según el caso.
• Si aparecen categorías especiales de datos: el artículo 9 del GDPR eleva el listón si el tratamiento revela, por ejemplo, datos de salud o utiliza biometría para identificar de manera unívoca.

Aquí aparece un detalle que muchas implementaciones prefieren ignorar: la misma funcionalidad puede ser jurídicamente tolerable en un contexto y desastrosa en otro. Un sistema de asistencia visual para mantenimiento industrial no plantea los mismos riesgos que un uso en atención al cliente, una consulta médica o un entorno educativo. No porque cambie el aparato, sino porque cambian los datos, los terceros afectados y la expectativa razonable de privacidad.

El artículo 5 del GDPR obliga a respetar principios de minimización, limitación de finalidad y limitación del plazo de conservación. Esa tríada suele quedar muy bonita en una política interna y muy mal en la práctica si el despliegue se hace con la lógica habitual del proveedor tecnológico: activar todo, recopilar todo y ya veremos luego qué utilidad tiene. Reguladoramente, ese “ya veremos” suele acabar mal.

La transparencia tiene un enemigo obvio: los terceros que ni siquiera saben que están dentro

El usuario que se pone unas gafas conectadas puede aceptar términos, pulsar una casilla o firmar una política corporativa. El verdadero quebradero de cabeza son los demás. Clientes, peatones, compañeros de trabajo, proveedores, pacientes, alumnos. Personas que no han iniciado la interacción con el sistema y que, sin embargo, pueden verse afectadas por él.

El GDPR no fue diseñado pensando solo en relaciones bilaterales limpias entre usuario y servicio. Los artículos 13 y 14 exigen información al interesado cuando se recogen datos personales, ya sea directamente o no. En un entorno donde un wearable puede captar información en espacios compartidos, cumplir con ese deber de transparencia no es una nota a pie de página: es un problema operacional de primer orden.

Decir “ya lo pondremos en un cartel” no siempre resuelve nada. Un aviso genérico puede ayudar, pero no sustituye por arte de magia al análisis de proporcionalidad, ni convierte en transparente un flujo de datos complejo, ni elimina la necesidad de definir fines concretos. Menos aún si el dispositivo se usa de forma móvil, en contextos cambiantes y con terceros que apenas pueden entender qué ocurre, quién recibe los datos o si interviene procesamiento algorítmico adicional.

Ese déficit de comprensión no es una sutileza académica. Afecta directamente a la licitud y a la equidad del tratamiento. El artículo 5.1.a del GDPR exige que el tratamiento sea lícito, leal y transparente. “Leal” aquí suele ser la palabra olvidada. Porque una práctica puede intentar apoyarse en una base jurídica y, aun así, resultar problemática si el diseño del servicio diluye deliberadamente la visibilidad de la captación o dificulta que terceros entiendan el alcance del tratamiento.

Interés legítimo: la base jurídica favorita hasta que deja de serlo

Cuando una empresa despliega un wearable con fines operativos, la tentación suele ser apoyarse en el interés legítimo del artículo 6.1.f del GDPR. No es una base jurídica ilegítima ni mucho menos. De hecho, puede ser viable en determinados escenarios. El problema es la versión perezosa de ese argumento: “mejora eficiencia, luego vale”. No funciona así.

El interés legítimo exige una prueba de ponderación real. Hay que identificar el interés perseguido, comprobar la necesidad del tratamiento y sopesarlo frente a los derechos y libertades del interesado. En dispositivos con potencial de captación ambiental, esa ponderación se complica por varios motivos.

Primero, porque la afectación no se limita al empleado o usuario principal. Puede extenderse a terceros que no tienen una relación simétrica con la organización. Segundo, porque existen alternativas menos intrusivas en muchos casos: registros manuales, activación puntual, anonimización funcional, procesamiento local, restricción de grabación o rediseño del flujo operativo. Tercero, porque el desequilibrio contextual pesa. No es igual hablar de un técnico en una planta cerrada con protocolos visibles que de un trabajador atendiendo al público o de un uso continuado en espacios comunes.

Tu empresa puede tener un interés organizativo perfectamente legítimo. Lo que no puede hacer es convertir ese interés en una barra libre para experimentar con captación ubicua. Si el tratamiento implica observación sistemática, recopilación persistente o análisis posteriores que exceden la finalidad inicial, el examen de necesidad se vuelve mucho más duro. Y con razón.

La DPIA no es burocracia: es el documento que te dirá si el proyecto estaba mal planteado

Cuando un despliegue entraña alto riesgo para los derechos y libertades de las personas, el artículo 35 del GDPR obliga a realizar una evaluación de impacto relativa a la protección de datos, la conocida DPIA. En wearables con captura de imagen o sonido en entornos reales, esa posibilidad no es remota. Es, en muchos casos, el punto de partida correcto.

La lógica de la DPIA es simple y bastante menos decorativa de lo que algunos comités internos querrían. Obliga a describir el tratamiento, evaluar necesidad y proporcionalidad, identificar riesgos y definir medidas para mitigarlos. Si se hace en serio, puede desmontar la narrativa triunfal del proyecto en una tarde. Y eso es bueno. Sale más barato descubrir el problema en una DPIA que en una investigación de la autoridad o en una crisis reputacional.

El Comité Europeo de Protección de Datos y varias autoridades nacionales llevan años insistiendo en indicadores de alto riesgo: observación sistemática, uso de tecnologías innovadoras, tratamiento a gran escala, tratamiento de personas vulnerables o combinación de conjuntos de datos. No hace falta que concurran todos a la vez para que salten las alarmas. Un wearable conectado con funciones de captura en movilidad puede encajar en varios de ellos según el caso de uso.

Además, si la DPIA concluye que el riesgo residual sigue siendo alto pese a las medidas previstas, el artículo 36 del GDPR impone consulta previa con la autoridad de control. Ese detalle suele omitirse en las presentaciones comerciales. Quizá porque rompe bastante el ambiente.

Lo laboral es donde el discurso de innovación se estrella contra la realidad

Si las gafas inteligentes se introducen en el trabajo, el análisis ya no puede quedarse en privacidad generalista. Entra de lleno el problema del poder de dirección, la monitorización y la asimetría entre empresa y empleado. Y aquí el consentimiento rara vez salva a nadie. El propio marco europeo ha sido constante al recordar que, en relaciones laborales, el consentimiento suele ser problemático por el desequilibrio entre partes.

Eso desplaza la discusión a otras bases jurídicas y, sobre todo, a la proporcionalidad de la medida. Una empresa puede querer asistencia remota, control de calidad o soporte en campo. Pero si el resultado práctico es una herramienta que intensifica vigilancia, genera trazabilidad excesiva del comportamiento o permite reutilizar datos para evaluación de desempeño más allá del fin inicial, el riesgo jurídico aumenta de forma visible.

No hay una respuesta única válida para todos los Estados miembros porque el empleo se cruza con derecho laboral nacional, negociación colectiva y criterios de autoridades de protección de datos. Lo que sí puede afirmarse con seguridad es esto: cuanto más cerca esté el wearable de la supervisión continua del trabajador, más difícil será defender su necesidad, su proporcionalidad y la minimización exigida por el artículo 5 del GDPR.

La pregunta que conviene hacer en comité no es “podemos técnicamente activarlo”, sino “qué pasará cuando recursos humanos, seguridad, operaciones y compliance quieran usar los mismos datos para fines distintos”. Porque pasará. Siempre pasa.

La biometría importa, pero no conviene usarla como comodín retórico

En cuanto aparece una cámara cerca de la cara, el debate se desliza rápido hacia reconocimiento facial, autenticación biométrica o inferencia emocional. A veces con razón. Otras veces por pura inercia narrativa. Conviene separar planos.

El artículo 4.14 del GDPR define datos biométricos como datos personales obtenidos a partir de un tratamiento técnico específico relativos a características físicas, fisiológicas o conductuales que permitan o confirmen la identificación única de una persona física. El artículo 9 sitúa esos tratamientos, cuando se usan para identificar de manera unívoca, dentro de las categorías especiales de datos, salvo que concurra una excepción aplicable.

Eso significa dos cosas. La primera: no toda imagen captada por un dispositivo es automáticamente un tratamiento de datos biométricos. La segunda: si el sistema incorpora funciones de autenticación o identificación basadas en rasgos físicos, el listón jurídico sube mucho. Y sube con motivo. Las empresas no deberían usar la palabra “biometría” para parecer sofisticadas ni evitarla para parecer menos intrusivas. Deberían describir exactamente qué hace el sistema.

La precisión terminológica aquí no es pedantería legal. Es la diferencia entre un tratamiento ordinario con riesgos altos y uno que puede entrar de lleno en el régimen del artículo 9, con consecuencias materiales para la base jurídica, la DPIA, las medidas de seguridad y la propia viabilidad del caso de uso.

Y la IA? Importa, pero no como muletilla comercial

Meter “IA” en la discusión añade más ruido que claridad si no se concreta la función. Un wearable puede incorporar modelos para transcripción, resumen, asistencia contextual, clasificación de objetos, traducción o activación por voz. Cada una de esas funciones tiene implicaciones distintas. El análisis serio no debería arrancar con “lleva IA”, sino con tres preguntas bastante menos glamourosas: qué hace el sistema, con qué datos y con qué efecto sobre las personas.

Cuando entra en juego el AI Act de la UE, la cuestión relevante no es repetir que la norma existe, sino identificar si el sistema o alguno de sus componentes puede encajar en categorías reguladas de forma específica, incluidas las prácticas prohibidas del artículo 5 o los supuestos de alto riesgo del artículo 6 y los anexos correspondientes. En muchos despliegues de wearables, la respuesta no será automática ni evidente. Dependerá del uso concreto, del sector, de la finalidad y de si la IA influye en decisiones que afecten a derechos, acceso a servicios o relaciones laborales.

Aquí conviene mantener la cabeza fría. Ni todo wearable con funciones algorítmicas entra en la parte más severa del AI Act, ni el AI Act es irrelevante porque el dispositivo parezca un accesorio de consumo. Lo prudente es revisar el caso de uso real y, si hay componentes de IA, analizarlos funcionalmente: clasificación, inferencia, recomendación, autenticación, monitorización o toma de decisiones asistida.

Eso exige un trabajo que muchos proveedores preferirían ahorrarse: documentación técnica comprensible, delimitación del sistema, explicación de entradas y salidas, y claridad contractual sobre quién asume qué obligación. Sin eso, cualquier conversación sobre IA en wearables es marketing con pretensiones regulatorias.

Seguridad: no basta con decir que el dispositivo va cifrado

La ciberseguridad de wearables conectados tiene un defecto de origen: demasiadas organizaciones la reducen a una pregunta de arquitectura y demasiado pocos la conectan con obligaciones legales concretas. El artículo 32 del GDPR exige medidas técnicas y organizativas apropiadas al riesgo. No dice “pon cifrado y ya”. Habla de confidencialidad, integridad, disponibilidad, resiliencia, restauración y verificación periódica de la eficacia de las medidas.

Aplicado a gafas inteligentes y dispositivos similares, eso obliga a revisar bastante más que el cifrado en tránsito. Por ejemplo: autenticación del usuario, gestión de sesiones, emparejamiento con otros dispositivos, endurecimiento del sistema, capacidad de borrado remoto, gestión de vulnerabilidades, registros de acceso, segregación de entornos, actualizaciones seguras, minimización del dato sincronizado y controles para evitar activaciones accidentales o usos no autorizados.

Si el fabricante o proveedor cloud actúa como encargado, el artículo 28 del GDPR exige un contrato con instrucciones documentadas, garantías suficientes y condiciones claras sobre subencargados, seguridad, asistencia al responsable y supresión o devolución de datos. Ese contrato suele presentarse como un trámite. No lo es. En servicios basados en plataformas cerradas, el contrato es a veces el único lugar donde descubrirás que el proveedor se reserva márgenes demasiado amplios sobre retención, uso para mejora del servicio o localización de tratamiento.

En sectores críticos, la conversación escala aún más. NIS2, en su artículo 21, impone medidas de gestión de riesgos de ciberseguridad a entidades esenciales e importantes, incluyendo seguridad de la cadena de suministro, gestión de incidentes, continuidad, criptografía e higiene básica. Y si hablamos de entidades financieras bajo DORA, la película se vuelve todavía más específica: gobernanza del riesgo TIC, gestión de incidentes, pruebas de resiliencia y control de terceros proveedores TIC, con un capítulo entero dedicado a estos últimos en el Título V y, en particular, a la gestión del riesgo derivado de terceros en los artículos 28 y siguientes.

La lección es menos épica de lo que sugiere el marketing del sector: si no sabes cómo se actualiza, qué registra, qué transmite y qué dependencia crea del proveedor, no estás comprando innovación; estás comprando superficie de riesgo con una montura bonita.

Los metadatos también cuentan, pero conviene no fantasear con la lista

Una parte del riesgo en dispositivos conectados no se juega solo en el contenido captado, sino en la información derivada del uso del servicio: eventos de conexión, registros técnicos, identificadores de cuenta, tiempos de acceso, datos de diagnóstico o telemetría necesaria para operar, mantener o asegurar la plataforma. Ese universo paralelo suele tratarse como si fuera inocuo por definición. No lo es.

El GDPR no distingue entre “dato interesante” y “dato aburrido”; distingue entre dato personal y lo que no lo es. Si un conjunto de registros técnicos puede vincularse a una persona, directa o indirectamente, entra en el perímetro regulatorio. Y a partir de ahí vuelven a aplicar los mismos principios de finalidad, minimización, seguridad y transparencia.

Conviene ser precisos. No toda categoría de telemetría debe darse por supuesta en cualquier modelo o servicio, y no todas las implementaciones recopilan los mismos datos técnicos. Lo que sí puede afirmarse de forma sólida es que los dispositivos conectados y las plataformas asociadas suelen generar logs, identificadores, datos operativos o diagnósticos cuya gestión también exige base jurídica, delimitación de fines y controles de acceso. Ignorarlo porque “solo son metadatos” es una forma bastante eficiente de incumplir sin hacer ruido.

Transferencias internacionales: el problema reaparece en cuanto miras el stack del proveedor

Muchas organizaciones evalúan el wearable, pero no el ecosistema. Error clásico. El tratamiento raramente termina en el dispositivo. Hay aplicaciones móviles, paneles de administración, servicios de soporte, analítica, almacenamiento, modelos de transcripción o moderación, y capas de terceros que el cliente descubre cuando ya ha firmado.

Si hay transferencias de datos personales fuera del Espacio Económico Europeo, entran en juego los artículos 44 y siguientes del GDPR. Y aquí la pregunta útil no es “el proveedor tiene presencia en Europa”, sino “dónde se tratan realmente los datos, quién puede acceder a ellos y bajo qué mecanismo de transferencia”. Decisiones de adecuación, cláusulas contractuales tipo, evaluaciones complementarias: nada de esto desaparece porque el dispositivo se venda como producto de consumo elegante reconvertido en herramienta empresarial.

Más aún: un servicio puede alojar datos en la UE y seguir implicando accesos remotos desde terceros países para soporte, mantenimiento o desarrollo. Ese detalle suele aparecer tarde, a menudo en anexos contractuales espesos y redactados con admirable vocación disuasoria para el lector.

Si tu organización no ha pedido un mapa claro de subprocesadores, localización y flujos de acceso, no ha terminado la diligencia debida. Apenas ha empezado.

Cuando el caso de uso toca salud, educación o finanzas, el margen se estrecha

Hay sectores donde el análisis general se queda corto muy deprisa. Si un wearable se usa en asistencia sanitaria o gestiona información clínica, el problema ya no es solo la captura contextual, sino la posibilidad de tratar datos de salud bajo el artículo 9 del GDPR y la necesidad de apoyarse en una excepción válida, además de cumplir las exigencias nacionales y sectoriales correspondientes. En ese terreno, improvisar con políticas internas suele acabar exactamente igual que cabría esperar.

En educación, el tratamiento puede afectar a menores, lo que endurece todavía más la evaluación de expectativas, transparencia y proporcionalidad. Y en servicios financieros o infraestructuras críticas, un dispositivo así puede convertirse en una pieza más del perímetro TIC, con implicaciones de seguridad, dependencia de proveedor y continuidad de negocio que trascienden la privacidad clásica.

Para entidades financieras, DORA no menciona “gafas inteligentes” como categoría autónoma, obviamente, pero sí obliga a gestionar el riesgo TIC de forma integral. Si el dispositivo o la plataforma asociada soporta procesos relevantes, canaliza datos sensibles o depende de un tercero para funciones operativas, no queda fuera del radar por tener forma de accesorio. DORA se fija en la función, no en la estética del aparato. Una buena cura de humildad para cierto entusiasmo de compras.

El proveedor no te presta cumplimiento como servicio

Este es uno de los malentendidos más persistentes del sector. El fabricante puede ofrecer documentación, ajustes de privacidad, certificaciones parciales o controles de seguridad. Todo eso ayuda. Nada de eso traslada automáticamente la responsabilidad jurídica principal del tratamiento cuando tu organización decide los fines y utiliza el sistema en su operativa.

El artículo 24 del GDPR obliga al responsable a aplicar medidas apropiadas y poder demostrar que el tratamiento es conforme. Poder demostrarlo. Esa parte suele olvidarse hasta que alguien pide evidencias. Y las evidencias no son eslóganes del proveedor ni diapositivas comerciales con palabras como “trust”, “responsible AI” o “privacy by design” en tamaño 36.

Lo que sí sirve es algo bastante más pedestre: DPIA bien hecha, contrato del artículo 28 cuando proceda, instrucciones documentadas, matriz de accesos, política de retención, controles técnicos verificables, formación al personal, procedimiento de incidentes y un criterio claro sobre qué funciones están prohibidas o limitadas. El cumplimiento serio casi nunca luce bien en una keynote. Mala suerte.

Privacidad desde el diseño: o limitas funciones al principio o no las limitarás nunca

El artículo 25 del GDPR exige protección de datos desde el diseño y por defecto. Esa obligación encaja como un guante en wearables conectados, precisamente porque el riesgo no se controla bien a posteriori. Si el despliegue arranca con grabación amplia, retención generosa, acceso interno difuso y poca segmentación funcional, intentar “corregir” después suele ser caro, incompleto y políticamente difícil dentro de la organización.

Lo razonable es decidir antes del despliegue qué capacidades quedan desactivadas por defecto, qué eventos se registran, cuánto tiempo se conservan, quién puede acceder a ellos, qué finalidades quedan vetadas y cómo se informa a usuarios y terceros. También conviene separar, si es posible, funciones locales de funciones cloud, y evitar que mejoras opcionales del servicio se activen silenciosamente mediante actualizaciones o cambios unilaterales del proveedor.

Tu organización debería tener una lista de “líneas rojas” mucho antes del piloto. Por ejemplo: no reutilizar datos para evaluación laboral salvo base jurídica y análisis específico; no mantener audio o vídeo más allá del tiempo estrictamente necesario para la finalidad definida; no permitir accesos generalizados a registros operativos; no activar funciones de análisis personal sin evaluación independiente; no ampliar fines por la puerta de atrás mediante cláusulas ambiguas del proveedor.

Si estas decisiones se dejan para el final, ya sabes el resultado: el negocio se enamora del caso de uso, compras firma el contrato, seguridad intenta apagar incendios y privacidad recibe una invitación a “acompañar” cuando el tren ya ha salido de la estación.

Incidentes y brechas: el reloj corre igual aunque el dispositivo sea pequeño

Cuando un wearable conectado pierde datos, expone grabaciones, permite acceso no autorizado o filtra información asociada a usuarios, el tamaño del dispositivo no ablanda el régimen de notificación. Si hay una violación de seguridad de los datos personales, el artículo 33 del GDPR obliga al responsable a notificarla a la autoridad de control competente sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia, salvo que sea improbable que constituya un riesgo para los derechos y libertades de las personas físicas.

Si el riesgo es alto, el artículo 34 añade la posible comunicación a los afectados. Otra vez: no importa si el incidente se originó en el hardware, la aplicación móvil, la API del proveedor o una consola de administración mal securizada. Desde fuera, la autoridad verá un tratamiento y pedirá responsabilidades, evidencias y cronología.

Por eso los despliegues serios incluyen algo más que una cláusula de notificación en el contrato. Incluyen pruebas de respuesta, responsables claros, acceso a registros y plazos operativos realistas para que el proveedor informe al cliente con suficiente antelación. Porque 72 horas parecen muchas hasta que descubres que nadie sabe quién tenía las logs, qué datos salieron o si el servicio subcontratado de soporte estaba en otra jurisdicción.

Lo que una empresa sensata debería hacer antes del piloto

Si estás evaluando un despliegue real, la secuencia correcta no empieza comprando diez unidades “para probar”. Empieza con gobernanza. Y sí, eso suena menos divertido. También evita errores caros.

• Define el caso de uso con una finalidad cerrada. Si la finalidad admite cinco reinterpretaciones internas, todavía no está definida.
• Haz una preevaluación jurídica y de riesgo. Identifica si habrá captura de terceros, tratamiento en movilidad, categorías especiales, decisiones asistidas por IA o dependencia relevante del proveedor.
• Solicita documentación técnica y contractual suficiente. No folletos. Flujos de datos, localización del tratamiento, subencargados, retención, seguridad, soporte y cambios funcionales.
• Determina si procede DPIA bajo el artículo 35 del GDPR antes del piloto, no después de que operaciones se entusiasme con los primeros resultados.
• Configura privacidad por defecto conforme al artículo 25: desactivación de funciones no necesarias, retención mínima, acceso restringido y registros controlados.
• Alinea seguridad y terceros con el artículo 32 del GDPR, y si aplica, con NIS2 art. 21 o DORA arts. 28 y siguientes sobre terceros TIC y gestión del riesgo.
• Prepara transparencia real para usuarios y terceros afectados, con avisos comprensibles y coherentes con el tratamiento efectivo.
• Fija límites internos por escrito. Qué no se puede hacer con esos datos importa casi más que lo que sí se permite.

Esta lista no garantiza que el despliegue sea aceptable. Garantiza algo más humilde y bastante valioso: que la organización entienda de verdad qué está intentando hacer.

La objeción habitual: “si el móvil ya hace todo eso, por qué tratar distinto a las gafas”

Es una objeción razonable, y no conviene despacharla con superioridad. Un smartphone ya permite captar imagen, audio, ubicación, comunicación y una cantidad nada despreciable de datos de uso. Entonces, qué cambia?

Cambian varias cosas. La primera es la fricción. Un móvil exige un gesto más visible para captar o consultar información; unas gafas pueden integrar la interacción en un flujo más continuo y menos perceptible para terceros. La segunda es la expectativa social: no reaccionamos igual ante alguien que levanta un teléfono para grabar que ante un dispositivo portátil que puede captar en segundo plano mientras el usuario mantiene una interacción aparentemente normal. La tercera es el contexto de uso: las gafas están diseñadas para acompañar la percepción, no solo para sustituir una pantalla.

Eso no convierte automáticamente a las gafas en una categoría prohibida. Sí justifica un escrutinio más fino de transparencia, minimización y proporcionalidad. En regulación tecnológica, las diferencias de interfaz suelen acabar siendo diferencias de riesgo. Y a veces muy sustanciales.

Mi lectura: el verdadero debate no es innovación versus privacidad, sino diseño responsable versus oportunismo funcional

A estas alturas ya sabemos cómo funciona cierta retórica corporativa. Primero se lanza una capacidad técnica. Después se prueban usos expansivos. Más tarde llega la incomodidad pública. Y, finalmente, aparecen presentaciones solemnes sobre uso responsable. El orden casi nunca falla.

Con wearables conectados, el problema regulatorio serio no es que exista una tecnología nueva, sino la combinación de tres impulsos bastante viejos: recopilar más de lo necesario, conservar más de lo justificable y reutilizar datos para fines cada vez más amplios. Si un despliegue evita esos tres reflejos, hay espacio para usos legítimos y defendibles. Si no los evita, ninguna estética futurista arreglará el expediente.

El mensaje incómodo para fabricantes y compradores es el mismo: la pregunta ya no es solo qué puede hacer el dispositivo, sino qué deberías prohibirte hacer con él aunque técnicamente sea posible. Ese es el umbral real de madurez. Lo demás es una demo.

Qué hacer ahora

Si tu organización está explorando gafas inteligentes o cualquier wearable con funciones de captura y asistencia algorítmica, no pidas primero una prueba de concepto. Pide primero cuatro cosas: mapa de datos, arquitectura de tratamiento, límites funcionales y borrador de DPIA. Si el proveedor no puede responder con claridad, o responde con marketing, ya tienes una señal bastante útil.

La regulación europea no impide por defecto estos despliegues. Lo que sí impide, y cada vez con menos paciencia, es la mezcla de opacidad, exceso de recogida y dependencia contractual mal entendida que tantas veces acompaña a la tecnología cuando sale al mercado con prisa. Las gafas pueden ser nuevas. Los errores de compliance, desde luego, no lo son.