Política de Privacidad

Resumen ejecutivo

• Doble rol: Responsable de datos de cuenta + Encargado de datos del cliente
• 3 categorías de datos: cuenta, uso del producto, datos del cliente (incluidas las grabaciones de voz que se dicten en la aplicación)
• Bases legales art. 6: consentimiento, contrato, interés legítimo, obligación legal
• No tomamos decisiones automatizadas con efectos jurídicos: las acciones críticas requieren aprobación humana
• No entrenamos modelos con tus datos · el proveedor de inferencia trabaja con retención cero y sin uso para entrenamiento
• El contenido que procesan los agentes se trata en la UE; el correo transaccional sale a EE. UU. bajo Cláusulas Contractuales Tipo
• Derechos RGPD arts. 15-22 ejercitables en [email protected]

Esta Política de Privacidad describe cómo AIGiner S.L. (en adelante, "AIGiner", "nosotros") trata los datos personales en relación con el sitio web sharasaas.com y el servicio Shara —en su acceso por navegador, en su aplicación de escritorio y en los agentes que el Cliente instale en sus equipos—, en cumplimiento del Reglamento (UE) 2016/679 (RGPD) y la Ley Orgánica 3/2018 de Protección de Datos Personales y Garantía de los Derechos Digitales (LOPDGDD).

AIGiner S.L. tiene CIF B93819753 y está inscrita en el Registro Mercantil de Barcelona (hoja B-662372, inscripción 1ª). Los datos registrales completos figuran en el Aviso Legal (/aviso-legal).

1. Doble rol: Responsable y Encargado

En Shara actuamos en dos roles diferenciados respecto del RGPD, separados con precisión técnica y contractual:

• Responsable del tratamiento respecto de los datos de cuenta del cliente y los datos generados por el uso del propio servicio (registros operativos, métricas de consumo, facturación, soporte). Esto se rige por la presente Política.
• Encargado del tratamiento (art. 28 RGPD) respecto de los datos personales que nuestros clientes (Responsables) alojan en Shara y que tratamos por cuenta suya cuando los agentes IA ejecutan sus tareas. Estas actuaciones se rigen por el Acuerdo de Encargado de Tratamiento (DPA) (/dpa) que el Cliente acepta al contratar el servicio.
• En esta política nos centramos en el rol de Responsable. Los datos que tratamos como Encargado se rigen por el DPA y están sujetos a las instrucciones documentadas del Cliente.

2. Responsable del tratamiento

• Responsable: AIGiner S.L. · CIF B93819753
• Domicilio: Gran Via de Carles III, 98, 08028 Barcelona, España
• Email general: [email protected]
• Privacidad: [email protected]
• Contacto de protección de datos: [email protected]. No hemos designado un Delegado de Protección de Datos conforme al art. 37 RGPD, porque el tratamiento no se encuentra en ninguno de los supuestos que lo exigen. Esa dirección es un buzón atendido por el responsable, y se usa para las solicitudes formales; si en algún momento designamos un DPO, lo publicaremos aquí con sus datos.

3. Glosario rápido

• Responsable del tratamiento: Quien decide el "para qué" y el "cómo" del tratamiento. AIGiner es Responsable de los datos de cuenta y operativos.
• Encargado del tratamiento: Quien trata datos por cuenta de un Responsable. AIGiner es Encargado de los datos del cliente que procesa cuando los agentes ejecutan tareas.
• Subencargado: Tercero al que el Encargado delega parte del tratamiento (el proveedor de inferencia, Supabase, Stripe, Resend...). Listado en /sub-encargados.
• Datos del cliente: Información que el Cliente conecta o sube a Shara (correos, contactos, facturas, documentos de recursos humanos, grabaciones de voz dictadas en la aplicación, etc.). El Cliente es Responsable y AIGiner Encargado.
• STU ("Shara Token Units"): unidad interna de medida del consumo de cómputo de modelos.
• Ejecución de agente: cada tarea individual que ejecuta un agente. Queda registrada con su identificador, el agente, el alias del modelo, una huella del prompt, los tokens y la latencia.
• Ficha de identidad del agente: fichero de contexto por agente que recoge las preferencias del Cliente. Se actualiza de forma incremental, nunca por sustitución, y cada cambio queda registrado.
• Cola de aprobación: cola de acciones críticas (envío de correo externo, pagos, decisiones de personal) que requieren aprobación humana antes de ejecutarse.

