Almost every AI system processes personal data. That means the AI Act and the GDPR apply at the same time – and the evidence overlaps heavily: data lineage in the Annex IV dossier is the same matter as data categories in the records of processing, and a fundamental rights assessment builds on the same analysis as a data protection impact assessment. The GDPR suite keeps both in one system, so you maintain these facts once instead of twice.

At a glance

Included from: Professional; individual modules from Enterprise
Where in the app: Left navigation → Data protection
Output: A complete data protection file including a full export as ZIP
API: /api/v1/processing-records, /toms, /dpia, …

The modules at a glance

Fourteen building blocks. Which ones you need depends on size, sector and data situation – not every company handles authority cases or third country transfers.

Module	Legal basis	Included from
Records of processing (RoPA)	Art. 30	Professional
TOMs	Art. 32	Professional
Data protection impact assessment	Art. 35	Professional
Data subject requests	Art. 15–22	Professional
Data breaches	Art. 33, 34	Professional
Consent & cookie banner	Art. 7, TTDSG	Professional
Retention & deletion	Art. 5(1)(e)	Professional
Privacy notices	Art. 13, 14	Professional
Processors (DPA)	Art. 28	Professional
Awareness & training	Art. 39(1)(b)	Professional
Full GDPR export	Art. 5(2) (accountability)	Professional
Data protection officer	Art. 37–39	Enterprise
Third country transfers	Art. 44–49	Enterprise
Authority cases & escalations	Art. 31, 77	Enterprise

Where the AI Act and the GDPR interlock

AI system ↔ processing activity

A processing record can be linked directly to an AI system. That single link answers two questions: "which personal data does this system process?" and "which system runs this processing?"

DPIA ↔ FRIA

The Art. 35 GDPR impact assessment and the AI Act’s fundamental rights assessment are not the same thing, but they overlap heavily: affected people, depth of intrusion, mitigations, residual risk. A well-kept DPIA is half the FRIA.

Data breach ↔ AI incident

Both have notification deadlines, but different recipients and triggers. SimpleAct keeps them separate – an incident can be both, and is then tracked in both registers, each with its own deadline.

TOMs ↔ controls

Art. 32 measures and EU AI Act controls partly cover the same safeguards. A TOM can reference processing records and vendors, which makes it shared evidence.

The full GDPR export

One call, one ZIP archive – for the supervisory authority, the auditor or your own internal audit:

index.html and index.pdf – the readable overview of the whole package.
summaries/ – PDF summaries of processing records, DPIAs, data subject requests and data breaches.
data/compliance-export.json – the complete raw data for machine processing.
data/ropa.csv – the records of processing as a spreadsheet, opens directly in Excel.

Two registers for processors?

No, one: the vendor register keeps providers in both their AI Act role (GPAI provider, API service, embedded component) and their GDPR role (processor with DPA status, sub-processors and third country transfers). You maintain a vendor once and see both perspectives.