Imagine this

The model is ready, the data lake is full, and the dashboard looks beautiful. Then some “weird” non IT guy asks a surprisingly innocent question 🤔:

Are we sure we can automate this decision? Can we use GPT here? Can we keep these logs forever? Are we thaaat compliant?

Weird non IT guy

The point of this article is simple: I think every Data practitioner should recognize the few regulations that regularly show up around our systems. Not know them by heart. Not interpret every exception BUT just know when a technical decision has entered legal territory.

For this article, I’ll keep things deliberately simple and focus on the two regulatory worlds we encounter most often (or at least for me, West biased, sorry for others 🙏): Europe and the United States. So the objective is not to build a law degree in ten minutes, It is just to know the map, and check in details if needed !

---

The European Way 🇪🇺

First of all, you need to know that Europe loves frameworks ! Instead of regulating every Data or AI project granularly, the European Union tends to create large regulatory frameworks that apply across sectors and organizations. For us, Data practitioners, there are two names worth remembering first: GDPR and the AI Act. They don’t regulate exactly the same thing.

GDPR mainly follows the personal data. For example, if we store a candidate’s name, date of birth, email address or CV, GDPR immediately becomes relevant because we are processing information related to an identifiable person.

The AI Act mainly follows the AI system and its use. For example, if we use a clustering or ranking algorithm to classify candidates, the question is no longer only which data we process, but also what the system is doing and how its output is used.

Personal Data? Think GDPR

General Data Protection Regulation (GDPR) becomes relevant when your system processes personal data and your organisation operates in the EU or offers services to people in the EU.

What is personal data? In GDPR terms, personal data is basically any information relating to an identified or identifiable person. Some examples are obvious: a name, an email address, a phone number or a date of birth. But the definition goes much further. Customer IDs, IP addresses, location data, browsing history, purchase history or behavioural data can also qualify as personal data if they can be linked, directly or indirectly, to an individual.

And this is the important part: a piece of data does not need to identify someone on its own. A random customer ID may look anonymous in one table, but if another dataset lets you map that ID back to a real person, you are still dealing with personal data.

So, from a Data perspective, the right question is not only Does this column contain names or emails? It is also: Could this data, alone or combined with other information reasonably available to us, be connected back to a person? If the answer is yes, GDPR is probably entering the picture 👋.

For a Data practitioner, I would not try to memorize the full regulation. I would keep two things in mind: the rights people can exercise, and the rules that should already shape the system.

And what does that really apply in real life, like for my Data & AI day-to-day project ? Now forget the article numbers for a minute. Once you translate all of this into reality, GDPR starts raising some very concrete technical questions:

How long should personal data remain in an operational system? If that data has already been replicated into a Data Lake, how do we propagate a deletion request there too?

And technically, what does “delete one customer” even mean when the data is buried inside several Parquet files?

What happens when analytical data is historized? How do we correct a value without silently rewriting history? Do we have a proper anonymisation process? Does our archival policy actually delete data at some point, or do we just move it somewhere colder and call it a day?

Are the clustering models we are training, or the LLMs we are fine tuning, using data we are actually allowed to use? And are their outputs legally acceptable?

Portability creates another very practical question: can we actually give a user their data in a structured format, for example JSON or CSV? Is this really what portability means ?

And for all these questions, there is rarely one perfect technical answer. The right solution depends on your architecture, the sensitivity of the data, the purpose for which it is processed, the applicable legal basis, your retention requirements and, more generally, the risks associated with the processing.

AI System? Think AI Act

First of all, what does the EU actually mean by an AI system? The first time I heard about the AI Act, my reaction was basically: “Yep, another EU framework trying to regulate everything called AI.”

And honestly, that reaction wasn’t completely wrong 🙃 !

The original proposal dates back to 2021, well before the LLM boom. So the AI Act was never designed only for LLMs systems. From the start, the idea was much broader: regulate machine-based systems that infer from inputs how to generate outputs such as predictions, content, recommendations or decisions (yeah that is a very broad definition…).

In other words, yes, LLMs are covered. But so are ranking models, recommendation engines, scoring systems and all the other machine learning projects/methods we usually use.

For us, I think there are really three things worth remembering about AI Act:

1. Know your role: are you providing the AI system, deploying it, or acting somewhere else in the value chain?
2. Know your use case: what the system actually does largely determines how the AI Act treats it.
3. Check the underlying model: if a General Purpose AI model is involved (we will define it) another regulatory layer may apply.

