What the EU AI Act actually requires of a masking layer

The Act never uses the word masking. It does not need to. Three articles, on data governance, record-keeping and human oversight, each describe a property a masking layer either has or does not, and retrofitting any of the three after a system is running costs far more than building toward them from the start.

Key takeaways

• Article 10 permits processing special category personal data only for bias detection, and only under conditions that already sound like a masking layer: strict security measures, no transmission to third parties, deletion once the purpose is served.
• Article 12 requires automatic logging over the lifetime of a high-risk system, with no specified retention period, which means the logging capability has to exist before anyone decides how long to keep it.
• Article 14 requires a human overseer to be able to interpret, override and stop a system, which fails silently if nothing in the pipeline explains what data reached a decision.
• Recent research on regulatory compliance argues that audit-time, binary compliance is structurally the wrong model for a running system; the requirement is a continuous signal, not a certificate filed once.
• None of this depends on whether a given system is formally classified as high-risk. The three properties are worth building toward regardless, because they are expensive to add later and cheap to design in now.

What does the Act actually say about data?

Article 10 governs training, validation and testing data for high-risk systems, and most of it reads like ordinary data-quality discipline: datasets have to be relevant, sufficiently representative and, to the best extent possible, free of errors. The part that matters for a masking layer is narrower and stricter. The Act allows processing of special category personal data, health, ethnicity, and similar sensitive fields, but only for the specific purpose of detecting and correcting bias, and only when a list of conditions holds: no alternative data would serve the purpose, technical limits restrict reuse, strict security measures apply, the data is never transmitted to third parties, and it is deleted once the bias has been corrected.

Read as an engineering requirement rather than a legal one, that is a masking and lifecycle policy with a narrow, purpose-bound exception carved into it. A system that cannot say which fields are sensitive, cannot restrict a specific processing purpose to a specific dataset, and has no deletion trigger tied to that purpose ending, has no way to satisfy this even if the underlying use case is legitimate. The masking boundary I described in why the masking layer matters more than the model is the component that makes the distinction between sensitive and non-sensitive fields exist at all; Article 10 is one concrete reason that distinction has to be enforced, not merely documented.

What has to be logged, and why does that matter for masking?

Article 12 requires that high-risk systems technically allow automatic recording of events over their lifetime, so that the system's functioning is traceable. Notably, it does not specify a retention period. That omission is easy to misread as leniency; in practice it means the logging capability has to exist unconditionally, because nobody can decide how long to keep records that were never captured in the first place.

A masking layer sitting at the boundary between internal systems and a model is naturally the place this logging belongs. It already sees every field that leaves the boundary, so it is the cheapest point to record what left, in what form, and under what placeholder mapping. Building this after the fact means reconstructing months of decisions from application logs that were never designed to answer a compliance question. Building it into the boundary from day one means the audit trail is a side effect of normal operation, which is the only version of record-keeping that survives contact with an actual audit.

What does human oversight mean for an automated pipeline?

Article 14 requires that a human assigned to oversee a high-risk system can understand its capacities and limitations, remain aware of the tendency to over-rely on its output, correctly interpret what it produced, and override, disregard or stop it. None of that is possible if the system presents a final answer with no visible path to the data behind it.

This is where masking and oversight pull in the same direction rather than against each other. A masking layer that replaces sensitive values with stable placeholders, the design I described in the same earlier article, gives a human reviewer something concrete to check: which fields were substituted, whether the substitution was correct, and whether the model's answer still makes sense once the real values are restored. An oversight requirement bolted onto a system with no visibility into what the model actually saw reduces to a person clicking approve on a black box, which satisfies the letter of the article and defeats its purpose.

Why does audit-time compliance fail for a running system?

A 2026 paper on regulatory compliance for deployed LLM systems argues that treating conformity as a binary, audit-time verdict is structurally mismatched to a requirement built around ongoing oversight and the detection of behavioural drift. The authors propose governance from metrics: compliance as a continuous signal derived from runtime observability, not a static assessment filed once and forgotten. Their own validation, a panel of small on-premise models scoring compliance criteria, found agreement rates between 51.5% and 69.1% depending on the model, with no single model dominating across every criterion, which is itself evidence that compliance judgement is not a solved, one-shot problem even with dedicated tooling.

The relevance here is architectural rather than a specific product recommendation: whatever machinery ends up checking compliance, it needs a continuous stream of real signal to check, not a document written before launch and never revisited. A masking layer with logging built in produces exactly that stream as a by-product of running. A compliance binder produced once for an audit does not, and updating it by hand every time the system changes is precisely the kind of expensive retrofit the rest of this article has been describing.

FAQ

Does this mean my system is legally classified as high-risk under the Act?

Not necessarily, and that classification depends on specifics this article does not cover, listed in the Act's Annex III. The three properties discussed here, purpose-bound handling of sensitive data, unconditional logging and genuine human oversight, are worth building regardless of classification, because the cost of retrofitting them after a system is running is far higher than the cost of designing them in.

Is a masking layer enough to satisfy Article 10 on its own?

No. Article 10 is about the training, validation and testing data pipeline as a whole, including bias examination that a masking layer does not perform. What a masking layer provides is the enforcement mechanism for the purpose-bound, security-conditioned handling that the special category data exception requires; the bias assessment itself is separate work.

Do I need a dedicated compliance tool like the one in the cited paper?

Not necessarily this specific one; it is research software, not a product recommendation. The useful idea to take from it is the framing: compliance as a continuous signal your system produces, not a document written once. Whether that signal comes from a purpose-built tool or from disciplined logging at your masking boundary is a separate decision.

Is this legal advice?

No. I am reading the Act's text as an engineer deciding what to build, not as a lawyer assessing legal exposure. Treat the article numbers as a starting point for a conversation with counsel, not as a substitute for one.

References

• Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal version of 13 June 2024. Articles 10, 12 and 14. Article 10, Article 12, Article 14.
• Jehanne Dussert. Who judges the judges? Governance from metrics: a runtime framework for continuous LLM compliance monitoring, 2026. arxiv.org/abs/2605.24737