On 27 July 2026, Regulation (EU) 2026/1744, the Digital Omnibus on AI, moved the European Union's high-risk AI obligations back by more than a year. A great many organizations read that as breathing room. It is not.
The requirements did not change. Only the date did. The deferral happened because the harmonized standards that would give high-risk systems a presumption of conformity were not ready in time, a problem with the scaffolding, not with the obligation. Meanwhile the Article 50 transparency and content-labelling duties took effect on 2 August 2026, and the prohibitions and general-purpose model obligations have been in force since 2025.
An organization that treats December 2027 as the start of the work has misread the situation twice, once about what is already binding, and once about how long the preparation actually takes.
Where the obligations stand
| Obligation | Applies from | Status |
|---|---|---|
| Article 5 — prohibited practices | 2 Feb 2025 | In force |
| Article 4 — AI literacy | 2 Feb 2025 | In force |
| General-purpose AI models (Art. 51–56) | 2 Aug 2025 | In force |
| Article 50 — transparency and content labelling | 2 Aug 2026 | In force |
| Article 50(2) — watermarking, pre-existing systems | 2 Dec 2026 | Grace period |
| High-risk, Annex III stand-alone | 2 Dec 2027 | Deferred |
| High-risk, Annex I embedded in products | 2 Aug 2028 | Deferred |
Sources: Regulation (EU) 2026/1744, in force 27 July 2026; AI Act (EU) 2024/1689.
The gap nobody measures
Most AI governance programs begin with a policy and a model register. Both are necessary. Neither is sufficient, because both describe sanctioned AI, the systems someone chose, documented and approved. The governance risk is concentrated in everything else.
You cannot govern what you cannot inventory, and an inventory assembled from procurement records describes intentions rather than behavior. The practical question is not which AI systems the organization approved. It is which ones are running, who is sending data to them, and what leaves the building in the process.
Four classes of ungoverned AI
- Shadow AI — staff using non-sanctioned services, usually with good intentions and frequently with production data pasted into the prompt.
- Compromised AI — sanctioned agents behaving outside their established pattern, because credentials were stolen or the agent was manipulated.
- Adversarial AI — agent frameworks driving reconnaissance and exploitation against the perimeter at machine cadence.
- Local models — workstation-hosted LLMs that never touch a corporate API, never appear in a vendor list, and leave no procurement trail at all.
Only the first of these is commonly discussed, and it is the only one a policy document alone has any chance of influencing. The other three are detection problems.
AI governance is mostly controls you already owe
The NIST AI Risk Management Framework and ISO/IEC 42001 are frequently presented as new disciplines requiring new machinery. Read closely, they ask for something more familiar. Both are management-system frameworks, they require that an organization know what it operates, decide who is accountable, apply proportionate controls, and produce evidence that the controls worked.
The evidence itself comes from capabilities most security programs already have, or already owe under existing obligations:
- Discovery and asset inventory, extended to cover AI services and locally hosted models.
- Access control, so that reaching a model is a decision evaluated against identity, device posture and context rather than a default.
- Data protection, classification and loss prevention on the outbound path, because the prompt is an exfiltration channel.
- Continuous monitoring and audit records sufficient to reconstruct who did what, when, and with which system.
In NIST SP 800-53 terms this is largely SI-4 information system monitoring, AC-3(13) attribute-based access control, AU-13 monitoring for information disclosure, and PM-12 insider threat program. An organization with those controls operating well is closer to defensible AI governance than one with an exemplary policy and no telemetry.
What to do in the next ninety days
- Inventory actual usage, not approved usage. Derive it from DNS resolution, network egress and endpoint process data, sources that describe behavior rather than intent.
- Decide the allowlist explicitly, and make the decision enforceable. An unenforced allowlist is a preference.
- Instrument the data path. Know what content is leaving for which model provider, treat the prompt as an egress channel and inspect it accordingly.
- Make the evidence continuous. Governance assessed annually is governance reconstructed under pressure. Controls should produce evidence as they run.
- Name the accountable owner. Both ISO/IEC 42001 and the AI RMF assume a person, not a committee, answers for the outcome.
Where a platform helps, and where it does not
Vulcan Rampart approaches this as a detection and evidence problem. Its rogue-AI capability identifies the four classes described above by correlating DNS queries to model-provider hostnames, network flows to AI infrastructure, behavioral cadence analysis that separates human from automated activity, outbound payload inspection, endpoint process detection for locally hosted models, and honeypot endpoints that only automation would touch. Findings map to the NIST controls named above and feed the same response and audit pipeline as any other incident.
It is worth being precise about the boundary. This is the control and evidence layer. It is not a governance program, and no platform is. The decisions about which systems are acceptable, at what risk threshold, under whose authority, are organizational and cannot be bought. Vulcan Rampart maps continuous compliance against FedRAMP High, NIST SP 800-53 Rev 5, NIST CSF 2.0, CIS Controls v8, ISO/IEC 27001:2022, SOC 2, the HIPAA Security Rule, PCI-DSS and the CISA Zero Trust Maturity Model. It does not today certify against ISO/IEC 42001 or the EU AI Act, and an organization needing that attestation will need a separate program for it.
What the platform does provide is the part that is hardest to retrofit under deadline. A continuously maintained, evidenced account of what AI is actually running inside the perimeter, and what it is doing with the organization's data.
Three questions worth asking
Governance maturity is easier to assess by interrogation than by documentation. Three questions tend to separate programs that would survive scrutiny from those that would not.
- How many distinct AI services did this organization send data to last month, and how do we know? An answer drawn from the approved-vendor list is not an answer to this question.
- If an employee pasted a customer record into a consumer chatbot this morning, which control would have recorded it, and who would see it?
- If a regulator asked for evidence that our AI controls operated continuously through the last quarter, could we produce it without a project?
An organization that can answer all three is largely ready for whichever framework it is eventually held to, because the underlying capability is the same in each. An organization that cannot has a documentation exercise ahead of it, and the deferred deadline is the window in which to avoid that.