Reading the EU AI Act as an Engineering Specification for Workplace AI
We have written before about the classification side of the EU AI Act — training models that decide where a system sits in the Act's risk taxonomy. Since 2 August 2026, the other side of the fence matters just as much: the obligations that apply once a high-risk system is deployed. We build AI into an employment platform, which puts us in an unusual position. We are a provider whose customers are deployers, and the systems in question — anything that evaluates, allocates, or monitors workers — are exactly the ones Annex III designates as high-risk. So we have spent a lot of time reading Articles 12, 14, and 26 the way we read any specification: as a list of system behaviours someone eventually has to implement. This article is that translation.
The Deployer Is a Systems Role, Not a Legal Role
The Act's deployer duties sound organisational — use the system per its instructions, ensure oversight, monitor operation. In practice each one decomposes into capabilities that either exist in the software or do not. A deployer cannot "monitor operation" of a system that exposes no operational telemetry. A deployer cannot "ensure input data is relevant and sufficiently representative" if the system gives no visibility into what data actually reached the model. Compliance postures inherit the ceilings of the systems underneath them. That framing changes procurement conversations: the question is not "is this vendor compliant?" but "does this system give me the affordances my own obligations require?"
Logging: Provenance, Not Printf
Article 12 requires high-risk systems to log automatically over their lifetime; Article 26 makes deployers keep those logs. The naive reading produces an application log. The useful reading produces a decision provenance record. The difference is what question the artefact can answer. An application log answers "what did the process do?" A provenance record answers "why did this worker receive this output?" — which is the question a works council, a regulator, or a court will actually ask. For our own AI features we settled on a bounded output package per decision-relevant inference:
- What was asked, with which inputs, against which model and version.
- What grounding data was retrieved and from which tenant's isolated store.
- What was returned, with uncertainty surfaced rather than suppressed.
- Who saw it, and what human action followed.
That last line matters more than it looks. The Act's oversight model assumes a human between the system and the consequence. If your audit trail ends at the model output, you cannot demonstrate that the human was really there.
Human Oversight Is a UX Problem Wearing a Legal Costume
Article 14 requires that systems be designed so the humans overseeing them can understand capabilities and limitations, spot anomalies, decide not to use an output, and interrupt the system. Every one of those verbs is an interface decision. Oversight fails quietly through automation bias: a confident-looking score next to a name, a default-accept button, a queue that rewards throughput. The engineering counters are unglamorous and effective — show the evidence beside the conclusion, make "insufficient evidence" a first-class output state, price the override at the same interaction cost as the acceptance, and record both equally. We took the same position in our classifier work: a system that cannot say "I am not sure" with a straight face is not fit for compliance workflows.
Article 26(7): the Notification Nobody Builds For
Before a high-risk AI system goes live at a workplace, workers and their representatives must be informed. Legally this is one sentence. Operationally it is a workflow with state: which representative bodies exist in which countries, what was shared with each, when, what questions came back, what was answered, and — in co-determination countries — what agreement gates the go-live. In Germany that is typically a works agreement; in the Netherlands, a consent right. A deployment plan that models "notify workers" as a milestone rather than a process with dependencies will discover the difference in production. This is where our two worlds meet: the AI governance problem degrades into a labour-relations process problem, which is the problem Graylark LRM exists to run. The deeper analysis of the consultation side is on our sister site: the AI Act and works councils.
Change Management: the Obligation With a Loop In It
Models get retrained. Thresholds move. Vendors ship features that change what a system infers about people. Each material change potentially re-triggers the stack above: re-classification, updated instructions for use, refreshed logs and oversight design, and — where representative agreements describe the system as deployed — renewed engagement, because the thing described no longer exists. We treat this as release engineering: model and prompt versions are part of the release artefact, releases that alter decision-relevant behaviour are flagged, and the flag propagates to the compliance record. Without that plumbing, an organisation's AI register describes last year's systems.
Where We Landed
The AI Act's workplace provisions reward a property that good engineering organisations already value: the ability of a system to explain itself after the fact. Provenance-grade logging, honest uncertainty, oversight interfaces that assume the human might disagree, and change management that knows which releases matter — none of this is exotic, and all of it compounds. Teams that build these properties in are not just compliant; they ship AI that their own works councils, customers, and auditors can be shown without flinching. That, in our experience, is what actually unblocks enterprise AI adoption.
For the broader platform context behind this work, visit Graylark Technologies.