Política de Privacidad

Versión 2.16 · Última actualización: 3 de septiembre de 2026 · Sustituye a la v2.15 de 27 de agosto de 2026 · Qué cambió en la 2.16

1. Quiénes Somos

Esta Política de Privacidad describe cómo Oney Finansal Danışmanlık Turizm ve Dış Ticaret AŞ («Omnisio», «nosotros») recopila, utiliza y comparte sus datos personales cuando usted utiliza la aplicación móvil Omnisio (iOS) y los servicios relacionados.

• Entidad legal: Oney Finansal Danışmanlık Turizm ve Dış Ticaret AŞ
• Registrada en: Türkiye
• N.º de identificación fiscal: 6430768526
• Registro Mercantil: 386006-5
• Número MERSİS: 0643076852600001
• N.º de Registro VERBIS: 74691528
• Contacto del responsable del tratamiento: privacy@omnisio.app
• Consultas al DPO: dpo@omnisio.app

2. Aviso Legal Importante

Omnisio es un coach de bienestar — NUNCA recetará medicamentos, recomendará dosis específicas de suplementos ni sustituirá el criterio de su médico. Si algún rango de referencia de bienestar le parece incorrecto, consulte el resultado con su médico.

3. Datos que Recopilamos

3.1 Cuenta y Perfil

• Nombre de perfil (es el nombre que ven los demás miembros en la Comunidad — no existe un apodo aparte)
• Dirección de correo electrónico
• Fecha de nacimiento
• Sexo biológico (para cálculos de bienestar)
• País / configuración regional
• Foto de perfil (opcional, elegida por usted desde su fototeca)
• Código de invitación (para referidos y solicitudes de amistad)
• Proveedor de inicio de sesión (Apple ID, Google o correo electrónico/contraseña)

3.2 Datos de Bienestar y Dispositivo Vestible

• Frecuencia cardíaca (en reposo, continua)
• Variabilidad de la frecuencia cardíaca (VFC)
• Duración del sueño y fases (ligero, profundo, REM)
• Actividad (pasos, minutos activos)
• Temperatura cutánea (según soporte del dispositivo vestible)
• Saturación de oxígeno en sangre (SpO2), cuando el dispositivo vestible la mide
• Entrenamientos y sesiones de entrenamiento — el tipo, la duración, el esfuerzo y la frecuencia cardíaca registrada durante ellos
• Mediciones de composición corporal
• Registros autoinformados: estado de ánimo, hidratación y los días que marcó como de descanso
• Registros del ciclo menstrual, solo si activa el seguimiento — fechas de inicio y fin del periodo, intensidad, registros de síntomas, estado de ánimo y energía
• Registros de embarazo y posparto, solo si activa el seguimiento — registros de sangrado posparto y las fechas de un periodo posparto. La ley turca los considera a la vez datos de salud y datos relativos a la vida sexual (artículo 6/1 de la KVKK). Figuraban en el §2.3 del aviso KVKK (en turco) y no aquí; la versión 2.8 cierra esa laguna

3.3 Datos de la Comunidad (opcional)

• Solicitudes de amistad y amistades
• Equipos y retos que crea o a los que se une, incluidos sus nombres y descripciones
• Sus decisiones de compartición por métrica y el valor de la métrica que decidió publicar
• Los ánimos («cheers») que da a un elemento de actividad de una amistad
• Las denuncias que presenta y los miembros que bloquea — véase el §8

3.4 Datos de Carrera (opcional)

• Ubicación precisa, registrada únicamente mientras una carrera está activa — véase el §9
• Distancia, ritmo, parciales, vueltas, duración, calorías
• Movimiento y forma física: cadencia desde el podómetro, desnivel desde el barómetro
• Frecuencia cardíaca durante la carrera, cuando hay una pulsera o un anillo conectados

3.5 Entradas del Diario (opcional)

Cuáles de una lista fija de hábitos diarios le aplicaron, más una nota de texto libre — véase el §11.

3.6 Lecturas de Señal Cardíaca (opcional)

Registradas con una pulsera Omnisio compatible y guardadas únicamente en su teléfono — véase el §10.

3.7 Fotos (opcional)

Fotos de comidas para la estimación nutricional con IA, y una foto de perfil — véase el §12.

3.8 Datos del Dispositivo y Uso

• Modelo de dispositivo, versión de iOS, versión de la aplicación
• Dirección IP (en el momento de la solicitud a la API, con fines de seguridad)
• Token de notificaciones push (cuando activa las notificaciones) — por quién pasa, véase el §15
• Los identificadores de un dispositivo vestible que haya emparejado
• La carga sin procesar de una sincronización del dispositivo, conservada un tiempo corto para poder explicar una sincronización que salió mal — véase el §18

3.9 Datos de Compra, Entrega y Facturación

La membresía de Omnisio incluye un dispositivo, y un dispositivo tiene que llegar a una dirección real. Por eso, hacernos un pedido directo nos obliga a tratar información que la aplicación por sí sola nunca necesitó y, en un plan familiar, información sobre personas distintas de usted. La tabla siguiente es el contenido completo de un registro de pedido.

Ninguno de los datos de esta sección se utiliza para publicidad, ninguno sirve para construir un perfil de marketing, y ninguno se vende ni se alquila a nadie.

3.10 Solicitudes de Sustitución de Dispositivo

Si nos pide sustituir su dispositivo, guardamos la propia solicitud: a cuál de sus dispositivos se refiere — incluidos la dirección de hardware Bluetooth y el código de producto de esa unidad — el motivo que seleccionó, cualquier nota que escribiera, el nivel de membresía desde el que se hizo la solicitud, y su estado. Si finalmente sustituimos la unidad, un registro interno independiente vincula el dispositivo que salió con el que llegó, de modo que su cuenta conserva un historial de sustituciones.

Ambos registros se incluyen en la exportación de sus datos, y ambos se eliminan con su cuenta.

3.11 Nuestro Sitio Web

El sitio web de Omnisio no instala ninguna cookie. Guarda dos cosas en el almacenamiento local de su navegador y nada más: el idioma que eligió — para que el sitio se abra en ese idioma la próxima vez — y, solo cuando pone algo en la cesta de la tienda, lo que puso ahí: un identificador de variante y una cantidad. Ninguna de las dos se nos envía por sí sola; la cesta nos llega únicamente como el contenido de un pedido que realiza usted mismo. Ambas figuran por su nombre en la página de cookies. No hay ningún script de analítica, ningún píxel publicitario ni ningún rastreador de redes sociales en ninguna página de este sitio, y nada le sigue de un sitio a otro. Por eso no se le pide que acepte nada.

Una petición no es nuestra, y hasta la versión 2.7 esta sección afirmaba más de lo cierto. Las páginas de tienda, pago, pedido, inicio y Omnisio Team cargan sus tipografías desde un servicio de fuentes de un tercero. Cuando su navegador descarga un archivo de fuente del servidor de otra empresa, esa empresa ve su dirección IP y qué navegador utiliza. No instala ninguna cookie, no hace seguimiento y nunca ve nada de lo que usted escribe, pero es un tercero que recibe una petición, y la frase anterior lo negaba de plano. El proveedor figura en el §15. Esta página y las demás páginas legales no lo cargan en absoluto.

3.12 Calibración matinal — qué mide su teléfono y qué llega hasta nosotros

Esta sección describe algo que ahora funciona. Todas sus versiones hasta la 2.15 describían una funcionalidad diseñada y apagada, y decían que no se recogía nada de ella. Esa ya no es la descripción honesta, así que la sección entera se reescribe en presente. La Calibración matinal es una medición opcional dentro de Omnisio Labs, en las membresías Horizon y solo en iPhone — funciona sobre el marco Vision de Apple en el propio dispositivo, de modo que no hay versión para Android ni nada que activar en otro sitio.

La fotografía nunca llega hasta nosotros, y eso es el diseño y no una promesa sobre nuestra conducta. Su teléfono toma tres fotogramas de su propia cara la misma mañana y los mide donde se toman. Cada imagen se libera en cuanto existen los números: no se escribe en el almacenamiento, no se sube y no se conserva. La interfaz que recibe una mañana no tiene ningún campo al que pudiera llegar una fotografía — todo lo que no está en su lista se rechaza en lugar de ignorarse en silencio — y tampoco se aceptan puntos de referencia, ni plantillas faciales, ni medida alguna de color. Es una disposición distinta de la foto de comida de §12.1, que sí sale de su teléfono y se describe allí.

Cuatro mediciones cruzan la red, y todas las versiones anteriores de esta sección llamaron proporciones a las cuatro. Tres lo son: cuánto tiene abiertos los párpados, expresado en anchuras de su propio iris; el área bajo su ojo, dividida por el cuadrado de la anchura de su cara; y cuánto difieren su lado izquierdo y su lado derecho, dividido por esa misma anchura. La cuarta no es una proporción. Es un ángulo — la inclinación de las comisuras de su boca respecto de la horizontal, registrada en radianes. La distinción merece una frase porque «proporción adimensional» hacía un trabajo tranquilizador en la redacción anterior, y una de las cuatro nunca lo fue. Ninguna de las cuatro es una longitud, ninguna es un color, y cuatro números de esta clase no pueden reconvertirse en una cara.

Una mañana es más que esos cuatro números, y ninguna versión anterior de esta sección lo dijo. Junto a ellos se guardan: la fecha de esa mañana en su propia zona horaria y el instante de la captura, con el desfase horario usado para calcular ambos; lo buena que el teléfono consideró la toma; cuántas capturas consiguió la sesión; si se negó a producir una lectura y por qué motivo; y el modelo de su iPhone, su versión de iOS, la versión de la aplicación y la versión del consentimiento que usted dio. Hay una columna más — los minutos entre despertarse y la captura — y está vacía para todos los miembros. La única hora de despertar que la aplicación podría leer significa dos cosas distintas según cómo se haya sincronizado, así que no se escribe nada ahí en lugar de una cifra que sería una observación por un camino y una invención por el otro. Si alguna vez se rellena, esta sección se reescribe en esa versión.

Una mañana que se niega no es una mañana que guardemos en silencio. Cuando los fotogramas no son lo bastante buenos, no se envía nada en absoluto — ni un registro vacío, ni un marcador de posición. De su teléfono no sale ninguna petición, y en nuestro lado no queda nada que muestre que se intentó una mañana. Cuando las tres capturas sí producen números pero no concuerdan entre sí, esos números son precisamente aquellos en los que acabamos de decidir no confiar, así que se quedan en el teléfono y lo que llega hasta nosotros es el registro de un intento sin ninguna medición dentro. Ese registro existe por una sola razón: para no pedirle que repita la misma mañana.

No se le dice nada sobre su cara. No hay puntuación, ni porcentaje, ni nota, ni tendencia, ni racha, ni comparación con nadie más. La única salida que el diseño permite es si esa mañana concuerda con algo que su propia fisiología ya haya indicado — y hoy tampoco produce eso: la funcionalidad está en su primera etapa y la respuesta que devuelve es «no disponible». Si alcanza los umbrales que publicamos para ella, se lo diremos; si no los alcanza nunca, también se lo diremos.

Conservamos una mañana durante 24 meses, o hasta que usted la borre, lo que ocurra antes. La caducidad se escribe en la fila una sola vez, cuando se crea, y es una fecha de borrado real sobre la que nuestra base de datos actúa por sí misma. Repetir la misma mañana actualiza las mediciones y no reinicia el reloj. Veinticuatro meses es mucho más de lo que el producto lee realmente — el modelo de envejecimiento mira unos seis meses atrás y la línea base personal usa sesenta mañanas — y esa diferencia es deliberada: es un techo, no un plan.

Puede borrar todas las mañanas en cualquier momento, desde Privacidad y Confianza, en cualquier nivel de membresía. El borrado no está detrás del requisito Horizon ni detrás del interruptor de la funcionalidad, y esa asimetría es el diseño: un miembro cuyo Horizon ha caducado, o que ha pasado a un teléfono donde la medición no puede ejecutarse, es exactamente quien debe seguir pudiendo borrar lo que se midió. Cuando usted lo pide, borramos y después volvemos a leer para confirmar que no queda nada suyo, y solo entonces le decimos que está hecho. Si queda algo, se le dice que no se borró nada, en lugar de entregarle un éxito parcial. Borrar su cuenta elimina estas filas junto con todo lo demás (§17).

Estas filas están en su exportación de datos, y esa es la única vía por la que salen de nuestros propios servidores. Una exportación se monta como archivo comprimido y se guarda con nuestro proveedor de almacenamiento de archivos hasta que usted la descarga, lo cual es una transferencia fuera de Turquía y de la UE — la misma que §16 describe para cualquier otra parte de una exportación. Nada de esto se envía a un proveedor de IA. La Calibración matinal no es una de las seis funcionalidades de §13.1, y en ninguna de esas cargas aparece medición facial alguna.

No es identificación y no es una medición médica. En ninguna parte del diseño hay plantilla facial, descriptor ni vector de identidad, de modo que no podemos reconocerle a partir de una mañana ni emparejar la mañana de un miembro con la de otro. No diagnostica nada, no criba nada y no es un producto sanitario (§2). No tratamos estos cuatro números como datos biométricos, porque nada en el diseño permite singularizarle a partir de ellos: no hay plantilla contra la que cotejar ni paso de cotejo que ejecutar. Esa es nuestra propia posición sobre cómo los tratamos, y no vamos a presentarla como un dictamen jurídico — ningún abogado ha certificado esta sección, y si eso cambia lo diremos aquí. Lo que sí podemos afirmar sin reservas es el mecanismo, y queda expuesto arriba por completo: qué se mide, qué sale de su teléfono, qué no sale, dónde se guarda, cuánto se conserva y cómo lo borra usted. Sopéselo por sí misma en lugar de aceptar nuestra conclusión por confianza.

Una de las tres condiciones que esta sección solía fijar sigue pendiente, y preferimos escribirlo a dejarlo pasar. La versión 2.15 decía que el interruptor no se encendería hasta que la medición hubiera superado sus umbrales publicados, hasta que esta sección describiera algo vigente y hasta que nuestro registro VERBIS (n.º 74691528) incluyera la categoría. La segunda ya es cierta. La primera no se ha cumplido, sino que se ha replanteado: esos umbrales rigen si alguna vez podremos decirle lo que una mañana significa, y no le decimos nada — nunca fueron la puerta correcta para el hecho de medir. La tercera no ha ocurrido. Hasta que el registro se actualice, la funcionalidad se mantiene cerrada en la configuración de nuestro servidor y no se recoge ninguna medición facial de nadie.

3.13 Informes de análisis de sangre (opcional)

Puede traernos un análisis de sangre que se haya hecho usted misma. Omnisio no vende, no encarga ni realiza pruebas de laboratorio, y no existe ningún laboratorio asociado (esa corrección está publicada también en el aviso KVKK y en la página de eliminación de datos). Lo que almacenamos es el archivo del informe que usted sube y los valores de biomarcadores leídos de él, con sus unidades, rangos de referencia, la fecha del informe y el laboratorio que figura en él.

Son resultados clínicos sobre su cuerpo, de modo que el §4.1 se les aplica íntegramente. Si pide el análisis con IA, lo que sale es el propio archivo del informe — qué significa eso exactamente está en el §13.1. Puede eliminar un informe, con sus valores, sin eliminar su cuenta, y ambos se van con la cuenta.

