Before you connect a mailbox: seven data rules to agree in writing

A company mailbox is the most complete record a business keeps without meaning to. Client files, personal data, contracts, prices, disputes, payslips sent by mistake: everything passes through it. Connecting an AI system to it can save a team hours each week. It also means that, from the first minute, a system and its provider can read what your people read.

That is why the rules come before the connection. Once access is open, reconstructing what was read, copied or kept is difficult. Before it is open, everything is still a decision. Below are the seven rules we ask to have agreed in writing before any access, and the questions that show whether a provider, including us, has really thought them through.

This is a practical checklist, not legal advice. The legal points at the end are for your counsel to confirm.

1. Confidentiality, by role

A confidentiality clause is the obvious start, and it is often too vague. It should cover everything the provider may see: message bodies, attachments, metadata, and the data extracted from them. It should say which roles on the provider’s side can access your data, for what purpose, and how that access is logged. It should forbid any use of your data for other clients, and it should survive the end of the contract.

Ask: who, by role, can see our messages, and where is each access recorded?

2. Where processing happens, stated truthfully

Storage and processing are two different questions. Documents may be stored in one place and read by a service located somewhere else. A modern AI system usually relies on one or more cloud services, each with its own location and its own terms.

The useful answer is specific: where your data is stored, where it is processed, which sub-processors are involved and in which countries, and whether any of them may use your data to improve their own models. The honest answer may be that processing happens abroad. That is not necessarily a problem, but it is a transfer, and it has conditions of its own. Be wary of blanket reassurance that data never leaves the building when the system obviously runs on a cloud service.

Ask: can you list, in writing, every place our data is stored or processed, and every company involved?

3. Retention and automatic deletion

Every system keeps more than it seems: the original documents, the fields extracted from them, the drafts it prepared, the logs of what it did, and the backups of all of these. Each needs a retention period, agreed in advance and applied automatically, not by someone remembering to clean up.

A good default is to keep working documents only as long as the business process needs them, keep the audit trail longer, and let backups expire on a known cycle. Ask how deletion is evidenced: a log entry, a report, a certificate.

Ask: for each kind of data, how long is it kept, and what triggers its deletion?

4. Export and deletion at exit

Every engagement ends one day, well or badly. The exit should be written on day one. You should be able to get your data back in a usable form: the documents, and the extracted data in an open format such as CSV or JSON, within an agreed delay. After that, the provider deletes it, including from backups once their cycle ends, and confirms it in writing.

Also agree what else is handed over: the rules the system applies, its settings and the company context written during the project. Settle it now, while everyone is on good terms.

Ask: if we stopped tomorrow, what would we receive, in which format, and within how many days?

5. A dedicated mailbox, not a personal inbox

The simplest rule has the most effect on risk. Do not connect anyone’s personal inbox. Create a dedicated address for the process in question, for example the one suppliers already use to send shipping documents or invoices, and route only those messages to it.

A dedicated mailbox limits by design what the system can see. It keeps private messages, HR matters and management correspondence out of scope. It is also easy to switch off, easy to audit and independent of any one employee.

Ask: which messages, exactly, will reach the mailbox the system reads?

6. Read-only first, sending rights later

Access should grow in steps, each one earned on real files and each one agreed in writing.

At the first step, the system reads the dedicated mailbox and cannot send anything. At the second, it prepares replies, requests or summaries, and a person reads, edits and sends them. Only then, and only if the team wants it, can a written agreement grant sending or writing rights for a short list of named actions, such as acknowledging receipt of a complete file. Staying at the second step for good is a perfectly sound choice.

Ask: what can the system send today without a person approving it? The right answer at the start is nothing.

7. Roles, two-factor sign-in and an audit trail

The last rule concerns people, on both sides. Every user has a named account; nobody shares a login. Roles separate who can view, who can approve and who can change the settings. Two-factor sign-in is required for everyone, including the provider’s staff. An audit trail records who viewed a file, who approved a draft and who sent it, and your team can read that trail without asking.

Plan for departures too: when someone leaves your company or the provider’s team, their access is removed the same day.

Ask: can we see, for any file, who looked at it and who approved what was sent?

Put it on one page, and sign it

These seven rules fit on a page. Attach it to the contract, have your IT contact review it, and sign it before the first access is opened. It will not slow the project down. It is usually what allows the project to start, because everyone knows where the limits are.