On May 7, 2026, the EU agreed to push the AI Act's high-risk system deadline from August 2, 2026 to December 2, 2027. A lot of engineering teams read that headline as "enforcement moved, we can wait." That reading is wrong for one specific reason: three enforcement mechanisms still activate on the original August 2, 2026 date regardless of the Annex III delay — Article 50 transparency obligations for AI-generated content, GPAI penalty enforcement, and national market surveillance authority. None of the three care whether your coding agent falls under Annex III. All three can reach a pull request.
What the Digital Omnibus Actually Deferred
The Digital Omnibus deferral applies to Annex III high-risk categories — biometrics, critical infrastructure, education and vocational training, employment and worker management, migration and border control. If a coding agent is used to screen job applicants or allocate worker tasks, that gets until December 2, 2027. If it is used to write, review, or ship application code, the Annex III delay does not apply, because ordinary developer tooling was never an Annex III category to begin with.
Three Obligations That Still Land on August 2, 2026
These activate on the original date, unaffected by the high-risk deferral:
Article 50 transparency. AI-generated or AI-manipulated content that an organization publishes or ships externally must be disclosed as such. This applies independent of whether the underlying use case is high-risk.
GPAI penalty enforcement. General-purpose AI model provider obligations have applied since August 2025; the Commission gains fining power against providers on August 2, 2026. If internal tooling is built on top of a GPAI model, the provider's compliance posture becomes your vendor risk.
Market surveillance authority. National authorities gain full investigative and sanction power on the same date, with penalties reaching €15 million or 3% of global turnover for violations within their remit.
The Documentation Gap This Exposes
Consider an engineering org routing 40% of commits through Copilot or Claude Code with zero record of which pull request came from which agent or model, and no log of which shipped output was ever disclosed externally as AI-generated. When a market surveillance authority asks for the Article 50 disclosure log covering AI-generated content shipped to customers, most teams have no answer — not because they failed to comply, but because they never built an artifact capable of answering. The same gap shows up in GDPR data-handling reviews and ISO 27001 audits — auditors ask for provenance records that most pipelines were never built to produce.
What to Have in Place Before August 2
A per-PR attribution log tying each code change to the specific agent or model that generated it, not just "AI-assisted: yes/no."
A documented human-review gate that demonstrates oversight occurred before merge — this is the evidence Article 50 and GPAI vendor reviews will ask for first.
A retained audit trail that is queryable by date and content type, not merely reconstructable from git blame after the fact. This maps directly to the risk-mapping approach in the NIST AI RMF guide.
How re-entry.ai Closes the Gap
re-entry.ai's FMEA-based PR risk scoring attaches agent and model provenance to every AI-attributed pull request, and its audit trail and MCP Gateway logging give compliance teams a queryable record — before an examiner asks, not after. Start at re-entry.ai or request a demo to see the provenance log against your own pull request history before the August 2 deadline.