What we store about people
What the application keeps, whose it is, how long it stays, and the things that are easy to get wrong — deleting, backups, and models.
What this application stores about people
This page describes what actually happens today, not what we intend to happen. It was written by reading the code and the database, module by module. If something here surprises you, that is the point of the page.
It is deliberately not written in legal language. If you need the legal framing, this is the factual basis for it — not a substitute.
The short version
Projetix holds three kinds of information about people:
- about you, because you use it — your account, how you sign in, what you are allowed to reach, and a record of what you changed;
- about colleagues, because the work is about them — salaries, contracts and identity documents;
- about people who have never heard of us — researchers named in proposals, contacts at the Commission, whoever wrote to a connected mailbox, the counterparty on an invoice.
The third group is the largest, and it is the one worth reading this page for. Those people have no account here, were never asked, and cannot see or correct what is stored.
What is stored, module by module
| Where | What about people | Whose | Files |
|---|---|---|---|
| the platform | username, name, password hash, linked Google/Microsoft identities, roles and permissions, IP addresses and actions, notifications, sessions and authorised MCP clients | yours | — |
| Salaries | name, birth date, email and phone, tax and social-security numbers, IBAN, addresses, identity documents, loyalty programmes, payment cards (last four digits), and contracts with the base salary | colleagues in an institution | files attached to each record |
| address, folders, and for each message subject, sender and the body as text; the mailbox credential, encrypted | whoever connects the mailbox — and everyone who wrote to them | the raw .eml and attachments |
|
| Intelligence | what a model read in mail and documents and proposes as a fact — a contact, an invoice, an event — with the title of where it came from, waiting for someone to approve or reject it | colleagues and third parties | — |
| Revolut | transactions and expenses (amount, description, date) | whoever connects the accounts | proof of payment |
| Contacts | name, email, affiliations | third parties — and each contact belongs to whoever wrote it | — |
| Proposals | of researchers: name, gender, nationality, email, career stage, identifier; of contacts: name, email, phone, role, department | third parties, never asked | proposal PDFs |
| EC Portal | contacts with email, name, surname and phone; and Portal messages with sender, recipients and body | colleagues and third parties | project documents |
| Calls | partner-search announcements: name, country, type, expertise | third parties | — |
| Machina | the coordinator, and whatever is written into the concepts | third parties | concepts, Part B, consortium file |
| Projects & Partners | organisations and participations, mirrored from CORDIS | almost nothing about people | — |
| Skills | comments | colleagues | — |
| Docs | nothing | — | — |
And on top of all of that, in every table: who owns the record, who created it, and the conversation history attached to it. Who wrote what, when, and what they said about it exists everywhere, without exception.
Five things that are easy to get wrong
1. Deleting does not delete
When a record is deleted, the files go. The data stays — the full record is written to a history table, on purpose, because that is what makes an accidental deletion undoable. Every kind of record has one of those tables, and nothing prunes them.
So a request to delete something today removes what you can see and leaves what you cannot.
2. Almost nothing has a retention period
Two exceptions, and they are the whole list:
- the audit trail — 365 days for security events, 90 days for the rest;
- notifications you have already seen — 60 days.
Everything else is kept without a defined period. That is a statement of fact, not a policy: no period has been decided.
3. Backups are write-only, by design
The database and the files are copied to external destinations. Those destinations are, by design, write-only: we can put a copy there, and we cannot delete from them or check what is in them. Anything that reached a backup is outside every deletion path described above.
4. What a model was sent, and what it answered, is kept for a while
Every call to a model is logged. The cost — tokens, the module, who made the call — is kept for good. The text — what was asked and what came back, which can be the body of an email or an invoice — is kept apart, cut at a ceiling per call, and deleted after 30 days. Only the person who made the call can read it; whoever administers cannot, except through «View as», which is audited.
What a model proposed from your mail or your documents (Intelligence) stays in its queue as a record like any other — point 1 applies to it.
There is also a cache of document readings, outside the database. None of the apps installed today writes to it, and it has been measured empty in production. If one that uses it comes back (Trips did), that cache has no expiry, is not in the backups, and no deletion path reaches it.
5. Your session is on one machine, but your data is not
Signing out clears your session and asks your browser to drop its cache. It does not affect anything in the list above.
Who reads your documents and your mail
Documents and mail are read by a language model to extract what is in them. Today that model is always a third-party one. Local models — running on our own machine, with nothing leaving the installation — are switched off here, and the only kind of provider this installation can use is Anthropic (Claude), configured in the administration page for models. The content goes to it over the internet, under a contract with them.
So the content of the document or message is sent to that provider. That is the part worth knowing: it is not metadata, it is the invoice, the receipt or the email body. Ask whoever administers the installation whether a provider is configured today — the answer lives in the database, not in this page. Without one, no model reads anything.
And what was sent and what came back is kept here for a while — see point 4 above.
Who can see what
Access is never granted by default. A new account reaches nothing at all until someone gives it a role, and each role is given explicitly. Administrators can see the administration pages, and what they do there is in the audit trail.
Two things are yours alone and are not shared by an administrator's role: your mailbox and your contacts — a contact belongs to whoever wrote it, and is shared one by one, read-only.
Correcting or removing something
There is no self-service route for this yet. Ask whoever administers the installation. Read point 1 first: what can be removed today is what you can see, and the history stays.
When this page is wrong
It will be. It was written by hand from a measurement taken on one day, and the application changes daily — the honest thing is to say so here rather than to let it quietly rot. If you find something in the application that this page does not describe, that is a bug in the page: report it through Report a problem, in the menu behind your name.