Política de privacidad

Última actualización: 2026-09-28T00:00:00.000Z

Idioma: Español English

Quiénes somos y cómo contactarnos

El responsable del tratamiento de los datos personales que se recogen a través de M1M (en adelante, «la plataforma») es:

• Razón social: MARTINUKA2220, SOCIEDAD LIMITADA («Martinuka2220, S.L.»)
• CIF: B72816911
• Domicilio: Carretera de Miñano Mayor s/n, Etxabarri-Ibiña, Álava (01196), Vitoria-Gasteiz, España
• Inscripción registral: Registro Mercantil de Álava (Portal de Castilla 7 bajo, 01005 Vitoria-Gasteiz), tomo 1757, folio 8, hoja VI-21090, inscripción 1
• Teléfono: +34 640296736
• Correo electrónico: empresa@hutrit.com
• Sitio web: mision1m.com

Tres nombres y una sola responsable. Vas a ver tres nombres alrededor de este servicio y conviene que sepas cómo se relacionan. M1M es una aplicación creada desde Hutrit, y Hutrit es el nombre comercial con el que opera Martinuka2220, S.L. Por eso nuestra dirección de contacto está en el dominio hutrit.com y ese nombre aparece asociado a los servicios de cómputo que sostienen la aplicación: es el nombre a través del cual se proveen. Frente a ti, quien responde legalmente es Martinuka2220, S.L., la sociedad identificada arriba. Conviene precisar el alcance de esos nombres: ni «M1M» ni «Hutrit» están registradas, ni como marca ni como nombre comercial. Son nombres comerciales no registrados de esa sociedad, que es la única inscrita, en el Registro Mercantil de Álava.

Esta política explica qué datos tratamos cuando usas la plataforma, para qué, con qué base jurídica, con quién los compartimos, cuánto tiempo los conservamos y qué puedes exigirnos. Se aplica a la web pública mision1m.com y al panel de la plataforma.

Alcance territorial, dicho con precisión. La plataforma se opera desde España y hoy la usan personas y organizaciones de Europa, América Latina y Norteamérica. Esta política está redactada conforme al RGPD y a la legislación española, y aplicamos el mismo estándar de protección a todas las personas usuarias, estén donde estén: las mismas medidas de seguridad, los mismos plazos de conservación y el mismo procedimiento para ejercer derechos. Si la normativa de tu país te reconoce derechos adicionales o impone requisitos propios sobre el tratamiento o la salida internacional de tus datos, se aplicarán además de lo que aquí se describe; escríbenos y te indicaremos cómo ejercerlos.

Para cualquier asunto relativo a esta política, incluido el ejercicio de tus derechos, escríbenos a empresa@hutrit.com indicando «Protección de datos» en el asunto.

No hemos designado un delegado de protección de datos, al no concurrir los supuestos del artículo 37 del RGPD. El punto de contacto para cualquier cuestión de privacidad es la dirección de correo indicada arriba.

Un matiz importante sobre los roles. Respecto de los datos de tu cuenta (alta, acceso, seguridad y, en su caso, facturación) nosotros somos responsables del tratamiento. Respecto del contenido que tú o tus agentes introducís en la plataforma —conversaciones, archivos, datos de terceros que conectáis—, tu organización es la responsable y nosotros actuamos como encargados del tratamiento por cuenta suya, conforme al artículo 28 del RGPD. La sección «Para qué los usamos» separa los dos bloques de forma expresa.

Y aquí va una carencia que preferimos decirte a que la descubras. El artículo 28 exige que ese encargo esté regulado por un contrato escrito, y hoy no lo tenemos firmado con ningún cliente: el acceso a la plataforma se ha venido concediendo sin él. Estamos preparando el anexo de encargo para incorporarlo a estos documentos. Mientras tanto, esta política describe las instrucciones a las que nos sujetamos y vale como compromiso nuestro, pero no sustituye a ese contrato ni pretendemos que lo haga. Si tu organización necesita firmarlo antes, escríbenos y lo resolvemos contigo.

Qué datos recopilamos

Datos de cuenta y registro. Nombre, apellidos, dirección de correo electrónico, contraseña, el agente que indicas que vas a usar al registrarte, el estado de tu verificación en dos pasos, la organización a la que perteneces y tu rol dentro de ella, la fecha de alta, tu preferencia de tema visual y, si la subes, tu imagen de perfil. La contraseña no se guarda nunca, ni en claro ni cifrada: conservamos únicamente un hash irreversible, del que la contraseña original no puede recuperarse. Al registrarte se genera además un token de acceso personal de 32 caracteres: solo se te muestra una vez y de él guardamos también una huella criptográfica, no el token.

Datos de autenticación federada. Si accedes con tu cuenta de Google o de Microsoft, recibimos de ese proveedor tu identificador de usuario, tu dirección de correo y tu nombre, junto con la confirmación de que has superado un segundo factor de autenticación. En ningún caso recibimos tu contraseña, y tampoco recogemos la imagen de perfil de esa cuenta. Estos datos no nos los facilitas tú directamente: su origen es el proveedor de identidad que eliges al iniciar sesión.

Datos de uso de la plataforma. El contenido de tus conversaciones con los agentes, las instrucciones que les das y sus respuestas; los archivos que subes o que tus agentes generan; los proyectos, tareas programadas y misiones que creas; la configuración de cada agente (incluido el proveedor de modelo elegido); y las métricas de consumo —número de peticiones, tokens consumidos por modelo y costo asociado— que necesitamos para mostrarte tu gasto y aplicar tus límites.

Datos técnicos y de seguridad. Un registro de actividad relevante para la seguridad de la cuenta: inicios y cierres de sesión, cambios de contraseña, rotación o revocación del token de acceso, altas y bajas de personas, cambios de permisos, intentos de acceso denegados y otras acciones administrativas. De cada uno guardamos quién lo hizo, qué hizo, sobre qué y cuándo. Registramos también eventos de actividad de los agentes y datos operativos de las peticiones (ruta, código de respuesta, duración).

Conviene que sepas dónde termina ese registro, porque declarar de más también es inexacto: la dirección IP de origen y el valor anterior y posterior de un cambio son campos que existen, pero hoy solo se rellenan en unas pocas acciones concretas. En la inmensa mayoría de los registros esos dos campos quedan vacíos, incluidos los inicios y cierres de sesión y los cambios de permisos.

Y una precisión más, porque la nota anterior también declaraba de más: un intento de inicio de sesión fallido no genera registro. Si alguien se equivoca de contraseña, no queda rastro de ese intento.

Datos de aplicaciones que tú conectas. Solo si autorizas una conexión: las credenciales de acceso que el proveedor nos entrega, el alcance concedido, su fecha de caducidad, y el contenido de esa aplicación al que el agente accede para ejecutar lo que le pides. Se detalla en «Datos de terceros que conectas».

Qué datos son obligatorios. Los datos marcados como necesarios en el registro —nombre, apellidos, correo y contraseña, o la cuenta de Google o Microsoft con la que accedes— son imprescindibles para crear la cuenta, identificarte y prestarte el servicio: sin ellos no podemos darte acceso. El resto (imagen de perfil, preferencias) es opcional y puedes no facilitarlo sin consecuencia alguna.

Qué NO recopilamos. No usamos herramientas de analítica, publicidad ni seguimiento en la web pública. No compramos ni enriquecemos datos con fuentes externas. No elaboramos perfiles comerciales. No te pedimos datos de categorías especiales (salud, ideología, religión, orientación sexual, biometría) y los Términos prohíben introducirlos deliberadamente sin un acuerdo previo con nosotros. Somos conscientes, no obstante, de que una fuente que tú conectes —un calendario con citas médicas, un documento que le entregues a un agente— puede contener datos de esas categorías de forma incidental, sin que ni tú ni nosotros los hayamos introducido: valora ese riesgo antes de conectarla y al elegir el proveedor de modelo de ese agente.

Para qué los usamos

Aquí hay que separar dos bloques, porque nuestro papel jurídico es distinto en cada uno y mezclarlos sería incorrecto.