4. Datos personales que tratamos

4.1 Datos de cuenta y contacto

4.2 Datos de uso del producto

4.3 Datos del cliente (tratados como Encargado)

Cuando un agente IA de Shara procesa correos, contactos, facturas, documentos de recursos humanos u otros datos que el Cliente conecta al producto, actuamos como Encargado de tratamiento. El Responsable (Cliente) determina el contenido, la finalidad y la duración de ese tratamiento; nosotros lo realizamos siguiendo sus instrucciones documentadas y las obligaciones del DPA (/dpa). Estos datos no se utilizan para fines propios ni para entrenar modelos.

Voz. La aplicación permite dictar por micrófono. La grabación es un dato personal, y puede contener datos de terceros si se dicta el nombre o los asuntos de un cliente. La transcripción se resuelve en el propio equipo cuando el modelo local está disponible; en caso contrario, el audio se envía al proveedor de inferencia —que opera en la Unión Europea— exclusivamente para transcribirlo, con retención cero y sin uso para entrenamiento. Ni la grabación ni su transcripción se conservan más allá de lo necesario para devolverte el texto y, si tú lo envías, para la conversación en la que lo uses. El micrófono solo se activa cuando el usuario lo pulsa.

Concerto Local. En el plan de despliegue en la infraestructura del Cliente, los modelos se ejecutan en sus propios servidores: ese tratamiento no pasa por nuestros sistemas. Solo lo hacen las tareas que el Cliente decida delegar expresamente a la cuota de orquestación en la nube, y únicamente si mantiene esa opción activada.

5. Tabla matriz de tratamientos

Este cuadro consolida en una vista las categorías de datos que tratamos como Responsable, las finalidades, las bases legales del art. 6 RGPD, los plazos de conservación y la fuente de los datos.

6. Datos especiales y datos de menores

6.1 Datos especiales (art. 9 RGPD)

Shara no está diseñado para tratar categorías especiales de datos (origen racial o étnico, opiniones políticas, convicciones religiosas o filosóficas, afiliación sindical, datos genéticos, biométricos, de salud, vida sexual u orientación sexual). Recomendamos expresamente al Cliente no conectar fuentes que contengan datos especiales sin haber realizado una evaluación de impacto y haber pactado por escrito con AIGiner las salvaguardas adicionales (cifrado reforzado, restricción de subprocesadores, compromiso explícito del Cliente de cumplir el art. 9.2). El uso por defecto del Servicio supone la garantía del Cliente de que no aporta este tipo de datos.

Sobre la voz: la grabación de la voz de una persona no es, por sí sola, un dato biométrico en el sentido del art. 4.14 RGPD, porque no la tratamos con la finalidad de identificar a nadie. Solo se transcribe. No hacemos reconocimiento de locutor ni ninguna otra forma de identificación por voz, y el Cliente no debe usar Shara para ello.

6.2 Menores (art. 8 RGPD y art. 7 LOPDGDD)

Shara es un servicio dirigido exclusivamente a profesionales y empresas. No tratamos datos de menores de 14 años de manera consciente —la edad que fija el artículo 7 de la LOPDGDD para España, por debajo del umbral supletorio de 16 del artículo 8 del RGPD—, ni hacemos targeting publicitario o de cualquier tipo a menores. El Sitio Web y el producto no son accesibles a este colectivo como destinatarios. Si detectamos que un menor ha facilitado datos sin la base legal adecuada (autorización de los titulares de la patria potestad o tutela), los eliminaremos sin demora. Cualquier sospecha puede comunicarse a [email protected].

7. Destinatarios y subprocesadores

Para prestar el Servicio recurrimos a proveedores terceros que actúan como sub-encargados de tratamiento. La lista completa y actualizada está publicada en /sub-encargados: hoy son el proveedor de inferencia (tercero bajo licencia, identidad protegida por NDA, sobre infraestructura soberana en la UE), la base de datos y autenticación (Supabase, Irlanda), el hosting de aplicación (Contabo, Francia), la red de distribución y protección (Cloudflare), los pagos y la facturación (Stripe), el correo transaccional (Resend) y el canal de soporte por tickets (Telegram). Notificamos cualquier nueva incorporación con un preaviso de 30 días para permitir su revisión y, en su caso, oposición motivada del Responsable.

