Personal Data Processing Notice (Art. 13 GDPR)

Dear user,

vault-radar builds and maintains the context of your work — who the people that matter are, what they were promised, which commitments were made — from what you write or connect. The radar that surfaces misalignments between what you state and what is observed in your communications is one of the functions that come from that context, not the point of the system. We provide you with the information required by art. 13 of Regulation EU 2016/679 (GDPR).

1. Data Controller

Ai’m of Sandro Vespucci, VAT no. 05494790750. Contact: privacy@vault-radar.it.

2. What we analyse

Only what you write or explicitly connect:

The entries you write in the diary within this application, and the files you attach in chat or upload to the application.
The sources you connect from Settings, each with your explicit authorisation, revocable at any time, and only when active in your workspace: your mailbox (Gmail or Microsoft 365 / Outlook — read-only, never send, and never the entire mailbox: only the emails to and from a contact, that is the people on your cards; of those from the last 30 days we keep the essential data without the text, for the contacts you choose to watch we also keep the full email, with no expiry, and we read the text of the others only at your request: see points 14 and 15), Google Drive and SharePoint (limited to the folders you choose), Google Calendar (your primary calendar only, read-only: see point 12), WhatsApp (messages received on the number you connect), LinkedIn (the export of your contacts that you upload).
Writes made by external AI assistants that you yourself authorise through the application's connector (diary entries, memories, contact-card updates): every write is recorded with its provenance and can be reviewed.

We do not analyse auto-replies, unreadable attachments, or emails marked as SPAM.

3. AI models used

Anthropic Claude Sonnet 5.5 — the assistant of the application's chat.
Anthropic Claude Haiku 4.5 — fast classification of every ingested element (is it a potential misalignment signal?), extractions, the automatic summary of chat conversations and the summary of the emails exchanged with a contact.
Anthropic Claude Sonnet 4.5 and Claude Sonnet 5 — in-depth analysis of candidate signals, textual explanations and document writing.
Voyage AI voyage-4 — generation of vector representations (embeddings) for semantic search.

Anthropic models are reached through OpenRouter (OpenRouter, Inc., USA), which acts only as a gateway: requests reach Anthropic (Anthropic PBC, USA) exclusively, with data collection for training excluded. OpenRouter does not divert them to other providers and, if OpenRouter does not respond, the application falls back only to Anthropic directly, never to other providers. Anthropic states that it does NOT use API requests to train models.

4. Processing purposes

Generate "Words-vs-Actions misalignment" signals that you can review to improve the consistency of your processes.
Allow you to query your work memory in natural language.
Automatically create and maintain the "living documents" of your taxonomy (Business, Context, Daily, Library, Projects, Skills, Team) by routing durable information from your diary entries into the relevant document, additively and versioned.

5. Legal basis

The explicit consent you are about to provide by clicking "I have read and accept" (art. 6(1)(a) GDPR).

6. Data residency and transfers

The data is hosted on a Hostinger server (Hostinger Cloud VPS) located in the Germany/Frankfurt region, within the European Union. Because it is located in an EU member state, the storage of your data is not a transfer to a third country and does not require, on that basis, Standard Contractual Clauses or a Transfer Impact Assessment.

API calls to language models (Anthropic via OpenRouter) and embedding services (Voyage AI) may transmit brief excerpts of your content to US-based providers. Anthropic keeps them for a limited period under its commercial terms and does not use them to train its models; Voyage AI does not use them for training. This is a transfer to a third country (USA): that transfer is subject to the safeguards of art. 46 GDPR (Standard Contractual Clauses) and, where applicable, a Transfer Impact Assessment scoped specifically to this component.

You can request further information on transfers by writing to privacy@vault-radar.it.

7. Retention

Your data remains in our systems as long as your account is active. Complete deletion within 30 days of deactivation (including derived embeddings).

8. Your rights

You may at any time (art. 15-22 GDPR):