Bloque A — Tratamientos en los que somos RESPONSABLES. Son los que decidimos nosotros. Cada uno tiene su finalidad y su base jurídica del RGPD:

Bloque B — Tratamientos en los que somos ENCARGADOS. Son los que recaen sobre el contenido de trabajo, y no los decidimos nosotros:

En este bloque no invocamos base jurídica propia: no la tenemos ni la necesitamos, porque no decidimos sobre estos tratamientos. Actuamos por cuenta de tu organización y siguiendo sus instrucciones documentadas, conforme al artículo 28 del RGPD; la base jurídica y el deber de informar a las personas afectadas corresponden a ella. No usamos el contenido de trabajo para finalidades propias. Si alguna vez fuera necesario, requeriría la autorización previa de tu organización y se le comunicaría antes, como exige el artículo 28.10 del RGPD.

Decisiones automatizadas. No tomamos decisiones automatizadas que produzcan efectos jurídicos sobre ti o te afecten significativamente de modo similar, en el sentido del artículo 22 del RGPD, ni elaboramos perfiles. Los agentes actúan siguiendo tus instrucciones, no las nuestras. Dicho eso, y para no escudarnos en una frase absoluta: la plataforma sí aplica automatismos operativos de control de gasto —al alcanzar un tope de consumo la ejecución se detiene automáticamente, y un consumo anómalo puede suspender temporalmente el servicio—. Son medidas contractuales, reversibles, que no evalúan aspectos personales tuyos; puedes pedir su revisión y el restablecimiento escribiendo a empresa@hutrit.com.

Transparencia sobre el contenido generado por IA. Los agentes producen texto sintético —respuestas, resúmenes, borradores y mensajes—. Un agente envía correo a terceros en tu nombre, y ese texto sale además por cualquier otro canal que tú conectes. Quien lo reciba no tendrá por qué saber que lo ha escrito una IA, aunque dentro del panel sea evidente. Hoy la plataforma no incorpora un marcado automático legible por máquina que identifique ese contenido como generado por IA, y preferimos decírtelo a que lo des por supuesto. Las obligaciones de transparencia del Reglamento (UE) 2024/1689 (Reglamento de IA) sobre el contenido generado artificialmente se aplican con su propio calendario y con un reparto de papeles que depende de cómo uses la plataforma; los Términos del servicio recogen qué te corresponde a ti mientras ese marcado no exista.

Datos de terceros que conectas

La plataforma puede conectarse a aplicaciones que ya usas para que tus agentes trabajen con ellas. Nada se conecta solo: la conexión solo existe si tú inicias sesión en el proveedor y apruebas expresamente el alcance que se te muestra.

Categorías de conexión previstas y para qué se usan:

• Identidad básica — cuando inicias sesión en la plataforma con tu cuenta de Google o de Microsoft obtenemos tu nombre y tu correo, para darte de alta o reconocerte. Al conectar una aplicación es distinto y recibimos menos: solo pedimos el identificador estable de esa cuenta, así que no nos llega ni tu nombre ni tu correo — por eso la tarjeta de una aplicación conectada no puede decirte de qué cuenta se trata. Nada de esto se usa para publicidad ni para perfilarte.
• Correo electrónico — enviar en tu nombre los mensajes que tú pidas enviar. No pedimos acceso de lectura a tu buzón.
• Archivos y documentos, incluidas hojas de cálculo — abrir los documentos que tú selecciones y guardar los resultados que el agente genere.
• Calendario — consultar tu disponibilidad y crear o modificar los eventos que le pidas.
• Notas y tareas — consultar el contenido que autorices y escribir en él cuando lo pidas.
• Mensajería — recibir instrucciones y enviar respuestas por el canal que conectes.

Cómo lo hacemos, en concreto:

• Permisos amplios, uso acotado. Algunos de los permisos que conceden estos proveedores son, por su propio diseño, más amplios que la tarea concreta que le pidas al agente: el permiso para consultar tu calendario, por ejemplo, alcanza a todos tus calendarios y a todos sus eventos, no solo al día por el que preguntas. Te mostramos el alcance real de cada uno en «Uso limitado de datos de Google» en lugar de describirlo como si fuera mínimo.
• Nunca vemos tu contraseña. La autorización se hace en la web del proveedor; a nosotros nos llega una credencial de acceso, no tus claves.
• Solo se accede bajo tu instrucción. El agente lee o escribe cuando ejecuta una tarea que tú has pedido o programado, y dentro del alcance concedido.
• No copiamos tu cuenta. No hacemos réplicas ni volcados completos del contenido de la aplicación conectada; se accede a lo necesario para la tarea. Lo que el agente produzca (por ejemplo, un resumen) sí queda en tu espacio de la plataforma, porque es tu resultado de trabajo, y se conserva como el resto del contenido de trabajo.

Cómo se revoca y qué pasa después. Puedes retirar una conexión en cualquier momento desde la plataforma, y también desde tu cuenta en el propio proveedor. Al revocarla desde la plataforma, la conexión queda revocada de inmediato y eliminamos del almacén la credencial asociada; si esa eliminación fallara, la conexión queda igualmente revocada y no vuelve a usarse. Con una precondición que preferimos decirte: si en ese momento el almacén de credenciales no estuviera disponible, la petición falla entera y no se revoca nada —te devolvemos un error en lugar de dejarte creer que se revocó—; vuelve a intentarlo o escríbenos. Esa es la vía fiable, y conviene usarla antes de cerrar la cuenta (ver «Dónde se almacenan y cuánto tiempo»). El contenido que ya se hubiera guardado en tu espacio de trabajo (por ejemplo, un archivo generado) sigue ahí hasta que tú lo borres o se elimine la cuenta; puedes pedirnos su eliminación en cualquier momento.

Uso limitado de datos de Google

Cuando inicias sesión con tu cuenta de Google, y cuando conectes a un agente una aplicación de Google, el tratamiento de la información obtenida a través de las API de Google se rige, además de por esta política, por la declaración oficial de Uso Limitado de Google, que reproducimos en su formulación literal:

“The use of information received from Google Workspace scopes will adhere to the Google User Data Policy, including the Limited Use requirements.”

En español: el uso de la información recibida a través de los permisos —«scopes»— de Google Workspace se ajusta a la Política de Datos de Usuario de los Servicios de API de Google, incluidos sus requisitos de Uso Limitado.

Qué permisos solicitamos, qué permite realmente cada uno y para qué lo usamos. Dos precisiones antes de la tabla:

• Al iniciar sesión con Google, lo único que se te pide es tu identidad. Los permisos de Google Workspace solo se te piden si conectas la aplicación correspondiente, nunca al entrar.
• La pantalla de consentimiento de Google es la fuente exacta. Lo que ahí se te muestre es la lista completa de lo que se te está pidiendo en ese momento: si aparece un permiso que esta tabla no declara, no lo aceptes y escríbenos.

Los permisos de la primera fila se solicitan hoy, si eliges iniciar sesión con Google. El resto se solicita cuando conectas una aplicación concreta a un agente, en el momento en que tú lo autorizas.

Dos precisiones, en lugar de la fórmula habitual de «pedimos el mínimo imprescindible»:

• No pedimos ningún permiso restringido, y esa es una decisión deliberada. Google clasifica como restringidos los permisos de lectura del buzón completo (gmail.readonly) y del Drive completo (drive.readonly). No los pedimos: del correo solo pedimos enviar, y de tus archivos solo aquellos que tú seleccionas. Renunciamos con ello a funciones que podríamos ofrecer —el agente no puede buscar, leer ni resumir tu buzón— a cambio de que la plataforma nunca llegue a tener acceso técnico a todo tu correo ni a todo tu disco.
• Algunos permisos incluyen más de lo que necesitamos. calendar.events ya incluye la lectura de los eventos, así que no hace falta pedir además un permiso de solo lectura de calendario. drive.file, por el contrario, es el permiso más estrecho que existe para trabajar con documentos, porque su alcance lo decides tú archivo a archivo.

