Privacy Policy

Last updated: 2026-09-28T00:00:00.000Z

Language: English Español

Who we are and how to contact us

The controller of the personal data collected through M1M (the “platform”) is:

• Legal name: MARTINUKA2220, SOCIEDAD LIMITADA (“Martinuka2220, S.L.”)
• Spanish tax ID (CIF): B72816911
• Registered office: Carretera de Miñano Mayor s/n, Etxabarri-Ibiña, Álava (01196), Vitoria-Gasteiz, Spain
• Commercial Registry: Registro Mercantil de Álava (Portal de Castilla 7 bajo, 01005 Vitoria-Gasteiz), volume 1757, folio 8, sheet VI-21090, entry 1
• Phone: +34 640296736
• Email: empresa@hutrit.com
• Website: mision1m.com

Three names, one party responsible. You will see three names around this service and you should know how they relate. M1M is an application created from Hutrit, and Hutrit is the trading name under which Martinuka2220, S.L. operates. That is why our contact address sits on the hutrit.com domain and why that name appears attached to the computing services that run the application: it is the name under which they are provided. Towards you, the party that answers legally is Martinuka2220, S.L., the company identified above. To be precise about the reach of those names: neither “M1M” nor “Hutrit” is registered, either as a trade mark or as a trade name. They are unregistered trading names of that company, which is the only one on the register, at the Registro Mercantil de Álava.

This policy explains what data we process when you use the platform, for what purpose, on what legal basis, who we share it with, how long we keep it and what you can require of us. It applies to the public website mision1m.com and to the platform dashboard.

Territorial scope, stated precisely. The platform is operated from Spain and is today used by people and organizations in Europe, Latin America and North America. This policy is drafted under the GDPR and Spanish law, and we apply the same standard of protection to every user, wherever they are: the same security measures, the same retention periods and the same procedure for exercising rights. Where the law of your own country grants you additional rights or imposes its own requirements on the processing or the international transfer of your data, those apply in addition to what is described here; write to us and we will tell you how to exercise them.

For any matter relating to this policy, including exercising your rights, write to empresa@hutrit.com with “Data protection” in the subject line.

We have not appointed a data protection officer, as none of the cases in Article 37 GDPR applies. The contact point for any privacy matter is the email address above.

An important note on roles. With respect to your account data (sign-up, access, security and, where applicable, billing) we are the controller. With respect to the content you or your agents put into the platform — conversations, files, data from the third-party services you connect — your organization is the controller and we act as processor on its behalf, under Article 28 GDPR. The “What we use it for” section separates the two blocks expressly.

And here is a gap we would rather tell you about than have you discover. Article 28 requires that processing to be governed by a written contract, and today we have none signed with any customer: access to the platform has been granted without it. We are preparing the data processing addendum so it can be incorporated into these documents. In the meantime, this policy describes the instructions we hold ourselves to and stands as our commitment, but it does not replace that contract and we do not pretend it does. If your organization needs it signed sooner, write to us and we will sort it out with you.

What data we collect

Account and registration data. First name, surname, email address, password, the agent you state you are going to use when registering, the status of your two-step verification, the organization you belong to and your role within it, the sign-up date, your visual theme preference and, if you upload one, your profile picture. Your password is never stored, neither in the clear nor encrypted: we keep only an irreversible hash, from which the original password cannot be recovered. Registration also generates a 32-character personal access token: it is shown to you once, and of it too we keep only a cryptographic fingerprint, never the token itself.

Federated authentication data. If you sign in with your Google or Microsoft account, we receive from that provider your user identifier, your email address and your name, together with confirmation that you have passed a second authentication factor. We never receive your password, and we do not collect the profile picture from that account either. This data does not come from you directly: its source is the identity provider you choose when signing in.

Platform usage data. The content of your conversations with agents, the instructions you give them and their responses; the files you upload or your agents generate; the projects, scheduled jobs and missions you create; each agent’s configuration (including the model provider you choose); and usage metrics — number of requests, tokens consumed per model and associated cost — which we need in order to show you your spend and enforce your limits.

Technical and security data. A log of activity relevant to account security: sign-ins and sign-outs, password changes, access-token rotation or revocation, people added and removed, permission changes, denied access attempts and other administrative actions. For each one we record who did it, what they did, on what and when. We also record agent activity events and operational request data (route, response code, duration).

You should know where that record stops, because over-declaring is inaccurate too: the source IP address and the before and after values of a change are fields that exist, but today they are only filled in for a few specific actions. In the vast majority of records those two fields are left empty, including sign-ins, sign-outs and permission changes.

And one further clarification, because the previous note over-declared too: a failed sign-in attempt generates no record. If someone enters a wrong password, no trace of that attempt is kept.

Data from applications you connect. Only if you authorize a connection: the access credentials the provider issues to us, the scope granted, its expiry date, and the content of that application the agent accesses in order to carry out what you ask. This is detailed under “Third-party data you connect”.

Which data is mandatory. The data marked as required at registration — first name, surname, email and password, or the Google or Microsoft account you sign in with — is essential in order to create the account, identify you and deliver the service: without it we cannot give you access. Everything else (profile picture, preferences) is optional and you may withhold it with no consequence whatsoever.

What we do NOT collect. We use no analytics, advertising or tracking tools on the public website. We do not buy or enrich data from external sources. We do not build commercial profiles. We do not ask you for special categories of data (health, political opinions, religion, sexual orientation, biometrics) and our Terms prohibit entering them deliberately without a prior agreement with us. We are aware, however, that a source you connect — a calendar holding medical appointments, a document you hand to an agent — may incidentally contain data of those categories, without either you or us having entered it: weigh that risk before connecting it and when choosing that agent’s model provider.

