Términos de servicio

El RGPD europeo, su desarrollo nacional en España mediante la LOPDGDD y el marco equivalente del Reino Unido bajo UK GDPR comparten una idea central: no basta con tratar datos personales; hay que poder explicar por qué se tratan, durante cuánto tiempo, con qué base, bajo qué controles y con qué medidas técnicas y organizativas. Principios como minimización, limitación de finalidad, integridad, confidencialidad, privacidad desde el diseño y responsabilidad proactiva no son simples textos decorativos. En la práctica obligan a diseñar procesos donde el dato personal no viaje más de lo necesario y donde la organización pueda demostrar que eligió una arquitectura razonable para reducir riesgo.

Cleversian se sitúa exactamente antes del punto de exposición. Cuando un usuario quiere usar un texto con IA externa, el producto detecta información personal o sensible, sustituye los valores reales por tokens y conserva la relación en un archivo vault reversible. Esa decisión técnica no convierte automáticamente el tratamiento en conforme al RGPD, pero ayuda a construir una historia de cumplimiento más sólida: la organización no está copiando nombres, DNI, emails, teléfonos, direcciones, datos sanitarios o datos financieros directamente a una herramienta externa; está introduciendo una capa previa de seudonimización y control.

La diferencia importa. En un flujo sin Cleversian, el texto sensible puede salir de la organización como payload completo, quedar en historiales de prompts, integraciones, logs, copias locales o respuestas de terceros. En un flujo protegido, el proveedor externo recibe contexto útil pero no los valores reales que Cleversian haya detectado o que el usuario haya marcado manualmente. Esto puede apoyar evaluaciones internas, políticas de uso aceptable de IA, registros de tratamiento, análisis de riesgo y, cuando proceda, evaluaciones de impacto en protección de datos.

Cleversian no debe describirse como una herramienta de anonimización absoluta. El flujo principal es reversible: si existe un archivo vault y hay permisos válidos y contexto de proceso, los tokens pueden convertirse de nuevo en los datos reales. Bajo los marcos europeos de protección de datos, esa reversibilidad significa que seguimos hablando de datos personales cuando quien controla el archivo vault o la información adicional puede reconstruir la identidad o el contenido original. Esta precisión no debilita el producto; lo hace más honesto y más jurídicamente defendible.

La seudonimización es una salvaguarda reconocida porque separa el contenido útil de la información que permite identificar directamente a una persona. Cleversian aplica esa separación mediante tokens y un archivo vault: el texto protegido puede circular por un flujo de trabajo con menos superficie de exposición, mientras las equivalencias permanecen bajo control del usuario autorizado. El archivo vault no se muestra como tabla de equivalencias en la interfaz pública del flujo, no se comparte entre miembros del workspace y se guarda con cifrado en reposo.

Este modelo está pensado para casos en los que anonimizar completamente destruiría el valor del trabajo. Un abogado puede necesitar restaurar nombres al final de un borrador; un equipo médico puede necesitar recuperar datos reales al revisar una respuesta; un departamento de soporte puede querer resumir incidencias sin entregar identificadores de clientes a la IA. Cleversian conserva esa utilidad, pero desplaza el dato real fuera del prompt externo y limita la restauración a un acto controlado.

El AI Act europeo refuerza una tendencia que ya era visible en compliance, privacidad y ciberseguridad: los sistemas de IA deben usarse con criterios de riesgo, transparencia, supervisión y trazabilidad. Muchas obligaciones concretas dependerán del papel de cada organización, del tipo de sistema usado, de si se trata de IA de alto riesgo, del sector y del uso final. Cleversian no convierte a una organización en cumplidora del AI Act por sí solo, ni sustituye la clasificación jurídica del sistema de IA utilizado.

Lo que sí aporta es una capa previa especialmente relevante para organizaciones que ya han detectado uso informal de IA. En vez de prohibir toda herramienta externa o permitir que cada usuario copie datos reales por su cuenta, Cleversian propone un canal operativo: primero proteger el contenido, después trabajar con la IA elegida y finalmente restaurar solo si corresponde. Ese patrón ayuda a transformar el shadow AI en un procedimiento más gobernable.