Lo que realmente acota estos permisos no es su nombre, sino los compromisos que asumimos a continuación, tu decisión sobre qué conexiones autorizas y tu capacidad de revocarlas en cualquier momento.

Compromisos que asumimos sobre los datos de Google, conforme a los requisitos de Uso Limitado:

1. Uso restringido a funciones visibles. Los datos recibidos de las API de Google se usan exclusivamente para prestar o mejorar las funciones de la plataforma que tú ves y usas, y que has activado de forma expresa.

2. No los vendemos ni los transferimos. No vendemos, cedemos ni transferimos datos de Google a terceros, salvo en los cuatro supuestos que admite la propia política de Google, y en sus mismos términos: (a) para prestar o mejorar las funciones de la plataforma que son visibles y destacadas en su interfaz, a los proveedores estrictamente necesarios para ejecutar la operación que has solicitado —entre ellos, el proveedor de modelo que tú mismo configuras para ese agente—, sometidos a obligaciones de confidencialidad equivalentes y únicamente con tu consentimiento. Cuál es ese proveedor de modelo lo decides tú, y lo que eso implica se explica justo debajo de estos compromisos; (b) por motivos de seguridad, por ejemplo para investigar un abuso; (c) cuando lo exija la ley; o (d) en el marco de una fusión, adquisición o venta de activos, previo consentimiento explícito tuyo. Fuera de esos cuatro supuestos, no transferimos.

3. No los usamos para publicidad. Ni para mostrar anuncios, ni para segmentación, ni para publicidad personalizada, de reimpacto o basada en intereses. No hacemos publicidad.

4. No los usamos para desarrollar, mejorar ni entrenar modelos de IA. Dicho en la formulación exacta que pide Google, y sin condiciones:

   “Google Workspace APIs are not used to develop, improve, or train non-personalized AI and/or ML models.”

   En español: los datos obtenidos a través de las API de Google Workspace no se usan para desarrollar, mejorar ni entrenar modelos de IA o de aprendizaje automático no personalizados.

   Y esto es lo que nos permite afirmarlo sin matices: no tenemos modelos. No desarrollamos ninguno, no entrenamos ninguno y no tenemos ninguno que mejorar. Tampoco cedemos ese contenido a nadie con fines de entrenamiento, ni lo agregamos, anonimizamos o derivamos para ese fin. Lo único que hacemos con él es lo que tú nos has pedido: pasárselo, para responder a esa petición concreta, al proveedor de modelo que tú has configurado para ese agente. Qué hace ese proveedor con lo que recibe lo fijan sus condiciones, no las nuestras, y por eso el punto siguiente está escrito con nombres.

5. Ninguna persona los lee. Ningún miembro de nuestro equipo lee el contenido obtenido de Google, salvo (a) que nos des tu consentimiento explícito para mensajes concretos, (b) que sea imprescindible por motivos de seguridad —por ejemplo, investigar un abuso—, (c) que lo exija la ley, o (d) que se trate de datos agregados y anonimizados para operaciones internas.

El proveedor de modelo lo eliges tú — y esto es lo que implica. Lo contamos aquí, junto a los compromisos, porque es la decisión que más peso tiene sobre el recorrido de tus datos de Google:

• La plataforma no elige por ti. El proveedor de modelo es un campo obligatorio: ningún agente se crea sin uno, el servidor rechaza el alta si falta y en ningún alta viene preseleccionado — tienes que elegirlo para poder continuar. Queda anotado, lo ves en el panel y puedes cambiarlo después, agente por agente.
• Cuáles garantizan por contrato no entrenar, con nombres. A fecha de este documento son dos: Google Vertex —el servicio empresarial de IA de Google, que contratamos nosotros; en el panel, «Google Vertex», no «Google Gemini»— y Anthropic (modelos Claude), conforme a sus términos comerciales de API. OpenRouter no la ofrece: es un agregador, no ejecuta el modelo sino que enruta tu petición a proveedores de terceros, y sus propias condiciones advierten de que algunos de esos modelos pueden almacenar y entrenar con lo que reciben. Del resto del catálogo, lo que hagan con tu contenido lo fijan sus condiciones y el plan que tengas con ellos, no las nuestras.
• En un agente con una aplicación de Google conectada esa libertad tiene un límite, y es contractual. Elegir proveedor es libre en general; pero si a ese agente le has conectado una aplicación de Google, nuestros Términos del servicio te exigen configurarlo con uno de los dos proveedores con garantía —Vertex o Anthropic—, como condición de uso de esa conexión. Enrutar ese contenido a un proveedor sin esa garantía no es una opción que te ofrezcamos: es un incumplimiento de los Términos, y podemos suspender esa conexión conforme a su sección «Suspensión y terminación».
• Y lo otro tampoco lo vamos a disfrazar: no hay bloqueo técnico. La plataforma no comprueba esa combinación, y no vamos a insinuar que lo haga. Si incumples esa obligación, el contenido que ese agente envíe al modelo —incluido el que venga de esa aplicación de Google— puede acabar en un proveedor que lo almacene o entrene con él. Nosotros ponemos la información y la herramienta; de esa decisión respondes tú.
• Y la alternativa no te pide nada a cambio. Vertex es el único proveedor del catálogo que no necesita una clave ni una cuenta tuyas: lo contratamos y lo pagamos nosotros, dentro de los límites de consumo que aplicamos. Quedarte en el camino con garantía de no entrenamiento no te obliga a contratar nada.

Qué datos de Google pueden llegar a un modelo y cuáles no. No todos los permisos de la tabla mueven contenido en esa dirección, y la diferencia importa:

• De Gmail no llega nada. El permiso que pedimos es gmail.send, que solo envía. No leemos, buscamos ni listamos tu buzón, de modo que el contenido de tus correos no llega a ningún modelo: lo que viaja es el texto que tú pides enviar, y va en el sentido contrario, de la plataforma a Gmail.
• De Calendar, de Drive, de Hojas de cálculo y de Documentos sí puede llegar. calendar.events incluye leer tus eventos, y drive.file —el mismo permiso que comparten Drive, Hojas de cálculo y Documentos— alcanza los archivos que tú seleccionas y los que la propia aplicación crea. Si le pides al agente que trabaje sobre uno de ellos, ese contenido va al proveedor de modelo que hayas configurado: es la única forma de que el agente pueda trabajar con él.
• De tu identidad no llega nada. openid, email y profile sirven para reconocer tu cuenta al iniciar sesión; no se envían a ningún modelo.
• Google Analytics, cuando esa aplicación esté disponible, se comportará como Calendar y Drive: los informes que le pidas viajarían al proveedor de modelo configurado para ese agente.

Cuando revocas la conexión desde la plataforma, la marcamos como revocada —deja de poder usarse de inmediato— y eliminamos del almacén de secretos la credencial asociada; si esa eliminación fallara, la conexión queda igualmente revocada y no vuelve a usarse. Esa es la vía fiable para retirar el acceso de un agente. Te recomendamos, además, retirar el permiso desde tu propia cuenta de Google en myaccount.google.com/permissions: es la única forma de invalidarlo en origen, y conviene hacerlo también antes de cerrar tu cuenta en la plataforma, por los motivos que explicamos en «Dónde se almacenan y cuánto tiempo».

Con quién compartimos datos

No vendemos datos personales. Nunca. No los cedemos con fines publicitarios ni los intercambiamos con nadie con fines comerciales.

Compartimos datos únicamente con quien es necesario para prestarte el servicio, y solo lo necesario:

1. Proveedores de modelos de IA. Es la categoría más relevante y queremos que la entiendas bien. Para que un agente responda, la plataforma envía al proveedor de modelo que tú has configurado para ese agente el contenido necesario para generar la respuesta: tu instrucción, el contexto de la conversación y, si la tarea lo requiere, el contenido de los archivos o de las aplicaciones conectadas sobre los que le pides trabajar. El proveedor devuelve la respuesta.