What we use it for

Two blocks have to be kept apart here, because our legal role differs in each and mixing them would be incorrect.

Block A — Processing where we are the CONTROLLER. These are the ones we decide on. Each has its purpose and its GDPR legal basis:

Block B — Processing where we are the PROCESSOR. These concern work content, and we do not decide on them:

In this block we invoke no legal basis of our own: we neither have one nor need one, because we do not decide on these processing activities. We act on behalf of your organization and on its documented instructions, under Article 28 GDPR; the legal basis and the duty to inform the individuals concerned are its responsibility. We do not use work content for our own purposes. Should that ever become necessary, it would require your organization’s prior authorization and would be communicated to it beforehand, as Article 28(10) GDPR requires.

Automated decisions. We make no automated decisions producing legal effects concerning you or similarly significantly affecting you, within the meaning of Article 22 GDPR, and we do not carry out profiling. Agents act on your instructions, not ours. That said, and so as not to hide behind an absolute: the platform does apply operational spend-control automation — when a consumption cap is reached, execution stops automatically, and anomalous consumption may temporarily suspend the service. These are contractual, reversible measures that do not evaluate personal aspects of you; you can ask for them to be reviewed and lifted by writing to empresa@hutrit.com.

Transparency about AI-generated content. Agents produce synthetic text — answers, summaries, drafts and messages. An agent sends email to third parties in your name, and that text also leaves through any other channel you connect. Whoever receives it will have no way of knowing an AI wrote it, obvious though that is inside the dashboard. The platform today embeds no automatic machine-readable marking identifying that content as AI-generated, and we would rather tell you than let you assume otherwise. The transparency obligations of Regulation (EU) 2024/1689 (the AI Act) on artificially generated content apply on their own timetable and with an allocation of roles that depends on how you use the platform; the Terms of Service set out what falls to you while that marking does not exist.

Third-party data you connect

The platform can connect to applications you already use so that your agents can work with them. Nothing connects by itself: a connection only exists if you sign in to the provider and expressly approve the scope shown to you.

Planned connection categories and what they are used for:

• Basic identity — when you sign in to the platform with your Google or Microsoft account we obtain your name and your email, to register you or recognize you. Connecting an application is different, and we receive less: we only request that account’s stable identifier, so neither your name nor your email reaches us — which is why the card of a connected application cannot tell you which account it is. None of this is used for advertising or to profile you.
• Email — sending on your behalf only the messages you ask to be sent. We do not request read access to your mailbox.
• Files and documents, including spreadsheets — opening the documents you select and saving the results the agent produces.
• Calendar — checking your availability and creating or modifying the events you ask for.
• Notes and tasks — reading the content you authorize and writing to it when you ask.
• Messaging — receiving instructions and sending replies over the channel you connect.

How we do it, specifically:

• Broad permissions, narrow use. Some of the permissions these providers grant are, by their own design, broader than the specific task you give the agent: the calendar read permission, for instance, reaches all your calendars and all their events, not just the day you are asking about. We show you the real scope of each one under “Limited Use of Google Data” instead of describing them as if they were minimal.
• We never see your password. Authorization happens on the provider’s own site; what reaches us is an access credential, not your password.
• Access happens only on your instruction. The agent reads or writes when it performs a task you have requested or scheduled, and within the granted scope.
• We do not copy your account. We make no replicas or bulk dumps of the connected application’s content; only what the task needs is accessed. What the agent produces (a summary, for instance) is kept in your workspace, because it is your work product, and is retained like the rest of your work content.

How to revoke it and what happens next. You can withdraw a connection at any time from the platform, and also from your account with the provider itself. When you revoke it from the platform, the connection is revoked immediately and we delete the associated credential from the store; should that deletion fail, the connection stays revoked all the same and is never used again. With one precondition we would rather state: if the credential store happens to be unavailable at that moment, the request fails entirely and nothing is revoked — we return an error rather than let you believe it was revoked; try again or write to us. That is the reliable route, and it is worth using before closing your account (see “Where data is stored and for how long”). Content already saved in your workspace (a generated file, for example) stays there until you delete it or the account is deleted; you can ask us to delete it at any time.

Limited Use of Google Data

When you sign in with your Google account, and when you connect a Google application to an agent, the processing of information obtained through Google APIs is governed, in addition to this policy, by Google’s official Limited Use declaration, which we reproduce verbatim:

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

Which permissions we request, what each one actually allows and what we use it for. Two clarifications before the table:

• When you sign in with Google, the only thing you are asked for is your identity. Google Workspace permissions are only requested if you connect the corresponding application, never on sign-in.
• Google’s consent screen is the exact source. What it shows you is the complete list of what is being requested at that moment: if a permission appears that this table does not declare, do not accept it and write to us.

The permissions in the first row are requested today, if you choose to sign in with Google. The rest are requested when you connect a specific application to an agent, at the moment you authorize it.

Two clarifications, instead of the usual “we request the bare minimum” formula:

• We request no restricted permission at all, and that is a deliberate decision. Google classifies as restricted the permissions to read the whole mailbox (gmail.readonly) and the whole Drive (drive.readonly). We do not request them: from your mail we ask only to send, and from your files only those you select. We give up features we could otherwise offer — the agent cannot search, read or summarize your mailbox — in exchange for the platform never holding technical access to all your mail or all your drive.
• Some permissions include more than we need. calendar.events already includes reading events, so there is no need to ask for an additional calendar read-only permission. drive.file, by contrast, is the narrowest permission there is for working with documents, because what it reaches is decided by you, file by file.

What really limits these permissions is not their name, but the commitments we make below, your decision about which connections to authorize, and your ability to revoke them at any time.