Adicionalmente, podremos comunicar datos cuando exista una obligación legal (autoridades fiscales, judiciales, AEPD) o sea estrictamente necesario para defender derechos en sede judicial.

8. Dónde se trata cada cosa

El contenido que procesan los agentes —lo que el Cliente conecta, lo que se escribe en el chat y las grabaciones de voz que se envían a transcribir— se trata íntegramente dentro de la Unión Europea. El proveedor de inferencia opera sobre infraestructura soberana en la UE, con procesamiento 100 % en la UE, por lo que no existe transferencia internacional de los prompts, de las respuestas del modelo ni del audio. Su relación se rige por un contrato de encargo (art. 28 RGPD), con política de retención cero y compromiso de no usar los datos para entrenar.

• La inferencia y la transcripción de voz, la base de datos (Supabase, Irlanda · eu-west-1) y el hosting de aplicación (Contabo, Lauterbourg, Francia) están en territorio de la Unión Europea.
• Medidas técnicas: minimización de lo que se envía al modelo, retención cero, no uso para entrenamiento y trazabilidad por petición.
• Lo que sí sale de la UE, y conviene decirlo sin rodeos: el correo transaccional del servicio (invitaciones, avisos de facturación, notificaciones) se envía a través de Resend, en Estados Unidos, y ese correo contiene el nombre y la dirección del destinatario y el contenido del propio aviso. La red de distribución y protección (Cloudflare) trata metadatos de tráfico con presencia global. Ambos tratamientos se amparan en las Cláusulas Contractuales Tipo de la Comisión Europea (Decisión 2021/914, art. 46.2.c RGPD) y en el DPA de cada proveedor. Stripe trata los datos de pago en Irlanda y Estados Unidos con la misma garantía.
• En Concerto Local la superficie se reduce todavía más: los modelos corren en la infraestructura del Cliente y solo salen de ella las tareas que decida delegar a la cuota en la nube, si la mantiene activada.

9. Decisiones automatizadas y derecho de oposición

Shara usa modelos de lenguaje para asistir al Cliente en la ejecución de tareas administrativas. No tomamos decisiones exclusivamente automatizadas que produzcan efectos jurídicos sobre el interesado (art. 22 RGPD): toda acción crítica (envío de correos externos, ejecución de pagos, contratación o despido, comunicación pública en nombre del Cliente, etc.) se encola y requiere aprobación humana antes de ejecutarse. El Cliente configura qué acciones requieren aprobación según su política interna.

Derecho de oposición (art. 21 RGPD): cuando el tratamiento se basa en interés legítimo (por ejemplo, métricas agregadas anonimizadas para mejora del producto o comunicaciones comerciales sobre productos similares), el interesado tiene derecho a oponerse en cualquier momento por motivos relacionados con su situación particular. Si la oposición es fundada, cesaremos el tratamiento salvo que acreditemos motivos imperiosos legítimos que prevalezcan o sean necesarios para el ejercicio de derechos en procedimientos judiciales. La oposición a comunicaciones comerciales es siempre incondicional y se atiende inmediatamente.

Más detalle sobre nuestra política de IA, mitigación de sesgos y EU AI Act en Política de Uso de IA (/politica-ia).

10. Derechos del interesado

Conforme a los artículos 15 a 22 del RGPD, puedes ejercer en cualquier momento los siguientes derechos:

• Acceso (art. 15) a los datos personales que tratamos sobre ti.
• Rectificación (art. 16) de los datos inexactos o incompletos.
• Supresión (art. 17) ("derecho al olvido") cuando los datos ya no sean necesarios.
• Oposición (art. 21) al tratamiento basado en interés legítimo o marketing.
• Limitación (art. 18) del tratamiento en los supuestos del precepto.
• Portabilidad (art. 20): recibir los datos en formato estructurado, de uso común y lectura mecánica (JSON / CSV).
• Retirada del consentimiento (art. 7.3) en cualquier momento, sin efectos retroactivos.
• No ser objeto de decisiones automatizadas (art. 22) con efectos jurídicos significativos.