La plataforma es deliberadamente abierta: puedes elegir entre un catálogo amplio de proveedores, entre otros OpenRouter, Anthropic (Claude), OpenAI, Google (modelos Gemini), DeepSeek, xAI (Grok), Mistral, Groq, NVIDIA, Hugging Face, Alibaba (Qwen), Moonshot (Kimi), MiniMax, z.ai (GLM) y otros. La lista completa y actualizada se muestra en la propia plataforma al configurar cada agente, y es allí donde eliges.

Y aquí hace falta un nombre exacto, no «Google». En el catálogo de la plataforma hay cuatro entradas de Google y no son lo mismo: dos se llaman «Google Gemini» y funcionan con una clave que aportas tú; las otras dos son Vertex —«Google Vertex» / «Google Vertex (Gemini)»— y son las únicas que contratamos nosotros, sin clave tuya. Siempre que en estos documentos decimos que contratamos a Google nos referimos a Vertex, y solo a Vertex. Elegir la opción llamada «Google Gemini» NO te sitúa en el proveedor que contratamos: te sitúa en tu propia cuenta de Google, cuyo nivel gratuito sí puede usar el contenido para mejorar sus productos.

Rol jurídico de estos proveedores, sin ambigüedad. Hay un proveedor que contratamos nosotros —Vertex— y todos los demás, que funcionan con una cuenta y una clave que aportas tú. La diferencia importa, porque cambia de quién es el contrato:

• Google, en su servicio empresarial de IA — es decir, Vertex (en el panel, «Google Vertex» o «Google Vertex (Gemini)»; no la opción llamada «Google Gemini», que va con clave tuya). Lo contratamos nosotros: interviene como subencargado del tratamiento y le exigimos las garantías del artículo 28 del RGPD.
• OpenRouter — y conviene leer este punto entero, porque de quién es la cuenta no siempre es lo mismo. Hoy, cuando eliges OpenRouter al crear un agente, la plataforma guarda y usa la clave que tú aportas: la cuenta es tuya, el contrato con OpenRouter es tuyo y esa salida de datos la decides tú. Hay dos casos en los que la clave es nuestra: los agentes antiguos, creados cuando el proveedor todavía no era un campo obligatorio y que por eso no lo tienen anotado; y los agentes que un administrador de tu organización haya puesto expresamente en la clave compartida de la plataforma —solo un administrador puede hacerlo, y es una decisión suya—. En esos dos casos la cuenta, el contrato y la transferencia son nuestros (se explica en «Dónde se almacenan y cuánto tiempo»), no te lo factura OpenRouter porque la cuenta no es tuya y, a cambio, ese consumo cuenta contra los límites que aplicamos nosotros. Sea de quien sea la cuenta, hay algo que no cambia:
  • OpenRouter es un agregador, no un proveedor con garantía contractual de no entrenamiento, y sus propias condiciones advierten de que algunos de los modelos a los que enruta pueden almacenar y entrenar con lo que reciben (se detalla en «Uso de tus datos en modelos de IA»). Si tu contenido no debe llegar a un modelo así, configura ese agente con Vertex o con Anthropic, que son los dos proveedores con garantía de no entrenamiento a fecha de este documento.
  • Y si la cuenta es tuya, el ajuste que decide a qué modelos se enruta lo controlas tú, no nosotros: está en tu panel de OpenRouter.
• Todos los demás del catálogo —incluidos los proveedores establecidos fuera del EEE— funcionan obligatoriamente con una cuenta y una clave que aportas tú: en esos casos el contrato es entre tú y ese proveedor, su papel y sus obligaciones los fija ese contrato y no el nuestro, y nosotros nos limitamos a dirigir la petición a la cuenta que has configurado.

Tres consecuencias que debes conocer antes de elegir:

• El proveedor que eliges recibe tu contenido. No hay forma de que un modelo responda sin recibir la pregunta.
• Cada proveedor tiene sus propias condiciones y su propia política de privacidad. Las nuestras no las sustituyen. Consúltalas antes de enviarle información sensible.
• Algunos proveedores del catálogo operan fuera del Espacio Económico Europeo, incluidos países sin decisión de adecuación de la Comisión Europea (por ejemplo, proveedores con infraestructura en China). Elegir uno de ellos implica una transferencia internacional que decide tu organización, y cuya cobertura jurídica se explica en «Dónde se almacenan y cuánto tiempo».

2. Servidores MCP y herramientas. A diferencia de la conexión de aplicaciones, esta función sí está en servicio hoy. Conviene ser exactos con quién autoriza qué, porque son dos pasos y no los da la misma persona: el catálogo y la habilitación de un servidor MCP para tu organización los administramos nosotros, a petición de tu organización —la administración de tu organización puede pedirlo, no activarlo—. Una vez habilitado, quién decide qué agentes lo usan es un administrador de tu organización o el dueño del agente, cada uno sobre los suyos. Cuando un agente lo usa, ese servidor recibe los datos que la operación requiera —tu petición y el contexto necesario— y puede consultar a su vez los sistemas de su propio proveedor. Lo decimos sin rodeos, porque es lo que importa: es una salida real de contenido hacia un tercero.

Sobre quién decide qué servidores existen hay dos vías, y no tienen el mismo control. Preferimos separarlas a resumirlas en un «catálogo cerrado» que no sería exacto:

• El catálogo del que se instala lo mantenemos nosotros. Dar de alta, editar o retirar una entrada del catálogo es una acción reservada a nuestra administración de plataforma; la administración de tu organización no puede hacerlo.
• Quien tenga el rol de mantenimiento dentro de tu propia organización puede registrar además un servidor propio. Ese registro no pasa por la revisión del catálogo, y queda acotado a tu organización: ninguna otra lo ve ni lo usa. Significa, eso sí, que la decisión de a qué tercero sale el contenido puede tomarla también alguien de tu equipo, no solo nosotros. Los Términos del servicio hacen responsable de ese riesgo a quien administra la cuenta, que es quien reparte los roles.

Y dos precisiones que preferimos hacer nosotros antes de que las preguntes, porque van en direcciones contrarias y las dos son ciertas:

• Lo que sí controlamos. Nuestro servicio intermediario solo habla con los servidores que están explícitamente autorizados en su configuración, y se cierra si no lo están: rechaza direcciones IP en cualquier forma, rechaza destinos locales y rechaza cualquier host que no figure en esa lista. Si la comprobación no pasa, la petición no llega a salir.
• Lo que no controlamos. La lista de destinos que declara un servidor es información de revisión, no una restricción técnica de red. Nos sirve para decidir si admitimos una entrada en el catálogo; no hay hoy un cortafuegos que impida a un servidor MCP, una vez en marcha, conectarse por su cuenta a un destino distinto del que declaró.

3. Aplicaciones que tú conectas. Reciben las peticiones que el agente realiza en tu nombre, dentro del alcance concedido (ver «Datos de terceros que conectas»).

4. Proveedores de infraestructura tecnológica que alojan la plataforma y sus copias de seguridad, y proveedores de servicios auxiliares (correo transaccional, soporte y, si algún día facturamos, facturación). Todos actúan como encargados del tratamiento con contrato del artículo 28 del RGPD, están obligados a confidencialidad y a medidas de seguridad, y solo pueden tratar los datos siguiendo nuestras instrucciones.

5. Autoridades y asesores, cuando exista una obligación legal, un requerimiento válido de una autoridad competente, o sea necesario para ejercer o defender reclamaciones.

6. En una operación societaria (fusión, adquisición o venta de activos), el adquirente, informándote previamente y manteniendo las garantías de esta política. Los datos obtenidos de las API de Google solo se transferirían en este supuesto con tu consentimiento explícito.

Uso de tus datos en modelos de IA

Esta es la sección que más importa, así que la escribimos sin ambigüedades, incluso donde la respuesta honesta es más incómoda que un titular absoluto.

Lo que sí podemos garantizar sin condiciones:

