Privacy Policy
In force since 19 September 2026.
The short version
- We are IUVIA Technologies, S.L., a Spanish company. Alcarta is our product.
- This website sets no cookie and runs no analytics. Nothing about you is collected by reading it.
- If you join the waiting list, we hold your email address, and only because you asked us to. One link in every message takes you off it.
- Alcarta connects to mailboxes that belong to somebody else. It does not store the mail. No message body, no attachment, no recipient address is ever written to our database. What it stores is described in section 6, line by line, and the list is short on purpose.
- We never sell your data, and we run no advertising of any kind.
This summary is here to be read. It is not the policy — the sections below are — but nothing in them contradicts it.
1. Who we are
IUVIA Technologies, S.L. ("IUVIA", "we", "us"), the company behind Alcarta.
| Tax number (NIF) | B16913006 |
| Registered office | Lugar Cabezares, 5, 27614 |
| Commercial registry | T 545, F 190, S 8, H LU 20807, I/A 1 |
| privacy@iuvia.io |
For anything in this policy, write to privacy@iuvia.io.
2. What this policy covers
It covers three different situations, and they are not the same:
- Reading this website. Section 4.
- Joining the waiting list. Section 5.
- Using the hosted Alcarta service, when it opens. Sections 6 and 7.
It does not cover the self-hosted software. If you run Alcarta on your own machines, your data never reaches us. We have no access to it, we receive no telemetry from it, and we are not involved in it in any way.
3. The two roles we can be in
Data protection law distinguishes between deciding why data is processed and merely handling it for somebody else who decided.
- For your account with us — your name, your email address, your sign-ins, your invoices — we decide, so we are the controller.
- For the mail that Alcarta reaches on your behalf, you decide. You choose the mailbox, you grant the access, you set the rules. We are the processor, and we act on your instructions. The terms governing that are in Annex A of our Terms of Service, which forms the data processing agreement required by Article 28 GDPR.
This distinction matters when you want something deleted. See section 10.
4. This website
The page you are reading is a static file. It sets no cookie, loads no analytics, and contains no tracking pixel, no advertising tag and no social widget. The only request it makes to anyone else is the one that carries your email address to our mailing provider, and that happens only when you submit the form yourself.
Serving the page means your device connects to our host, Cloudflare, which processes your IP address, the time of the request and your browser's user-agent string in order to deliver the page and to defend it against attack. Cloudflare acts as our processor. The lawful basis is our legitimate interest in running a website that works and is not trivially knocked over (Article 6(1)(f) GDPR).
If we ever add analytics, we will say so here before switching them on, and we will ask for your consent where the law requires it.
5. The waiting list
What we hold. Your email address, the fact that you ticked the consent box, and the date, time and IP address of the moment you ticked it. That last part is not curiosity: it is the evidence that your consent was given, which we are required to be able to show.
Why. To send you one message when the hosted service opens, and occasional messages about the product. That is all. We do not use the list for anything else and we do not share it.
Lawful basis. Your consent, under Article 6(1)(a) GDPR. You gave it by ticking the box; nothing was collected before that.
Taking it back. Every message we send carries an unsubscribe link, and it works immediately. You can also write to privacy@iuvia.io and ask. Withdrawing consent is free, needs no reason, and does not make anything we did beforehand unlawful.
How long. Until you unsubscribe, or until 24 months pass without the hosted service opening, whichever comes first. After you unsubscribe we keep a minimal record that you were on the list and that you left it, because without it we cannot prove we stopped when you asked.
Who else handles it. Brevo, run by Sendinblue SAS in France, sends the mail for us and stores the list. They are our processor, they are in the EU, and they act only on our instructions.
6. The hosted service: your account
When the hosted service opens and you create an account, we hold:
| What | Why |
|---|---|
| Name and email address | To identify you, to reach you about the service, and to send you the sign-up, verification and password-reset messages |
| Your password, hashed with Argon2id | So we can check it without ever knowing it. We cannot read your password and cannot recover it |
| Two-factor secret, if you turn it on | Encrypted at rest, like every other secret we hold |
| Organisation membership and role | To decide what you are allowed to do |
| Sessions: IP address, user-agent, last seen | So you can see where you are signed in and sign other devices out, and so we can spot an intrusion |
| API tokens | We store a digest, never the token. A token is shown once, when it is created, and never again |
| Billing details, if and when there is billing | To invoice you, and because Spanish tax and commercial law requires us to keep the records |
Lawful basis. Performing our contract with you (Article 6(1)(b)) for everything needed to run the service; a legal obligation (Article 6(1)(c)) for invoices and accounting records; and our legitimate interest in keeping the service secure (Article 6(1)(f)) for the sign-in and audit records.
7. The hosted service: your mail
This is the section worth reading closely, because it is where a mail gateway would normally be at its worst.
7.1 What Alcarta never stores
There is no table for any of the following, and no column anywhere holds them:
| Never stored | Where it stays |
|---|---|
| Message bodies, text or HTML | On your provider. Fetched live each time they are needed, passed straight through, never written to our database, never written to disk, never logged |
| Attachments, and the names of attachments | On your provider. An approval screen lists a name, a size and a type, fetched at the moment the page is drawn |
From, To, Cc, Bcc, Subject and Date of ordinary messages | On your provider |
| Flags, labels and thread structure | On your provider |
| Folder contents, message counts and synchronisation state | Nowhere. There is no sync engine, which is exactly why an idle mailbox costs us nothing |
| Search indexes of your mail | Nowhere. We do not build one |
| The plaintext of any mailbox password or token | Nowhere. It exists only in memory while a connection is open, and is wiped afterwards |
7.2 What Alcarta does store
| What | Detail |
|---|---|
| Mailbox connection credentials | Encrypted with AES-256-GCM under a key of their own, which is itself wrapped by a master key held in a file on the server. The encryption is bound to the row and to your organisation, so a row moved anywhere else simply fails to decrypt. No route, no page, no log and no error message ever gives a credential back — not even to you |
| Message handles | An opaque pointer that names where a message sits, signed so it cannot be forged. It reveals nothing about what the message says |
| Draft tracking rows | Where the draft is, a SHA-256 of its body and of its headers, the number of recipients, the number of attachments, the size, and the subject line |
| Approval requests | The action an agent asked for, a pointer to the message, the hashes above, and the agent's own free-text explanation of why it is asking (at most 1000 characters) |
| Audit records | One row for every action: who, what, when, against which mailbox, the outcome, your IP address and user-agent, and a redacted summary of the arguments. Never content. The log is append-only and hash-chained, so a row cannot be altered or removed without breaking the chain |
| Webhook payloads, if you configure a webhook | See 7.4 |
On the subject line. It is the one piece of message content we store, and we would rather not. It is there because a list of approvals that says only "approve this send" is useless to the person deciding, and re-fetching fifty subjects to draw one page would mean fifty round trips to your provider. It is a single short header, it expires with the row after seven days, and it is stripped out of error messages. A deployment that wants even this gone can switch it off, and the screen then reads (subject hidden).
On the hashes. A SHA-256 is 32 bytes and cannot be turned back into a message. They exist for one reason: when you approve a message, we record what you approved, and if a single character changes afterwards the send is refused. That is the safety property the whole product is built around.
7.3 What an agent writes
The free-text reason on an approval request is written by an AI agent, not by us. An agent could in principle paste part of a message into it. We treat that text as untrusted: it is escaped before it is displayed, it is left out of webhook payloads by default, and it is deleted with the request.
7.4 The one exception, stated plainly
If you configure a webhook so that another system is told when an approval is requested, the payload we queue can include the envelope of the message — sender, subject and date — so the receiving system can show a person something meaningful. That payload is frozen when it is queued and kept for up to 7 days, or up to 30 days if delivery failed and it went to the dead-letter queue.
This is the only place where anything drawn from a message outlives the request that produced it. It happens only for webhooks an administrator of your organisation set up, it can be reduced to identifiers alone with a single setting, and the retention can be lowered to one hour. No message body is ever included, at any setting.
8. How long we keep things
| Data | Kept for |
|---|---|
| Waiting-list address | Until you unsubscribe, or 24 months |
| Pending approval requests | 24 hours by default, then they expire (adjustable from 1 minute to 30 days) |
| Finished approval requests | 30 days |
| Draft tracking rows | 7 days since they were last touched, then 7 more days |
| Sessions | 30 days at most, or 12 hours idle, then one more day |
| API tokens | Until they expire — every token has an expiry, there is no permanent one — then 90 days |
| Audit records | 365 days by default, adjustable by your organisation between 90 days and 10 years |
| Webhook payloads | 7 days delivered, 30 days dead-lettered |
| Sign-up, verification and password-reset links | 7 days past use or expiry |
| Accounting and invoicing records | As long as Spanish tax and commercial law requires, which is longer than any period above |
Deletion is real deletion. The rows are removed, not flagged.
9. Who else is involved
We use a small number of providers. Each one acts on our instructions and none of them may use your data for their own purposes.
| Provider | What they do | Where |
|---|---|---|
| Brevo (Sendinblue SAS) | Sends our mail and holds the waiting list | France |
| Cloudflare | Serves this website, and stores encrypted backups | EU, with the reservations in section 11 |
| IUVIA Technologies, SL | Runs the hosted service | Spain |
Your own mail provider is not in this table, because it is not ours. You choose it, you already have a relationship with it, and Alcarta connects to it because you told it to. What that provider does with your mail is between you and them.
We also disclose data where a court or a competent authority lawfully requires it. If that happens and we are permitted to tell you, we will.
We do not sell personal data. We have never done so and the business does not depend on it.
10. Your rights
You can ask us to:
- give you a copy of the personal data we hold about you;
- correct it if it is wrong;
- delete it ("the right to be forgotten");
- restrict what we do with it, or object to it;
- hand it over in a portable format, or send it to somebody else;
- withdraw your consent, at any time, where consent is what we relied on.
Write to privacy@iuvia.io. We answer within one month. If the request is complicated we may take two months more, and we will tell you within the first month if that happens. We do not charge for this.
One thing to know about mail data. For the mail Alcarta reaches, the controller is the customer whose mailbox it is, not us. If you are an end user and you ask us to erase something there, we will pass your request to that customer and help them carry it out, because the decision is theirs to make and not ours.
Erasure of an organisation. When a customer asks for their organisation to be erased, we run a purge that deletes every row belonging to it in order, overwrites the stored credentials with random bytes before deleting them, and removes the audit log last. It is thorough and it is not reversible.
If you are unhappy with us, please tell us first — most things are a misunderstanding we can fix. You also have the right to complain to the Spanish data protection authority, the Agencia Española de Protección de Datos (C/ Jorge Juan 6, 28001 Madrid, www.aepd.es), or to the supervisory authority where you live.
11. Sending data outside the EU
Our providers are in the EU or the EEA, and the hosted service runs in Spain.
Cloudflare is a global network and a request may be served from a location outside the EEA. Where that happens, the transfer is covered by the European Commission's Standard Contractual Clauses together with Cloudflare's data processing addendum. We have chosen the settings that keep processing in the EU where the product offers that choice.
12. How we protect it
Some of this is unusual enough to be worth writing down:
- Every mailbox credential is encrypted with its own key and its own nonce, so one key can never be reused, and the encryption is bound to the row and the organisation that owns it.
- Master keys are read from files with 0600 permissions on the server. They are never in an environment variable and never in the database.
- Passwords are hashed with Argon2id. We cannot read them.
- Nothing secret ever reaches a log line, an error message, a debug output or a template. This is enforced by a test that checks every secret-bearing type at once, so a new one that forgets will fail the build rather than leak quietly.
- The audit log is append-only and hash-chained. There is no code path in the system that can update or delete an audit row.
- Every request is authorised against the database rather than against the token alone, so removing somebody's access takes effect in well under a second, not whenever their token happens to expire.
- Connections to mail providers always validate certificates, and the address a connection is made to is the address that was checked.
No system is perfectly secure and we will not pretend otherwise. If a breach happens that is likely to put your rights at risk, we will notify the AEPD within 72 hours and tell you directly where the law requires it.
13. Automated decisions
We make no automated decision that produces a legal effect on you or similarly significantly affects you.
This is worth stating because Alcarta exists to make it true. An AI agent can only ask. It cannot send, delete or move anything on its own; a named person approves each one, and the record of who approved what is kept. The product is designed so that the consequential decision is never the machine's.
14. Children
Alcarta is for professional use and is not offered to anyone under 18. We do not knowingly collect data about children. If you believe we have, write to privacy@iuvia.io and we will delete it.
15. Changes
We will update this page when the service changes, and the date at the top will change with it. If a change materially affects your rights, we will tell the people it affects directly rather than relying on you to re-read the page.
16. Contact
privacy@iuvia.io, or by post to IUVIA Technologies, S.L., Lugar Cabezares, 5, 27614.