Sectoral Rules and Overlapping Regimes

An AI system in a regulated sector faces the AI Act plus whatever already applied. The regimes were not designed together, they use different vocabularies for overlapping concepts, and they occasionally point in different directions. Treating AI regulation as a single obligation is the most common structural error in a compliance programme.

The regimes that overlap

Data protection. The GDPR applies wherever personal data is processed, which covers most training data and most inference on people. Its requirements are independent of the AI Act's: a lawful basis, purpose limitation, data minimisation, and the rights of data subjects. Article 22, restricting solely automated decisions producing legal or similarly significant effects, applies to precisely the systems the AI Act calls high-risk, and it imposes a right to obtain human intervention that the AI Act's human oversight requirement resembles without replacing.

Sector regulation. Financial services rules on model risk management and creditworthiness assessment, medical device regulation for clinical software, employment law on discrimination in hiring, and consumer protection rules all apply on their own terms. A credit scoring model is high-risk under the AI Act and separately subject to consumer credit rules, and both must be satisfied.

Product safety. The Annex I route into high-risk classification exists precisely because AI embedded in a regulated product is already covered by that product's regime, and the AI Act layers on top rather than replacing it.

Non-EU regimes. State-level rules in the US, sector regulators' guidance, and other national AI laws apply to the same system in other markets, with different definitions and different thresholds.

The practical approach

Map obligations to controls once, not per regime. Most requirements across regimes reduce to a smaller set of underlying capabilities: knowing what data was used and on what basis, being able to explain a decision, being able to demonstrate testing including for disparate impact, having human oversight that is real, logging enough to reconstruct what happened, and being able to identify and correct errors.

Building those capabilities well satisfies most of what several regimes ask for, and a control-to-obligation mapping then shows which regime each control serves. This scales; a separate programme per regime does not.

When it breaks

Definitions do not align. "Automated decision-making" in the GDPR, "high-risk AI system" in the AI Act, and a sector regulator's definition of a model do not carve the world the same way, so a system can be in scope for one and not another. Mapping has to be at the obligation level rather than the label level.

Regimes can conflict. Data minimisation pushes toward collecting less, and demonstrating that a system does not discriminate often requires the demographic attributes that minimisation discouraged collecting. This tension is real, and the resolutions available, separate collection with restricted access, proxy methods with stated limitations, or accepting that the analysis cannot be done, are all imperfect.

The strictest requirement usually governs the design. Building to the most demanding applicable standard once is generally cheaper than maintaining variants, and it is also the decision that ages best as regimes converge.

Compliance load falls unevenly on small teams. The fixed cost of a compliance programme does not scale down, which advantages incumbents and is a documented concern about the regime rather than a problem any individual team can solve. Recognising it is useful for planning even where nothing can be done about it.