Esta sección es nueva en la versión 2.8. Las palabras «análisis de sangre» aparecían una sola vez en la versión anterior de esta página, dentro de una lista sin relación sobre lo que la Comunidad nunca muestra. Una categoría de datos tan sensible no podía quedar descrita solo por omisión.

3.14 Registro de nutrición y comidas (opcional)

Las comidas que registra van formando un historial de nutrición en nuestros servidores: qué registró, la ración, la energía y los macronutrientes estimados, cualquier corrección que hiciera a una estimación y los totales diarios que agregamos a partir de ellos. El §12.1 describe la foto y dice que no la conservamos; eso nunca fue una afirmación sobre el registro que la foto produjo, y esta sección existe para que no se confundan.

3.15 Archivos que importa desde otro servicio (opcional)

Puede traerse su historial desde otro dispositivo vestible o aplicación — un archivo de exportación de Whoop, Oura, Garmin o Apple Health. Lo que nos entrega es un archivo que obtuvo de esa empresa, y lo que conservamos es lo que podemos leer en él: noches de sueño, días de actividad, historial de frecuencia cardíaca y las respuestas diarias que llevara, cada una guardada en el día en que realmente ocurrió y no en el día en que la importó. Los registros importados son suyos exactamente igual que el resto de su historial: están en su exportación y se eliminan con su cuenta. El §5.1 del aviso KVKK enumera este método de recogida desde agosto de 2026 y esta página no lo hacía.

4. Cómo Utilizamos Sus Datos

4.1 Los datos de bienestar se tratan como datos de salud

La frecuencia cardíaca, la variabilidad de la frecuencia cardíaca, el sueño, la temperatura de la piel, la saturación de oxígeno, las lecturas de señal cardíaca, los entrenamientos, la composición corporal, los valores de biomarcadores de un análisis de sangre que usted suba, los registros del ciclo menstrual, del embarazo y del posparto, y las puntuaciones que calculamos a partir de todo ello permiten extraer conclusiones sobre su cuerpo. Por eso tratamos todos ellos como datos de categoría especial conforme al artículo 6 de la KVKK y al artículo 9 del RGPD — la lectura más estricta posible — en lugar de sostener que una puntuación de bienestar es de algún modo menos que un dato de salud.

Eso tiene una consecuencia, y no es cosmética: para estos datos el contrato no basta por sí solo. Lo que nos permite tratarlos es el consentimiento explícito.

Lo que el producto registra hoy, exactamente — y ha habido que dividirlo en tres, porque una sola línea lo describía mal.

• El Informe Profundo de Salud. Un registro versionado y de solo adición en nuestros servidores: cada aceptación y cada retirada se guardan como una fila propia, con la versión del texto que aceptó y el momento en que actuó. Nada se sobrescribe, de modo que el historial queda como rastro de auditoría. Ese consentimiento además se comprueba en nuestro lado: sin él el informe se rechaza allí, no simplemente se oculta en la aplicación. Se retira en Más → Privacidad y Confianza → Personalización con IA.
• Las otras cinco funcionalidades de IA. El consentimiento se pide — la misma pantalla, antes del primer uso — y es lo que la aplicación comprueba antes de enviar nada. Pero el registro de su respuesta vive en su teléfono y no en nuestros servidores, y hoy nuestros servidores no rechazan una solicitud que llegue sin él. Hasta la versión 2.8 la línea de arriba unía ambas cosas como «Funciones de IA e Informe Profundo de Salud», lo que reclamaba un rastro de auditoría en servidor para consentimientos que no lo tenían. El §13.4 dice qué se ha construido para cerrarlo y qué tiene que ocurrir antes de encenderlo.
• Compartir métricas en la Comunidad. Se presta métrica a métrica, está desactivado por defecto y se retira por la misma vía (§7.2).

Compartir una métrica de bienestar con la Comunidad es un segundo consentimiento, distinto del anterior. Publicar su recuperación, disposición, esfuerzo, pasos, puntuación de sueño o racha en una clasificación hace visibles datos de salud a otras personas, algo que el consentimiento anterior nunca cubre. Lo presta métrica a métrica, está desactivado por defecto, y lo retira por la misma vía (§7.2).

5. Integración con Apple Health (HealthKit)

Omnisio puede leer datos de salud de Apple Health si usted concede permiso en los Ajustes de iOS. Leemos:

• Frecuencia cardíaca, VFC, frecuencia cardíaca en reposo
• Energía activa quemada, pasos, minutos de ejercicio
• Análisis del sueño (fases del sueño cuando estén disponibles)
• Temperatura corporal, saturación de oxígeno (cuando estén disponibles)

Los datos de Apple Health se procesan en el dispositivo y se envían a nuestros servidores únicamente si dispone de una sesión activa en Omnisio y no ha desactivado la sincronización en la nube.

6. Dispositivo Vestible (Wearable)

Omnisio se conecta con un dispositivo vestible (wearable) de bienestar para consumidores mediante Bluetooth de baja energía. NO es un dispositivo médico y no cuenta con autorización médica de la FDA, CE-MDR ni TITCK.

En esta página no indicamos ningún marcado de conformidad ni ninguna referencia de certificado para el dispositivo. La versión 2.4 de esta página afirmaba que el dispositivo tenía marcado CE; es una afirmación regulatoria sobre un certificado que no hemos visto, así que se ha retirado en lugar de repetirse. Nada de esta página debe leerse como una aprobación regulatoria de ningún tipo; la descripción contractual del dispositivo está en los Términos de Servicio §3.3.

Los datos del dispositivo vestible se leen en el dispositivo y se cargan en nuestros servidores cuando la aplicación está abierta y usted ha iniciado sesión.

7. Comunidad — Qué Pueden Ver los Demás

La Comunidad de Omnisio le permite añadir amistades, crear un equipo o unirse a uno, organizar un reto, aparecer en una clasificación y animar a alguien. Es opcional. Si nunca abre la Comunidad, nada de esta sección le aplica.

7.1 Su perfil en la Comunidad

Hay dos cosas suyas visibles para otros miembros de Omnisio:

• Su nombre de perfil — el nombre de su perfil de Omnisio. La Comunidad no tiene un campo de apodo aparte.
• Su foto de perfil, si ha establecido una.

Cualquier miembro de Omnisio con la sesión iniciada puede encontrarle buscando su nombre de perfil o su código de invitación. Su dirección de correo electrónico, su fecha de nacimiento y su número de teléfono nunca se muestran a otros miembros y nunca aparecen en la búsqueda de miembros. Alguien a quien haya bloqueado no puede encontrarle en absoluto.

7.2 Métricas de bienestar: por defecto no se comparte nada

Se pueden compartir con la Comunidad exactamente seis métricas de bienestar: recuperación, disposición (readiness), esfuerzo (strain), pasos, puntuación de sueño y racha. Todas ellas están DESACTIVADAS por defecto. No existe un botón de «compartir todo» y ninguna métrica se activa por usted.

Usted las activa una a una en Comunidad → Qué comparte, o en Más → Privacidad y Confianza → Compartir en la Comunidad. Cuando activa una métrica y guarda, Omnisio publica el valor que esa métrica tiene en ese momento. Ese número publicado permanece igual hasta que vuelve a abrir la pantalla y guarda de nuevo: es una instantánea que usted decidió publicar, no una transmisión en directo de su cuerpo.

Desactivar una métrica elimina el valor publicado, no solo su visibilidad. Una vez desactivada, no queda ningún número almacenado que nadie pueda ver.

7.3 Quién puede ver una métrica que ha compartido

• Clasificaciones de amistades — usted y las amistades cuyas solicitudes ha aceptado.
• Clasificaciones de equipo — los miembros de un equipo al que pertenece.
• Posiciones de un reto — los participantes del reto al que se ha unido.
• Feed de actividad — solo sus amistades aceptadas. Muestra que ha activado una métrica (con el valor que publicó), que se ha unido a un equipo o que se ha unido a un reto. Sus amistades pueden «animar» uno de esos elementos, lo que registra quién animó qué.

Un miembro que no ha activado una métrica simplemente no aparece en esa clasificación. Nunca estimamos, promediamos ni rellenamos un valor ausente.

7.4 Equipos y retos

Crear un equipo o un reto guarda su nombre y su descripción opcional, quién lo creó, quién se unió y cuándo. Los nombres y las descripciones son visibles para todas las personas de ese equipo o reto. Un equipo tiene además un código de acceso: cualquiera que lo tenga puede unirse, así que trátelo como una invitación y no como un secreto.

7.5 No hay chat

La Comunidad no tiene mensajería, ni mensajes directos, ni comentarios, ni publicación de fotos. El único texto libre que puede publicar es su nombre de perfil y el nombre y la descripción de un equipo o reto que cree. Lo que resulta aceptable en esos campos se explica en nuestras Normas de la Comunidad.

7.6 Salir

Puede eliminar una amistad, abandonar un equipo, salir de un reto o desactivar todas las métricas en cualquier momento. Eliminar su cuenta de Omnisio elimina sus amistades, sus pertenencias a equipos, los equipos y retos que creó y sus opciones de compartición de métricas. Los bloqueos que usted haya puesto también se eliminan con la cuenta. Las denuncias se tratan de otra manera — véase el §8.3.

8. Seguridad: Denuncias, Bloqueos y Registros de Moderación

La Comunidad tiene un botón de denuncia y un botón de bloqueo. Usar cualquiera de los dos crea un registro que identifica a las personas implicadas. Lo decimos con claridad porque es una consecuencia real de pulsar esos botones.

8.1 Cuando denuncia a alguien o algo

Almacenamos:

• Su identificador de usuario, como denunciante
• El identificador de usuario de la persona sobre la que trata la denuncia — que deducimos nosotros del contenido denunciado, en lugar de aceptar a quien nombre el denunciante
• Qué se denunció (un miembro, un equipo, un reto o un elemento de actividad) y su identificador
• El motivo que eligió: nombre ofensivo, acoso o intimidación, discurso de odio, spam, suplantación de identidad, contenido inapropiado u otro
• Cualquier detalle que escriba, hasta 500 caracteres
• La hora de envío y su estado actual
• Una vez tramitada: qué cuenta de personal la resolvió, cuándo, qué medida se tomó y una nota interna

Las denuncias las leen personas. Personal autorizado de Omnisio las revisa mediante una cola de moderación exclusiva para administradores y actúa sobre el contenido objetable y los usuarios abusivos en un plazo de 24 horas. Nunca decimos a un miembro denunciado quién lo denunció.

8.2 Cuando bloquea a alguien

Almacenamos su identificador de usuario, el de la otra persona y la hora. Un bloqueo les oculta mutuamente en la búsqueda de miembros, las clasificaciones, los equipos y el feed de actividad, y elimina cualquier amistad entre ustedes. Nunca avisamos a la persona bloqueada. Puede revisar y deshacer sus bloqueos en Comunidad → Seguridad → Personas bloqueadas.

8.3 Cuánto tiempo los conservamos y por qué

Los conservamos como rastro de seguridad y auditoría: para reconocer conductas repetidas, para impedir que un miembro expulsado de forma permanente vuelva sin más, para revisar una decisión cuando alguien la recurre y para responder a una autoridad reguladora o a un tribunal si se nos requiere. Nuestra base jurídica es el interés legítimo en la seguridad de nuestros miembros y, cuando corresponda, el cumplimiento de una obligación legal.

Si cree que un registro de moderación sobre usted debe eliminarse, escriba a privacy@omnisio.app. Ponderaremos su solicitud frente a esos intereses y le daremos una respuesta.

El contenido retirado durante la moderación — un nombre de equipo ofensivo, un título de reto, un nombre de perfil — se elimina o se sustituye por un marcador neutro. Suspender el acceso de alguien a la Comunidad nunca afecta a sus datos de bienestar, ni a su exportación, ni a su derecho a eliminar la cuenta.

9. Carreras: Ubicación Precisa y Datos de Movimiento

9.1 Cuándo se usa la ubicación

Omnisio recopila ubicación precisa únicamente mientras una carrera está activa. Iniciar una carrera la activa; terminarla o descartarla la desactiva. No hay recopilación de ubicación cuando no está corriendo, y Omnisio nunca solicita el permiso de ubicación «Siempre»: el único permiso que pedimos es «Mientras se usa la app».

9.2 Qué se registra y adónde va

Durante una carrera registramos una serie de puntos, cada uno con latitud, longitud, precisión del GPS en metros, altitud relativa barométrica cuando está disponible, velocidad cuando el dispositivo la informa y una marca de tiempo. A partir de ellos calculamos su ruta, distancia, ritmo, parciales, vueltas y desnivel positivo y negativo.

La carrera finalizada, ruta incluida, se guarda en su teléfono y se sube a los servidores propios de Omnisio para que su historial de carreras le acompañe entre dispositivos. Los puntos de la ruta no se envían a ningún servicio de IA, ni a ningún anunciante, ni a ningún otro tercero, y nunca son visibles para otros miembros de Omnisio. Las carreras en interior y en cinta no llevan ruta alguna: nuestro servidor la rechaza si se llegara a enviar.

Puede eliminar una carrera concreta, junto con su ruta, de su historial en cualquier momento.

9.3 Movimiento y forma física

Mientras una carrera está activa, Omnisio también lee datos de movimiento con su permiso: el podómetro, para mostrar su cadencia en pasos por minuto, y en el iPhone el barómetro, para medir el desnivel positivo y negativo. No se usa para nada más y solo durante una carrera. Si rechaza el permiso de Movimiento y forma física, la carrera se registra igualmente: simplemente no muestra cadencia ni desnivel, en lugar de un número inventado.

10. Las Lecturas de Señal Cardíaca se Quedan en Su Dispositivo

Con una pulsera Omnisio compatible puede registrar una lectura de señal cardíaca de una sola derivación.

Cada lectura guardada contiene la forma de onda, la frecuencia cardíaca media y la VFC que calculó la pulsera, la duración y la frecuencia de muestreo, las etiquetas de situación que eligió (como «en reposo» o «después de hacer ejercicio») y cualquier nota que escribiera. Su teléfono conserva las 30 lecturas más recientes y descarta las anteriores automáticamente.

Una lectura solo sale de su dispositivo cuando usted la exporta o la comparte — por ejemplo, enviándose la tira exportada a sí mismo o a un profesional clínico. A partir de ese momento reside allí donde usted la envió, y esta Política de Privacidad ya no rige esa copia. La exportación no lleva deliberadamente ni nombre ni fecha de nacimiento: identifica el registro, no a la persona.

Como nunca llegan a nuestros servidores, las lecturas de señal cardíaca no forman parte de su exportación de datos, y eliminar su cuenta de Omnisio no las elimina. Para retirarlas, bórrelas en la aplicación o desinstale la aplicación de su teléfono.

11. Diario

El Diario le permite registrar, para un día concreto, cuáles de una lista fija de hábitos le aplicaron y añadir una nota de texto libre. La lista es: cafeína, alcohol, comida tardía, pantallas en la cama, meditación, lectura en la cama, compartir cama, sentirse mal, estar lesionado y tomar medicación. Algunos de ellos llevan un pequeño detalle que usted elige: el número de raciones o la hora de su último café.