Commitments we make regarding Google data, in line with the Limited Use requirements:

1. Use restricted to user-facing features. Data received from Google APIs is used exclusively to provide or improve platform features that you see and use, and that you have expressly enabled.

2. We do not sell or transfer it. We do not sell, disclose or transfer Google data to third parties, except in the four cases Google’s own policy allows, and on the same terms: (a) to provide or improve platform features that are visible and prominent in its user interface, to the providers strictly necessary to carry out the operation you requested — among them the model provider you yourself configure for that agent — bound by equivalent confidentiality obligations and only with your consent. Which model provider that is, you decide, and what that means is explained right below these commitments; (b) for security purposes, for example to investigate abuse; (c) where required by law; or (d) as part of a merger, acquisition or sale of assets, after obtaining your explicit prior consent. Outside those four cases, we do not transfer.

3. We do not use it for advertising. Not for serving ads, not for targeting, not for personalized, retargeted or interest-based advertising. We do not run advertising at all.

4. We do not use it to develop, improve or train AI models. In the exact wording Google asks for, and without conditions:

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

   And here is what lets us say that without qualification: we have no models. We develop none, we train none and we have none to improve. Nor do we hand that content to anyone for training purposes, or aggregate, anonymize or derive it for that end. The only thing we do with it is what you asked us to do: pass it, in order to answer that specific request, to the model provider you configured for that agent. What that provider does with what it receives is determined by their terms, not ours, and that is why the next point is written with names.

5. No human reads it. No member of our team reads content obtained from Google, except (a) where you give explicit consent for specific messages, (b) where it is strictly necessary for security purposes — for example, investigating abuse — (c) where required by law, or (d) where the data has been aggregated and anonymized for internal operations.

You choose the model provider — and here is what that means. We put it here, next to the commitments, because it is the decision that weighs most on where your Google data travels:

• The platform does not choose for you. The model provider is a mandatory field: no agent is created without one, the server rejects the request if it is missing, and none is preselected in any sign-up — you have to choose it before you can continue. It is recorded, you see it in the dashboard and you can change it afterwards, agent by agent.
• Which ones contractually guarantee no training, by name. As of this document there are two: Google Vertex — Google’s enterprise AI service, which we contract ourselves; in the dashboard, “Google Vertex”, not “Google Gemini” — and Anthropic (Claude models), under its commercial API terms. OpenRouter does not offer it: it is an aggregator, it does not run the model but routes your request on to third-party providers, and its own terms warn that some of those models may store and train on what they receive. For the rest of the catalogue, what they do with your content is set by their terms and by the plan you hold with them, not by ours.
• On an agent with a Google application connected, that freedom has a limit, and it is contractual. Choosing a provider is free in general; but if you have connected a Google application to that agent, our Terms of Service require you to configure it with one of the two providers offering the guarantee — Vertex or Anthropic — as a condition of use of that connection. Routing that content to a provider without the guarantee is not an option we offer you: it is a breach of the Terms, and we may suspend that connection under their “Suspension and termination” section.
• And we are not going to dress up the other half: there is no technical block. The platform does not check that combination, and we are not going to imply that it does. If you breach that obligation, the content that agent sends to the model — including content coming from that Google application — may end up with a provider that stores it or trains on it. We supply the information and the tool; that decision is one you answer for.
• And the alternative asks nothing in return. Vertex is the only provider in the catalogue that needs no key or account of yours: we contract it and we pay for it, within the usage limits we apply. Staying on the no-training path does not require you to sign up for anything.

Which Google data can reach a model and which cannot. Not every scope in the table moves content in that direction, and the difference matters:

• Nothing reaches a model from Gmail. The scope we request is gmail.send, which only sends. We do not read, search or list your mailbox, so the content of your email never reaches any model: what travels is the text you ask to send, and it goes the other way, from the platform to Gmail.
• From Calendar, Drive, Sheets and Docs it can. calendar.events includes reading your events, and drive.file — the same scope shared by Drive, Sheets and Docs — reaches the files you select and those the application itself creates. If you ask the agent to work on one of them, that content goes to the model provider you configured: it is the only way the agent can work with it.
• Nothing reaches a model from your identity. openid, email and profile serve to recognize your account at sign-in; they are not sent to any model.
• Google Analytics, once that application is available, will behave like Calendar and Drive: the reports you ask for would travel to the model provider configured for that agent.

When you revoke the connection from the platform, we mark it as revoked — it can no longer be used from that moment — and we delete the associated credential from the secret store; should that deletion fail, the connection stays revoked all the same and is never used again. That is the reliable way to withdraw an agent’s access. We also recommend withdrawing the permission from your own Google account at myaccount.google.com/permissions: it is the only way to invalidate it at source, and it is worth doing before you close your platform account, for the reasons explained under “Where data is stored and for how long”.

Who we share data with

We do not sell personal data. Ever. We do not disclose it for advertising purposes and we do not trade it with anyone for commercial gain.

We share data only with those necessary to deliver the service to you, and only what is necessary:

1. AI model providers. This is the most significant category and we want you to understand it properly. For an agent to answer, the platform sends the model provider you configured for that agent the content needed to generate the response: your instruction, the conversation context and, if the task requires it, the content of the files or connected applications you asked it to work on. The provider returns the response.

The platform is deliberately open: you can choose from a broad catalogue of providers, including OpenRouter, Anthropic (Claude), OpenAI, Google (Gemini models), DeepSeek, xAI (Grok), Mistral, Groq, NVIDIA, Hugging Face, Alibaba (Qwen), Moonshot (Kimi), MiniMax, z.ai (GLM) and others. The full, current list is shown in the platform itself when you configure each agent, and that is where you choose.