• Nosotros no entrenamos modelos. Martinuka2220, S.L. no desarrolla ni entrena modelos de inteligencia artificial. Tu contenido —conversaciones, archivos, instrucciones, datos de aplicaciones conectadas— nunca se usa para entrenar, ajustar ni mejorar ningún modelo propio, sencillamente porque no los hay. Para el contenido que llega de las API de Google esto está dicho además en la formulación literal que Google exige, en Uso limitado de datos de Google.
• No cedemos tu contenido a nadie para que entrene con él. No vendemos ni entregamos datasets, ni damos acceso a tu contenido a terceros con fines de entrenamiento, investigación o desarrollo de modelos.
• Se envía lo necesario para responder, no tu cuenta. Al proveedor de modelo se le envía el contenido imprescindible para atender la instrucción concreta: tu instrucción, el contexto de esa misma conversación que hace falta para mantener la continuidad y, si la tarea lo requiere, el contenido de los archivos o de las aplicaciones sobre los que le pides trabajar. Nunca se envía tu cuenta completa ni el histórico de tus demás conversaciones.

El filtro de credenciales: qué hace y hasta dónde llega. Antes teníamos esta frase dentro de la lista de arriba, y era el sitio equivocado, porque no es una garantía y su propio código dice que no lo es. Lo explicamos entero, que es más útil que la frase corta:

• Qué hace. La plataforma pasa un filtro sobre el bloque con el que se le recuerda a un agente lo que ya se dijo en la conversación, y sobre la nota de contexto de cada hilo. Ese filtro reconoce formatos habituales de clave o de credencial y los sustituye antes de que el texto salga.
• Por qué no es una garantía. Reconoce formas conocidas; una credencial con una forma poco común pasa. Está pensado como una capa de refuerzo, no como el control que impide que un secreto salga.
• Qué no cubre. No se aplica al mensaje que acabas de escribir, ni al contexto persistente que fijes a un agente, ni al de un proyecto, ni a las instrucciones con las que configuras un sub-agente.
• Y hay un caso que conviene que sepas, porque es el de hoy. Los agentes que actualmente están operativos mantienen su propia memoria de conversación, de modo que el bloque de recuerdo —el único que se filtra— ni siquiera llega a componerse para ellos.

Lo que se deduce de todo eso, dicho como petición y no como letra pequeña: no escribas credenciales en el chat ni las dejes escritas en el contexto de un agente. Si un agente necesita una clave para trabajar, guárdala como credencial en la plataforma —para eso existe el almacén de secretos que se describe en «Cómo los protegemos»—, en lugar de pegarla en un mensaje.

Lo que no es una garantía nuestra sino una obligación tuya — y por qué lo decimos en vez de callarlo:

• Con una aplicación de Google conectada, el proveedor admisible está determinado. Nuestros Términos del servicio te exigen enrutar el contenido procedente de las API de Google únicamente a proveedores con garantía contractual de no entrenamiento —hoy, Vertex o Anthropic—, como condición de uso de esa conexión. Enrutarlo a otro es un incumplimiento de los Términos, no una alternativa que te ofrezcamos, y podemos suspender esa conexión conforme a su sección «Suspensión y terminación».
• No hay bloqueo técnico, y no vamos a insinuar que lo haya. La plataforma no comprueba esa combinación: es una obligación que cumples tú, y la presentamos así —y no como un automatismo del sistema— porque es exactamente lo que es. Si la incumples, ese contenido puede acabar en un modelo que lo almacene o entrene con él, y de eso respondes tú.

Lo que depende del proveedor que tú elijas — y por qué no podemos prometerlo por él:

Tu contenido debe llegar al proveedor de modelo que hayas configurado para que el agente pueda responder. Qué hace ese proveedor con lo que recibe lo determinan sus condiciones, no las nuestras. Y no todas dicen lo mismo:

• Proveedores con garantía contractual de no entrenamiento. Hay proveedores cuyos términos comerciales de API se comprometen a no usar el contenido enviado por sus clientes para entrenar ni mejorar sus modelos. Hoy es el caso de Anthropic (modelos Claude) y de Google en su servicio empresarial de IA, Vertex (modelos Gemini contratados por nosotros para la plataforma; en el panel, «Google Vertex», no «Google Gemini»). Si necesitas una garantía de no entrenamiento, configura tus agentes con uno de estos proveedores; y si conectas aplicaciones de Google, los Términos te obligan a hacerlo.
• Agregadores de modelos. Servicios como OpenRouter no ejecutan el modelo: enrutan tu petición hacia proveedores de terceros. Sus propias condiciones advierten de que algunos de esos modelos pueden almacenar y entrenar con lo que les envías, y de que poder excluirse de ese entrenamiento depende de las condiciones de cada modelo, no del agregador. Que tu contenido acabe o no en un proveedor que entrena con él depende de un ajuste de la cuenta del agregador, y el destino real puede variar de una petición a otra. Aquí hay que distinguir de quién es esa cuenta: si elegiste OpenRouter al crear el agente, la cuenta y ese ajuste son tuyos; la cuenta es nuestra —y el ajuste lo controlamos nosotros— en los agentes antiguos y en los que un administrador de tu organización haya puesto expresamente en la clave compartida, ver «Con quién compartimos datos». Lo que sí conviene que sepas en los dos casos: las condiciones del agregador declaran que, cuando es posible, se han excluido del entrenamiento en los modelos que utilizan, y su panel de cuenta permite desactivar el enrutado hacia los proveedores que entrenan, con ajustes separados para los modelos de pago y los gratuitos. Sobre el registro de tus peticiones sus condiciones son claras en los dos sentidos: si activas el registro de peticiones («prompt logging») les concedes sobre ese contenido una licencia perpetua, irrevocable, sublicenciable y extendida a sus propios fines comerciales, y si no lo activas, declaran no almacenar tus entradas más allá de categorizarlas; al margen de esa opción, mantienen una licencia sobre entradas anonimizadas limitada a métricas de uso de su sitio. Aun así: un agregador no es un proveedor con garantía contractual de no entrenamiento, y no debes enrutar a través de él contenido confidencial ni datos personales de terceros.
• Tu propia cuenta de proveedor (clave aportada por ti). La plataforma admite que uses tus propias credenciales con todos los proveedores salvo uno: Vertex, el único que contratamos nosotros y el único que no te pide clave. En ese caso el contrato es entre tú y ese proveedor: los ajustes de esa cuenta —incluidos los relativos al entrenamiento con tus datos— los controlas tú. Nosotros no podemos leerlos, cambiarlos ni forzarlos. Ten presente que algunos planes gratuitos o de desarrollo de proveedores muy conocidos sí utilizan el contenido para mejorar sus productos, mientras que sus planes de pago o empresariales no lo hacen: la diferencia está en el plan, no solo en la marca.

Qué hacemos con esa realidad, en lugar de esconderla:

• Te decimos dónde va tu contenido. El proveedor y el modelo de cada agente se eligen al configurarlo y pueden consultarse y cambiarse en cualquier momento desde la plataforma.
• Lo convertimos en una obligación contractual, no en un bloqueo. Nuestros Términos del servicio te obligan, si conectas aplicaciones de Google o cualquier otra fuente con contenido confidencial o datos personales de terceros, a configurar con uno de los proveedores con garantía contractual de no entrenamiento que se nombran arriba todos los agentes a los que vincules esa conexión: la autorización es de tu cuenta y puedes vincularla a más de un agente, así que configurar uno solo no basta si has vinculado varios. La plataforma no lo comprueba ni lo impide: es una obligación que cumples tú.
• Recomendación práctica. Para tratar datos personales de terceros o información confidencial, usa esos proveedores y no enrutes ese contenido a través de agregadores.

Preferimos decirte exactamente dónde llega nuestro compromiso y dónde empieza el de otro, antes que firmar un absoluto que no dependa de nosotros. Un compromiso que no podemos cumplir no protege a nadie.

Prohibiciones que asumimos

Con independencia de la base jurídica que nos ampare, nos obligamos a lo siguiente. Esta lista es un compromiso, no una descripción:

• No vendemos datos personales, ni los alquilamos, ni los cedemos a cambio de contraprestación.
• No los usamos con fines publicitarios, ni propios ni de terceros: ni anuncios, ni segmentación, ni publicidad personalizada, de reimpacto o basada en intereses.
• No elaboramos perfiles comerciales ni de comportamiento ajenos a la prestación del servicio, y no tomamos decisiones automatizadas con efectos jurídicos sobre las personas.
• No usamos tu contenido para entrenar modelos propios —no los tenemos— ni lo cedemos a nadie para que entrene con él. Lo que haga con lo que recibe el proveedor de modelo que tú eliges no depende de nosotros y no lo prometemos en su nombre: la diferencia, proveedor por proveedor, está explicada en Uso de tus datos en modelos de IA.
• No cruzamos los datos entre organizaciones. El contenido de una organización no se usa para nada relacionado con otra, en ningún caso.
• No enriquecemos tu perfil con fuentes externas ni compramos datos a intermediarios.
• No destinamos tu contenido a ninguna finalidad distinta de las declaradas en esta política, incluidos los supuestos tasados de acceso humano y de comunicación a terceros que en ella se describen: fuera de esos supuestos, no hay ningún otro uso. Si en el futuro apareciera una finalidad nueva, te lo comunicaríamos y, si la ley lo exige, te pediríamos consentimiento antes de llevarla a cabo.

Acceso humano a tus datos

Por defecto, nadie de nuestro equipo lee tu contenido. El acceso al contenido de las conversaciones, los archivos y los datos de las aplicaciones que conectas está restringido, y solo puede producirse en estos supuestos tasados:

1. Con tu petición o tu consentimiento explícito — por ejemplo, cuando abres una incidencia de soporte y nos autorizas a mirar un caso concreto para resolverlo.
2. Por seguridad — cuando sea imprescindible para investigar un incidente, un acceso no autorizado, un abuso de la plataforma o una amenaza para otras organizaciones.
3. Por obligación legal — para atender un requerimiento válido de una autoridad competente.
4. Sobre datos agregados y anonimizados, que no permiten identificar a nadie ni reconstruir el contenido.

Controles que aplicamos a ese acceso:

• Mínimo imprescindible. Solo las personas cuyo trabajo lo requiere, solo sobre lo estrictamente necesario y solo durante el tiempo necesario.
• Trazabilidad. Los accesos y las acciones administrativas quedan registrados con autor, momento, objeto de la acción y origen de la conexión.
• Confidencialidad. Todo el personal está sujeto a deber de confidencialidad, que subsiste tras el fin de su relación con la empresa.
• Sobre datos de Google se aplica, además, la restricción específica de la sección Uso limitado de datos de Google.

Dónde se almacenan y cuánto tiempo

Dónde. La plataforma y sus copias de seguridad se alojan en Estados Unidos, en instalaciones de proveedores de infraestructura que actúan como encargados del tratamiento. Además, el contenido que envías a un modelo de IA se trata allí donde opere el proveedor que hayas elegido, que puede estar en otros países (ver «Con quién compartimos datos»).

Transferencias internacionales. Estamos establecidos en España, de modo que el capítulo V del RGPD se aplica a las salidas de datos que hacemos nosotros con independencia de dónde vivas tú: lo que activa ese régimen es la posición de quien exporta los datos, no la nacionalidad ni la residencia de la persona a la que se refieren. En la práctica, las garantías del punto 1 te amparan también si estás en América Latina o en Norteamérica; y si además la ley de tu país impone condiciones propias, se aplicarán sumadas a estas. Hay que distinguir dos situaciones, porque su cobertura jurídica no es la misma y presentarlas juntas sería inexacto:

1. Transferencias que hacemos nosotros — alojamiento, copias de seguridad, servicios auxiliares y el único proveedor de modelo que contratamos nosotros, el servicio empresarial de IA de Google. Aquí somos parte del contrato, y la salida del Espacio Económico Europeo se ampara en las garantías del capítulo V del RGPD: Cláusulas Contractuales Tipo aprobadas por la Comisión Europea (Decisión de Ejecución 2021/914) y, cuando el proveedor está certificado, el Marco de Privacidad de Datos UE-EE. UU., junto con las medidas complementarias que resulten de la evaluación de impacto de la transferencia. Puedes pedirnos copia de las garantías aplicadas.
2. Transferencias derivadas de la elección de proveedor de modelo que hace tu organización — cualquier otro proveedor del catálogo, con cuenta y clave aportadas por ti y, por tanto, sin contrato con nosotros: agregadores como OpenRouter y proveedores establecidos fuera del EEE, entre otros. (Quedan fuera los agentes que arrancan con nuestra clave de OpenRouter —los antiguos y los que un administrador de tu organización haya puesto expresamente en la clave compartida, descritos en «Con quién compartimos datos»—: esa salida entra en el punto 1.) En ese caso nosotros no podemos aportar garantías del capítulo V sobre esa salida: no somos parte de ese contrato. La transferencia deriva de una instrucción de tu organización, y es ella quien debe asegurarse de contar con una base válida. Lo decimos así de claro para que puedas decidir con la información correcta: si necesitas que todas las salidas queden cubiertas por garantías nuestras, limita la configuración de tus agentes al proveedor de modelo que contratamos nosotros.

Cuánto tiempo. Distinguimos lo que la plataforma depura sola de lo que solo se elimina cuando se elimina la cuenta. Preferimos decirlo así, en lugar de anunciar automatismos que no existen:

• Registros de acceso y auditoría (inicios de sesión, IP, acciones administrativas, intentos denegados) — 90 días. Un proceso diario de la plataforma los depura automáticamente al superar ese plazo.
• Eventos de actividad de los agentes — 180 días, con la misma depuración automática diaria.
• Instantáneas históricas de consumo — 365 días, con la misma depuración automática diaria.
• Registro de uso por agente (los tokens y el costo que ves en tus paneles de gasto) — no se depura por el paso del tiempo: se conserva mientras exista la cuenta, porque es la base de tu histórico de gasto y del cálculo de tus límites. Se elimina cuando se elimina la cuenta.
• Contenido de trabajo —conversaciones, archivos, proyectos, tareas programadas, resultados de los agentes y el contenido que un agente haya traído de una aplicación conectada y quede en el hilo— no se borra automáticamente por el paso del tiempo. Se conserva mientras exista la cuenta o la organización, o hasta que tú lo elimines, y se elimina junto con ellas.
• Datos de cuenta y perfil — mientras exista la cuenta.
• Credenciales de aplicaciones conectadas (tokens de acceso y de refresco) — hasta que revoques la conexión desde la plataforma, momento en el que la conexión queda revocada y eliminamos la credencial del almacén de secretos; si esa eliminación fallara, la conexión queda igualmente revocada y no vuelve a usarse. Además, cuando ejecutamos el borrado de una cuenta eliminamos también manualmente las credenciales de sus conexiones del almacén de secretos, mientras la plataforma no lo haga por sí sola. Dicho esto, y para que puedas actuar con conocimiento: el cierre de la cuenta, por sí solo, no revoca estas credenciales, y no comunicamos la revocación al proveedor. Por eso, si vas a dejar de usar la plataforma, revoca tus conexiones antes de cerrar la cuenta y retira además el permiso desde tu cuenta en el proveedor —en el caso de Google, en myaccount.google.com/permissions—, que es la única forma de invalidarlo en origen. Y si ya has perdido el acceso —porque cerraste la cuenta o porque tu organización te dio de baja—, retira el permiso en esa misma página y escríbenos a empresa@hutrit.com para que eliminemos la credencial: sigues teniendo derecho a exigirlo.
• Claves de API de proveedores de modelo que tú aportas — mientras las mantengas configuradas. Puedes sustituirlas o eliminarlas en cualquier momento; al eliminarlas se borran de inmediato de los sistemas en producción. Al ejecutar el borrado de una cuenta, el propio proceso intenta eliminar automáticamente estas claves del almacén de secretos. Es un intento con red, no una garantía: si esa eliminación fallara, el borrado de la cuenta continúa igualmente, el fallo queda registrado y nuestro equipo la completa a mano. Si dejas de usar la plataforma, rota o revoca esas claves en el panel de tu proveedor: es la única forma de invalidarlas en origen.
• Copias de seguridad — se conservan en rotación cíclica: el criterio es mantener el número de copias necesario para poder restaurar el servicio ante un incidente reciente, y ninguna copia se conserva más allá de ese ciclo, al término del cual se sobrescribe. Por eso, un dato eliminado de los sistemas en producción puede subsistir en una copia hasta que esa copia se sobrescriba; mientras tanto permanece cifrado, protegido y sin usarse para ninguna finalidad.
• Datos de facturación y documentación contable — hoy no existen: el servicio se presta sin coste y no emitimos facturas por su uso, de modo que no hay obligación contable que cumplir ni datos de facturación que conservar. Si en el futuro contratas un plan de pago, desde ese momento se conservarán 6 años desde el último asiento, por obligación legal (Código de Comercio), y 4 años a efectos fiscales, prevaleciendo el plazo más largo.
• Datos necesarios para atender reclamaciones — durante el plazo de prescripción de las acciones legales que puedan derivarse —con carácter general, cinco años para las acciones personales, artículo 1964 del Código Civil—, bloqueados y a disposición exclusiva de autoridades y tribunales.