11. Procedimiento de ejercicio de derechos

Si los datos los aporta el Cliente como Responsable y el ejercicio se refiere a un interesado del Cliente, redirigiremos la solicitud al Responsable correspondiente y le asistiremos según el DPA en un plazo máximo de 5 días hábiles.

• Envío de la solicitud a [email protected] o a [email protected], indicando claramente el derecho ejercido.
• Identificación: adjunta documento que permita verificar tu identidad (DNI/NIE redactado parcialmente o equivalente). Si la solicitud llega desde la cuenta verificada del servicio, podemos prescindir del documento.
• Plazo de respuesta: resolveremos en el plazo máximo de un mes desde la recepción (art. 12.3 RGPD).
• Ampliación motivada: en supuestos complejos o de alto volumen podemos ampliar el plazo por dos meses adicionales, notificándote la ampliación en el primer mes con las razones.
• Reclamación ante la AEPD: si no estás conforme con la respuesta, puedes presentar reclamación ante la Agencia Española de Protección de Datos en www.aepd.es. La reclamación es gratuita.

12. Cookies y medidas de seguridad

El uso de cookies en el sitio web informativo se rige por la Política de Cookies (/cookies), donde encontrarás el detalle por cookie (origen, finalidad, duración, tipo). Puedes modificar tus preferencias en cualquier momento desde el Gestor de Cookies. Las cookies estrictamente técnicas no se desactivan porque son necesarias para el funcionamiento del sitio.

Aplicamos las medidas técnicas y organizativas apropiadas exigidas por el art. 32 RGPD para garantizar un nivel de seguridad adecuado al riesgo. Entre otras: cifrado en tránsito (TLS 1.2 como mínimo, con preferencia por TLS 1.3), cifrado en reposo con AES-256-GCM y claves envueltas por una clave maestra, separación entre clientes mediante filtrado obligatorio por empresa en cada consulta y, como segunda capa, seguridad a nivel de fila de Postgres activada y forzada en los esquemas de consumo de modelos, facturación y aprobaciones, con aislamiento por empresa en la capa de aplicación en el resto de dominios mientras se extiende esa segunda capa, segundo factor TOTP disponible para todas las cuentas y exigible a toda la empresa desde la configuración, registro de auditoría que no admite modificación posterior, batería de pruebas adversariales contra la manipulación de instrucciones con cobertura del OWASP LLM Top 10 (el 95 % neutralizado es condición para publicar una versión), cortes automáticos de gasto (5 € por tarea, 50 € por hora, 400 € por día), copias de seguridad diarias cifradas y fuera de sede con simulacro mensual de restauración, y revisión de accesos. Detalle en el Anexo III del DPA (/dpa).

Lo que no tenemos, dicho aquí para que nadie lo deduzca al revés: AIGiner no dispone de certificación ISO/IEC 27001 ni de informes SOC 2, ni está en proceso de certificación. Las medidas anteriores son las que aplicamos y se pueden verificar por las vías del apartado 7 del DPA.

13. Brechas de seguridad

Notificación en plazo art. 33-34 RGPD: En caso de brecha de seguridad que afecte a datos personales aplicamos un protocolo escalado conforme a los arts. 33 y 34 del RGPD.

• Notificación a la AEPD (art. 33): en un plazo máximo de 72 horas desde la detección, salvo que la brecha no entrañe riesgo para los derechos y libertades de los interesados.
• Notificación al interesado (art. 34): sin dilación indebida cuando la brecha entrañe alto riesgo para sus derechos y libertades, con un lenguaje claro y sencillo y la información mínima exigida (naturaleza de la brecha, contacto, consecuencias probables y medidas adoptadas).
• Asistencia al Responsable Cliente: si la brecha afecta a datos tratados como Encargado, notificaremos al Cliente sin demora indebida y le proporcionaremos toda la información razonablemente disponible para que cumpla con sus obligaciones art. 33-34, conforme al DPA (/dpa).

14. Cambios en esta política

Esta política puede actualizarse para reflejar cambios legales, técnicos u operativos. Los cambios materiales se notificarán por email a la cuenta del Cliente con un preaviso mínimo de 30 días. La fecha de la última revisión y el historial de versiones figuran al pie del documento.