And here an exact name is needed, not “Google”. The platform catalogue holds four Google entries and they are not the same thing: two are called “Google Gemini” and run on a key you supply; the other two are Vertex — “Google Vertex” / “Google Vertex (Gemini)” — and are the only ones we contract ourselves, with no key of yours. Whenever these documents say we contract Google, we mean Vertex, and only Vertex. Choosing the option labelled “Google Gemini” does NOT put you on the provider we contract: it puts you on your own Google account, whose free tier may indeed use content to improve its products.

The legal role of these providers, without ambiguity. There is one provider we contract ourselves — Vertex — and all the others, which run on an account and a key you supply. The distinction matters, because it changes whose contract it is:

• Google, in its enterprise AI service — that is, Vertex (in the dashboard, “Google Vertex” or “Google Vertex (Gemini)”; not the option labelled “Google Gemini”, which runs on a key of yours). We contract it: it acts as a sub-processor and we require the Article 28 GDPR guarantees of it.
• OpenRouter — and this point is worth reading in full, because whose account it is is not always the same. Today, when you pick OpenRouter while creating an agent, the platform stores and uses the key you supply: the account is yours, the contract with OpenRouter is yours and that data exit is one you decide. There are two cases in which the key is ours: older agents, created back when the provider was not yet a mandatory field and which therefore have none recorded; and agents that an administrator of your organization has expressly put on the platform’s shared key — only an administrator can do that, and it is their decision. In those two cases the account, the contract and the transfer are ours (it is explained under “Where data is stored and for how long”), OpenRouter does not bill you because the account is not yours, and in exchange that consumption counts against the limits we apply. Whoever’s account it is, one thing does not change:
  • OpenRouter is an aggregator, not a provider with a contractual no-training guarantee, and its own terms warn that some of the models it routes to may store and train on what they receive (detailed under “Use of your data in AI models”). If your content must not reach a model like that, configure that agent with Vertex or with Anthropic, the two providers with a no-training guarantee as of this document.
  • And if the account is yours, the setting that decides which models it routes to is under your control, not ours: it is in your OpenRouter dashboard.
• Every other provider in the catalogue — including providers established outside the EEA — necessarily runs on an account and a key that you supply: in those cases the contract is between you and that provider, its role and its obligations are set by that contract and not by ours, and we merely direct the request to the account you configured.

Three consequences you should know before choosing:

• The provider you choose receives your content. There is no way for a model to answer without receiving the question.
• Each provider has its own terms and its own privacy policy. Ours do not replace theirs. Read them before sending sensitive information.
• Some providers in the catalogue operate outside the European Economic Area, including countries without a European Commission adequacy decision (for example, providers with infrastructure in China). Choosing one of them entails an international transfer that your organization decides on, and whose legal cover is explained under “Where data is stored and for how long”.

2. MCP servers and tools. Unlike application connections, this feature is in service today. It is worth being exact about who authorises what, because these are two steps and not the same person takes them: the catalogue and the enabling of an MCP server for your organization are administered by us, at your organization’s request — your organization’s administration can ask for it, not switch it on. Once enabled, who decides which agents use it is an administrator of your organization or the agent’s owner, each over their own. When an agent uses it, that server receives the data the operation requires — your request and the necessary context — and may in turn query its own provider’s systems. We say it plainly, because it is the part that matters: it is a real flow of content out to a third party.

On who decides which servers exist there are two routes, and they do not carry the same control. We would rather separate them than sum them up as a “closed catalogue”, which would not be accurate:

• The catalogue you install from is maintained by us. Adding, editing or withdrawing a catalogue entry is reserved to our platform administration; your organization’s administration cannot do it.
• Anyone holding the maintenance role inside your own organization can also register a server of their own. That registration does not go through the catalogue review, and is confined to your organization: no other one sees it or uses it. It does mean, though, that the decision about which third party content flows to can also be taken by someone on your team, not only by us. The Terms of Service place responsibility for that risk on whoever administers the account, since they are the one who hands out roles.

And two clarifications we would rather make before you ask, because they point in opposite directions and both are true:

• What we do control. Our intermediary service only talks to the servers explicitly authorised in its configuration, and closes down when they are not: it rejects IP addresses in any form, rejects local destinations and rejects any host absent from that list. If the check does not pass, the request never leaves.
• What we do not control. The list of destinations a server declares is review information, not a technical network restriction. It helps us decide whether to admit an entry into the catalogue; it does not amount to a firewall stopping an MCP server, once running, from connecting on its own to a destination other than the one it declared.

3. Applications you connect. They receive the requests the agent makes on your behalf, within the granted scope (see “Third-party data you connect”).

4. Technology infrastructure providers hosting the platform and its backups, and ancillary service providers (transactional email, support and, if we ever bill, billing). All act as processors under an Article 28 GDPR agreement, are bound by confidentiality and security measures, and may only process data on our instructions.

5. Authorities and advisers, where there is a legal obligation, a valid request from a competent authority, or where it is necessary to bring or defend legal claims.

6. In a corporate transaction (merger, acquisition or sale of assets), the acquirer, with prior notice to you and maintaining the guarantees in this policy. Data obtained from Google APIs would only be transferred in that scenario with your explicit consent.

Use of your data in AI models

This is the section that matters most, so we write it without ambiguity, even where the honest answer is less comfortable than an absolute headline.

What we can guarantee unconditionally:

• We do not train models. Martinuka2220, S.L. neither develops nor trains artificial intelligence models. Your content — conversations, files, instructions, data from connected applications — is never used to train, fine-tune or improve any model of ours, quite simply because there are none. For content arriving from the Google APIs this is also stated in the literal wording Google requires, under Limited Use of Google Data.
• We do not hand your content to anyone to train on it. We do not sell or supply datasets, and we do not give third parties access to your content for model training, research or development purposes.
• What is sent is what is needed to answer, not your account. The model provider receives the content strictly required to handle the specific instruction: your instruction, the context of that same conversation needed to maintain continuity and, where the task requires it, the content of the files or applications you ask it to work on. Your full account is never sent, nor the history of your other conversations.

The credential filter: what it does and how far it reaches. This sentence used to sit inside the list above, and that was the wrong place, because it is not a guarantee and its own code says so. We would rather explain it in full than keep the short version:

• What it does. The platform runs a filter over the block that reminds an agent what was already said in the conversation, and over each thread’s context note. That filter recognises common shapes of key or credential and replaces them before the text leaves.
• Why it is not a guarantee. It recognises known shapes; a credential with an unusual shape gets through. It is designed as a reinforcing layer, not as the control that stops a secret from leaving.
• What it does not cover. It does not apply to the message you have just written, nor to the persistent context you pin to an agent, nor to a project’s, nor to the instructions with which you configure a sub-agent.
• And there is one case you should know about, because it is today’s. The agents currently in service keep their own conversation memory, so the recall block — the only one that is filtered — is never even assembled for them.

What follows from all of that, put as a request rather than as small print: do not write credentials into the chat, and do not leave them written in an agent’s context. If an agent needs a key in order to work, store it as a credential in the platform — that is what the secret store described under “How we protect it” is for — instead of pasting it into a message.

What is not a guarantee of ours but an obligation of yours — and why we say so rather than keep quiet about it:

• With a Google application connected, which provider is admissible is determined. Our Terms of Service require you to route content obtained from the Google APIs only to providers with a contractual no-training guarantee — today, Vertex or Anthropic — as a condition of use of that connection. Routing it elsewhere is a breach of the Terms, not an alternative we offer you, and we may suspend that connection under their “Suspension and termination” section.
• There is no technical block, and we are not going to imply there is. The platform does not check that combination: it is an obligation you comply with, and we present it that way — rather than as an automatic behaviour of the system — because that is exactly what it is. If you breach it, that content may end up in a model that stores it or trains on it, and that is something you answer for.

What depends on the provider you choose — and why we cannot promise it on their behalf:

Your content has to reach the model provider you configured for the agent to be able to answer. What that provider does with what it receives is determined by their terms, not ours. And they do not all say the same thing:

• Providers with a contractual no-training guarantee. Some providers’ commercial API terms commit to not using customer-submitted content to train or improve their models. Today that is the case for Anthropic (Claude models) and for Google in its enterprise AI service, Vertex (Gemini models contracted by us for the platform; in the dashboard, “Google Vertex”, not “Google Gemini”). If you need a no-training guarantee, configure your agents with one of these providers; and if you connect Google applications, the Terms require you to.
• Model aggregators. Services such as OpenRouter do not run the model: they route your request on to third-party providers. Their own terms warn that some of those models may store and train on what you send them, and that being able to opt out of that training depends on each model’s terms, not on the aggregator. Whether your content ends up with a provider that trains on it depends on a setting in the aggregator’s account, and the actual destination may vary from one request to the next. Here you have to be clear about whose account that is: if you picked OpenRouter when you created the agent, the account and that setting are yours; the account is ours — and the setting under our control — in older agents and in those an administrator of your organization has expressly put on the shared key, see “Who we share data with”. What is worth knowing in both cases: the aggregator’s terms state that, where possible, they have opted out of model training on the models they use, and their account settings let you switch off routing to providers that train, with separate settings for paid and free models. On the logging of your requests their terms are clear in both directions: if you turn prompt logging on you grant them a licence over that content that is perpetual, irrevocable, sublicensable and extends to their own commercial purposes, and if you do not, they state that they do not store your inputs beyond categorizing them; separately from that option, they keep a licence over anonymized inputs limited to usage metrics on their site. Even so: an aggregator is not a provider with a contractual no-training guarantee, and you must not route confidential content or third-party personal data through one.
• Your own provider account (a key you supply). The platform supports using your own credentials with every provider but one: Vertex, the only one we contract ourselves and the only one that asks you for no key. In that case the contract is between you and that provider: that account’s settings — including those about training on your data — are under your control. We cannot read them, change them or enforce them. Bear in mind that some free or developer plans from very well-known providers do use content to improve their products, while their paid or enterprise plans do not: the difference lies in the plan, not only in the brand.

What we do about that reality, instead of hiding it:

• We tell you where your content goes. Each agent’s provider and model are chosen when configuring it and can be reviewed and changed at any time from the platform.
• We turn it into a contractual obligation, not into a block. Our Terms of Service require you, if you connect Google applications or any other source holding confidential content or third-party personal data, to configure every agent you link that connection to with one of the providers with a contractual no-training guarantee named above: the authorization belongs to your account and you can link it to more than one agent, so configuring just one is not enough if you linked several. The platform neither checks nor prevents this: it is an obligation you comply with.
• Practical recommendation. To process third-party personal data or confidential information, use those providers and do not route that content through aggregators.

We would rather tell you exactly where our commitment ends and someone else’s begins than sign an absolute that does not depend on us. A commitment we cannot keep protects no one.

Prohibitions we commit to

Regardless of the legal basis available to us, we bind ourselves to the following. This list is a commitment, not a description:

• We do not sell personal data, nor rent it, nor disclose it for consideration.
• We do not use it for advertising purposes, ours or anyone else’s: no ads, no targeting, no personalized, retargeted or interest-based advertising.
• We do not build commercial or behavioural profiles unrelated to delivering the service, and we do not make automated decisions with legal effects on people.
• We do not use your content to train models of our own — we have none — nor do we hand it to anyone to train on it. What the model provider you choose does with what it receives is not up to us and we do not promise it on their behalf: the difference, provider by provider, is explained under Use of your data in AI models.
• We do not cross data between organizations. One organization’s content is never used for anything related to another, under any circumstances.
• We do not enrich your profile from external sources and we do not buy data from brokers.
• We do not put your content to any purpose other than those stated in this policy, including the narrow cases of human access and disclosure to third parties described in it: outside those cases, there is no other use. Should a new purpose arise in the future, we would tell you and, where the law requires it, ask for your consent before carrying it out.

Human access to your data

By default, nobody on our team reads your content. Access to the content of conversations, files and data from the applications you connect is restricted and may only occur in these narrow cases:

1. At your request or with your explicit consent — for instance, when you open a support ticket and authorize us to look at a specific case in order to resolve it.
2. For security — where it is strictly necessary to investigate an incident, unauthorized access, abuse of the platform or a threat to other organizations.
3. Legal obligation — to respond to a valid request from a competent authority.
4. On aggregated and anonymized data, which does not allow anyone to be identified or content to be reconstructed.

Controls we apply to such access:

• Strict minimum. Only people whose job requires it, only over what is strictly necessary and only for as long as necessary.
• Traceability. Access and administrative actions are logged with author, time, object of the action and origin of the connection.
• Confidentiality. All personnel are bound by a duty of confidentiality that survives the end of their relationship with the company.
• For Google data, the specific restriction in the Limited Use of Google Data section applies in addition.

Where data is stored and for how long

Where. The platform and its backups are hosted in the United States, in facilities of infrastructure providers acting as processors. In addition, the content you send to an AI model is processed wherever the provider you chose operates, which may be in other countries (see “Who we share data with”).

International transfers. We are established in Spain, so Chapter V GDPR applies to the transfers we make regardless of where you live: what triggers that regime is the position of whoever exports the data, not the nationality or residence of the person the data is about. In practice, the safeguards in point 1 protect you too if you are in Latin America or North America; and if your own country’s law imposes its own conditions, those apply on top of these. Two situations have to be distinguished, because their legal cover is not the same and presenting them together would be inaccurate:

1. Transfers we make ourselves — hosting, backups, ancillary services and the only model provider we contract, Google’s enterprise AI service. Here we are a party to the contract, and any exit from the European Economic Area relies on the safeguards in Chapter V GDPR: Standard Contractual Clauses approved by the European Commission (Implementing Decision 2021/914) and, where the provider is certified, the EU-US Data Privacy Framework, together with any supplementary measures identified by the transfer impact assessment. You may request a copy of the safeguards applied.
2. Transfers resulting from your organization’s choice of model provider — any other provider in the catalogue, running on an account and key you supply and therefore with no contract with us: aggregators such as OpenRouter and providers established outside the EEA, among others. (Left out are the agents that start on our OpenRouter key — the older ones and those an administrator of your organization has expressly put on the shared key, described under “Who we share data with”: that exit falls under point 1.) In that case we cannot supply Chapter V safeguards for that transfer: we are not a party to that contract. The transfer stems from an instruction of your organization, and it is your organization that must ensure it has a valid basis for it. We say so plainly so that you can decide with the right information: if you need every transfer to be covered by safeguards of ours, restrict your agents’ configuration to the model provider we contract.

For how long. We distinguish what the platform prunes on its own from what is only deleted when the account is deleted. We would rather put it that way than announce automation that does not exist:

• Access and audit logs (sign-ins, IP, administrative actions, denied attempts) — 90 days. A daily platform process prunes them automatically once that period is exceeded.
• Agent activity events — 180 days, with the same daily automatic pruning.
• Historical consumption snapshots — 365 days, with the same daily automatic pruning.
• Per-agent usage records (the tokens and cost you see in your spend dashboards) — not pruned by the passage of time: they are kept for as long as the account exists, because they are the basis of your spending history and of your limit calculations. They are deleted when the account is deleted.
• Work content — conversations, files, projects, scheduled jobs, agent outputs and any content an agent has brought in from a connected application and left in the thread — is not deleted automatically by the passage of time. It is kept for as long as the account or the organization exists, or until you delete it, and is deleted together with them.
• Account and profile data — for as long as the account exists.
• Credentials of connected applications (access and refresh tokens) — until you revoke the connection from the platform, at which point the connection is revoked and we delete the credential from the secret store; should that deletion fail, the connection stays revoked all the same and is never used again. In addition, when we carry out the deletion of an account we also manually delete its connections’ credentials from the secret store, for as long as the platform does not do so by itself. That said, and so you can act knowing where you stand: closing the account does not, by itself, revoke these credentials, and we do not notify the revocation to the provider. So if you are going to stop using the platform, revoke your connections before closing the account and also withdraw the permission from your account with the provider — for Google, at myaccount.google.com/permissions — which is the only way to invalidate it at source. And if you have already lost access — because you closed the account or your organization deactivated you — withdraw the permission on that same page and write to us at empresa@hutrit.com so that we delete the credential: you are still entitled to demand it.
• Model provider API keys you supply — for as long as you keep them configured. You can replace or delete them at any time; deleting them removes them immediately from production systems. When an account is deleted, the process itself attempts to delete these keys from the secret store automatically. It is an attempt with a safety net, not a guarantee: should that deletion fail, the account deletion still proceeds, the failure is logged and our team completes it by hand. If you stop using the platform, rotate or revoke those keys in your provider’s console: that is the only way to invalidate them at source.
• Backups — kept in cyclical rotation: the criterion is to keep the number of copies needed to restore the service after a recent incident, and no copy is kept beyond that cycle, at the end of which it is overwritten. Data deleted from production systems may therefore survive in a backup until that backup is overwritten; in the meantime it remains encrypted, protected and unused for any purpose.
• Billing and accounting records — none exist today: the service is provided free of charge and we issue no invoices for its use, so there is no accounting obligation to meet and no billing data to keep. If you contract a paid plan in the future, from that moment they will be kept for 6 years from the last entry, as required by law (Spanish Commercial Code), and 4 years for tax purposes, the longer period prevailing.
• Data needed to handle claims — for the limitation period of any legal action that may arise — as a general rule, five years for personal actions, Article 1964 of the Spanish Civil Code — blocked and available exclusively to authorities and courts.

