If you read one thing about the EU AI Act this summer, it was probably that parts of it had been delayed. [1]
Those delays affected many of the high-risk requirements companies had been preparing for. The Digital Omnibus, Regulation (EU) 2026/1744, pushed the deadline for Annex III systems from August 2, 2026, to December 2, 2027, while requirements for high-risk systems embedded in regulated products under Annex I were moved to August 2, 2028.[2] For companies operating systems used in areas such as hiring or credit scoring, this gives them considerably more time to prepare.
But another set of obligations arrived on schedule. The transparency obligations in Article 50 began applying on August 2, 2026, including requirements governing how certain AI-generated or manipulated content is identified. [1] Violations can carry fines of up to €15 million or 3% of worldwide annual turnover under Article 99(4)(g). [1]
The Omnibus left that date alone, and its one concession was a four-month transition on the machine-readable marking duty in Article 50(2), and only for generative systems already placed on the market before August 2, 2026. That transition ends on December 2, 2026. [2]
Article 50 matters for reasons that go beyond the deadline itself. Some of its requirements begin to shift AI compliance from documenting what a system is supposed to do toward producing evidence that others can use to verify what actually happened.
Figure 1. Two of the three deadlines moved. Article 50 did not, and the one Article 50(2) transition ends 2 December 2026.
Why Article 50 requires more than disclosure
At first glance, Article 50 looks primarily like a disclosure rule. Several of its requirements focus on telling people when they are interacting with an AI system, when content has been artificially generated or manipulated, or when certain systems are being used to infer emotions or other characteristics.
Article 50(2) introduces a different kind of requirement. It says providers of generative AI systems must mark certain outputs in a machine-readable format and ensure they are “detectable as artificially generated or manipulated.”
The word “detectable” matters here. Marking an output is something the provider does. Detectability requires that someone else be able to recognize that marking later, potentially using a verifier the provider does not control, and on a copy of the content that has already left the original system.
That changes the compliance question. It’s no longer enough to say that a system was designed to mark its outputs. An organization may also need to produce evidence showing that the marking can actually be detected outside its own environment.
That distinction between documenting what a system is supposed to do and demonstrating what it actually did is what makes this requirement more difficult than it first appears.
The compliance model has changed, but many programs have not
Software teams are accustomed to compliance frameworks such as SOC 2 [3], ISO 27001 [4], and ISO/IEC 42001 [5], which largely assess whether an organization has established and follows the right management processes. A company documents what it does, an assessor tests those processes, and the result is an evaluation of how well that management system operates.
The EU AI Act introduces a different model. It draws on the EU’s New Legislative Framework for product regulation, which uses harmonized standards, conformity assessments and technical documentation to see whether a product meets applicable requirements. [6] For high-risk AI systems, the Act similarly requires technical documentation that regulators and other assessors can use to evaluate whether the system itself complies.
That shift extends beyond Article 50, though on a later clock. The record-keeping duties that follow are high-risk obligations, so they now fall due in December 2027 rather than this August. Article 12 requires automatic logging across the lifetime of a system, while Article 19 requires providers to keep those logs. Article 26(6) places related record-keeping obligations on deployers when those logs are under their control. [1]
Together, those requirements point to records that remain available and understandable after the activity they document has occurred. A written policy alone cannot provide that evidence.
AI agents make that distinction even more consequential. When software can take actions across multiple systems on an organization’s behalf, having a policy that says what an agent is allowed to do is different from being able to demonstrate that a specific action was actually authorized. That gap is the difference between documenting a control and proving that it worked.
How to build compliance mapping that can be verified
Most organizations preparing for the AI Act will create a compliance mapping table, a tool that links regulatory requirements to internal security controls and assigns a status to each. That can be useful, but it becomes less reliable when multiple items are written into a single cell.
A stronger mapping table separates five elements.
Requirement: Start with the specific legal obligation, ideally at the paragraph level rather than the article level. An article can contain several distinct duties, so citing only the article can create the appearance of full coverage even when one requirement has been missed.
Control: Identify what the system or process is expected to do to satisfy that requirement.
Assessment method: Define how someone will determine whether the control is actually present and functioning as intended.
Evidence locator: Identify the artifact that can be produced to support that assessment, whether that is a clause, test result, exported record, or other documented output. If the evidence cannot be located and produced, the control is difficult to assess in any meaningful way.
Residual gap: This is what most tables are missing. State what the control does not cover. Every control has boundaries, and leaving those boundaries unstated can make compliance mapping look more complete than it actually is.
Figure 2. “Partial” is three answers collapsed into one.
The same precision should apply to status labels. “Partial” often collapses several very different findings into one category. A control may be incomplete, meaning required behavior is missing; unverifiable, meaning the behavior exists but produces no evidence that an assessor can check; or out of boundary, meaning the obligation sits outside the scope of the system being assessed.
Those findings require different responses. Treating them all as one status makes the assessment much harder to act on.
What testing the controls actually revealed
I spent six months this year applying this method to a production AI agent platform. Across eleven articles of the EU AI Act, two fell outside the system’s scope. None were fully covered, while nine were assessed as only partially addressed.
Article 12, which covers record-keeping and automatic logging for high-risk AI systems, was one of the strongest areas in the assessment. Yet testing still uncovered a serious flaw: one chain verification function returned true unconditionally. Three of the four audit implementations reviewed also contained integrity defects.
At first, that looked like an isolated implementation issue. Then the same underlying problem appeared in a separate specification maintained by a different team and codebase. In that case, the specification required a verifier with no revocation evidence to report that no revocation check had been performed. Instead, the reference implementation returned a passing result.
The problem in both cases was the same. The system could report that a check had passed or failed, but it did not have a clear way to report a third outcome: “I did not check.” When that uncertainty had nowhere to go, it was effectively converted into a pass.
That was the most useful thing six months of this work taught me. The lesson also extends well beyond software: any assessment with only two outcomes risks turning “unknown” into “pass.” If a status system has no way to record that something was not tested, an unknown result can quietly become a positive one.
Figure 3. A verifier that cannot fail reports success.
When existing frameworks don’t fit AI agents
The gap is not only in how controls are implemented. It can also exist in the frameworks that organizations use to map those controls.
While mapping an AI agent control set into a widely used, open cross-standard requirements corpus, I reviewed all 522 requirements and searched for several concepts central to agentic systems. [7] “Agent” returned zero results. So did “delegation,” “attestation,” “provenance,” and “non-repudiation.” “Identity” returned one result: verifying a person’s identity during credential recovery.
The corpus itself is strong in many areas and handles issues such as prompt injection well. It organizes what published standards already state, so the absence sits upstream of it: the standards it draws on do not yet address a non-human agent with its own identity that acts autonomously and can delegate authority to another agent.
That matters because a mapping exercise does not fail loudly when the destination is missing. Instead, it can map a new type of risk to the nearest existing requirement, leaving the table looking complete even though the underlying framework does not actually address the issue. Proposals are underway to close some of these gaps, but they’re not yet resolved.
Figure 4. Some of the map has no destination.
What to do next
There are three practical steps organizations can take now, none of which require a new procurement cycle.
First, break one article down to the paragraph level and see whether your existing compliance mapping still covers each requirement.
Second, identify the evidence behind one control currently marked green. If nobody can name the artifact that proves the control worked, that is a gap worth addressing.
Third, make the control fail. Feed it something that should be rejected and confirm that the system responds as expected. In both of the implementations I tested this year, the controls could not do that: each function returned true regardless of input, while the corresponding assessments still showed only a partial gap.
The delays gave organizations more time to prepare for some of the AI Act obligations. However, Article 50 deserves more attention than it has received. Its requirements are already in effect, signaling a broader shift in AI compliance.
Organizations need to be ready to show what happened, with evidence that an outside party can verify. When an assessor or regulator comes asking, the real test will be whether that proof can actually be produced.
References:
- European Union, Regulation (EU) 2024/1689 (EU AI Act). https://artificialintelligenceact.eu/
- European Union, Regulation (EU) 2026/1744 (Digital Omnibus on AI). https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
- AICPA, SOC 2. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
- ISO, ISO/IEC 27001. https://www.iso.org/standard/27001
- ISO, ISO/IEC 42001. https://www.iso.org/standard/42001
- European Commission, New Legislative Framework. https://single-market-economy.ec.europa.eu/single-market/goods/new-legislative-framework_en
- OWASP OpenCRE (open cross-standard requirements corpus). https://opencre.org/