Las entradas del diario se almacenan en los servidores de Omnisio, una entrada por día, para que le acompañen entre dispositivos y puedan compararse con sus tendencias de sueño y recuperación. Son privadas: las entradas del diario nunca se muestran a otros miembros de Omnisio, nunca se comparten con anunciantes y no se envían a ningún servicio de IA salvo que usted consienta por separado una funcionalidad de IA que las utilice.

La nota es texto libre. Por favor, no incluya en ella información privada de otra persona. Qué hábitos decide seguir es un ajuste que se guarda únicamente en su teléfono.

12. Cámara y Fototeca

12.1 Fotos de comidas

El Escáner de Comidas pide acceso a su cámara, o a su fototeca si prefiere elegir una foto existente. Omnisio solo recibe la única foto que usted hace o selecciona — nunca su fototeca completa.

La foto se envía para una estimación nutricional con IA, y esa transmisión requiere su consentimiento de IA (véase el §13). Si no lo ha dado, la foto no sale de su teléfono: la aplicación se lo pregunta antes y el análisis no se ejecuta.

No conservamos la foto. Una vez recibida la estimación, lo que guardamos con el análisis son los alimentos y la nutrición estimados más un hash de referencia unidireccional de la imagen — suficiente para reconocer una repetición de la misma foto, insuficiente para reconstruirla. La foto en sí no se conserva en los servidores de Omnisio.

12.2 Foto de perfil

Establecer una foto de perfil abre su fototeca para que elija una imagen. La foto se sube a los servidores propios de Omnisio y se muestra a otros miembros en la Comunidad. Se sirve mediante un enlace directo que en sí mismo no está protegido por control de acceso, por lo que cualquiera que tenga ese enlace puede abrir la imagen. Puede reemplazarla en cualquier momento. Las fotos de perfil no se envían a ningún servicio de IA.

13. Compartición de Datos con Servicios de IA

13.1 Las seis funcionalidades que envían datos, y qué envía cada una