How an account is deleted. There is no deferred automatic deletion and no self-destruct button: deleting an account, an organization and their content is a process carried out on request by our team when you or your organization ask for it, in the manner described under “Your rights, revocation and deletion”. Until then, work content is retained.

How we protect it

We describe guarantees and outcomes, not the specific technology behind them: that part is confidential information, and publishing it would weaken the protection itself.

• Encryption. Data travels encrypted in transit and is stored encrypted at rest.
• Isolation between organizations. Each organization operates in its own logical space and the system prevents, by design, one from reaching another’s content. Agents are likewise isolated from each other.
• Credentials live apart, and none is stored in the clear. Your password is stored as an irreversible hash — not encrypted, but transformed so that it cannot be recovered — and of the access token we keep only a fingerprint. The API keys and application tokens you connect are held encrypted at rest in a separate secret store, apart from the rest of the data and from the machines where agents run.
• Least privilege. Every component and every person has only the permissions they need, and nothing more.
• Hardened access. Federated sign-in with Google or Microsoft requires resolving a second authentication factor, and two-step verification is mandatory for the platform’s administration accounts. In all cases: controlled sessions and immediate credential revocation on request.
• Traceability. Relevant actions are logged so that what happened, who did it and when can be reconstructed.
• Backups taken regularly, encrypted, with the ability to recover from an incident.
• Incident handling. Should a security breach occur, we act according to our role in each case: where it affects data for which we are the controller (account, authentication, security and, where applicable, billing), we will notify the Spanish Data Protection Agency (AEPD) within 72 hours of becoming aware of it, and will inform you without undue delay where the risk to you is high; where it affects work content, for which your organization is the controller, we will notify your organization without undue delay, under Article 33(2) GDPR, so that it can meet its own duty to notify the authority and the individuals concerned.

No system is invulnerable. We commit to maintaining appropriate, up-to-date measures and to being transparent if something fails.

Your rights, revocation and deletion

The GDPR grants you the following rights over your personal data:

• Access — to know what data of yours we process and obtain a copy.
• Rectification — to correct inaccurate or incomplete data.
• Erasure (the “right to be forgotten”) — to have it deleted where it is no longer necessary, you withdraw consent, or you successfully object to the processing.
• Restriction of processing — to have us keep it but stop using it while a challenge is resolved.
• Portability — to receive the data you provided in a structured, commonly used, machine-readable format, or to have it sent directly to another controller where technically feasible.
• Objection — to object to processing based on our legitimate interest, explaining your particular situation.
• Withdrawal of consent — at any time, without affecting the lawfulness of processing carried out beforehand.
• Not to be subject to automated decisions with legal effects. As stated under “What we use it for”, we do not make them.

Your right to object, set out separately. Article 21(4) GDPR requires this right to be presented to you expressly and separately from the rest, not as one more bullet inside a list: you may object at any time, on grounds relating to your particular situation, to the processing we base on our legitimate interest — the security of the platform and improving the service from technical usage metrics. If you do, we will stop processing that data, unless we demonstrate compelling legitimate grounds which override your interests, rights and freedoms, or which are needed to establish or defend legal claims.

How to exercise them. Write to info@hutrit.com stating which right you are exercising. We may need to verify your identity before acting on the request, in order to protect your own data. We will respond within one month of receipt; if the request is particularly complex, we may extend that by two further months, telling you why within the first month. Exercising these rights is free of charge.

If you are a member of an organization, note that your organization is the controller of the work content: we may forward your request to it and act on its instructions, as Article 28 GDPR requires. We will tell you if that happens.

Revoking a connected application. You can withdraw the authorization granted to an external application at any time from the platform itself: when you do, the connection is revoked immediately and we delete the associated credential from the store; should that deletion fail, the connection stays revoked all the same. Do it before closing your account, because closure does not revoke connections by itself, and also withdraw the permission from your account with the provider — for Google, at myaccount.google.com/permissions — which is the only way to invalidate it at source. If you can no longer sign in to the platform, withdraw the permission on that page and write to us: we will delete the credential for you.

Deleting your account. Deletion is neither automatic nor deferred: it is a process carried out on request. Ask for it by writing to info@hutrit.com; before carrying it out we will offer you a copy of your content, and once confirmed we delete the account and its work content without undue delay and, in any event, within the one-month period in which we must respond to you. Excluded from that deletion, and these four things and no more:

1. data we must keep by legal obligation, which will remain blocked;
2. data needed to handle or defend claims, for the limitation period — which is not an obligation to retain, but the possibility that someone brings a claim — also blocked;
3. any residue surviving in the database backups until those drop out of the seven we keep, or in the transaction logs for their 7 days;
4. the objects that storage retains for 7 days after their deletion as a recovery margin. This is not a backup: it is storage itself holding what has already been deleted before discarding it entirely, which is why we state it separately from point 3.