Además, Cleversian no utiliza un LLM para decidir qué partes del texto son sensibles en el flujo actual. La detección se basa en reglas, patrones, validadores y sustituciones manuales. Esta decisión reduce la paradoja de enviar el texto completo a una IA para decidir qué debería ocultarse antes de usar IA. Para equipos legales, de seguridad o de DPO, esa diferencia técnica puede ser relevante al documentar por qué se eligió una herramienta de protección previa.

Los datos de salud tienen una sensibilidad especial en prácticamente todos los marcos regulatorios. En Estados Unidos, HIPAA exige salvaguardas administrativas, físicas y técnicas para proteger ePHI cuando aplica a covered entities y business associates. En Europa, el Espacio Europeo de Datos Sanitarios (EHDS) avanza hacia usos primarios y secundarios de datos de salud con especial atención a entornos seguros, reutilización confiable, seudonimización, anonimización cuando proceda y prohibiciones de reidentificación indebida.

Cleversian no debe venderse como una garantía HIPAA ni como una solución EHDS completa. Para eso harían falta contratos específicos, análisis de rol, acuerdos de tratamiento o BAA cuando proceda, controles organizativos, gestión de incidentes, políticas internas y validación jurídica del caso de uso. Sin embargo, si una organización sanitaria quiere usar IA para resumir notas, preparar borradores, clasificar incidencias o trabajar con documentación clínica, la pregunta clave es muy práctica: ¿qué datos reales está copiando fuera del entorno controlado?

La propuesta de Cleversian es reducir esa copia. Detectores como identificadores sanitarios, números de seguridad social, NPI, Medicare MBI, NHS number, Carte Vitale, SIP/TSI, nombres, direcciones, fechas de nacimiento, teléfonos y datos financieros permiten proteger fragmentos especialmente delicados antes de que el contenido llegue a una IA externa. El valor comercial no está en prometer cumplimiento automático, sino en ofrecer una barrera técnica clara entre el dato sanitario real y el procesamiento externo.

NIS2 y DORA no son normas de privacidad en sentido estricto, pero importan mucho para Cleversian porque elevan la exigencia sobre gestión de riesgos, controles, terceros, incidentes, resiliencia digital y documentación. Las organizaciones en sectores esenciales, importantes o financieros no solo deben proteger datos; deben demostrar que gobiernan sus sistemas, sus proveedores y sus flujos operativos.

Cuando un equipo pega datos reales en herramientas externas sin procedimiento, se mezclan varios riesgos: exposición de información sensible, dependencia de terceros, falta de trazabilidad, dificultad para investigar incidentes y ausencia de una política técnica verificable. Cleversian ayuda a cerrar parte de esa brecha proporcionando un flujo reconocible: entrada sensible, seudonimización, texto protegido, archivo vault controlado, restauración autorizada y auditoría sin payload sensible.

La auditoría de Cleversian está diseñada para no convertirse en otro repositorio de información delicada. Registrar que se procesó o restauró un contenido puede ser útil; registrar el texto original, los tokens con equivalencias o la respuesta restaurada sería crear un nuevo riesgo. Por eso el producto guarda eventos operativos seguros y metadata limitada, manteniendo fuera de la auditoría los valores que permitirían reconstruir el contenido sensible.

En Estados Unidos, marcos como CCPA/CPRA en California insisten en derechos del consumidor, información personal, información personal sensible, transparencia y control sobre ciertos usos o comunicaciones de datos. Según el caso, una organización puede tener obligaciones de aviso, acceso, supresión, corrección, limitación de uso de datos sensibles u opt-out. Cleversian no sustituye esos flujos de derechos ni la política de privacidad de cada cliente.

Lo que sí puede aportar es una reducción práctica de exposición en los flujos internos y externos donde aparece información personal sensible. Si un equipo de soporte, operaciones, legal, finanzas o recursos humanos usa IA para transformar contenido, la organización puede preferir que nombres, direcciones, identificadores gubernamentales, datos de salud o datos financieros no salgan en claro. Esa preferencia no es solo técnica; encaja con la expectativa regulatoria de limitar usos innecesarios y controlar mejor los datos que circulan.

Por eso Cleversian está pensado como pieza complementaria dentro de un programa de privacidad, no como programa completo. La gestión de derechos, las bases legales, los avisos, los contratos, la retención documental general y las transferencias internacionales siguen siendo responsabilidad de la organización que decide cómo y para qué usa los datos.