EU AI Act · GDPR

The AI recruiting tool sits in the data protection officer's record of processing activities and in the IT department's AI list. Two files, two versions, maintained by two people who rarely talk to each other.

That is the reality in most mid-sized companies taking both topics seriously. And it is the most expensive way to meet both obligations: duplicate data entry, contradictory entries, and a data protection officer who does not know about half the AI systems in use.

The cause is structural. The two registers have different legal origins, and that is precisely why they come into existence separately.

Only one of the two registers is expressly mandated

This distinction is usually skipped over in practice, yet it is the heart of the problem.

Record of processing activities

An express obligation under Art. 30 GDPR

The text of the law states exactly which entries the record must contain. It has to be made available to the supervisory authority on request.

AI inventory

No dedicated article, but practically indispensable

The AI Act contains no provision saying "keep an AI register". It presupposes one in several places: Art. 4 requires risk-appropriate training, Art. 50 the correct disclosure per system, Art. 26 the deployer duties, Art. 72 monitoring in operation.

In practice: one register exists because a law demands it. The other exists because without it, none of the AI obligations can be met cleanly. Two origins, two departments, two files.

On the exemption in Art. 30(5)

Companies with fewer than 250 employees are exempt from the record, but only where the processing poses no risk, is occasional, and involves no special categories of personal data. With AI-assisted processing of employee or applicant data, those conditions are almost never all met. The increase to 750 employees proposed in the Digital Omnibus is not yet in force; the general Omnibus remains in the legislative process.

A worked example: AI-assisted applicant screening

A mid-sized company uses a bought-in tool that pre-sorts incoming applications and proposes a ranking to the hiring managers. A standard case, and one that triggers both frameworks at once.

From the GDPR side this is a processing activity involving applicant data, with a processor in the background and a legal basis that has to be justified. From the AI Act side it is an AI system in the employment domain, for which the role has to be established, which needs a risk classification, and which is likely to qualify as high-risk from December 2027.

Both views describe the same object. They simply ask for different things.

What is captured twice, and what is not

Entry	Art. 30 GDPR	AI inventory
Name and purpose	Yes	Yes
Categories of data subjects and data	Yes	Yes, for the risk assessment
Recipients and service providers used	Yes	Yes, as the system's provider
Third-country transfers	Yes	Indirectly relevant
Technical and organisational measures	Yes	Yes, partly identical
Legal basis and retention periods	Yes	No
Role as provider or deployer	No	Yes
Risk class under the AI Act	No	Yes
Disclosure under Art. 50	No	Yes
Human oversight and training status	No	Yes

Half the fields are identical. That is exactly the half most companies collect twice, maintain twice, and eventually update in only one place.

The trap: the roles do not map onto each other

Anyone merging the two registers will almost inevitably stumble at one point. Both frameworks use a pair of roles, and the two pairs sound similar without meaning the same thing.

GDPR: controller and processor

The classification turns on who determines the purposes and means of processing personal data.

AI Act: provider and deployer

The classification turns on who develops the system and places it on the market under their own name, and who uses it under their own authority.

In the recruiting example your company is the controller under the GDPR and the deployer under the AI Act. The tool vendor is the processor and the provider. That alignment holds here, but it is not a law of nature. A provider may process personal data purely for its own purposes and therefore be a controller itself. A deployer may act on a customer's instructions and therefore be a processor.

What this means for implementation: create two separate role fields, not one. Collapsing both roles into a single column produces exactly the errors that surface in an audit.

Three errors that separate registers reliably produce

The blind spot

Business units adopt AI tools without involving data protection. The system lands in the IT list but never in the record of processing. Shadow AI is therefore an AI Act problem and a GDPR problem at once.

The contradiction

The purpose is narrowly worded in the record of processing and broadly worded in the AI list. When an authority sees both documents, the discrepancy is the first thing they ask about.

The version drift

The vendor updates the model and the feature set changes. IT notices, data protection does not. From that moment both assessments rest on a state of the system that no longer exists.

Record once, output two views

Merging the two is not a software question but a question of sequence. Five steps that work even in a well-maintained spreadsheet.

Make the system the shared anchor

Not the processing activity and not the tool, but the specific AI system with its version and intended purpose. Both views hang off that.

Define the shared fields once

Purpose, data categories, data subjects, service providers, security measures. One wording that satisfies both requirements, instead of two variants that drift apart.

Keep the specific fields apart

Legal basis and retention periods on one side, risk class, role and disclosure on the other. Separate fields, shared record.

Establish one intake process

New AI tools go through one notification, not two. The data protection officer and the person responsible for AI see the same intake. This is the single most effective lever against shadow AI.

Generate two exports from one source

The data protection authority receives the record in the shape of Art. 30, market surveillance receives the AI view. Two documents, one state of truth.

The point that matters

Discussion of AI compliance tends to revolve around new obligations. In practice, though, the effort rarely comes from the obligation itself. It comes from the question of where the information sits and whether it is still accurate.

Companies that maintain a proper record of processing activities have already done half the work for their AI inventory. They often do not realise it, because the two topics sit in different areas of responsibility. Merging them saves more than the duplicate entry. It also creates the basis for the next point where the two frameworks meet: deciding when a data protection impact assessment under Art. 35 GDPR is required and when a fundamental rights impact assessment under Art. 27 of the AI Act is.

With SimpleAct

Record one system, serve two obligations.

EU AI Act and GDPR in one platform: register AI systems centrally, classify them rule-based, assign responsibilities and export audit-ready evidence at any time. Made in Germany, hosted in Germany.

Start your AI inventory →

This article is for general information only and does not constitute legal advice. Last updated: 13 August 2026.

One AI System, Two Registers: Why Your AI Inventory and Your GDPR Record Belong Together