Cómo se elimina una cuenta. No existe un borrado automático diferido ni un botón de autodestrucción: la eliminación de una cuenta, de una organización y de su contenido es un proceso a petición que ejecuta nuestro equipo cuando tú o tu organización lo solicitáis, del modo que se describe en «Tus derechos, revocación y borrado». Hasta ese momento, el contenido de trabajo se conserva.

Cómo los protegemos

Explicamos garantías y resultados, no la tecnología concreta que hay detrás: esa parte es información reservada y contarla en público debilitaría la propia protección.

• Cifrado. Los datos viajan cifrados en tránsito y se almacenan cifrados en reposo.
• Aislamiento entre organizaciones. Cada organización opera en su propio espacio lógico y el sistema impide, por diseño, que una acceda al contenido de otra. Los agentes también están aislados entre sí.
• Las credenciales viven aparte, y ninguna se guarda en claro. Tu contraseña se guarda como un hash irreversible —no cifrada, sino transformada de modo que no puede recuperarse— y del token de acceso conservamos solo una huella. Las claves de API y los tokens de las aplicaciones que conectas se custodian cifrados en reposo en un almacén de secretos independiente, separado del resto de los datos y de las máquinas donde se ejecutan los agentes.
• Acceso mínimo necesario. Cada componente y cada persona tiene únicamente los permisos que necesita, y nada más.
• Acceso reforzado. El acceso federado con Google o Microsoft exige resolver un segundo factor de autenticación, y la verificación en dos pasos es obligatoria para las cuentas de administración de la plataforma. En todos los casos: sesiones controladas y revocación inmediata de credenciales cuando se solicita.
• Trazabilidad. Las acciones relevantes quedan registradas de forma que se puede reconstruir qué pasó, quién lo hizo y cuándo.
• Copias de seguridad periódicas, cifradas y con capacidad de recuperación ante un incidente.
• Gestión de incidentes. Si se produjera una violación de seguridad, actuamos según nuestro papel en cada caso: cuando afecte a datos de los que somos responsables (cuenta, autenticación, seguridad y, en su caso, facturación), la notificaremos a la Agencia Española de Protección de Datos en un plazo de 72 horas desde que tengamos conocimiento de ella, y te informaremos sin dilación indebida cuando el riesgo para ti sea alto; cuando afecte al contenido de trabajo, del que tu organización es responsable, se lo notificaremos a ella sin dilación indebida, conforme al artículo 33.2 del RGPD, para que pueda cumplir su propio deber de notificación ante la autoridad y ante las personas afectadas.

Ningún sistema es invulnerable. Nos comprometemos a mantener medidas apropiadas y actualizadas, y a ser transparentes si algo falla.

Tus derechos, revocación y borrado

El RGPD te reconoce los siguientes derechos sobre tus datos personales:

• Acceso — saber qué datos tuyos tratamos y obtener una copia.
• Rectificación — corregir los datos inexactos o incompletos.
• Supresión («derecho al olvido») — pedir que los borremos cuando ya no sean necesarios, retires tu consentimiento o te opongas con éxito al tratamiento.
• Limitación del tratamiento — pedir que los conservemos pero dejemos de usarlos mientras se resuelve una impugnación.
• Portabilidad — recibir los datos que nos has facilitado en un formato estructurado, de uso común y lectura mecánica, o pedir que se los enviemos directamente a otro responsable cuando sea técnicamente posible.
• Oposición — oponerte a un tratamiento basado en nuestro interés legítimo, explicando tu situación particular.
• Retirada del consentimiento — en cualquier momento, sin que afecte a la licitud del tratamiento anterior.
• No ser objeto de decisiones automatizadas con efectos jurídicos. Como se indica en «Para qué los usamos», no las tomamos.

Tu derecho de oposición, señalado por separado. El artículo 21.4 del RGPD exige que este derecho se te presente de forma expresa y separada del resto, y no como un guion más dentro de una lista: puedes oponerte en cualquier momento, por motivos relacionados con tu situación particular, a los tratamientos que basamos en nuestro interés legítimo —la seguridad de la plataforma y la mejora del servicio a partir de métricas técnicas de uso—. Si lo haces, dejaremos de tratar esos datos, salvo que acreditemos motivos legítimos imperiosos que prevalezcan sobre tus intereses, derechos y libertades, o que sean necesarios para formular o defender reclamaciones.

Cómo ejercerlos. Escríbenos a info@hutrit.com indicando qué derecho ejerces. Puede que necesitemos verificar tu identidad antes de atender la solicitud, para proteger tus propios datos. Responderemos en el plazo de un mes desde la recepción; si la solicitud es especialmente compleja, podemos ampliarlo dos meses más, informándote del motivo dentro del primer mes. El ejercicio de estos derechos es gratuito.

Si eres miembro de una organización, ten en cuenta que sobre el contenido de trabajo la responsable es tu organización: podemos redirigirle tu solicitud y atenderla siguiendo sus instrucciones, como exige el artículo 28 del RGPD. Te lo comunicaremos si ocurre.

Revocar una aplicación conectada. Puedes retirar en cualquier momento la autorización concedida a una aplicación externa desde la propia plataforma: al hacerlo la conexión queda revocada de inmediato y eliminamos del almacén la credencial asociada; si esa eliminación fallara, la conexión queda igualmente revocada. Hazlo antes de cerrar tu cuenta, porque el cierre no revoca las conexiones por sí solo, y retira también el permiso desde tu cuenta en el proveedor —en Google, en myaccount.google.com/permissions—, que es la única forma de invalidarlo en origen. Si ya no puedes entrar en la plataforma, retira el permiso en esa página y escríbenos: eliminaremos la credencial por ti.

Borrar tu cuenta. El borrado no es automático ni diferido: es un proceso a petición. Solicítalo escribiendo a info@hutrit.com; antes de ejecutarlo te ofreceremos una copia de tu contenido, y una vez confirmado eliminamos la cuenta y su contenido de trabajo sin dilación indebida y, en todo caso, dentro del plazo de un mes en que debemos responderte. Quedan fuera de ese borrado, y son estas cuatro cosas y no más:

1. los datos que debamos conservar por obligación legal, que permanecerán bloqueados;
2. los datos necesarios para atender o defender reclamaciones, durante el plazo de prescripción —que no es una obligación de conservar, sino la posibilidad de que alguien reclame—, también bloqueados;
3. el residuo que subsista en las copias de seguridad de la base de datos hasta que salgan de las siete que conservamos, o en los registros de transacciones durante sus 7 días;
4. los objetos que el almacenamiento retiene 7 días tras su eliminación como margen de recuperación. Esto no es una copia de seguridad: es el propio almacenamiento reteniendo lo ya borrado antes de descartarlo del todo, y por eso lo decimos aparte del punto 3.

