Ask the DPO or in-house counsel where they keep their records of processing activities. Nine times out of ten, the answer is the same: Excel. And that Excel was last properly updated eight months ago, when the colleague who owned it left.
The work nobody talks about
Article 30 of the GDPR requires data controllers to maintain records of all processing activities. In practice, that means: for every process where the company handles personal data — hiring, invoicing, email marketing, customer support — there must be a record. Who owns the data, for what purpose, how long it is kept, who it is shared with.
The spreadsheet gets created once, during the first audit or after a legal consultation. Then the company is told to "keep it up to date." Reality: a new invoicing app arrives, the CRM is replaced, a web chat widget goes live. Each change should mean opening the file and adding a row — but who is responsible for that? Usually nobody specific. And so the record falls behind.
We have the record. The last time we opened it was when the regulator came. It listed ten systems. We now run twenty-two.
— DPO at a mid-size manufacturing company, describing the situation at an initial conversation
What a "living record" actually means
AI stack builds small, focused MCP servers — each one is a bridge between Claude and one company system. The server carries the identity and permissions of the person asking: Claude never sees more than an authorised person would see. No data copies outside your cloud, no cache on a third-party server.
A connection to the ERP, CRM, and HR system lets Claude continuously read the shape of the data — not the personal records themselves, but the metadata: what categories of data the system holds, who accesses it, how long it is retained. From that, Claude assembles or updates the processing record in a format the DPO can use directly.
Concretely: Pohoda, Money S3, or Helios
Most mid-size Czech companies manage invoicing and accounting in Pohoda or Money S3, payroll in Helios or a similar platform, and sales in Raynet or eWay-CRM. Each of these systems processes personal data — and each is a separate island. An MCP server for each reads its data structure and passes Claude exactly what is needed: processing categories, legal basis, retention periods, recipients. Illustratively: a company with thirty employees and three main systems could have a current, structured record assembled in under an hour instead of a week of legal work.
- Claude detects a new system or new data category and proposes an addition to the record.
- When the legal basis changes (consent → legitimate interest), Claude alerts the DPO and drafts the amendment.
- Before a supervisory authority audit, Claude assembles the full records overview in the required format — no manual export needed.
- Records are versioned: every change carries a timestamp and the name of the approver.
- If a system stops reporting metadata, Claude flags the gap.
An illustrative example: an e-commerce company running three brands switched to a new CRM and found that their processing records no longer matched reality. The new system was tracking customer behaviour, but the record made no mention of it. An MCP bridge reading from the CRM, the e-shop platform, and the email tool would have flagged that gap automatically — without waiting for the next audit.
What Claude will not do in GDPR compliance — and why that is good
Claude is not a DPO and does not replace legal judgment. Decisions about whether a specific processing activity is lawful, which legal basis applies, or whether a DPIA is required remain with the responsible person. Claude proposes the structure of the record and flags gaps — it does not make legal classifications.
This boundary is not a technical limitation — it is a design choice. The GDPR places responsibility on the data controller, not on software. The living record Claude maintains is source material for a human decision. Approval, sign-off, and accountability are always human.
What it would take
No year-long project. MCP servers for common company systems — ERP, CRM, HR, email tool — are ready within weeks, deployed on your cloud, not ours. Your data never leaves your infrastructure. The DPO gets access to Claude through a standard interface and can continuously review, supplement, and approve records.
What's left
The model is not the bottleneck. Claude only needs to see the metadata of company systems — structure, categories, retention periods. The bottleneck is that this metadata is scattered across a dozen systems with no one connecting them. An MCP bridge closes that gap: not by copying data, but by connecting to its source.
If your processing records live in a spreadsheet that was last properly updated three months ago, write to us. A short call is enough to show what a bridge for your specific systems would look like.