Access your data and export it in a machine-readable format, from Settings → Your data if you are an owner or administrator of the workspace; if you are a member, by writing to privacy@vault-radar.it.
Delete your data — the whole account, or a single diary entry — from the same page (the whole workspace only owners and administrators; a member can simply write to privacy@vault-radar.it).
Object to the processing by contacting privacy@vault-radar.it.
File a complaint with the Italian Data Protection Authority — Garante per la protezione dei dati personali (https://www.garanteprivacy.it).

9. Human oversight (AI Act, Art. 14)

All radar signals are advisory: the system never acts autonomously towards third parties and you manually confirm every resolved signal.

Living documents (auto-maintenance). The documents of your taxonomy may be updated automatically by the AI from your entries. This automation is designed as "human-on-the-loop": every change is additive (it never overwrites or deletes), versioned, visible in the "what changed" feed, and revertible in one click. For each folder you can choose between automatic application and propose→approve (the sensitive folders — Business, Context, Team — are propose→approve by default). The safety floor (versioning, feed, revert, no blind deletion) is always on and cannot be switched off. The revert rate of automatic changes is monitored as an accuracy indicator.

10. Known limitations

The system may produce false positives (non-relevant signals). Every signal can be confirmed or dismissed by you.
Italian and English are both supported on the user interface. LLM-generated signal narratives currently produce Italian output regardless of interface language; full English LLM output is planned for a later release.

11. MCP connector (Claude, ChatGPT)

If you connect your Claude or ChatGPT to the vault through this application's connector (/settings/claude), the following applies in addition to point 2:

What leaves the vault. The content returned by the read tools you authorise your assistant to use: diary entries, memories, contact cards, commitments, documents. Access secrets (tokens, passwords, keys) never leave: no tool reads them.
What enters the vault. The writes you ask your assistant to make (new diary entries, memories, contact-card updates) are additive and remain recorded with the provenance mcp:<client>. No deletion scope exists: no data is ever removed through this route.
Who chooses the permission. When you connect — by pasting the vault's address into your client, with no identifier to register in advance — it is you who choose, on the vault's own consent screen, whether to grant "Read and write" or "Read only": no permission is assigned to you by us. You can change that choice, or revoke it entirely, at any time from the /oauth/consent page, with immediate effect on subsequent calls.
To whom. The content read reaches the provider of the client you chose to connect — Anthropic for Claude, OpenAI for ChatGPT — for the duration of the conversation you hold with your assistant. This is your own initiative, taken by connecting the connector and asking the question: it is not a sub-processing arrangement that we initiate.
Where your data is hosted. As already stated at point 6, on a server within the European Union, Germany/Frankfurt region; the whole-server backups kept by the hosting provider also stay within the European Union (Lithuania): no location on other continents.
How to stop it. You can change the permission you granted, or revoke it entirely, at any time from the /oauth/consent page; you can also request operator-side revocation by writing to privacy@vault-radar.it, and everything already stated at point 8 about your rights (art. 15-22 GDPR) still applies.

12. Google Calendar (optional connector)

If you connect your Google Calendar from Settings, the following applies in addition to point 2. Connecting is optional and starts only from an action of yours: before sending you to Google's consent screen, the application shows you a disclosure screen with the same information and waits for your confirmation.

What we read. Your primary calendar only, read-only: title, time, location and attendees (name and email address) of the events falling between 30 days ago and 120 days ahead of today. We do not import birthdays, focus-time blocks, working locations, events created from Gmail, or events you have declined. We write nothing to Google Calendar: we do not create, change or delete events and we do not reply to invitations.
What we do not read. Event descriptions, attachments and video-call links. Nor the other calendars of your account.
Private events. Events that Google marks as private or confidential come in as "Private event": we keep only the time, never the title, description, location or attendees.
Why. To show you your events in the Agenda, to link them to the cards of the people you already know, and to make them available, read-only, to the AIs you connect and to the application's chat when you query them. The AIs receive the date and time, the title, the linked card and the names of the other attendees (or their email address, when Google gives no name); in email-confirmation proposals, the attendee's name and email address; not the location. An event is linked to a card only if the attendee's email address is an identifier you have confirmed. If an attendee's name matches, with certainty, a single person already in your cards, we propose that you confirm that email address, without any artificial-intelligence model: until you answer, no data is associated with the card.
Archive of watched contacts. For each contact you watch we keep the full email (the received text, including the quoted parts of earlier emails, and a copy without the quoted parts) in an archive searchable by words, with no expiry. When you switch watching on we recover the emails of the last 30 days; then we add each new email, including those with automatic headers, but not drafts, spam and trash. An archived email never changes. Switching watching off or the passing of time does not delete the archive. Disconnecting the mailbox the emails come from deletes them (this revokes access: disconnecting Gmail deletes the archived Gmail emails, disconnecting Outlook the Outlook ones), as do "Start over" and the deletion of the account (or your deletion request under point 8).
What does not happen. Google Calendar data, as we read it from Google, does not enter the application's memory, does not feed the radar and is not used for automatic summaries. It is not sent to artificial-intelligence models on the application's own initiative, nor used to train any: it is received only by the AI you yourself query, that is the ones you have connected (point 11 applies to them) and the application's chat (see point 13).
The chat's answers. If you ask the application's chat about your events, the assistant's answer may repeat their titles and names. Like any other conversation, that answer stays in the chat history, goes into the conversation's automatic summary and may go into the memory the application derives from conversations. These texts are not deleted by disconnecting Google Calendar: they are deleted with "Start over" or by deleting the account. Only a preview of at most 50 characters of each model answer, stripped of recognisable personal data, remains in the register of model calls kept for AI Act obligations.
Protection against prompt injection. Calendar content is treated as untrusted data: it is neutralised and wrapped in delimiters, with a notice that it is not instructions, before it reaches the connected AIs, and no tool can change it.
Who sees it. The connection applies to the whole workspace: events are visible to the members of your workspace, not only to the person who connected the calendar. Only owners and administrators of the workspace can connect and disconnect.
For how long. Until you disconnect. In addition, at every synchronisation we remove events that ended more than 30 days ago. If in the meantime you have removed access from your Google account, the application stops updating the events, but the copy stays until you disconnect.
How they are deleted. By disconnecting Google Calendar from Settings, by using "Start over", or by deleting the account: in all three cases we revoke access at Google and delete from our system the events, the access token and the synchronisation state. If revocation at Google does not succeed, we tell you and you can try again or remove access directly from myaccount.google.com/permissions.
Legal basis and withdrawal. Your consent, given when you connect. You may withdraw it at any time by disconnecting Google Calendar, with the deletion described above; your rights stated at point 8 remain unchanged.

The use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The Google Workspace API User Data and Developer Policy, in the version updated on 3 September 2026, also applies.

13. Google Calendar data: who we share it with and how we protect it

This point is about the data we read from Google Calendar (see point 12): titles, times, locations and attendees of your events, and the token that lets us read them.

Who we share it with. We do not sell this data, we do not use it for advertising and we do not transfer it to data brokers. It is received only by:

Google, from which we read it, read-only, and at which we revoke access when you disconnect.
Hostinger, which hosts the server in the European Union (Germany, Frankfurt) where we keep the events and the encrypted token, and keeps weekly backups of the whole server, also in the European Union (Lithuania).
The members of your workspace, who see the events in the application (point 12, "Who sees it").
The AIs you connect (for example Anthropic's Claude or OpenAI's ChatGPT), only when you query them and under the terms of your own account with them (point 11).
OpenRouter, Inc. (USA) and Anthropic PBC (USA), only when you query the application's chat: OpenRouter acts as a gateway and the request reaches exclusively Anthropic's Claude model, also when the application has to call Anthropic directly, with data collection for training excluded. For chat answers that repeat event titles or names, the automatic summary (Claude Haiku 4.5, also to Anthropic) and the vector representations of the memory (Voyage AI, Inc., USA) also apply, as described at point 12, "The chat's answers". Searches that the chat or a connected AI runs over memory, which may contain event titles or names, also go through Voyage AI for vector representations. These are transfers to the United States, for which point 6 applies.

Nobody else receives Google Calendar data: in particular the service that sends the application's emails does not receive it, because no email contains it. Apart from you and the members of your workspace, no person reads the content of your events, except with your explicit consent for support you ask us for, for security reasons or to comply with the law.

How we protect it.

Encryption in transit. All communication between your browser and the server, and between the server and Google, travels encrypted (HTTPS/TLS).
Encrypted token. The token that lets us read your calendar is stored encrypted in the database, with a dedicated key that is kept neither in the database nor in its backups; the key is on the server and therefore also in the whole-server backups kept by Hostinger. The temporary access token stays only in memory for the length of one synchronisation. No screen, API or tool shows it.
Only what is needed. A single read-only permission, on the primary calendar only. We request from Google only the fields we need: no descriptions, attachments or video-call links. For private events we store only the time, and a database constraint enforces it. We keep only the events between 30 days ago and 120 days ahead of today.
Separation between workspaces. Every server read is limited to your workspace. The tables holding Google Calendar data cannot be reached through the database's public interface or with a user's account: only the server reads them. Row Level Security stays enabled as an extra barrier should that access ever be reopened by mistake. Email-confirmation proposals derived from attendees are visible to workspace members like any other proposal.
Access to the server. The database accepts no direct connections from the internet. Only the data controller accesses the server, with a cryptographic key (password login is disabled), behind a firewall and protection against repeated login attempts. For maintenance the controller may use AI-based coding assistants, which on the server read only metadata and counts, never the content of the events.
Logs. The application's logs contain neither the content of the events nor the token.
Protection against prompt injection. See point 12.
Backups. Every night we make a copy of the database. The unencrypted copy stays on the server for 14 days; the encrypted copies, on the server and with the data controller, serve only to restore service after a failure and cannot be read without the key, which the controller keeps off the server. Hostinger also keeps a weekly copy of the whole server, in the European Union (Lithuania), and retains the last three. For this reason, after a deletion, events may remain in the backups: for up to 14 days in the unencrypted copy, for up to about three weeks in the whole-server copies, and in the encrypted copies, which currently have no automatic expiry, until the controller removes them.
Deletion. When you disconnect, use "Start over" or delete the account, we revoke access at Google and delete from the database the events, the token and the synchronisation state (point 12). If the token can no longer be read, we delete the data anyway and ask you to remove access at myaccount.google.com/permissions.

14. Gmail (optional connector)

If you connect your Gmail mailbox from Settings, the following applies in addition to point 2. Connecting is optional and starts only from an action of yours: before sending you to Google's consent screen, the application shows you a disclosure screen with the same information and waits for your confirmation. Until Google has completed the verification of the application, its screen may show you an unverified app warning: this is normal.

What we read. Only the emails to and from a contact, that is the people on your cards, read-only (permission gmail.readonly): those in which an address you have confirmed on the card appears. Of each email of the last 30 days we keep sender, recipients, date, subject and identifiers, without the text: it lets us know whom you wrote to, when and about what (a summary list, refreshed about every 15 minutes; rows older than 30 days are deleted). We read the text of an email when you ask for it: by pressing "Read the latest emails" on the contact's card, or by asking the chat or an AI you have connected, and in that case we do not save it. For the contacts you choose to watch we also read the text on our own, once a day for the summary and about every 15 minutes for the archive, only for the emails that arrived after the last check. Never the rest of the mailbox. Spam, trash and drafts stay out; automated emails (newsletters, notifications, calendar invitations, auto-replies) do not enter the summary list or the summary. Connecting Gmail does not import any email into the diary or the memory. We write nothing to Gmail: we do not send, change, delete or archive emails.
What we do not read. Attachments, emails exchanged with other people and everything that is not about the contact you chose.
Why. To know and tell you whom you have written to, when and about what, to let you read an email when you ask for it and to write into your diary, when you press "Read the latest emails" or for the watched contacts, a summary of the emails exchanged with a contact. For each reading we write a single diary entry. The summary list, the emails read on request and the archive are available to the application's chat and to the AIs you connect (points 11 and 12), and the radar (point 4) reads the text of the new archived emails of the watched contacts, at most five per card at a time. The summary goes into your diary and, from there, into the cards, the memory and the AIs you connect, when you query them, and it may be used by the application for the functions described at points 3 and 4. Nothing in the diary, the memory, the cards, the commitments or the proposals is created on its own from the emails.
Who writes it. The text of the selected emails, with their headers, is sent to an Anthropic model (Claude Haiku 4.5), through OpenRouter, solely to write the summary; the same model and the same guarantees apply to the radar when it reads the archived emails: the request reaches Anthropic exclusively, with data collection for training excluded. We do not use your emails to train any model. To search the summary in memory, its vector representations are generated by Voyage AI (point 15).
Protection against prompt injection. The text of the emails is treated as untrusted data: it is neutralised and wrapped in delimiters, with a notice to the model that it is data to summarise or to read and not an instruction, and the summary passes a safety check before it is saved.
Who sees it and who can connect. The connection applies to the whole workspace: the summaries, the summary list and the archived emails are visible to the members of your workspace, and readable by the connected AIs and the chat, not only by the person who connected the mailbox. Only owners and administrators of the workspace can connect, disconnect, read the mail and choose which contacts to watch.
Watching contacts. It is optional and is switched on from a contact's card, only if it has a confirmed email address: from then on, once a day and only if there are new emails, the summary arrives in the diary. Contacts you do not watch are read only when you press the button on the card. If you disconnect the last connected mailbox (Gmail or Outlook), watching switches off for all contacts: when you reconnect, you switch it on again from the card.
For how long. The token, until you disconnect. The summary list, 30 days (older rows are deleted on their own; it is also deleted when you disconnect). The archive of watched contacts, with no expiry, even if you switch watching off; it is deleted when you disconnect Gmail (only the archived Gmail emails), by using "Start over" or by deleting the account (point 8). The summary stays in the diary after you disconnect, until you delete it, use "Start over" or delete the account (point 8). If in the meantime you have removed access from your Google account, the application stops reading and Gmail shows as "to reconnect", but the token, now unusable, stays until you disconnect.
How to disconnect. By disconnecting Gmail from Settings, by using "Start over" or by deleting the account, we revoke access at Google and delete the token, the summary list and the archived Gmail emails. Disconnecting Outlook does not touch the Gmail archive, and vice versa; switching watching off does not delete the archive. If revocation at Google does not succeed, we tell you and we do not delete the token: you can try again or remove access directly from myaccount.google.com/permissions.
Legal basis and withdrawal. Your consent, given when you connect with the current version of this text (whoever connected earlier must reconnect for the summary list and the archive to start). You may withdraw it at any time by disconnecting Gmail, with the deletion of the token, the list and the archived Gmail emails described above; to delete the diary summaries as well, use "Start over" or delete the account, or ask us under point 8.
Outlook. The targeted reading described in this point applies in the same way to the Outlook / Microsoft 365 mailbox you connect from Settings; revocation at Google and the declaration that follows concern Gmail only.

The use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. In particular, we use Gmail data only to provide you with the function you see in the application, that is the list, the reading and the archive of the contacts' emails, the summary and the radar check; we do not transfer it to others except to provide that function, for security or to comply with the law; we do not use it for advertising or to train artificial-intelligence models; no person reads its content, except for security or legal obligations (point 15). The Google Workspace API User Data and Developer Policy, in the version updated on 3 September 2026, also applies.

15. Gmail data: who we share it with and how we protect it

This point is about the data we read from Gmail (see point 14): the emails exchanged with the people on your cards, of which we keep the summary list for 30 days (without the text), for the watched contacts the full email, with no expiry, and the summary in the diary, and the token that lets us read them.

Who we share it with. We do not sell this data, we do not use it for advertising, we do not transfer it to data brokers and we do not use it to train models. It is received only by:

Google, from which we read it, read-only, and at which we revoke access when you disconnect.
Hostinger, which hosts the server in the European Union (Germany, Frankfurt) where we keep the summaries, the summary list, the archive of the watched contacts' emails and the encrypted token, and keeps weekly backups of the whole server, also in the European Union (Lithuania).
OpenRouter, Inc. (USA) and Anthropic PBC (USA), to write the summary and for the radar check: the text of the selected or archived emails reaches exclusively Anthropic's Claude model, through OpenRouter, also when the application has to call Anthropic directly, with data collection for training excluded.
Voyage AI, Inc. (USA), which receives the summary, and the searches that the chat or a connected AI runs over memory, to generate their vector representations (point 3); it does not use them to train models. It does not receive the full emails.
Resend, Inc. (USA), the email service provider that delivers the application's service emails. If you have turned on the weekly summary or the radar digest, those emails may contain short excerpts of radar signals, which can derive from the email summaries in the diary. Nothing else from Gmail goes to Resend: not the emails, not the full summaries, not the token.
The members of your workspace, who see the summaries in the diary (point 14, "Who sees it and who can connect").
The AIs you connect (for example Anthropic's Claude or OpenAI's ChatGPT) and the application's chat, only when you query them and under the terms of points 11 and 12 ("The chat's answers"): they can read the summaries.

These are transfers to the United States, for which point 6 applies.

Nobody here reads your emails: the operator sees only counts and dates, except for security or legal obligations. Apart from you and the members of your workspace, no other person reads the summaries, with the same exceptions.

How we protect it.

Encryption in transit. All communication between your browser and the server, and between the server and Google, travels encrypted (HTTPS/TLS).
Encrypted token. The token that lets us read your mailbox is stored encrypted in the database, with a dedicated key for Gmail that is kept neither in the database nor in its backups; the key is on the server and therefore also in the whole-server backups kept by Hostinger. The temporary access token stays only in memory for the length of one reading. No screen, API or tool shows it.
Only what is needed. A single permission, read-only, on the emails exchanged with a contact only. We do not read attachments. We keep the text of an email only for the contacts you watch (archive); for the others, of each reading only the summary in the diary remains.
Separation between workspaces. Every server read is limited to your workspace. The table holding the Gmail token cannot be reached through the database's public interface or with a user's account: only the server reads it. The summaries are in the diary, and the summary list and the archive in their own tables, all isolated per workspace with Row Level Security; the tables of the list and of the archive are not reachable even through the database's public interface.
Access to the server. The database accepts no direct connections from the internet. Only the data controller accesses the server, with a cryptographic key (password login is disabled), behind a firewall and protection against repeated login attempts. For maintenance the controller may use AI-based coding assistants, which on the server read only metadata and counts, never the content of the emails.
Logs. The application's logs contain neither the content of the emails nor the token.
Protection against prompt injection. See point 14.
Backups. As in point 13: every night we make a copy of the database and Hostinger keeps a weekly copy of the whole server, in the European Union (Lithuania). For this reason, after a deletion, the summaries may remain in the backups for the times stated at point 13, "Backups".
Deletion. When you disconnect Gmail, use "Start over" or delete the account, we revoke access at Google and delete the token and the archived Gmail emails (with "Start over" or by deleting the account the Outlook archive and the diary summaries are deleted too, point 14). If the token can no longer be read, we delete the token anyway and ask you to remove access at myaccount.google.com/permissions.