What deletion covers. You ask us for one single thing — to delete your account — and that request covers everything of yours: the database records, the files in storage — your agents’ files, their previous versions and your profile picture —, your agents’ API keys and the credentials of your connected applications. You do not have to list any of those parts, nor ask for them separately, and we make none of them conditional on your claiming it: it is your right in full, not a menu to choose from. Our commitment is an outcome: when the one-month period stated above expires, none of that remains in our systems, save for what the law requires us to keep blocked and the residue that survives in the backups.

And now how that outcome is reached, because not all of it runs on the same mechanism and we think you are entitled to know where our promise rests on code and where it rests on people:

• What the system does on its own. It deletes from the database your account data and all your work content — conversations, projects, scheduled tasks, missions and the index of your files.
• What the system attempts, without guaranteeing it. Two things: removing your agents’ API keys from the secret store, and tearing down the services they were running on. Both are attempts with a safety net: should either fail, the deletion of your account proceeds anyway and the failure is noted in our technical logs, with no automatic retry.
• What the system does NOT do today. It does not delete the files in storage nor the credentials of your connected applications: the automatic process does not reach them. They are part of what we complete when we handle your request, within that same one-month period. We would rather tell you than describe an automation that does not exist.

Once all of that is done, storage still retains the deleted objects for 7 days as its recovery margin, like any other file you delete (see “Where data is stored and for how long”).

One warning we would rather give you before than after: deleting your account communicates nothing to the provider of an application you have connected. So revoke your connections before asking for it, and also withdraw the permission from your own account with the provider — for Google, at myaccount.google.com/permissions — which is the only way to invalidate it at source.

Complaint to the supervisory authority. If you believe we have not handled your request properly or that we are processing your data improperly, you can lodge a complaint with the Spanish Data Protection Agency (AEPD), C/ Jorge Juan 6, 28001 Madrid — www.aepd.es, which is our country’s supervisory authority. You are not obliged to go to it: Article 77 GDPR lets you complain to the supervisory authority of the Member State where you reside, where you work, or where the alleged infringement took place. And if you are outside the European Economic Area, you may also approach your own country’s data protection authority, where one exists. We would appreciate the chance to resolve it with you first, but it is your right and you may exercise it directly.

Cookies and similar technologies

Let us be specific, because this is an area where vague language is widely abused:

The public website mision1m.com uses no cookies. No analytics, no tracking pixels, no advertising, no third-party cookies. We do not know who visits us and we do not try to find out.

The only thing this website stores in your browser is a local preference (m1m-lang-suggestion-dismissed), created only if you dismiss the notice suggesting you read the page in another language. Its purpose is to avoid showing it again. It identifies nobody, it never travels to any server, and you can delete it from your browser. Being a preference you set through an express action of your own, it does not require prior consent.

The platform dashboard uses strictly necessary cookies, and here they are with their name and their lifetime, which is what has to be declared:

• m1m_session — keeps your identity authenticated as you browse and protects the session from misuse. Without it, signing in is not possible. It lasts 7 days and persists even if you close the browser: it is not a “session” cookie in the strict sense, and we would rather say so than use that label as a catch-all. It is removed when you sign out or when it expires.
• m1m_active_org — remembers which organization you are working in when you belong to several. It also lasts 7 days, and is not removed when you sign out: it stays until it expires or until you clear it from your browser. It grants no access on its own — access is always decided by the session — but it is another cookie and it was undeclared.

Both are technical, necessary cookies, exempt from the prior consent requirement under Article 22.2 of the Spanish LSSI.

The dashboard also stores things in your browser’s local storage, which are not cookies but are worth declaring because some of them contain content of yours: the draft message you are writing and have not sent, the context notes you pin to a conversation, and interface preferences (theme, selected agent, sidebar state, office-view layout, last notice read). If you sign in with Google or Microsoft, that provider’s identity component additionally stores in your browser the token that keeps the session open. All of that lives on your device, not on our servers, and you can clear it from your browser; the draft and the context notes go with it.

We use no analytics, profiling or advertising cookies, whether ours or third parties’. Should we ever do so, we would ask you first through a consent mechanism and update this section.

You can configure your browser to block or delete cookies and local storage. If you block technical cookies, you will not be able to sign in to the dashboard.

Minors and changes to this policy

Minors. M1M is a service intended exclusively for people over 18. It is designed for professional or business use, although whoever uses it may qualify as a consumer and then keeps the rights the law grants them, as explained in the Terms of Service. It is not directed at minors, we do not knowingly collect minors’ data, and access is restricted to accounts authorized by an organization. If we find that an account has been created by a minor, we will delete it together with its data. If you believe a minor has provided us with data, write to empresa@hutrit.com and we will act immediately.

Changes to this policy. We may update this policy to reflect changes in the service, in the providers involved or in applicable law. The date of the last update appears at the top of the document.

• If the change is material — a new purpose, a new category of recipients or a change to retention periods, for example — we will notify you by email or through the platform at least 30 days before it takes effect.
• If the change is minor — wording corrections, clarifications, contact updates — we will publish the new version and update the date.
• Where a change requires your consent, we will ask for it expressly before applying it. Continuing to use the platform after a change that does not require consent takes effect means you accept the version in force.

Previous versions. Announcing a change is only useful if you can check what it consists of, so: we keep the previous versions of this document and, if you need to know what it said on a given date or what has changed since the previous one, ask us and we will provide it. The advance notice of a material change will state what changes, not merely that a new version exists.

This policy is available in Spanish and English. In the event of any discrepancy between the two versions, the Spanish version prevails.