AI training after the SRB ruling: A practical playbook for engineers who now define compliance

Those who build artificial intelligence systems today — especially in domains like human resources, workforce analytics, health-adjacent services or behavioral platforms — are no longer just writing code. They are shaping how data protection law applies to systems.

That is not because engineers are being asked to become lawyers. It is because the law, particularly after the Court of Justice of the European Union's Single Resolution Board judgment, is starting to catch up with how systems actually work. The EU General Data Protection Regulation no longer treats personal data as a label stuck to a dataset forever. It treats identifiability as something that depends on architecture, access and capability.

In other words, what a system can realistically do determines what the law thinks is happening.

This is most visible when AI training involves special category data. Many teams assume that if such data ever existed in the pipeline, training is either forbidden or requires some heroic legal justification. That assumption is wrong; and it's not "don't worry about it." The correct answer is to design systems so the legal question has a clear, documented and defensible answer.

The SRB ruling clarifies that there are two legitimate ways to do this. Which one is the result depends almost entirely on engineering choices.

Let's start with something that often confuses teams. Unlike consent, legitimate interest, vital interests, performance of a contract, and others, pseudonymization is not a separate lawful basis of processing the data. Hashing identifiers, tokenizing records or stripping names does not magically authorize new processing. It is a technical measure. It reduces risk. It does not change why the data exists or what the controller is allowed to do with it.