Seis funcionalidades de Omnisio envían datos fuera de nuestros servidores para su procesamiento con IA. Todas son opcionales y todas preguntan antes. Hasta la versión 2.8 esta sección empezaba así: «Cuando usted opta por las funcionalidades basadas en IA (Today's Insight, Food Scanner), Omnisio envía los siguientes datos» — una lista cerrada que nombraba dos de las seis. Entre las cuatro que faltaban están las dos que más llevan: un informe clínico de laboratorio y todo lo que usted escribe en un chat sobre su propia salud. Aquí están las seis.

Cada una de estas solicitudes lleva además su configuración regional (por ejemplo, «tr-TR») y un identificador de solicitud. Ninguna se hace desde su teléfono: la solicitud sale de nuestros servidores, así que el proveedor ve la dirección de Omnisio y no la suya.

13.2 Qué NO Enviamos

• Su correo electrónico o número de teléfono
• Su nombre, en cinco de las seis vías de IA — la vía del análisis de sangre es la excepción, y las dos formas en que lo es se nombran en §13.1
• Su ubicación precisa, sus rutas de carrera y su dirección IP
• Sus lecturas de señal cardíaca — esas no salen siquiera de su teléfono (§10)
• Su foto de perfil (§12.2) y cualquier foto que no sea la única foto de comida que eligió
• Identificadores gubernamentales, incluido un número de identidad nacional que le pidiera una pasarela de pago (§3.9)
• Datos de otros miembros
• Absolutamente nada, por ninguna de las seis vías, antes de que se le haya preguntado y usted haya aceptado

13.3 Quién lo recibe y hasta dónde llega la cadena

Omnisio mantiene credenciales con una sola empresa de IA y no llama a ninguna otra. Aquí la identificamos como proveedor externo de procesamiento con IA y no por su nombre comercial, cosa que permite el artículo 13(1)(e) del RGPD — y la identidad está a su disposición si la pide: escríbanos a privacy@omnisio.app y se la diremos.

La solicitud no se detiene en esa empresa, y describir la cadena con honestidad importa más que describirla con pulcritud. El punto de acceso al que llamamos es un punto de enrutamiento y toma el nombre de un modelo como parámetro — lo que significa que nuestro proveedor pasa la solicitud a quien opera ese modelo en lugar de ejecutarla él mismo. Así que en la cadena hay al menos dos empresas: aquella con la que contratamos y la que opera el modelo. Podemos afirmar eso porque es visible en la llamada que hace nuestro propio código. Lo que no haremos es nombrar una tercera empresa como un hecho cuando lo que tenemos es el nombre de un punto de acceso. Hasta la versión 2.8 esta sección presentaba a un «proveedor de infraestructura de enrutamiento de modelos» como subencargado distinto y describía sus prácticas de registro y entrenamiento; eso abría en el documento un hueco del tamaño de una segunda empresa y luego describía su comportamiento, que es más de lo que sabemos.

• Retención por el proveedor de procesamiento con IA: su anexo de tratamiento prevé que conserva lo que enviamos hasta que termine nuestro contrato con él, y no durante la vida de una sola solicitud — versiones anteriores de este punto decían «el procesamiento estándar de la solicitud», que se leía más corto que el documento (§13.5). Accedemos mediante un nivel de pago cuyos términos publicados excluyen el uso de las solicitudes para el entrenamiento de modelos; esa exclusión está en los términos del nivel y no en el anexo, y el §13.5 explica por qué la diferencia importa.
• Retención por Omnisio: una respuesta de IA se almacena en caché hasta 24 horas para no pagar dos veces la misma pregunta. Un Today's Insight servido desde caché no envía nada.
• Qué conserva Omnisio del resultado: el análisis y no la entrada — la estimación nutricional y no la foto de la comida (§12.1), el informe y no el extracto con el que se escribió. Una conversación con el Conserje se guarda en nuestros servidores como su historial de chat y se elimina con su cuenta.

13.4 Su consentimiento, y dónde vive el registro de él

Antes de que una funcionalidad de IA se ejecute por primera vez, Omnisio muestra la Pantalla de Consentimiento de IA que describe lo anterior. Usted puede:

• Aceptar — las funcionalidades de IA quedan habilitadas
• Rechazar — las funcionalidades de IA siguen apagadas; el resto de la aplicación funciona sin ellas
• Retirar — en cualquier momento en Más → Privacidad y Confianza → Personalización con IA. Las solicitudes posteriores se detienen. Una ya respondida no puede recuperarse, pero no se envía nada más.

13.5 Protección Equivalente

Omnisio es cliente de pago del proveedor de IA al que llama, y el anexo de tratamiento de datos de ese proveedor se aplica a esa cuenta y ya ha sido leído. Dos cosas van antes que ninguna otra, porque fijan cuánto vale el resto de esta sección. Es el anexo estándar del proveedor — publicado abiertamente e incorporado a los términos que aceptamos, no negociado para nosotros ni firmado página a página. Tener un documento y haberlo negociado son afirmaciones distintas, y solo la primera es nuestra. Y es un documento que puede moverse: lleva su propia fecha de «última actualización», y la versión leída para esta publicación es la del 31 de julio de 2026. Lo que sigue es lo que dice esa versión, y termina donde termina el documento.

Qué cubre. Cada uno de estos puntos está en el documento, y cada uno es de los que el artículo 28(3) del RGPD exige resolver en una relación con un encargado.

• Finalidad. El proveedor trata lo que enviamos solo conforme a nuestras instrucciones documentadas — que el documento define como el propio anexo, los términos que hay detrás y lo que pide nuestra propia configuración del servicio — y por lo demás solo cuando una ley lo exige; en ese caso debe avisarnos antes, salvo que la ley se lo prohíba.
• Confidencialidad. Las personas a las que permite acercarse a los datos están sujetas a obligaciones de confidencialidad.
• Seguridad. Un programa de seguridad escrito, descrito con medidas concretas y no con adjetivos: acceso según necesidad de conocer y retirado cuando deja de hacer falta, credenciales únicas por usuario, cifrado de los datos en tránsito por redes públicas y en reposo en sus sistemas, escaneo de vulnerabilidades con remediación por gravedad, herramientas de prevención de fugas, segmentación de red y controles de acceso físico. Solo puede cambiar esas medidas de forma que no reduzca el nivel de protección.
• Aviso de brecha. Nos notifica a nosotros sin dilación indebida tras tener conocimiento de un incidente de seguridad, toma medidas razonables para limitarlo y nos ayuda a cumplir nuestras propias obligaciones de notificación. Conviene leerlo despacio: el deber es hacia Omnisio, no hacia usted. Avisarle a usted, y avisar a una autoridad, sigue siendo trabajo nuestro (§20).
• Supresión. A nuestra elección suprime lo que enviamos, y las copias existentes, una vez terminado el contrato — conservando solo lo que una ley le obligue a conservar y solo durante lo que esa ley diga. El certificado de supresión es nuestro si lo pedimos por escrito.
• Auditoría. Encarga auditorías SOC 2 Type II e ISO 27001, o equivalentes, y nos entrega resúmenes de los informes vigentes cuando se los pedimos. Si esos resúmenes no bastan para que juzguemos su cumplimiento, podemos auditar in situ avisando con 30 días, nosotros mismos o mediante un auditor independiente.
• Subencargados. Puede usarlos, y hemos aceptado de antemano que lo haga. A cambio nos debe 15 días de aviso antes de incorporar uno nuevo y tenemos 10 días para oponernos; si la oposición no se resuelve en otros 10 días, cualquiera de las partes puede terminar la parte del servicio que no puede prestarse sin la empresa objetada. Debe vincular a cada subencargado a protecciones no más débiles que las suyas, y responde ante nosotros de lo que hagan como de lo suyo propio.
• Ayudarnos a responderle. Cuando nuestro uso del servicio no nos permite atender algo que usted pide conforme al §17, asiste; lo mismo para las evaluaciones de impacto. Si una autoridad pública reclama los datos, nos lo comunica siempre que la ley se lo permita, para que tengamos ocasión de oponernos o pedir protección.
• La transferencia misma. Las Cláusulas Contractuales Tipo de la UE — Módulo Dos, de responsable a encargado, con nosotros como exportador y el proveedor como importador — están incorporadas al anexo y se tienen por firmadas, para transferencias a países sin decisión de adecuación. El apéndice del Reino Unido a esas cláusulas cubre los datos sujetos al RGPD británico, y una variante suiza cubre los datos suizos. Las controversias bajo las cláusulas se rigen por el Derecho irlandés y los tribunales de Irlanda.

Lo que esto resuelve para Turkiye: nada. Las Cláusulas Contractuales Tipo son el mecanismo europeo, y la KVKK no se satisface con ellas. El artículo 9/4 quiere uno propio — normas corporativas vinculantes aprobadas por el Consejo, el contrato tipo del propio Consejo notificado a la Autoridad dentro de los cinco días hábiles siguientes a la firma, o un compromiso escrito con autorización del Consejo — y este anexo no es ninguno de los tres. La posición escrita en el §4.1 del aviso KVKK no queda tocada por él: no tenemos constancia de tal contrato para ningún encargado, y esa sección lo dice con esas palabras. En cuanto al artículo 12, el deber propio del responsable de mantener seguros los datos, el anexo de seguridad anterior es prueba que podemos invocar por haber elegido a este encargado y no a otro. No es el cumplimiento de ese deber, que sigue siendo nuestro.

Lo que esta sección decía antes, y por qué la frase antigua no se restituye tal cual. Hasta la versión 2.8 decía: «Hemos revisado sus acuerdos de tratamiento de datos (DPA) y nos satisface que cumplen los requisitos del Artículo 28 del RGPD y el Artículo 12 de la KVKK». Se retiró en la 2.8 como afirmación de cumplimiento sin verificar: ser cliente de una empresa no es lo mismo que tener con ella un acuerdo de tratamiento, y nadie podía señalar ninguno. De la 2.8 a la 2.13 esta sección dijo que la relación de cliente era todo lo que podíamos afirmar. El documento ya se ha obtenido y leído, y esta versión escribe lo que contiene. La frase retirada no vuelve. Afirmaba satisfacción en dos patas, y la segunda — el artículo 12 de la KVKK — no es algo que un anexo europeo de tratamiento pueda entregar, como expone el párrafo anterior. Lo que la sustituye es una descripción y no un veredicto: si un acuerdo satisface el artículo 28 para un tipo concreto de tratamiento es un juicio, y una página que ha eliminado los veredictos de cumplimiento ajenos (§16.1, §20) no debería concederse uno nuevo.

14. Comprar una Membresía: Pago, Entrega y su Dispositivo

Esta sección trata la vertiente de datos de una compra. Qué recibe, cuánto cuesta y cuáles son las reglas de cancelación y desistimiento corresponden a los Términos del Servicio. Si alguna vez parecen discrepar, los Términos describen el acuerdo y esta página describe los datos.

14.1 Dos formas de pagar, dos rutas de datos distintas

Dónde compra determina quién gestiona su pago, y cambia lo que nosotros llegamos a ver.

• Comprado dentro de la aplicación de iOS. Apple lo vende y lo procesa. Nunca vemos una tarjeta, una dirección de facturación ni el correo de su cuenta de Apple. Utilizamos RevenueCat como agregador de recibos; recibe su Apple User ID anónimo (una cadena larga y opaca, no su correo), el token de verificación del recibo de Apple, el identificador del producto de suscripción y el estado de renovación, y un código de país con fines fiscales. RevenueCat no recibe su nombre ni su dirección de correo. Véase la política de privacidad de RevenueCat.
• Comprado fuera de la aplicación. Un proveedor de pago procesa la tarjeta, y nosotros procesamos el pedido. El contenido completo de un registro de pedido se detalla en el §3.9: su nombre, dirección de entrega, número de teléfono, dirección de correo, datos de facturación, líneas del pedido, referencias de pago — y, en un plan familiar, las direcciones de correo de las personas que usted añadió. La tarjeta en sí sigue yendo al proveedor y nunca a nosotros.

14.2 Entrega

Para enviar un dispositivo entregamos a la empresa de transporte lo que una empresa de transporte necesita y nada más: el nombre del destinatario, la dirección de entrega, el número de teléfono y una descripción del contenido. La empresa de transporte no recibe sus datos de salud, los datos de su cuenta de Omnisio ni el importe de su pedido.

La empresa de transporte decide por su cuenta cuánto tiempo conserva los datos de entrega y bajo qué reglas; eso no lo fijamos nosotros. Hoy no nos vuelve ningún número de seguimiento ni ningún estado de la entrega: no hay ningún sistema de transporte conectado al nuestro, así que ese campo del registro del pedido está vacío y así sigue, y del paquete se ocupa una persona. El día en que esté operativa una integración con la empresa de transporte, ambos volverán a nosotros y se guardarán en el pedido (§3.9). Si su dispositivo se envía a un país distinto de aquel en el que operamos, sus datos de entrega llegan a una empresa de transporte de ese país: eso es una transferencia internacional, y se le aplica el §16.

14.3 Sustitución de su dispositivo

Mientras su membresía esté activa, un dispositivo que falla se sustituye. Hacerlo implica tratar la solicitud de sustitución (§3.10), los números de serie de la unidad que sale y de la que llega, y una dirección de entrega para la nueva. Cuando hay un defecto de fabricación de por medio, podemos comunicar al fabricante el número de serie y una descripción de la avería. No le comunicamos sus datos de salud junto con ello.

14.4 Si desiste, cancela, devuelve o recibe un reembolso

Ejercer un derecho de desistimiento o de cancelación, devolver un dispositivo o recibir un reembolso es, en sí mismo, algo que debemos registrar y poder acreditar: qué pidió, cuándo lo pidió, qué hicimos y cuándo se devolvió el dinero.

Ahora sí conservamos ese registro. Un desistimiento, una cancelación, una devolución o un reembolso sobre un pedido hecho directamente con nosotros se escribe en el propio pedido y sigue la conservación del §18, lo que hoy significa que se va cuando se va el pedido, y el pedido se va cuando usted elimina su cuenta. Una compra hecha en la App Store no cambia: un reembolso allí es un registro de Apple y no nuestro. La versión 2.6 decía que no conservábamos ningún registro de ese tipo y prometía decirlo aquí el día en que eso cambiara. Este es ese día.

14.5 Recomendaciones

Si invita a alguien con su código de invitación, guardamos el emparejamiento entre las dos cuentas y el crédito que generó, para que ambas partes reciban lo que les corresponde y una misma cuenta no pueda acreditarse dos veces. Los registros de recomendación aparecen en la exportación de sus datos y se eliminan con su cuenta. Un código de invitación no le cuenta a la persona invitada nada de usted más allá de lo que la Comunidad ya muestra (§7.1).

Una invitación a un plan familiar es otra cosa, y no queremos que se confundan. Ahí sí le contamos algo sobre usted: su nombre completo y la fecha en que introdujo su dirección. Estamos obligados a hacerlo: quien nunca nos dio sus datos tiene derecho a que le digamos de dónde salieron (RGPD art. 14(2)(f); KVKK art. 10). Eso es todo lo que llega a saber de usted. Ni su dirección de correo, ni lo que pagó, ni nada de su cuenta o de la Comunidad. Véase el §14.6.

14.6 Planes familiares: cuando introduce la dirección de correo de otra persona

Un plan familiar es un solo pago que compra entre 3 y 10 membresías. Usted introduce las direcciones de correo de las personas a las que van las demás plazas. Es la primera vez que Omnisio pide a un cliente datos personales de otra persona, y merece decirse sin rodeos: desde el momento en que usted escribe una dirección, esa persona también es interesada frente a nosotros — y sus datos no nos los dio ella. Nos los dio usted.

Qué le enviamos. Cada dirección recibe un correo. Dice quién compró la membresía — su nombre completo —, la fecha en que usted introdujo su dirección, de qué plan se trata y cómo reclamar la plaza. En ese mismo correo, y no detrás de un enlace, se le indica qué guardamos sobre ella (su dirección de correo y nada más: ni nombre, ni teléfono, ni dirección, ni dato de salud alguno), por qué lo guardamos, durante cuánto tiempo, quién más lo ve, cuáles son sus derechos y dónde reclamar. Lleva además un enlace que elimina su dirección en un clic: sin iniciar sesión y sin formulario. Ese correo es transaccional. No lleva ninguna oferta, ningún otro producto y ninguna frase de marketing.

La base jurídica es el interés legítimo, no el consentimiento. Nos apoyamos en el artículo 6(1)(f) del RGPD y en el artículo 5/2-f de la KVKK: nuestro interés es hacer llegar la membresía que usted pagó a la persona para la que la pagó. Deliberadamente no es consentimiento, porque el consentimiento tiene que venir de la persona cuyos datos son, y nadie puede darlo en nombre de otro. Cuando introduce una dirección le pedimos que confirme que conoce a esa persona y que la introduce con su conocimiento. Esa confirmación es una promesa que usted nos hace. No es el consentimiento de esa persona, y no lo vamos a llamar así.

Qué ve usted y qué no ve nunca. Como persona que ha pagado, usted ve el estado de cada plaza: invitada, reclamada, no reclamada o trasladada a otra dirección. No ve el nombre del miembro, no ve su dirección de entrega y no ve nunca ninguno de sus datos de bienestar: ni recuperación, ni sueño, ni carreras, ni diario, ni una sola métrica. Un plan familiar es una forma de pagar la membresía de alguien. No es una forma de vigilarle.

Una dirección que nunca se reclama. Si nadie reclama una plaza, eliminamos esa dirección de correo 90 días después de la última invitación que le enviamos. Durante esos 90 días usted puede cambiarla por otra. La plaza en sí sigue siendo suya durante todo el periodo que pagó: perder la dirección no le cuesta la plaza. Pasados los 90 días la dirección desaparece del sistema en uso, y lo que queda es el registro del pedido, que conserva lo que usted compró durante el plazo legal del §18.

Trasladar una plaza a otra persona. Una plaza que no se ha reclamado puede trasladarse a otra dirección en cualquier momento. Una plaza reclamada que ya es una membresía activa no se traslada durante el periodo. Puede cancelarla, y el traslado surte efecto al final del periodo que ya pagó; la persona que la usa conserva su membresía hasta esa fecha. No vamos a quitarle a nadie una membresía en funcionamiento a mitad de periodo porque quien pagó haya cambiado de opinión.

Si el miembro elimina su cuenta. Eliminar una cuenta de Omnisio borra los datos propios de esa persona — y su dirección de correo sale con ellos del pedido de usted. Las dos copias: la plaza misma y la lista de direcciones con la que su pedido quedó congelado al comprarlo. Lo que queda es una plaza sin dirección, y no se le dice por qué se vació. Si esa persona había aceptado la plaza, esta figura como terminada y usted puede indicar a qué dirección pasa después, con efecto al final del periodo que ya pagó. Si nunca la aceptó, es simplemente una plaza vacía y puede dársela a otra persona de inmediato. Hasta esta corrección, este párrafo decía que esa dirección se quedaba en su pedido por formar parte de un registro comercial. No se queda. El §17 llevaba la misma frase como quinto límite y se ha corregido con él; quien fue invitado y nunca se registró tiene su propia sección en el §17.1.

Si es usted quien elimina su cuenta, las membresías que pagó no se van con ella. El pedido se queda y las plazas se quedan. Todo el que aceptó una conserva su membresía, su propia dirección de entrega y sus propios datos hasta el último día del periodo que usted pagó. Ese dinero lo cobramos entero y por adelantado, por esas personas; que usted se marche no es motivo para quitarles lo que ya se compró para ellas. Lo que se va es usted: su dirección de correo, su teléfono, su nombre y su dirección de entrega se borran del pedido, su propia plaza se vacía y el pedido ya no puede abrirse — la referencia y su dirección dejan de funcionar juntas, de modo que lo que era su credencial no sirve para leer las direcciones de los demás miembros. Después no se renueva nada, y nunca se renovó nada: este servicio no tiene ningún mecanismo que renueve una membresía por sí solo, un plazo pagado sencillamente termina en su fecha. Esa fecha se les comunica a los miembros: un aviso en cuanto esto ocurre, y otros dos 30 días y 7 días antes del final — o solo los que queden por delante si resta menos tiempo. Esos correos dicen la fecha de fin y qué pueden hacer al respecto. No hablan de usted. Cerrar su cuenta es un acto suyo, no una noticia que traslademos a quienes se beneficiaron de lo que usted compró.

Edad. Cada plaza de un plan familiar está sujeta al mismo mínimo que cualquier otra membresía: nadie menor de 16 años (§19). Comprar una plaza para alguien no cambia la edad que tiene.

14.7 Pedir sin cuenta

Puede hacernos un pedido sin crear una cuenta de Omnisio. Si lo hace, guardamos lo que necesita cualquier pedido — su nombre, dirección de entrega, número de teléfono, dirección de correo y el pedido en sí — sin ninguna cuenta asociada. Hasta la versión 2.7 esta página no contemplaba la figura de un comprador sin cuenta. Debería haberlo hecho antes de que el primer pedido así fuera posible, y esta sección es esa corrección.

Cómo volver a abrirlo. Un pedido de invitado se abre con la referencia del pedido más la dirección de correo que usó. Guardamos un hash unidireccional de esa dirección y lo comparamos con lo que usted escribe; juntos funcionan como una contraseña para ese único pedido. Guarde la referencia para usted por la misma razón por la que guardaría una contraseña.

Eliminarlo tiene ahora dos respuestas distintas, y cuál le toca depende de si hay otras personas en el pedido. La eliminación de cuenta antes no alcanzaba nada de esto, porque un pedido de invitado no lleva cuenta. Ahora lo alcanza a través de la dirección de correo verificada de su cuenta: un pedido hecho con esa dirección es suyo, y eliminar su cuenta lo elimina — el pedido, sus líneas, sus intentos de pago y cualquier cosa que un proveedor hubiera devuelto con él. Un pedido no se elimina, y es justo el que no es solo suyo: un plan familiar que usted pagó. De ese pedido cuelgan las membresías de entre tres y diez personas más, y terminarlas porque usted cerró su cuenta sería quitarles algo comprado y pagado en su nombre. Ese pedido se queda, vaciado de usted: su dirección de correo, su teléfono, su nombre y su dirección de entrega se borran de él, y ya no puede abrirse con la referencia (§14.6). Un pago familiar que nunca llegó a cobrarse no lleva a nadie encima, y se elimina como cualquier otro pedido. Todo esto va ligado a una dirección que su cuenta haya verificado: si no hay ninguna, no ocurre nada de lo anterior, y el camino para que se atienda ese pedido es escribir a privacy@omnisio.app con la referencia. Lo que podamos hacer entonces está limitado por la misma conservación que cualquier otro pedido (§18).

15. Otros Servicios de Terceros

16. Almacenamiento y Transferencia de Datos

16.1 Dónde se almacenan sus datos

El servidor de aplicación de Omnisio funciona en Railway y su base de datos es un clúster gestionado de MongoDB Atlas, con contratos que los convierten en encargados que actúan siguiendo nuestras instrucciones y sin finalidad propia alguna.

Hasta la versión 2.8 esta sección decía que identificamos a nuestros proveedores «por categoría y no por nombre comercial» — y cuatro párrafos más abajo el §16.2 nombraba un país, una región de nube y una ciudad. Una misma página no puede sostener las dos frases, y la contradicción era visible para cualquiera que siguiera leyendo. La regla que de verdad seguimos es más estrecha, y queda escrita aquí en vez de quedar implícita: nombramos a un destinatario cuando lo hemos verificado, y describimos por categoría a aquel al que nombrar diría más de lo que sabemos. Por eso Apple, Google, RevenueCat, Railway y MongoDB Atlas están nombrados en esta página y nuestro proveedor de IA no (§13.3): la categoría es lo que permite el artículo 13(1)(e) del RGPD, y la identidad está a su disposición si la pide — escríbanos a privacy@omnisio.app y se la indicaremos.

16.2 Transferencias fuera de su país

Algunos destinatarios se encuentran fuera de Türkiye y fuera de la Unión Europea. Apple, Google y RevenueCat están establecidos en Estados Unidos, al igual que nuestro proveedor externo de procesamiento de IA. También lo está nuestro proveedor de correo transaccional — lo que significa que una dirección que usted introduzca para un miembro de la familia sale de su país en cuanto se envía la invitación —; también el servicio de notificaciones push por el que pasa cada notificación antes de llegar a Apple; y también el proveedor de almacenamiento de objetos que guarda las fotos de perfil y, durante siete días, el archivo que produce su exportación de datos. Cuando un dispositivo se envía al extranjero, la empresa de transporte que lo entrega está en el país de destino, y el proveedor de pago que procesa una tarjeta suele estar en el país donde se emitió esa tarjeta.

Las transferencias desde la Unión Europea se basan en las Cláusulas Contractuales Tipo y, cuando el destinatario está certificado, en el Marco de Privacidad de Datos UE-EE. UU. Las transferencias desde Türkiye se basan en los mecanismos del artículo 9 de la KVKK. Nuestra base de datos gestionada consta como situada en Alemania (AWS eu-central-1, Fráncfort) — lea la nota sobre la fuente en el §16.1 antes de apoyarse en esa frase — y nuestro servidor de aplicación opera fuera de Türkiye, es decir, la transferencia continua al extranjero la implica el propio servicio y no solo una lista de destinatarios externos. En qué mecanismo del artículo 9 se apoya y qué queda pendiente se detalla en el §4.1 del aviso KVKK (en turco). Cuando un destinatario de los anteriores se describe por categoría en vez de nombrarse, el motivo y la regla están en el §16.1; la identidad está a su disposición si la pide en privacy@omnisio.app.

16.3 Si se encuentra en la Federación de Rusia

Esté donde esté, sus datos se tratan como describe esta política, y todos los derechos del §17 están a su disposición íntegramente.

Lo que podemos afirmar como hecho. Las tarjetas emitidas en la Federación de Rusia no se aceptan para una compra directa (§15), de modo que aquí no nace ningún registro de pedido, factura o entrega a partir de una tarjeta rusa. Nuestros servidores y nuestra base de datos están fuera de Rusia. Esta página, la aplicación y la invitación al plan familiar se publican en ruso.

Lo que está sin resolver, y no lo vamos a maquillar. La ley rusa obliga al operador que recoge datos personales de ciudadanos de la Federación de Rusia a registrarlos, almacenarlos y actualizarlos usando una base de datos situada en Rusia (Ley Federal 152-FZ, artículo 18(5)), y a notificar al regulador antes de una transferencia transfronteriza (artículo 12). Si eso alcanza a una empresa turca sin entidad rusa, que no acepta tarjetas rusas y que llega a personas en Rusia solo a través de una aplicación en ruso, es una pregunta sobre hasta dónde llega una ley extranjera. Para nosotros no está respondida. No hemos presentado ninguna notificación conforme al artículo 12.

Qué cambió con el plan familiar, y por qué se escribe aquí. Hasta esta versión nada de esta página creaba un registro sobre una persona en Rusia, así que la pregunta abierta seguía siendo teórica. Ha dejado de serlo en un punto concreto: un cliente de cualquier país puede escribir en un plan familiar la dirección de correo de un familiar que vive en Rusia, y esa dirección queda escrita en una base de datos fuera de Rusia. Rechazar las tarjetas rusas no cierra esa puerta, porque la persona cuyos datos son no es la que paga.

Nuestra posición por ahora. No afirmamos cumplir la ley rusa de localización, ni afirmamos que no sea aplicable. Ninguna de las dos cosas podríamos sostenerla. La versión 2.6 decía que la revisión estaba en curso cuando no se recogía nada: una frase honesta entonces que no lo sería ahora. Así que exponemos la situación real y tratamos la decisión como abierta y pendiente. Si está en Rusia y esto le importa, escriba a privacy@omnisio.app: le diremos en qué punto está la respuesta y, si nos lo pide, eliminaremos su dirección en lugar de dejarla en un lugar que ninguno de los dos puede evaluar.

17. Sus Derechos (KVKK / RGPD / CCPA)

Usted tiene derecho a:

• Acceder a sus datos y recibir una copia (en la aplicación: Más → Privacidad y confianza → Tus datos → Exportar Mis Datos)
• Rectificar datos inexactos
• Eliminar su cuenta y datos (Más → Privacidad y confianza → Tus datos → Eliminar cuenta, o Perfil y Ajustes → Datos y privacidad → Eliminar cuenta: es el mismo control, accesible por dos rutas). La eliminación es inmediata e irreversible; qué se borra y qué sobrevive está detallado en nuestra página de eliminación de datos
• Restringir el tratamiento
• Oponerse al tratamiento basado en intereses legítimos
• Portabilidad — recibir sus datos en formato legible por máquina
• Retirar el consentimiento para las funcionalidades de IA (Más → Privacidad y Confianza → Personalización de IA)
• Retirar el consentimiento para cualquier métrica de bienestar compartida, métrica a métrica (Comunidad → Qué comparte)
• Presentar una reclamación ante la KVKK (Türkiye), la autoridad supervisora de la UE o la autoridad local de protección de datos

Conviene conocer de antemano cinco límites. Los registros de moderación — denuncias — sobreviven a la eliminación de la cuenta por los motivos de seguridad y auditoría expuestos en el §8.3; escríbanos y ponderaremos una solicitud de supresión frente a esos intereses. Las lecturas de señal cardíaca nunca llegan a nuestros servidores, por lo que no pueden figurar en una exportación que preparemos nosotros ni se eliminan al borrar su cuenta: se eliminan borrándolas en la aplicación o desinstalando la aplicación (§10).

El tercer límite ya afecta, y hasta esta versión no lo hacía. El derecho de supresión no prevalece sobre una obligación legal de conservación (artículo 7 de la KVKK; artículo 17(3)(b) del RGPD), y la legislación tributaria y mercantil turca obliga a conservar las facturas y los registros de pedido que hay detrás durante un número fijo de años, prefiéranlo o no usted o nosotros. Omnisio ya crea esos registros. Lo que todavía no crea es el documento que pone en marcha el plazo: el artículo 82 corre sobre los libros mercantiles y los documentos que hay detrás, y el documento que hace falta aquí es una factura — y no la emitimos, porque la integración de contabilidad y facturación electrónica no está conectada (§18). Así que la respuesta honesta hoy es la contraria a la que daba este párrafo: eliminar su cuenta elimina el pedido asociado a ella, con sus líneas, sus intentos de pago y las notificaciones del proveedor. El día en que se conecte la facturación, una factura y el pedido que hay detrás dejarán de poder eliminarse, y este párrafo cambiará en esa versión y no antes. Las versiones 2.5 y 2.6 de esta página decían que no conservábamos ningún registro de pedido; era cierto cuando se escribió y ya no lo es.

Lo que contiene un pedido, para que sepa qué se va con él: quién compró qué, cuándo, por cuánto, a qué dirección, las líneas del pedido y las referencias de pago — y, en un plan familiar, las direcciones de correo que usted introdujo para otras personas, el estado de cada plaza y el historial de las invitaciones que enviamos. La versión 2.6 decía el registro comercial «y nada más»; se escribió antes de que existieran los planes familiares y se quedaba corta sobre lo que contiene un pedido. Los datos de bienestar, las carreras, el diario, el grafo de comunidad, el historial de sustituciones y la propia cuenta se van con él. Hay un pedido al que la eliminación de cuenta no llega, y es el cuarto límite de abajo: un plan familiar que usted pagó, con las membresías de otras personas encima. El quinto límite de abajo era un segundo caso — el pedido de otra persona que lleva su dirección — y ha dejado de ser un límite. Los plazos están en el §18.

El cuarto límite, que se ha estrechado: un pedido hecho sin cuenta. Un pedido de invitado hecho con la dirección de correo que su cuenta ha verificado se elimina ahora junto con su cuenta, con sus líneas, sus intentos de pago y cualquier notificación de un proveedor. Hasta esta corrección no se alcanzaba nada de eso. Lo que sigue sin eliminarse es un plan familiar que usted pagó: sobre ese pedido están las membresías de otras personas y duran hasta el final del periodo que usted pagó, así que el pedido sobrevive con todo lo que le identificaba a usted borrado de él (§14.7). Para un pedido hecho con una dirección que su cuenta no ha verificado, escriba a privacy@omnisio.app con la referencia; el plazo del §18 se le aplica exactamente igual que a cualquier otro pedido.

El quinto límite ha desaparecido: si alguien le compró una plaza en un plan familiar. Preferimos decirlo así antes que dejar en pie una frase que nos hacía parecer más cuidadosos de lo que éramos. Eliminar su cuenta de Omnisio retira ahora también su dirección de correo del pedido de quien pagó: de la plaza misma y de la lista de direcciones con la que su pedido quedó congelado. En su registro no queda nada de usted. A esa persona le queda una plaza sin dirección, y no se le dice por qué (§14.6). Versiones anteriores de esta página decían que esa dirección se quedaba con su registro comercial y que había que escribirnos aparte por ella. No hace falta.

Una condición previa, porque decide si los dos párrafos anteriores llegan a ocurrir. Todo lo que la eliminación de cuenta hace por dirección y no por cuenta — el pedido de invitado, el pedido familiar, su plaza en el pedido de otra persona — funciona con la dirección de correo que su cuenta ha verificado, leída en el momento de la eliminación. Si la cuenta no tiene dirección verificada, o no podemos leerla, esos pasos no se ejecutan: la cuenta y todo lo asociado a ella se van igualmente, y en el registro de eliminación que conservamos queda anotado que la parte ligada a la dirección se omitió. Preferimos dejar eso detrás y decírselo aquí antes que borrar la invitación de un desconocido porque una dirección sin verificar coincidiera con la suya. Si es su caso, escriba a privacy@omnisio.app.

Pedir sus datos crea una segunda copia de ellos, y conviene que sepa adónde va esa copia. Una exportación se construye en un único archivo comprimido y se guarda en almacenamiento de objetos privado (§15). Usted recibe un enlace a él; el enlace y el archivo dejan de existir a los 7 días. Si elimina su cuenta antes, el archivo se elimina con todo lo demás. Ese fichero es todo lo que tenemos sobre usted reunido en un solo sitio, así que trate el enlace como trataría el fichero. Ninguna versión de esta página anterior a la 2.8 mencionaba el archivo, de modo que quien ejercía el derecho más protector de esta lista lo hacía sin que se le dijera su forma.

Tres registros quedan atrás a propósito cuando elimina su cuenta, y ninguno trata de su salud. Están listados con sus plazos en el §18, y aquí se describen por primera vez:

• Un recibo de supresión. Una fila que registra que la eliminación ocurrió y si con ella se revocó su concesión de Iniciar Sesión con Apple. Eliminarla junto con la cuenta destruiría la única prueba de que hicimos lo que usted pidió.
• Un rastro de auditoría de credenciales. Eventos de inicio de sesión y de uso de claves de API — qué ocurrió, qué credencial, cuál fue el resultado. Nunca una dirección, nunca un token, nunca nada que usted midiera. Es lo que hace visible el abuso de credenciales contra otras cuentas, que es el terreno estrecho en el que el derecho de supresión deja en pie un registro así.
• La fila de la concesión de membresía, vaciada en lugar de eliminada. Si tuvo una membresía comprada en omnisio.app, su identificador de usuario, su dirección de correo y el hash de esta se retiran de la fila y la concesión se marca como revocada — pero la clave de la fila permanece. Eliminarla era lo que permitía que una conciliación rutinaria posterior reconstruyera en silencio esa membresía contra su dirección y se la entregara a quien registrara esa dirección después. Lo que queda describe una compra y no nombra a nadie.

Para ejercer estos derechos: privacy@omnisio.app. Respondemos en un plazo de 30 días (Artículo 13 de la KVKK).

17.1 Si le invitaron a un plan familiar y nunca se registró

Puede que esté leyendo esto porque le llegó un correo diciendo que alguien le compró una membresía de Omnisio, y usted no tiene cuenta con nosotros ni la quiere. Tiene derechos aquí, y no dependen de que llegue a ser cliente.

Qué guardamos sobre usted: su dirección de correo y un hash unidireccional de ella. Nada más: ni nombre, ni teléfono, ni dirección, ni dato de salud de ningún tipo. De dónde la sacamos: de la persona que pagó, que la introdujo al finalizar la compra; su nombre y la fecha figuran en el correo que usted recibió. Para qué: para entregarle la plaza de membresía comprada para usted, sobre la base del interés legítimo (RGPD art. 6(1)(f); KVKK art. 5/2-f) — no del consentimiento, porque usted nunca lo dio y nadie puede darlo por usted. Durante cuánto: 90 días después de la última invitación, y luego se elimina.

Cómo terminar con esto ahora. El correo de invitación lleva un enlace de eliminación en un clic: sin iniciar sesión y sin formulario. Seguirlo elimina su dirección y la registra para que no se pueda volver a invitar a esa misma dirección. También puede escribir a dpo@omnisio.app. Tiene derecho a oponerse sin más a este tratamiento (RGPD art. 21; KVKK art. 11), y si se opone, paramos. No le pedimos que lo justifique ni se lo consultamos a quien pagó.

Ese único clic llega más lejos de lo que esta página admitía, y la corrección es a su favor. Seguir el enlace borra su dirección de los tres sitios donde se guarda: la plaza que se le estaba reservando, el registro de la invitación que hay detrás y la lista de direcciones dentro del pedido de quien compró el plan. En su registro no queda nada de usted. Hasta esta versión, este párrafo decía que la copia dentro de su pedido era lo único que no podíamos deshacer y que su oposición no alcanzaba a su interior. Sí alcanza. Era la peor frase de esta página — decirle a alguien que no podemos hacer por él algo que de hecho hacemos — y por eso este párrafo empieza ahora al revés. A quien compró el plan le queda una plaza sin dirección, y sin explicación. Lo que sí conservamos es un hash unidireccional de su dirección en una lista de supresión, con el único fin de no volver a escribirle nunca. El enlace funciona mientras la plaza no se haya aceptado; una vez aceptada, la plaza pertenece a una cuenta y el camino desde ahí es la eliminación de cuenta (§17), que ahora también retira la dirección del pedido del comprador.

18. Retención de Datos

Un pedido no es un solo reloj. Hasta esta versión esta tabla trataba un pedido como un único elemento con un único plazo. No lo es. Una fila de pedido contiene un registro comercial que la ley turca bloquea diez años y, justo al lado, la dirección de correo de alguien que quizá nunca llegue a ser cliente. Esos dos no pueden compartir plazo de conservación, así que la tabla siguiente va por campo y no por fila.

Por qué corren dos relojes distintos. La KVKK y el RGPD dicen que solo podemos conservar datos personales mientras su finalidad lo exija. La ley tributaria turca dice que una factura debe conservarse cinco años; el Código de Comercio turco dice que los libros mercantiles y los documentos que los sustentan deben conservarse diez. Cuando esas reglas apuntan al mismo documento y discrepan, gana el plazo legal más largo, y a partir de ahí el dato queda vinculado únicamente a esa finalidad. Los diez años no empiezan el día en que usted hace el pedido. El artículo 82/6 del Código de Comercio turco cuenta el plazo desde el final del año natural en que se hizo el registro, de modo que un pedido hecho en marzo de 2026 se conserva hasta el final de 2036, y no hasta marzo de 2036. Un registro de pedido conservado durante diez años existe para contabilidad, auditoría y defensa jurídica y para nada más: no para perfilarle, no se reintroduce en la aplicación y no es una forma de mantener viva su cuenta después de que usted la eliminara. Esto ya está en vigor (§3.9).

19. Menores y Jóvenes

Omnisio no es para nadie menor de 16 años. No recopilamos a sabiendas datos de menores de 16 años. Si cree que lo hemos hecho, escriba a privacy@omnisio.app y los eliminaremos.

A los 16 y 17 años interviene un progenitor o representante legal — en el lado del contrato. La membresía en sí se celebra con esa persona (Términos §1.3), porque un contrato anual de pago que incluye un dispositivo es una obligación que un menor no puede asumir solo. Esa misma persona confirma el consentimiento para el tratamiento de datos de bienestar descrito en el §4.1, desde una dirección de correo que hemos verificado, y conservamos constancia de que la confirmación se dio y de cuándo — sin otra finalidad que poder acreditar que se obtuvo.

16 es un suelo deliberado, no un mínimo que nos hayan impuesto. Se sitúa en o por encima de la edad de consentimiento digital de todos los Estados miembros de la UE, de modo que el artículo 8 del RGPD — la regla de consentimiento parental para datos de menores — no llega a activarse por el lado de los datos, y queda muy por encima del umbral de 13 años de la ley estadounidense COPPA. El paso parental anterior existe por el lado del contrato, que es una pregunta distinta con una respuesta distinta.

Los Términos y esta página llevan ya el mismo número. Hasta la versión 2.4 no era así: los Términos decían 18 y esta página 16. La fuente única es el §1.3 de los Términos, y ambos documentos remiten ahora a él.

20. Seguridad

Lo que está en marcha:

• HTTPS / TLS para todas las comunicaciones de red
• Cifrado en reposo (AES-256-GCM) para los campos sensibles
• Control de acceso basado en roles
• Un rastro de auditoría para los eventos de credenciales — uso de claves de API e inicios de sesión (§17)
• Que las lecturas de señal cardíaca no lleguen nunca a nuestros servidores — protección por diseño y no por política (§10)
• Credenciales de inicio de sesión guardadas en su dispositivo en el Llavero de iOS, cifradas por el sistema operativo
• Un filtro de nombres y una cola de moderación revisada por personas para el contenido de la Comunidad (§8)

Ningún sistema es 100% seguro. Si sospecha de una brecha de seguridad: security@omnisio.app

21. Cambios en Esta Política

Qué cambió en la versión 2.16 (3 de septiembre de 2026). Algo se ha lanzado y, por primera vez en siete versiones, el cambio de esta página no es una corrección a la descripción de un código que ya estaba funcionando. §3.12 describía la Calibración matinal como diseñada y apagada en todas las versiones hasta la 2.15. El código que la ejecuta está escrito y desplegado, y entre él y el interruptor queda una condición — el registro VERBIS de §3.12 —, de modo que todavía no se mide ninguna mañana de nadie. Reescribimos la sección ahora y no el día en que se accione el interruptor, para que lo que describe pueda comprobarse antes de que empiece. Esa sección no se ha editado sino reescrito a partir del código: qué mide el teléfono, que una de las cuatro mediciones es un ángulo y no una proporción como la llamaron todas las versiones anteriores, los once campos adicionales que una mañana lleva junto a esas cuatro y que ninguna versión enumeró, qué deja y qué no deja tras de sí una mañana rechazada, la conservación de 24 meses y la relectura en el borrado. La regla que añadió la versión 2.12 sigue rigiendo — no «¿sale el estado privado?» sino «¿qué dice esta carga sobre este miembro que la sección no nombra?» — y aplicarla a una sección sobre una cara es lo que sacó a la luz esos once campos y ese ángulo.

Una de las tres condiciones que §3.12 fijaba para encender el interruptor sigue sin cumplirse: el registro VERBIS todavía no incluye la categoría. Eso está escrito dentro de la propia sección en lugar de dejarse a que el lector lo advierta, y la funcionalidad permanece cerrada en la configuración del servidor hasta que se presente.

Qué cambió en la versión 2.15 (27 de agosto de 2026). No se ha lanzado nada nuevo. La versión 2.12 escribió la corrección más grande de la fila del plan de entrenamiento con IA — que la sesión de ejemplo que le damos al modelo está construida a partir de sus cifras de bienestar y lleva su puntuación de recuperación — y desde entonces nadie la había releído. Medida de nuevo contra el código desplegado, esa fila acierta con cada miembro del que hemos medido algo, y dice más de lo que es cierto sobre el miembro del que no hemos medido nada.

• La fila del plan de entrenamiento con IA del §13.1 decía que sale su puntuación de recuperación, o su puntuación de sueño bajo ese nombre. Cuando no tenemos ninguna de las dos, bajo ese nombre sale un sesenta y cinco fijo. Es el mismo número para todo el mundo en esa situación, así que no es en absoluto una cifra sobre su cuerpo — y la duración de la sesión, su techo de esfuerzo, la frase sobre su disposición y el número de orden de cada ejercicio candidato se calculan a partir de él exactamente igual que se calcularían a partir de una puntuación real. La fila ahora lo dice. Esta corrección va en la dirección poco habitual: la página describía una transferencia mayor que la que ocurre. Sigue siendo una frase falsa en cualquier dirección, y una miembro que no ha registrado nada tiene derecho a saber que el número que ocupa el lugar de su cuerpo en esa solicitud no es suyo.
• La cifra se envía a propósito, y esa decisión corresponde a esta página y no a un comentario en el código. Una sesión no puede dimensionarse con honestidad sin alguna indicación de cuán recuperado parece estar usted, así que el indicador de disposición sigue dentro de lo que enviamos y se describe aquí en vez de retirarse en silencio. Lo que esta página le debe es una descripción exacta de él, en el mismo lenguaje de categorías que usa el resto del §13: una cifra que nuestro propio motor derivó de sus lecturas, enviada a un proveedor de procesamiento con IA identificado aquí por categoría.
• Lo que esto no toca. El resto de la fila se releyó contra el código desplegado y se mantiene: el esfuerzo al que apuntamos, el objetivo de entrenamiento, la semana del ciclo y cómo la llamamos, la duración de la sesión y sus techos de esfuerzo, el esfuerzo objetivo de cada movimiento, la confianza que depositamos en el plan, la lista de nuestros propios registros consultados, la frase sobre la disposición en sesenta, las notas de sueño bajo y de semana aligerada forzada, la nota de falta de historial, la línea de recuperación baja en cuarenta y el título de recuperación activa. El embarazo y el posparto se siguen reteniendo en los términos que la fila ya describe. Ninguna otra fila del §13.1 y ningún punto del §13.2 cambian.

Qué cambió en la versión 2.14 (27 de agosto de 2026). No se ha lanzado nada nuevo. La versión 2.8 retiró la afirmación de que habíamos revisado el acuerdo de tratamiento de datos de nuestro proveedor de IA y dejó su obtención registrada como acción pendiente. El documento ya se ha obtenido y leído, y el §13.5 expone lo que contiene, incluidas las partes que no nos ayudan.

• El §13.5 describe ahora el anexo de tratamiento en lugar de la relación de cliente. Es el documento estándar del proveedor, publicado abiertamente e incorporado a los términos que aceptamos, no negociado para nosotros; la versión leída es la del 31 de julio de 2026. La sección enumera lo que el documento resuelve: tratamiento solo conforme a nuestras instrucciones, confidencialidad, un programa de seguridad escrito con medidas nombradas, aviso de brecha a nosotros sin dilación indebida, supresión tras la terminación con certificado a petición, auditoría mediante resúmenes de informes y derecho de auditoría in situ con 30 días de aviso, aviso de nuevo subencargado con 15 días y ventana de oposición de 10, y las Cláusulas Contractuales Tipo de la UE incorporadas para las transferencias, con variantes británica y suiza.
• Cuatro cosas que no hace quedan escritas junto a las cuatro que sí. No nombra a ningún subencargado — el anexo que debería enumerarlos remite a una dirección que no nos entregó ni un nombre —, así que la segunda empresa de la cadena (§13.3) sigue sin identificar. No contiene ninguna cláusula que excluya el uso de nuestras solicitudes para entrenar modelos: esa exclusión viene de los términos publicados del nivel que compramos y no de este documento, que además permite expresamente tratar datos desidentificados para mejorar el servicio. No nombra ningún país ni promete residencia. Y prevé la conservación hasta que termine el contrato.
• La misma lectura corrige el punto de retención del §13.3. Describía la retención del proveedor como «el procesamiento estándar de la solicitud». El documento dice que el proveedor conserva lo que enviamos hasta que termine nuestro contrato con él. El punto ahora lo dice y remite al §13.5.
• Lo que esto cambia para Turkiye: nada, y la sección lo dice. Las Cláusulas Contractuales Tipo son el mecanismo europeo. El artículo 9/4 de la KVKK quiere uno propio, y este anexo no lo es. El §4.1 del aviso KVKK sigue registrando que no tenemos tal contrato para ningún encargado, y esta versión no lo toca.
• La frase retirada no se restituye. Afirmaba satisfacción con el artículo 28 del RGPD y con el artículo 12 de la KVKK. Lo que la sustituye es la descripción de un documento, no un veredicto sobre él.

Qué cambió en la versión 2.13 (27 de agosto de 2026). No se ha lanzado nada nuevo. Desde la versión 2.8, cada versión ha llevado dos afirmaciones sobre su nombre en la vía del análisis de sangre que no pueden ser ciertas las dos a la vez, y esta es la versión que lo notó.

• El §13.2 prometía, sin excepciones, que su nombre no se envía. La propia fila del análisis de sangre en §13.1 dice desde la versión 2.8 que sí — impreso en la página que usted sube, donde el laboratorio lo puso. Las dos frases han convivido a unas cuarenta líneas de distancia desde que se construyó por primera vez la divulgación de IA, y esta es la primera versión que cotejó una con la otra. El §13.2 ahora dice qué cinco vías cumplen esa promesa y nombra la que no, en vez de prometerlo de las seis.
• La fila del análisis de sangre también subestimaba su propia fuga en una línea, sin relación con el contenido de la página. «Hoy no sale nada más con él» no era del todo exacto: el propio nombre del archivo — la cadena que le dio su teléfono o su ordenador, no algo impreso en el documento — se envía como una línea de texto aparte junto con la solicitud. Un archivo nombrado como suele nombrarse la descarga propia de un laboratorio turco, por el paciente al que pertenece, lleva un nombre que no está en la página en absoluto. La fila ahora lo dice, como una segunda vía separada por la que su nombre puede salir en esta única ruta, distinta de la vía de la página impresa mencionada antes.
• Lo que esto no hace. Nada aquí afirma que Omnisio redacte, lea o retire de otro modo un nombre de un documento antes de enviarlo — esa capacidad no existe, y esta página no va a describir una que no tiene. Tampoco toca las otras cinco filas ni el resto de la lista del §13.2: su correo electrónico, su número de teléfono, su ubicación precisa, su dirección IP, sus lecturas de señal cardíaca, su foto de perfil, los identificadores gubernamentales y los datos de otros miembros siguen sin enviarse, por ninguna vía, y nada de lo encontrado aquí dice lo contrario.

Qué cambió en la versión 2.12 (27 de agosto de 2026). No se ha lanzado nada nuevo. La versión 2.11 corrigió tres filas del §13.1 haciéndole a cada una una sola pregunta: ¿sale un registro de embarazo o de posparto? Todas las pasadas anteriores hicieron esa misma pregunta. Ninguna preguntó qué dice el resto de la solicitud sobre su bienestar, y por eso la fila del plan de entrenamiento con IA era falsa.

• La fila del plan de entrenamiento con IA del §13.1 nombraba cuatro cosas que salen. Dejaba fuera la sesión de ejemplo, y esa sesión lleva su puntuación de recuperación. La fila decía «lo que ha pedido, la categoría que eligió, los ejercicios candidatos a los que nuestro propio motor ya ha reducido el plan y una restricción de movimiento neutra». Enviamos además el plan que nuestro propio motor ya había escrito para usted, para que el modelo tenga algo que mejorar en lugar de inventar — y ese plan está construido a partir de sus cifras. Su puntuación de recuperación va como número; con ella van el esfuerzo al que apuntábamos, su objetivo de entrenamiento, la semana del ciclo, la duración de la sesión y sus techos de esfuerzo — los tres calculados a partir de esa puntuación —, un veredicto escrito sobre su disposición y notas que dicen que su puntuación de sueño fue baja, que unas sesiones recientes duras forzaron una semana aligerada o que no tiene historial con nosotros. El §4.1 de esta página trata las cifras sobre su cuerpo como dato de categoría especial, y una puntuación de recuperación es una de ellas. La fila ahora las enumera.
• A las otras cinco filas se les hizo la misma pregunta, y dos de ellas también se quedaban cortas. La fila de Today’s Insight no mencionaba la confianza que depositamos en su estimación de envejecimiento. La fila del Informe Profundo de Salud resumía su envío como «las métricas calculadas y las tendencias que hay detrás» sin decir que entre ellas están sus puntuaciones de recuperación y de disposición con sus zonas, una línea base de cada constante vital, la lista de métricas que no pudimos medir en absoluto y cualquier aviso que nuestros propios servidores ya hubieran marcado — una racha de noches por debajo del noventa por ciento de oxígeno en sangre, con las fechas y las lecturas. Ambas filas lo dicen ya. Las filas de Food Scanner, análisis de laboratorio y Conserje de IA no llevan ninguna cifra derivada de sus datos de bienestar, y no cambian.
• La limpieza que retiene las líneas de embarazo y posparto no retiene nada más, y la fila dice ya cuál es cuál. Compara palabras. Por eso un título de sesión, una indicación de entrenamiento o una línea de seguridad que nombre uno de esos estados se queda en nuestro lado, y por eso las cifras de recuperación que están a su lado no. Además elimina la línea en vez de sustituirla, así que el ejemplo de una miembro en posparto llega una línea más corto que el de todas las demás: el argumento que la versión 2.11 hizo sobre la forma de las instrucciones vale también para el plan de ejemplo.
• La regla que añade esta versión. Las versiones 2.9, 2.10 y 2.11 midieron cada una una fila contra la pregunta que la anterior había fallado. Preguntar «¿sale el estado privado?» tres veces seguidas nunca encontrará una fila que se quede corta sobre una cifra de bienestar corriente. A partir de ahora cada fila se mide también contra una segunda pregunta: ¿qué dice este envío sobre el cuerpo de esta persona que la fila no nombre?

Qué cambió en la versión 2.11 (27 de agosto de 2026). No se ha lanzado nada nuevo. La versión 2.10 comprobó la fila del Conserje de IA contra su propio servicio y concluyó que allí un periodo posparto registrado solo cambia la redacción. Esa conclusión era falsa, y estaba dentro de la divulgación más sensible de esta página.

• La fila del Conserje de IA del §13.1 decía que ni el hecho de un registro posparto ni el número de semanas llegan al proveedor. El hecho del registro sí llega. Va escrito en las instrucciones adjuntas a su propio mensaje, en una frase que dice que usted está en el posparto, y otra vez en las instrucciones que van por encima, que nombran el parto reciente, la interrupción de un embarazo y una pérdida. La fila ya lo dice.
• Esa misma fila llamaba a esas instrucciones «frases fijas». No lo son. Cuatro reglas se añaden solo cuando le corresponden, de modo que la propia forma de la solicitud lleva dos cosas más: si ha registrado que hay un bebé en casa — si no lo ha hecho, aparece una regla que nombra el aborto espontáneo, la muerte fetal, la muerte neonatal y la interrupción del embarazo — y si el apoyo de recuperación física está desactivado para usted, que es su propio ajuste. Una regla que solo aparece cuando corresponde revela aquello de lo que depende. La mitad que era cierta se conserva en lugar de borrarse con el resto: el número de semanas sigue sin enviarse por esta vía.
• La fila de Today’s Insight se midió de nuevo. Su descripción de los datos se sostiene; su descripción de las instrucciones se quedaba corta. Dos de las reglas de esa vía también son condicionales, y dependen del mismo dato sobre un bebé en casa; la fila lo dice ahora. Aquella medición preguntó solo por las instrucciones; la versión 2.12 de arriba añade lo que no buscaba: la confianza que depositamos en la estimación de envejecimiento.
• La fila del plan de entrenamiento con IA decía que en los términos que sí cruzan no hay «nada dentro que diga por qué». Sí lo hay. Una clase de movimiento se añade solo en esa vía, y el único techo de intensidad se calcula a partir de la fase y de si el parto fue quirúrgico, instrumental, con complicaciones o no declarado. El estado, el número de semanas, la fase y la vía del parto siguen sin enviarse como campos — pero la fila ya no afirma que lo que queda no diga nada. Aun así, a esa fila le faltaba lo principal, y la versión 2.12 de arriba lo corrige: la sesión de ejemplo que va con la solicitud lleva su puntuación de recuperación y las cifras derivadas de ella.
• Las filas del Informe Profundo de Salud, Food Scanner y análisis de laboratorio se releyeron contra el código en funcionamiento y no cambian. La vía del informe sigue descartando los dos campos que nombrarían el estado antes de construir el extracto, y las otras dos no tienen ningún tratamiento de embarazo ni de posparto. «No cambian» era cierto para la pregunta que se hizo; la versión 2.12 de arriba cambia la fila del Informe Profundo de Salud por otra distinta.
• La regla que escribió la versión 2.10 era correcta y se aplicó de forma demasiado estrecha. «Dos filas que comparten una frase no comparten un comportamiento» es lo que impidió estropear una fila que era correcta. Lo que no hizo fue obligar a medir la segunda fila con el mismo cuidado que la primera: la fila del Conserje se comprobó contra la parte del servicio que compone las instrucciones que salen como texto de sistema, y no contra la que compone el texto que sale como mensaje suyo. La regla dice ahora: cada fila se mide contra todos los lugares en que su propio servicio compone una solicitud.

Qué cambió en la versión 2.10 (27 de agosto de 2026). No se ha lanzado nada nuevo. La versión 2.9 corrigió el tiempo verbal del §13.1 y dejó en esa misma tabla tres transferencias descritas por debajo de lo que son — cada una, una fila que nombraba menos de lo que el código en funcionamiento envía de verdad.

• El §13.1 decía que un registro posparto da forma a las instrucciones. También viaja dentro de la solicitud. La fila de Today's Insight decía «las instrucciones que acompañan a la solicitud lo reflejan», lo que invita a una usuaria a concluir que un periodo posparto registrado solo cambia cómo está redactada su tarjeta. La solicitud misma lleva el hecho del registro y el número de semanas enteras transcurridas desde que empezó, además de tres marcadores internos sobre nuestra lectura de su línea base. Un recuento de semanas fecha el final de un embarazo con un margen de una semana, y el §4.1 de esta página califica un registro posparto de dato de categoría especial. La fila dice ahora las dos mitades. La fila del Conserje de IA lleva casi la misma frase, y se comprobó por separado en lugar de darla por errónea también: allí las instrucciones son de verdad todo lo que cambia, así que esa frase se queda tal como estaba. Esa comprobación fue a su vez errónea, y la versión 2.11 de arriba la corrige: el hecho del registro también está en la solicitud del Conserje, y esas instrucciones no son fijas.
• El §13.1 resumía el envío de Today's Insight en cuatro cifras, y lleva muchas más de cuatro. «Recuperación, VFC, sueño, actividad» dejaba fuera la puntuación de disposición, las cifras de envejecimiento y el ritmo de envejecimiento, la puntuación de estrés con la media de la semana pasada al lado, los bloques nocturnos de saturación de oxígeno y de regularidad del sueño, el desglose de pasos hora a hora y siete constantes vitales más — y cada constante se envía con su media, su mínimo y su máximo además de la lectura de hoy. La fila enumera ahora lo que hay dentro.
• La fila del Conserje describía dos solicitudes y no los datos adjuntos a la segunda. Cuando su pregunta es de las que necesitan sus propias cifras, con ella salen hasta noventa días de sus lecturas registradas — hasta cinco mil, cada una con su valor, su unidad, su hora y el dispositivo del que viene. Esa fila decía además que el contenido de esta vía lo decide usted y no nosotros: era cierto sobre su texto y falso sobre las lecturas. La corrección va en contra nuestra.
• Dos filas no se corrigen sino que se refuerzan, y ambos cambios van a su favor. La fila del plan de entrenamiento con IA nombraba solo el embarazo como estado retenido deliberadamente frente al modelo; un registro posparto se retiene en los mismos términos, hasta el punto de limpiar esas palabras del plan de ejemplo que enviamos. La fila del Informe Profundo de Salud callaba sobre el posparto y ahora dice que el estado se descarta antes de construir el extracto.
• Las filas de Food Scanner y del análisis de sangre se releyeron contra el código en funcionamiento y no cambian. Ninguna de las dos rutas tiene tratamiento alguno de embarazo o posparto, y ninguna envía nada más allá de lo que esas filas ya describen.

Qué cambió en la versión 2.9 (27 de agosto de 2026). No se ha lanzado nada nuevo y, esta vez, la corrección es de tiempo verbal. La versión 2.8 reconstruyó el §13.1 leyendo el código — pero leyó el código del disco de un desarrollador y no el que está en funcionamiento. Dos de las seis filas describían por eso, en presente, datos que nunca han salido de nuestros servidores.

• El §13.1 le decía que enviamos datos de perfil que no enviamos. La fila de Today's Insight enumeraba su sexo de referencia, país, estatura, peso, nivel de forma declarado y objetivos de salud, y la fila del Informe Profundo de Salud arrastraba la misma lista por referencia. Lo que realmente sale de su perfil por esas dos rutas es su edad y nada más. La proyección más amplia existe como código escrito y sin desplegar. Una política de privacidad tiene que describir lo que está funcionando: ambas filas dicen ahora qué se envía, nombran lo que no se envía y describen la versión ampliada como esta página describe todo lo demás que está construido y sin lanzar — algo que empieza el día en que salga, con la fila reescrita en esa misma versión. La fila de Today's Insight afirmaba además que un embarazo registrado modela la solicitud; hoy solo lo hace un periodo posparto registrado.
• La fila del análisis de sangre del §13.1 acertaba con el archivo y callaba el resto. Decía que lo que sale es el propio archivo del informe de laboratorio — sigue siendo exactamente cierto — y no decía que un cambio ya escrito enviaría con él su perfil y un resumen de sus propios análisis de sangre anteriores: para un máximo de tres informes previos, el nombre de cada biomarcador, su valor, su unidad y la fecha de la extracción. Eso haría que una sola subida llevase también su historial de laboratorio anterior, y eso se le cuenta a un miembro antes de que empiece, no después en unas notas de versión. La fila dice ahora las dos mitades: qué sale hoy y qué está construido y sin desplegar.
• Las otras cuatro filas se releyeron contra el código en funcionamiento y no cambian. Food Scanner, el Conserje de IA y el plan de entrenamiento de IA envían exactamente lo que decía el §13.1. En particular, la ruta de entrenamiento sigue sin enviar el estado de embarazo ni el trimestre, y el Conserje sigue sin llevar ningún dato de perfil.

Qué cambió en la versión 2.8 (27 de agosto de 2026). No se ha lanzado nada nuevo. Esta versión existe porque una revisión de lo que esta página dice frente a lo que hace el código encontró afirmaciones equivocadas en ambos sentidos, y la mayor de ellas era una comunicación sobre IA que nombraba dos funcionalidades de seis.

• El §13 comunicaba dos de las seis funcionalidades de IA, y esa es la corrección por la que existe esta versión. La sección decía que Omnisio envía «los siguientes datos» para «Today's Insight, Food Scanner» — una lista cerrada. Quedaban sin comunicar cuatro comunicaciones de datos: el análisis del informe de laboratorio, el Informe Profundo de Salud, el Conserje de IA y los planes de entrenamiento con IA. Dos de ellas llevan más que cualquiera de las comunicadas: la vía del análisis de sangre envía el propio archivo del informe de laboratorio, con cada valor y cada nombre impresos en él, y el Conserje envía todo lo que usted escribe sobre su propia salud. El §13.1 es ahora una tabla de las seis, que dice para cada una qué sale realmente. La tabla de finalidades del §4 nombraba las mismas dos y ahora nombra las seis. No ha cambiado nada de lo que hace la aplicación; lo que ha cambiado es que la página ahora lo describe.
• El §13.2 pierde una línea, y perderla va en nuestra contra. «Historial médico, medicamentos» figuraba en la lista de lo que no enviamos. Los valores de biomarcadores de un informe clínico son historial médico, y salen como el informe entero; la lista fija de hábitos del Diario incluye tomar medicación, y una entrada del diario sí llega a una funcionalidad de IA que usted consienta. La línea se ha eliminado, no suavizado.
• El §13.3 deja de describir a una segunda empresa que no podemos nombrar. Presentaba a un «proveedor de infraestructura de enrutamiento de modelos» como subencargado distinto y daba sus prácticas. Omnisio mantiene credenciales con una empresa de IA. Lo que sí vemos desde nuestro propio código es que el punto de acceso al que llamamos es un punto de enrutamiento que toma un nombre de modelo como parámetro, de modo que la solicitud sigue hacia quien opera ese modelo. Eso es lo que dice ahora la sección. Nombrar una empresa apoyándose en el nombre de un punto de acceso sería afirmar un hecho que no tenemos.
• El §13.5 retira la afirmación de que hubo una revisión. Decía que habíamos revisado los acuerdos de tratamiento de datos de los proveedores y quedábamos satisfechos con el artículo 28 del RGPD y el artículo 12 de la KVKK. Somos cliente de pago del proveedor; eso no es un acuerdo de tratamiento firmado, y no podemos señalar ninguno. La frase ha desaparecido, en su lugar consta la relación de cliente, y obtener el documento queda registrado como acción pendiente en vez de descrito como hecho.
• §4.1 y §13.4: se reclamaba un rastro de auditoría de consentimiento para consentimientos que no tenían registro en servidor. El §4.1 decía que «Funciones de IA e Informe Profundo de Salud» comparten una entrada versionada y de solo adición. Solo lo hace el Informe Profundo de Salud. Para las otras cinco funcionalidades el consentimiento se pide en la aplicación y la respuesta vive solo en su teléfono; nuestros servidores hoy no rechazan una solicitud que llegue sin él. Ambas secciones lo dicen ahora, incluida la parte incómoda: un registro que solo guarda un teléfono es uno que una reinstalación borra y que no podríamos producir si usted lo pidiera. Lo construido para cerrarlo — un tipo en el libro, una migración que preserva el momento en que usted consintió realmente y un rechazo en servidor detrás de un interruptor apagado — se describe en el §13.4 como construido y no encendido, con las mismas palabras que esta página usa para todo lo demás en ese estado.
• §4.1: los tres tipos de consentimiento del libro eran la cifra correcta con el contenido equivocado. La versión 2.7 los enumeraba como el del Informe Profundo más dos de la Calibración matinal. Los dos de la Calibración matinal se convirtieron en uno cuando se retiró la pregunta sobre el tono de piel, y se había añadido un tipo para las comunicaciones electrónicas comerciales. Siempre fueron tres, y ninguno de los tres nombrados seguía siendo correcto. Una cifra que sigue siendo cierta mientras cambia su contenido es peor que una cifra desactualizada, porque sobrevive a la comprobación obvia; por eso la caja ahora enumera los tipos en lugar de contarlos.
• §3.12: la declaración opcional de tono de piel ha desaparecido del producto y de esta página. Se ha eliminado del diseño, de la interfaz y del libro de consentimientos, junto con la comparación por franjas para la que existía. En la Calibración matinal nada mide el color, así que nada necesita un tono declarado.
• Sentry nunca existió aquí, y esta página lo nombraba en cuatro sitios. «Sentry / informes de fallos» en el §15, registros de fallos en el §3.8, una finalidad de «análisis de diagnóstico y fallos» en el §4 y un plazo de 90 días en el §18. No hay ningún componente de informes de fallos, analítica o telemetría en la aplicación ni en nuestros servidores — ni el nombrado, ni ningún otro. Los cuatro se han eliminado. La regla del propio §15 nos apunta aquí: anunciar un destinatario que no existe es tan incorrecto como ocultar uno que sí existe.
• §18: se prometía una eliminación por 36 meses de inactividad que no existe. La fila de bienestar decía «hasta que elimine su cuenta (o 36 meses de inactividad)». Nada la ejecuta; los datos de salud básicos no tienen caducidad alguna. La promesa se retira en lugar de dejarse incumplida en silencio, y aquí queda registrado que se retiró. Construir una purga por inactividad es una decisión de producto, y esta página no la creará describiéndola.
• El §16.1 contradecía al §16.2 en la misma pantalla. El §16.1 decía que los encargados se identifican «por categoría y no por nombre comercial»; el §16.2, cuatro párrafos después, nombraba un país, una región de nube y una ciudad. La regla que de verdad seguimos queda ahora escrita — nombrar lo verificado, describir por categoría aquello que nombrar exageraría — y Railway y MongoDB Atlas están nombrados, como ya los nombraba el aviso KVKK. La afirmación sobre Fráncfort se mantiene, con su fuente declarada: procede de nuestra documentación de arquitectura y de una comprobación de nombre de host, no de la configuración del clúster en vivo, y volver a confirmarla es una acción pendiente. El análisis turco de transferencia internacional que se alimenta de ella no depende de la respuesta, porque no existe decisión de adecuación para ningún país.
• Destinatarios que nunca se habían enumerado. El servicio push de Expo recibe el token de su dispositivo y la propia notificación antes que Apple — el §15 nombraba solo a Apple. Cloudflare R2 guarda las fotos de perfil en un bucket público y, durante 7 días, el archivo que produce una exportación de datos: un único fichero con todo lo que tenemos sobre usted, que ninguna sección de esta página había mencionado nunca. Ambos se añaden al §15 y a la lista de destinatarios establecidos en Estados Unidos del §16.2. El §17 describe ahora el archivo en el punto en que usted ejerce el derecho que lo crea. Y la fila de Firebase del §15 decía «correo electrónico, token de inicio de sesión», mientras que la cuenta que allí se guarda contiene su correo, su teléfono, su nombre visible, su avatar y su proveedor de inicio de sesión.
• El §3 era más delgado que el aviso KVKK turco, que es lo contrario de lo que promete el encabezado de esta página. Categorías que el sistema recoge y esta sección no enumeraba: informes de análisis de sangre y sus valores de biomarcadores (ahora §3.13), el registro continuo de nutrición como algo distinto de la foto de comida (§3.14), archivos importados de Whoop, Oura, Garmin o Apple Health (§3.15) y — añadidos al §3.2 — la saturación de oxígeno, los entrenamientos, la composición corporal y los registros de embarazo y posparto, que la ley turca considera a la vez datos de salud y datos relativos a la vida sexual.
• El §20 afirmaba controles de seguridad que no existen y contradecía nuestro propio aviso KVKK. Enumeraba autenticación multifactor, pruebas de penetración anuales por terceros, almacenamiento de contraseñas con Bcrypt y registro de auditoría de todas las acciones administrativas. El aviso KVKK dice desde el 9 de agosto de 2026 que las dos primeras no existen; esta página siguió afirmándolas. La lista describe ahora lo que hay realmente y nombra lo que no hay.
• §17 y §18: tres registros que sobreviven a la eliminación de la cuenta no se habían descrito nunca. El recibo de supresión que prueba que la eliminación ocurrió, el rastro de auditoría de credenciales que hace visible el abuso contra otras cuentas, y la fila de la concesión de membresía que se vacía en lugar de eliminarse para que una conciliación posterior no pueda reconstruir su membresía contra su dirección. Los tres son legítimos; ninguno estaba escrito. El §18 gana además el archivo de exportación (7 días), el archivo de la carga sin procesar de sincronización del dispositivo (30 días) y una fila resumen para los relojes de infraestructura que no tratan de usted.

Qué cambió en la versión 2.7 (4 de agosto de 2026). La venta directa y el plan familiar están abiertos. La versión 2.5 escribió una promesa en el §3.9: que el recuadro que decía que nada de esto se recogía se retiraría en la misma versión que el código que empiece a escribir esos registros, y ni un día antes. Esta es esa versión, y esta entrada existe para que la promesa se vea cumplida y no abandonada en silencio.

• Corregido de nuevo dentro de la propia 2.7: el libro de consentimientos tiene tres tipos, no uno, y un nuevo §3.12 explica para qué sirven los otros dos. El §4.1 decía que el libro aceptaba exactamente un tipo de consentimiento. Acepta tres: el del Informe Profundo de Salud y dos que pertenecen a la Calibración matinal — un estudio de medición facial y una declaración opcional de tono de piel. Nada de eso cambia lo que se recoge, y ahí está justamente la dificultad de la frase anterior: erraba en la dirección que nos favorecía. Por eso la afirmación más incómoda queda ahora escrita en sus dos mitades — el libro acepta tres, y solo uno de ellos está en uso, porque las superficies que abren los otros dos están apagadas en el servidor y toda llamada dirigida a ellas se rechaza. El §3.12 es nuevo y describe la medición mientras sigue cerrada: cuatro proporciones geométricas calculadas en el teléfono, una franja opcional de tono de piel, ninguna fotografía que nos llegue en codificación alguna, y las tres condiciones que han de ser ciertas a la vez antes de encender el interruptor. La Calibración matinal se describe en el sitio web a partir de esta versión, y una función que cuentan las páginas públicas no tiene por qué faltar en la política.
• Corregido de nuevo dentro de la propia 2.7: qué hace la eliminación de cuenta con un plan familiar — cinco lugares, y uno de ellos era el peor error que esta página puede cometer. El código de eliminación cambió y el texto seguía describiendo el comportamiento anterior, equivocado además en las dos direcciones. Donde decíamos que conservamos, borramos. A un miembro que elimina su cuenta se le retira ahora la dirección también del pedido del comprador (§14.6, el antiguo quinto límite del §17, §18), y el enlace de oposición de un clic del §17.1 alcanza igualmente el pedido del comprador. Esa última es la corrección que importaba: el §17.1 le decía a una persona que no podíamos hacer por ella algo que de hecho hacemos, y no hay frase peor en esta página. Donde decíamos que borramos, conservamos. Un pedido de invitado se elimina ahora junto con la cuenta cuya dirección verificada lo hizo — salvo un plan familiar que llegó a cobrarse, que sobrevive a su comprador para que las membresías de entre tres y diez personas lleguen al final del plazo ya pagado (§14.7, el cuarto límite del §17, §18). El §14.6 gana la otra mitad de eso: qué conservan esos miembros, y que se les comunica la fecha de fin una vez ahora y otras dos 30 y 7 días antes, en un mensaje que nunca menciona a quien se marchó. La condición previa que ninguna sección había escrito está ahora en el §17: todo esto va ligado a una dirección de correo verificada, y donde la cuenta no acredita ninguna, no ocurre nada. El recuadro de la tarjeta bajo el §3.9 queda sujeto a la misma regla que las cinco filas de encima: aquí ninguna membresía se renueva sola, así que no se guarda ningún token de renovación, y decir lo contrario describía un mecanismo que no existe.
• Corregido de nuevo dentro de la propia 2.7: una quinta fila y tres lugares que la repetían. La corrección de abajo arregló cuatro filas de la tabla del §3.9 y se dejó la fila del envío, que decía que tenemos un número de seguimiento y un estado de la entrega. No tenemos ninguno de los dos: el campo de seguimiento del registro del pedido está vacío, la lista de envíos que hay a su lado está vacía y no hay ningún sistema de transporte conectado al nuestro — del paquete se ocupa y hace seguimiento una persona. El mismo presente había sobrevivido en tres sitios más: el párrafo de entrega del §14.2, la fila de contabilidad y facturación electrónica del §15 (no hay proveedor contable conectado y no emitimos facturas, cosa que el §18 ya decía en su propia fila) y el recuadro de la tarjeta bajo la tabla del §3.9, que describía una referencia de transacción, un resultado y un token de renovación llegando de un proveedor que no está conectado. Todo ello dice ahora lo que es cierto hoy y nombra el día en que empieza lo demás. No se ha eliminado ninguna fila.
• Corregido dentro de la propia 2.7: cuatro filas de la tabla del §3.9 describían datos que no recogemos. La primera redacción de esta versión enumeraba los datos de facturación, la referencia de pago, los intentos de pago con la notificación en bruto del proveedor y el sello de conversión de divisa como contenido de un registro de pedido. El registro no contiene ninguno de ellos. No hay ningún proveedor de pago conectado — el pedido se registra, no se cobra nada y a partir de ahí lo lleva una persona; el formulario de pedido nunca pide un dato de facturación y el esquema del pedido lo rechaza; el código de conversión no se llama nunca. Las cuatro filas ahora lo dicen, con las mismas palabras que la tabla ya usaba para la dirección de entrega de un miembro de la familia. Se quedan en la tabla en vez de borrarse, porque los campos están construidos y esconderlos dejaría que el mismo hueco se abriera de nuevo el día en que arranque el pago directo. El §15 y el §18 repetían las mismas cuatro afirmaciones y se han corregido con ellas. El recuadro que abre el §3.9 exige que una fila que describa algo construido pero todavía no recogido lo diga ella misma: esto es esa regla aplicada a la versión que la escribió.
• El recuadro de advertencia del §3.9 ha desaparecido y la sección describe el presente. Once categorías de datos que nunca se habían descrito están ahora en la tabla, y la más pesada de ellas son las direcciones de correo de otras personas. Un plan familiar es lo primero que Omnisio vende que pide a un cliente datos personales de otra persona, y la política no podía callarlo ni una sola versión.
• Los planes familiares tienen su propia sección (§14.6): qué ve quien paga (el estado de cada plaza — nunca un nombre, nunca una dirección, nunca ningún dato de bienestar), qué se le dice a la persona invitada y sobre qué base jurídica (interés legítimo, no consentimiento, porque nadie puede consentir en nombre de otro), la vida de 90 días de una dirección que nunca se reclama, el rango de 3 a 10 plazas, y la regla de que una membresía activa no se retira a mitad de periodo.
• Pedir sin cuenta se describe por primera vez (§14.7), incluida la parte que se malinterpreta con facilidad: la eliminación de cuenta no alcanza un pedido de invitado. Esta página no contemplaba la figura de un comprador sin cuenta, y debería haberlo hecho antes de que el primer pedido así fuera posible.
• El §17 pasa de tres límites a la supresión a cinco, y suma el §17.1 para quien fue invitado y nunca se registró: qué guardamos, de dónde salió, durante cuánto tiempo y cómo terminarlo en un clic sin cuenta.
• El §18 va ahora por campo y no por fila. Un pedido contiene un registro comercial y, al lado, la dirección de correo de alguien que quizá nunca sea cliente; no pueden compartir plazo. La fila que decía que un pedido no se elimina con su cuenta dice ahora lo contrario, porque es lo que hace el código: el reloj de diez años del artículo 82 pertenece a la factura y a los libros que hay detrás, y todavía no se emite ninguna factura. Cuando ese reloj empiece a correr, se enuncia bien por primera vez: según el artículo 82/6 del Código de Comercio turco corre desde el final del año natural, y no desde la fecha del pedido. En la misma pasada se corrigieron el §14.4, el §14.7, el §17 y el §17.1, porque cuatro secciones repetían la misma frase equivocada.
• Dos correcciones en el §15. Se ha añadido un proveedor de correo transaccional: cada invitación pasa por él llevando la dirección del destinatario y el nombre completo del comprador, y ninguna categoría existente cubría un servicio de envío de correo. Y se ha eliminado el proveedor de pago ruso aparte: no existe ninguno. Las tarjetas emitidas en la Federación de Rusia se rechazan, y anunciar un destinatario que no existe es tan incorrecto como ocultar uno que sí existe.
• El §3.11 ya no afirma que no haya ninguna petición a terceros en ninguna página de este sitio. Las páginas de tienda, pago, pedido, inicio y Omnisio Team cargan sus tipografías desde un servicio de fuentes de un tercero, que ve una dirección IP. No instala cookies y no es seguimiento, pero la frase anterior afirmaba más de lo cierto. El proveedor de fuentes figura ahora en el §15.
• El §16.3 deja de decir que la cuestión de la localización rusa está en revisión y expone la situación real. Esa frase era honesta mientras no se recogía nada. Dejó de serlo en cuanto una página de pago en ruso pudo escribir la dirección de correo de un residente en Rusia en una base de datos fuera de Rusia. No adoptamos ninguna posición de cumplimiento, porque no tenemos ninguna que adoptar: la sección da ahora los hechos, la pregunta abierta y la decisión pendiente, en lugar de una tranquilización.
• Todo lo que la versión 2.5 decía sobre «no se recoge» queda superado. La entrada de 2.5 se conserva abajo, porque un registro de cambios es un registro y no una descripción del presente. Donde dice que nada escribe en la tabla de pedidos, eso dejó de ser cierto con esta versión. Su entrada de conservación legal también queda superada: dice que las facturas y los registros de pedido no se eliminan con su cuenta, y hoy sí lo hacen — el motivo está en el §18.

Qué cambió en la versión 2.6 (30 de julio de 2026). Dos correcciones. El §19 decía que el onboarding de la app seguía admitiendo usuarios desde los 13 años. Dejó de ser cierto cuando cambió el control de edad: la app ya no acepta una fecha de nacimiento inferior a 16 años, y la compra está cerrada por debajo de 18. La sección describe ahora el control que está en producción y nombra lo único que falta: la confirmación verificada de un progenitor o tutor legal para los 16 y 17 años. Además, se retiraron de la página notas editoriales que nunca debieron publicarse: un aviso de estado de trabajo y marcas de revisión interna. Ningún derecho, plazo u obligación ha cambiado.

Qué cambió en la versión 2.5 (29 de julio de 2026). Todos los cambios de esta versión son correcciones: la 2.4 describía un producto que aún no existe, y en cada caso la solución fue describir el que sí existe.

• Consentimiento para datos de bienestar (§4.1) — la 2.4 decía que solicitamos consentimiento explícito antes de tratar cualquier dato de bienestar y que lo registramos. No lo hacemos: tal como estaba el libro en julio de 2026, aceptaba un tipo, el del Informe Profundo de Salud, además de las métricas compartidas en la Comunidad. Los dos consentimientos que sí existen se describen ahora con exactitud, y el que falta se marca como ausente en lugar de afirmarse. Superado solo en la cifra: desde entonces el libro ha ganado los dos tipos de la Calibración matinal, ninguno de los cuales está en uso — la cifra actual está en el §4.1.
• Datos de compra, entrega y facturación (§3.9, §14.4) — no se recoge ninguno. Las membresías se venden por la App Store; la tabla de pedidos de nuestra base de datos no tiene quien escriba en ella. La sección lo dice ahora desde el principio y se mantiene como descripción anticipada de la venta directa, no del presente.
• Conservación legal (§17, §18) — la 2.4 decía que las facturas y los registros de pedido sobreviven a la eliminación de la cuenta. No pueden sobrevivirla: no existen, y la eliminación de cuenta purga hoy también la tabla de pedidos inactiva junto con todo lo demás. Corregido, conservando la posición futura y etiquetándola claramente como futura.
• El marcado CE del dispositivo (§6) — la 2.4 afirmaba que el dispositivo tenía marcado CE para uso de bienestar de consumo. Es una afirmación regulatoria y el certificado no se ha verificado, así que se retira y el campo queda abierto, igual que ya decían los Términos.
• Edad mínima (§19) — esta página decía 16 mientras los Términos decían 18. Ahora hay un solo número, 16, definido en el §1.3 de los Términos, más el paso del progenitor o representante legal que exige el lado contractual entre los 16 y los 18.
• Qué idioma vincula (parte superior de la página) — las versiones turca, rusa y española de esta página decían cada una que la vinculante era la inglesa, mientras los Términos decían que para los consumidores en Türkiye vincula el texto turco. Dos documentos no pueden responder distinto a esa pregunta. Los ocho documentos llevan ahora la regla de los Términos.

Qué cambió en la versión 2.4 (29 de julio de 2026). Omnisio empezó a vender una membresía que incluye un dispositivo, y enviar un dispositivo exige datos que la aplicación por sí sola nunca necesitó. Esta versión los documenta y corrige tres cosas que la versión anterior tenía mal:

• Datos de compra, entrega y facturación (§3.9, §14) — nombre, dirección de entrega, número de teléfono, datos de facturación, historial de pedidos, referencia de pago, número de serie del dispositivo y seguimiento del envío, cada uno con su finalidad, base jurídica, plazo de conservación y destinatario. El número de su tarjeta no está entre ellos, y nunca lo estuvo.
• Conservación legal obligatoria (§17, §18) — las facturas y los registros de pedidos se conservan durante un plazo fijado por ley y no se eliminan cuando usted elimina su cuenta. La versión anterior daba a entender que se iba todo. Era falso, y decirlo con claridad es el motivo de esta versión.
• Los datos de bienestar se tratan como datos de salud (§4.1) — categoría especial conforme al artículo 6 de la KVKK y al artículo 9 del RGPD, tratados sobre la base del consentimiento explícito y no del contrato. La versión 2.3 los basaba en el contrato, que no es condición suficiente para datos de categoría especial.
• Solicitudes de sustitución de dispositivo (§3.10) — una categoría de datos que el producto ya recogía y que esta política nunca había descrito.
• Ubicación de almacenamiento (§16) — la versión 2.3 nombraba un centro de datos concreto que no se corresponde con cómo está desplegado el servicio. La afirmación se ha eliminado en lugar de reformularse.
• El sitio web (§3.11) — no instala cookies ni ejecuta analítica. Se dice en voz alta, porque una política de privacidad que calla sobre esto invita a suponer que algo se está contando.

Qué cambió en la versión 2.3 (25 de julio de 2026). Un solo cambio, y no altera lo que ocurre con sus datos:

• Los destinatarios de IA se describen por categoría (§13, §15) — nuestro proveedor de procesamiento con IA y su subencargado de enrutamiento de modelos se identifican ahora por categoría y no por su nombre comercial, tal como permite el artículo 13(1)(e) del RGPD. Qué enviamos, qué no enviamos, que las funcionalidades de IA son opcionales y revocables, que sus datos no se usan para entrenar modelos, la posición sobre conservación y los acuerdos de tratamiento de datos que la respaldan permanecen sin cambios.

Qué cambió en la versión 2.2 (25 de julio de 2026). Dos correcciones, ambas porque el texto publicado no coincidía con lo que nuestros sistemas hacen realmente:

• Registros de suscripción (§18) — la versión 2.1 decía que conservábamos los recibos de suscripción durante 7 años. No es así: los registros de suscripción que tenemos se eliminan con su cuenta, y el registro de compra en sí lo conservan Apple y RevenueCat conforme a sus propias políticas. La fila de conservación ya lo refleja.
• Rutas dentro de la aplicación (§17) — corregidas a las etiquetas que la aplicación usa realmente, y ahora se nombran las dos rutas que llevan al mismo control de eliminación. La página de eliminación de datos se reescribió en el mismo paso: describía un selector de categorías, un número de referencia enviado por correo y un proceso de destrucción de datos genéticos; nada de eso existe.

Qué cambió en la versión 2.1 (25 de julio de 2026). Aquella versión documentó funcionalidades que la 2.0 no cubría:

• Comunidad (§7) — qué pueden ver los demás miembros, consentimiento por métrica desactivado por defecto, amistades, equipos, retos, el feed de actividad y el hecho de que no hay chat.
• Denuncias y registros de moderación (§8) — qué almacenamos, que los revisa personal humano y que estos registros sobreviven a las cuentas.
• Ubicación precisa durante las carreras (§9) y Movimiento y forma física para la cadencia y el desnivel.
• Lecturas de señal cardíaca (§10) — guardadas solo en su dispositivo.
• Entradas del diario (§11).
• Cámara y fototeca (§12) — fotos de comidas y fotos de perfil.
• La retención (§18) y los derechos (§17) se han ampliado para cubrir todo lo anterior; las rutas dentro de la aplicación se han corregido a Más → Privacidad y Confianza.

La versión 2.1 no añade ningún destinatario tercero nuevo. Los datos de Comunidad, carreras y diario los trata íntegramente Omnisio.

Le notificaremos los cambios significativos mediante:

• Banner en la aplicación en el próximo inicio
• Correo electrónico a su dirección registrada (si el cambio es significativo)
• «Fecha de vigencia» actualizada en la parte superior de esta página

El uso continuado tras la notificación constituye aceptación.

22. Contacto

• Privacidad general: privacy@omnisio.app
• Consultas al DPO: dpo@omnisio.app
• Divulgación de seguridad: security@omnisio.app
• Solicitudes KVKK: kvkk@omnisio.app
• Teléfono: +90 532 666 00 77
• Dirección postal: Oney Finansal Danışmanlık Turizm ve Dış Ticaret AŞ, Esentepe Mah. Kore Şehitleri Cad. Yonca Apt. No:1-3 Daire 6, 34394 Şişli/İstanbul/Türkiye

Última actualización: 3 de septiembre de 2026 · Versión: 2.16