Qué comprende el borrado. Nos pides una sola cosa —que borremos tu cuenta— y esa petición comprende todo lo tuyo: los datos de la base de datos, los archivos del almacenamiento —los de tus agentes, sus versiones anteriores y tu imagen de perfil—, las claves de API de tus agentes y las credenciales de tus aplicaciones conectadas. No tienes que enumerar ninguna de esas partes ni pedirlas por separado, y no condicionamos ninguna a que la reclames: es tu derecho entero, no una lista de la que elegir. Nuestro compromiso es un resultado: cuando venza el plazo de un mes indicado arriba, nada de eso sigue en nuestros sistemas, salvo lo que la ley nos obligue a conservar bloqueado y el residuo que subsista en las copias de seguridad.

Y ahora, cómo se llega a ese resultado, porque no todo lo ejecuta el mismo mecanismo y creemos que tienes derecho a saber dónde nuestra promesa descansa en código y dónde en personas:

• Lo que hace el sistema solo. Elimina de la base de datos tus datos de cuenta y todo tu contenido de trabajo —conversaciones, proyectos, tareas programadas, misiones y el índice de tus archivos—.
• Lo que el sistema intenta, sin garantizarlo. Dos cosas: eliminar del almacén de secretos las claves de API de tus agentes, y retirar los servicios en los que corrían. Las dos son intentos con red: si alguna fallara, el borrado de tu cuenta continúa igualmente y el fallo queda anotado en nuestros registros técnicos, sin reintento automático.
• Lo que el sistema NO hace hoy. No elimina los archivos del almacenamiento ni las credenciales de tus aplicaciones conectadas: el proceso automático no llega a ellos. Forman parte de lo que completamos nosotros al atender tu solicitud, dentro de ese mismo plazo de un mes. Preferimos decírtelo a describir un automatismo que no existe.

Hecho todo eso, el almacenamiento conserva todavía los objetos eliminados durante 7 días por su margen de recuperación, como cualquier otro archivo que borres (ver «Dónde se almacenan y cuánto tiempo»).

Una advertencia que preferimos darte antes y no después: el borrado de tu cuenta no comunica nada al proveedor de una aplicación que hayas conectado. Por eso, revoca tus conexiones antes de pedirlo y retira además el permiso desde tu propia cuenta en el proveedor —en Google, en myaccount.google.com/permissions—, que es la única forma de invalidarlo en origen.

Reclamación ante la autoridad de control. Si consideras que no hemos atendido correctamente tu solicitud o que tratamos tus datos de forma indebida, puedes presentar una reclamación ante la Agencia Española de Protección de Datos (AEPD), C/ Jorge Juan 6, 28001 Madrid — www.aepd.es, que es la autoridad de control de nuestro país. No estás obligado a acudir a ella: el artículo 77 del RGPD te permite reclamar ante la autoridad de control del Estado miembro en el que residas, trabajes o donde se haya producido la supuesta infracción. Y si te encuentras fuera del Espacio Económico Europeo, puedes dirigirte además a la autoridad de protección de datos de tu propio país, cuando exista. Te agradeceríamos la oportunidad de resolverlo antes contigo, pero es tu derecho y puedes ejercerlo directamente.

Cookies y tecnologías similares

Vamos a ser concretos, porque en esto se abusa mucho del lenguaje vago:

La web pública mision1m.com no usa cookies. No hay analítica, ni píxeles de seguimiento, ni publicidad, ni cookies de terceros. No sabemos quién nos visita y no lo intentamos averiguar.

Lo único que esta web guarda en tu navegador es una preferencia local (m1m-lang-suggestion-dismissed), que se crea solo si cierras el aviso que sugiere leer la página en otro idioma. Sirve para no volver a mostrártelo. No identifica a nadie, no viaja a ningún servidor y puedes borrarla desde tu navegador. Al ser una preferencia que activas tú con una acción expresa, no requiere consentimiento previo.

El panel de la plataforma usa cookies estrictamente necesarias, y aquí van con su nombre y su duración, que es lo que hay que declarar:

• m1m_session — mantiene tu identidad autenticada mientras navegas y protege la sesión frente a usos indebidos. Sin ella no es posible entrar. Dura 7 días y persiste aunque cierres el navegador: no es una cookie «de sesión» en el sentido estricto, y preferimos decirlo a usar esa etiqueta como comodín. Se elimina al cerrar sesión o cuando caduca.
• m1m_active_org — recuerda con qué organización estás trabajando cuando perteneces a varias. Dura también 7 días, y no se borra al cerrar sesión: permanece hasta que caduca o hasta que la borras desde tu navegador. No da acceso por sí sola —el acceso lo decide siempre la sesión—, pero es una cookie más y estaba sin declarar.

Las dos son técnicas y necesarias, exentas del deber de consentimiento previo conforme al artículo 22.2 de la LSSI.

Y el panel guarda además cosas en el almacenamiento local de tu navegador, que no son cookies pero conviene declarar porque algunas contienen contenido tuyo: el borrador del mensaje que estás escribiendo y no has enviado, las notas de contexto que ancles a una conversación, y preferencias de interfaz (tema, agente seleccionado, estado de la barra lateral, disposición de la vista de oficina, último aviso leído). Si accedes con Google o Microsoft, el componente de identidad de ese proveedor guarda además en tu navegador el testigo que mantiene la sesión abierta. Todo eso vive en tu equipo, no en nuestros servidores, y puedes borrarlo desde tu navegador; el borrador y las notas de contexto desaparecen con ello.

No usamos cookies de analítica, de perfilado ni de publicidad, ni propias ni de terceros. Si algún día lo hiciéramos, te lo pediríamos antes mediante un mecanismo de consentimiento y actualizaríamos esta sección.

Puedes configurar tu navegador para bloquear o eliminar cookies y almacenamiento local. Si bloqueas las cookies técnicas, no podrás iniciar sesión en el panel.

Menores de edad y cambios en esta política

Menores de edad. M1M es un servicio dirigido exclusivamente a personas mayores de 18 años. Está pensado para un uso profesional o empresarial, si bien quien lo usa puede tener la condición de consumidor y conservar entonces los derechos que la ley le reconoce, como explican los Términos del servicio. No está dirigido a menores, no recogemos datos de menores de forma consciente y el acceso está restringido a cuentas autorizadas por una organización. Si detectamos que se ha creado una cuenta de un menor, la eliminaremos junto con sus datos. Si crees que un menor nos ha facilitado datos, escríbenos a empresa@hutrit.com y actuaremos de inmediato.

Cambios en esta política. Podemos actualizar esta política para reflejar cambios en el servicio, en los proveedores que intervienen o en la normativa aplicable. La fecha de la última actualización figura al principio del documento.

• Si el cambio es sustancial —por ejemplo, una nueva finalidad, una nueva categoría de destinatarios o un cambio en los plazos de conservación—, te avisaremos por correo electrónico o desde la plataforma con al menos 30 días de antelación a su entrada en vigor.
• Si el cambio es menor —correcciones de redacción, precisiones, actualizaciones de contacto—, publicaremos la nueva versión y actualizaremos la fecha.
• Cuando un cambio requiera tu consentimiento, te lo pediremos expresamente antes de aplicarlo. Seguir usando la plataforma tras la entrada en vigor de un cambio que no requiera consentimiento implica que aceptas la versión vigente.

Versiones anteriores. Avisar de un cambio solo sirve si puedes comprobar en qué consiste, así que: conservamos las versiones anteriores de este documento y, si necesitas saber qué decía en una fecha concreta o qué ha cambiado respecto de la anterior, pídenoslo y te lo facilitaremos. El aviso previo de un cambio sustancial indicará qué cambia, no solo que hay una versión nueva.

Esta política está disponible en español e inglés. En caso de discrepancia entre ambas versiones, prevalece la versión en español.