First: know your role

The AI Act does not only care about what the AI system does. It also cares about what your company does with it. The regulation defines several actors: Provider, Deployer, Importer, Distributor, Authorised Representative, Product Manufacturer, etc.

For most Data practitioners, I would suggest you to remember the two first:

• Provider: develops an AI system and places it on the market or puts it into service under its own name. Think of the organisation responsible for bringing the system into use.
• Deployer: uses an AI system under its authority. Think of the organisation operating the system in a real business context.

There is one important trap though: your company does not have one permanent role. Why ?Because imagine you use an external model to build your own internal recruitment application. You did not build the underlying model, but that does not automatically make you “Ooooh, i’m just a Deployer 🫣“. If you put the downstream AI system into service under your own name, you may be also its Provider.

Second: know your use case

Once we know who we are, we need to categorize what your AI system is actually doing.

The AI Act is usually described as a risk based framework. For us, the easiest starting point is simply the use case. A system does not become high risk because it uses an LLM, billions of parameters or some really fancy architecture. What matters much more is its intended purpose and context of use.

At a simple level, there are four categories worth knowing:

• Prohibited practices: AI is prohibited for uses such as manipulative or deceptive techniques that materially distort behavior and cause significant harm, social scoring, biometric categorization inferring sensitive attributes (e.g. race, gender), and uses of real-time remote biometric identification in public spaces (non-exhaustive list, see details).
• High risk systems: AI systems used in sensitive contexts such as recruitment, education, access to essential services or remote biometric identification (see details).
• Transparency obligations: some AI systems remain permitted but must disclose how AI is involved, for example when users interact with AI, when synthetic content must be marked, or when deepfakes, emotion recognition or biometric categorization are used (practically, it’s the “Generated by AI” footnote you see on ads if it has used AI).
• Other AI systems: systems outside these categories are not subject to these specific AI Act regimes, although other legal obligations may still apply.

Now that you know your use case fit in which category, the legal requirement differs by your role, for example.

For high risk systems:

• Provider: ensures risk management, data governance, technical documentation, logging capabilities, conformity assessment, accuracy, robustness and cybersecurity.
• Deployer: ensures correct use of the system, human oversight, operational monitoring and retention of required logs.

And for transparency obligations:

• Provider: builds the required transparency mechanisms into the system, such as AI interaction notices or watermark of AI generated or manipulated content.
• Deployer: informs affected persons when required, for example when using emotion recognition or biometric categorisation systems, or when involved in deepfakes.

Third: understand the GPAI layer

As we saw earlier, the AI Act was initially drafted before the generative AI wave. That is important, because the original regulation logic was mainly built around decade-long ML systems and not to regulate specifically Generative AI.

Therefore, the European Commission added another layer: General Purpose AI (GPAI), with specific regulatory requirements applying at the model level. So, let’s define the terms first, as they are used in the AI Act:

• GPAI model: a general purpose AI model designed to perform a wide range of tasks and to be integrated into many downstream systems. LLMs are a common example, but GPAI can also include general purpose image, audio, video or multimodal models. 
• GPAI model with systemic risk: a GPAI model with high impact capabilities, I know definition is broad but think frontier models. One of the legal presumptions is triggered when the cumulative amount of compute used for training is greater than 10^25 FLOPs (warning, this is still on debate, and can be upgraded over time !).

Imagine we build a recruitment assistant using GPT to rank resumes:

GPAI model (GPT) → AI system (recruitment assistant) → use case (resume ranking)

Here, GPT is the underlying GPAI model. The recruitment assistant is the AI system built on top of it and resume ranking is the specific use case.

Why does this distinction matter? Because the AI Act now asks two different questions.

• At the model level, we look at the GPAI itself and the obligations of its Provider, such as technical documentation, information for downstream providers, copyright compliance and transparency around training content. If the GPAI model presents systemic risk, additional obligations apply around model evaluation, risk mitigation, incident reporting and cybersecurity.

• At the system level, we look at what the final application actually does. Who is the Provider or Deployer? What is its intended use? Which risk category applies? In our example, using AI to rank candidates brings the recruitment assistant into the High Risk regime.

The nutshell cheatsheet

And now we can finally put everything together:

---

The American Way 🇺🇸

If Europe loves frameworks, the U.S. loves exceptions, sectors and jurisdictions 😅.

There is no single American equivalent of GDPR + the AI Act telling you, in one place, how Data and AI systems should be handled. Instead, the rules are spread across federal laws, regulators and state laws.

Take candidate ranking again. In Europe, you quickly land in the AI Act’s High Risk regime. In the U.S., there is no equivalent universal label. But that does not mean “no regulation”. Employment discrimination law may apply, a state may impose additional rules on automated decisions, and regulators can still intervene if the system creates unlawful discrimination or if you make misleading claims about what it does.

For Data practitioners, the useful takeaway is simple: in the U.S., AI regulation often comes from laws that were not written specifically for AI.

First: think Federal

At the federal level, AI is often regulated through existing laws and regulators rather than one AI BIG JUMBO framework. The useful question is therefore: Which regulator would already care about this activity even if AI were not involved?

Let’s take some examples:

• Hiring / employment → Equal Employment Opportunity Commission (EEOC) & Americans with Disabilities Act (ADA): resume screening, candidate ranking, video interview scoring or employee evaluation systems can trigger federal anti discrimination rules. An automated system that disproportionately excludes protected groups or disadvantages candidates with disabilities can create legal exposure.
• Credit / lending → Equal Credit Opportunity Act (ECOA): credit scoring, loan approval, credit limits or pricing models remain subject to anti discrimination and adverse action requirements. If credit is denied or offered on worse terms, the creditor may need to provide the specific reasons behind the decision.
• Healthcare data → Health Insurance Portability and Accountability Act (HIPAA): AI pipelines processing Protected Health Information can inherit privacy and security requirements around access, permitted uses, disclosure and safeguards. Sending patient data to an external model provider is therefore not just an API design decision.
• Clinical AI → Food and Drug Administration (FDA): if an AI based software function qualifies as a medical device, warning Sir !, because safety, effectiveness, validation and potentially premarket requirements enter the picture.
• Consumer facing AI → Federal Trade Commission Act (FTC): claims such as “99% accurate” or “fully automated” need to be supportable. Misrepresenting an AI system’s capabilities, accuracy, biases or behavior can become a consumer protection issue.

Second: think State

Federal law is only one layer of the U.S. regulatory landscape. Individual states can impose their own privacy rules, requirements for automated decision making, and AI specific legislation, which means that the obligations attached to the same system can change depending on where it is deployed or used.

California is a useful example ☀️. The California Consumer Privacy Act (CCPA) gives consumers specific rights over their personal information, including rights to access, delete, and limit certain uses of that data (somewhat like RGPD that we saw below). These rules do not regulate AI as a technology in itself, but they can directly affect AI systems when personal information is collected, processed, or used to make decisions.

Other states take different approaches. Colorado regulates certain high risk AI systems used in consequential decisions, Texas adopted the “Texas Responsible Artificial Intelligence Governance Act”, and Utah introduced disclosure requirements for defined uses of generative AI.

So yes, you get the idea: I’m not going to map all 50 states and their differences here. The key point is that these laws differ in scope, terminology, covered systems, and obligations. There is no single “state level AI rule” that applies uniformly across the United States.

For Data and AI teams, this fragmented landscape creates a concrete architecture decision when the same product is deployed across multiple states:

• Option 1: build one national baseline that satisfies the strictest requirements the organization chooses to support.
• Option 2: make parts of the product jurisdiction aware, so disclosures, opt outs, user rights, or decision workflows change according to the applicable state law.

The first approach reduces product variation but can impose stricter controls than legally required in some states. The second preserves local flexibility but increases implementation and governance complexity because the system must reliably determine when different rules apply.

---

Let’s conclude

The conclusion is going to be a little harsh 🙂: we have barely scratched the surface of IT compliance.

AI regulation and data protection are only two layers. In Europe, organizations may also face cybersecurity obligations under frameworks such as NIS2, while specific industries add their own requirements. Financial institutions, for example, must consider the Digital Operational Resilience Act (DORA), while life sciences operate under Good Practice (GxP) requirements. ISO 27001, meanwhile, is not a law but a standard for building an information security management system, and Governance, Risk and Compliance (GRC) is the broader discipline used to organize these controls, risks, and obligations.

The United States follows the same general pattern we saw throughout this article: there is rarely one rule to look at. Federal requirements, state laws, sector specific regulation, privacy obligations, cybersecurity rules, and contractual requirements can all overlap around the same system.