Many companies have read the AI Omnibus mainly as a timetable announcement. That is understandable—and operationally risky. A changed deadline does not tell you which AI systems your organisation actually uses, who is authorised to make decisions about them, or whether today’s evidence would survive scrutiny.
Note: General professional guidance; not legal advice or a certification or audit guarantee.
The AI Omnibus entered into force on 27 July 2026. It introduces targeted simplifications, support measures and changed dates of application. More precisely, Chapter III, Sections 1 to 3 of the AI Act—with the exception of Article 6(5)—apply from 2 December 2027 to systems classified as high-risk under Article 6(2) in conjunction with Annex III. Those sections apply from 2 August 2028 to systems classified as high-risk under Article 6(1) in conjunction with Annex I. Other parts of the AI Act regime follow their own timelines. “The AI Act has been postponed” is therefore not a reliable blanket statement.
At the same time, 2 August 2026 remains a general implementation, supervision and enforcement milestone: from that date, the AI Office and Member State authorities are responsible for implementing, supervising and enforcing the Act, while the transparency rules apply from August 2026. The ninth prohibited practice added by the Omnibus—AI systems that generate non-consensual sexually explicit or intimate content or child sexual abuse material—applies from December 2026. Companies therefore need a use-case-specific timeline covering obligations already in force, requirements taking effect during 2026 and later dates of application, not one supposed finish line.
Germany’s AI Market Surveillance and Innovation Promotion Act (KI-MIG) has additionally been in force since 29 July 2026. The Federal Network Agency is the general market-surveillance authority unless the Act assigns a sectoral or state authority; it is therefore not Germany’s sole AI regulator. The Act also establishes a coordination and competence centre at the Agency, together with the central point of contact and central complaints office. A governance inventory should therefore identify not only the relevant EU provision but also the competent authority, supervisory route and any applicable sectoral regime for each use case.
Management should therefore focus not on the supposed gain in months but on present decision capability: the company must be able to explain which systems it controls, why it classifies them as it does and who may accept an exception.
The real pain: AI grew faster than its accountability structure
Most organisations now have a mixture of centrally sponsored AI projects, purchased SaaS features, embedded copilots, local experiments and functions that become “AI-enabled” after a product update. Procurement, privacy, information security, Legal, IT and business teams each maintain fragments of the picture. No one owns a defensible whole.
The gap appears when an approval is needed. The permitted use of employee data, the company’s role in the value chain, the assessed model version and the practical form of human oversight must then be clear. A spreadsheet containing a product name cannot resolve the decision if these relationships are missing.
An AI inventory without accountable owners is like an organisation chart without names—beautifully structured and remarkably quiet during an incident. The mechanism is less amusing: without explicit decision rights, risk is passed from team to team until time pressure makes the decision by default.
Consider a hypothetical operating situation. An international mid-sized company enables a new summarisation feature in its recruitment platform. Procurement knows the SaaS contract, HR knows the intended purpose, Privacy knows the data categories and IT knows the authentication setup. Yet, on the day of approval, nobody can say with authority whether the feature merely condenses text or already influences candidate pre-selection. The product label does not resolve that question; actual use in the process does.
The team should therefore not begin by debating an abstract risk colour. It should reconstruct the workflow: what input the system receives, what output it creates, who sees that output and which decision follows. Only then can role, affected people, oversight and controls be assessed coherently. If the purpose remains vague, the classification is precise only in appearance. In this hypothetical case, management might restrict use to summarisation, require a documented human review and treat any extension of purpose as a reassessment signal. An unclear tool question has then become a concrete operating decision.
That does not close the case. HR must translate the limitation into process design and working instructions; IT must align enabled features and permissions with the approved scope; Procurement must surface vendor changes; and Privacy and Information Security must base their reviews on the same purpose statement. If every function keeps its own shorthand description of the use case, good individual work still produces four versions of the truth. The inventory therefore becomes a shared decision object. It does not duplicate every specialist document, but connects the valid versions, owners and open issues.
A common governance failure would be to treat the recruitment tool as static after its initial approval. Three months later, the vendor enables a new ranking option, HR trials it with live cases and IT regards the update as routine product maintenance. Without a change signal, the authorised decision-maker never receives the information. The primary failure is then not missing expertise but a broken handover. A defensible inventory assigns the product update a reporting route. Until reassessment, the new function remains disabled or restricted to a controlled test environment.
Management can now distinguish three decisions. It may continue the existing, narrowly limited use, approve a time-bounded pilot for the extension, or stop the change until specified evidence is available. Each option has an owner, review date and stopping criterion. This is not dramatic governance, but it is defensible. It prevents a technical default from quietly becoming a business decision.
What makes a governance inventory different from a tool list
A governance inventory does not merely document technology. It connects each relevant use case to a controllable decision chain. At least six perspectives are needed.
1. Use case and effect
Record the activity or decision the system supports, the people affected and the plausible impact of failure. “Chatbot” is not an adequate description. “Drafts customer-service replies; does not automatically reject requests or make contractual decisions” is something management can control.
2. Role and value chain
The organisation should document the role in which it acts and the external parties involved. Contracts, product descriptions and actual use must align. A vendor’s marketing label is not a substitute for your own role determination.
3. Classification and rationale
Classification cannot be reduced to a colour or dropdown. It needs a date, owner, source facts, unresolved assumptions and a trigger for reassessment. The rationale is the evidence—not the green cell.
4. Controls and evidence
Each material risk should connect to concrete controls: approval thresholds, logging, access restrictions, tests, human oversight, escalation routes, supplier assurance or training. The storage location, owner, currency and next review date of the evidence matter just as much.
Evidence is not merely an attachment to the register. It connects a claim to actual operation. If “human oversight” appears as a control, the record should show who performs the review, which cases are escalated and which records allow the review to be reconstructed. A training slide proves that a slide exists. It is rather less expressive about behaviour in the live process.
5. Lifecycle and change signals
Model changes, new data sources, changed purposes, product updates and new user groups can invalidate an earlier assessment. The inventory therefore needs defined change signals and a process that initiates reassessment.
6. Management decision
Not every open risk can be engineered away immediately. It must, however, be visible, time-bounded and decided by an authorised role. That is how AI governance and information security become manageable: not risk-free, but decision-ready and auditable.
The relationships in the inventory determine its control value
The six perspectives become useful only as a connected model. A use case points to the current purpose statement, affected services and groups of people. A classification points to the facts and assumptions on which it rests. Controls point to operating roles and evidence. Change signals point to assessments that they reopen. Exceptions point to a specific management decision. If one of these relationships is absent, the inventory may remain searchable without being reliably governable.
This connection also changes how control functions work together. Legal does not assess a product label in isolation but a documented role and use. Privacy can see which change of data or purpose initiates another review. Information Security can relate technical controls to the process that was actually approved. Procurement turns contractual and product changes into governance inputs. The business function remains accountable for the business purpose and cannot delegate that responsibility to a central register administrator.
False confidence often develops at these handovers. A supplier questionnaire may be complete while the local configuration differs from the described standard. A test may have passed but relate to an earlier model version. Documented oversight may exist while the reviewer has neither time nor escalation authority in daily work. The inventory should not flatten these differences into one aggregate status. It keeps the claim, scope, evidence date and residual deviation separate. That may produce less green on the slide, but considerably more control.
Metrics need the same logic. A count of recorded systems measures coverage, not control. The proportion of reasoned classifications indicates formal maturity, but not operational effectiveness. More decision-useful measures include overdue reassessments, high-impact cases without a decision-maker, controls without current evidence and exceptions approaching expiry. Each metric should have a predetermined management response. Otherwise, the dashboard is merely a very well-lit archive.
The AI Omnibus changes priorities, not the need for control
The changes span different subjects: timelines for certain high-risk categories, measures for SMEs and small mid-caps, sandboxes, selected administrative obligations, AI literacy, oversight and procedural clarity. The previous corporate AI-literacy requirement has been simplified, with the Commission and Member States taking a stronger role in promoting AI literacy. That is not a defensible reason to delete internal capability measures wholesale. The organisation still needs to decide which knowledge its roles require for approval, use, oversight and escalation.
Supervision also becomes more concrete. The AI Office has extended oversight of certain AI systems, including systems built on GPAI models and embedded in very large online platforms and search engines. For GPAI models, it may request technical documentation, evaluate models, require corrective measures and impose fines for non-compliance. The operational consequence for the governance inventory is clear: model dependencies, provider roles, technical documentation, regulatory contacts and open corrective actions must be retrievable and version-controlled. Which Omnibus change matters to a company still depends on the specific system, its role and its context of use.
A global “Omnibus exemption” in the roadmap is therefore the wrong control. A delta procedure is more useful. For each affected use case, document which previous assumption changes under the final legislative text, which remains valid, and which internal action should be rescheduled, adapted or deliberately continued.
A postponed deadline is not a closed risk; it is a risk with more calendar. The mechanism is practical. If teams treat extra time as task removal, dependencies disappear from planning and return shortly before the next milestone as executive escalation.
A second hypothetical situation shows why the distinction matters. A product team plans to extend an already assessed AI feature with a new data source and automated prioritisation. In light of the Omnibus changes, it proposes moving the governance review by several quarters. The delta procedure separates the legal timeline from the operating change: the new data source alters the factual basis, prioritisation changes the potential effect, and both may invalidate parts of the earlier assessment regardless of the next statutory milestone.
The resulting decision sequence is deliberately plain. First, record which assumptions remain valid. Then identify affected controls and evidence. Finally, the authorised role decides whether to approve the extension, limit it to a controlled pilot or stop it pending clarification. The inventory thus prevents a general legal update from becoming an accidental product approval. The legislative text sets the framework; the organisation must define its own operational acceptance criteria.
A concrete 30-day start
During week one, consolidate existing lists from Procurement, Privacy, Information Security, Enterprise Architecture, IT and business functions. The objective is not to claim completeness. It is to create a traceable baseline and make search gaps explicit.
In week two, prioritise use cases by impact, affected people and uncertainty. For the highest-priority cases, establish purpose, role, data, vendor, model dependency and decision ownership.
During week three, connect classification decisions and controls to existing evidence. Do not hide missing artefacts behind “in progress”. Give each gap an owner, target date and interim decision.
In week four, provide management with a compact control view: number of prioritised cases, unresolved roles, overdue reviews, critical evidence gaps and upcoming change signals. Avoid traffic lights without rationale and metrics without a defined management response.
After 30 days, the inventory is not “finished”. It is operational for the first time. The quality test is whether an owner can recognise a change, locate the affected assessment and trigger a decision with the supporting evidence. Completeness can then grow in a controlled manner. A large list without that feedback loop, by contrast, quickly loses contact with live operations.
Steady-state operation also requires a clean handover between the business function and central governance. The business function usually sees a change of purpose first, while central teams can see role questions, legal changes and recurring control patterns across several use cases. The inventory has to connect both perspectives. If it is maintained only centrally, it soon drifts away from operational facts. If it is maintained only locally, the same status acquires several definitions. A practical arrangement lets the business owner update changes and evidence while an independent second role reviews classification, exceptions and cross-cutting dependencies.
This creates a clear decision logic for management. Executives do not need to approve every technical detail. They need to see where a business purpose meets an unresolved role, missing evidence or inadequate oversight, and what options are available. A time-bounded pilot may be more defensible than an apparently final approval built on thin facts. What matters is that the limitation, review date and stopping criterion are recorded. Governance proves its value not through the number of fields completed, but through better decisions at the handovers.
A short management review secures the next step
- Central, decentralised and embedded AI use is connected in one consolidated view.
- Every priority use case has an accountable business owner and an authorised decision-maker.
- Classifications are reasoned, dated, version-controlled and linked to current evidence.
- Changes to the model, purpose, data, supplier or legal position trigger a use-case-specific reassessment.
- Exceptions are visible, time-bounded and available for management acceptance or escalation.
Conclusion: the A-R-C impulse
The AI Omnibus introduces targeted changes, not a governance-free interval. Updating dates alone merely reschedules ambiguity. Connecting systems, roles, decisions and evidence creates a durable foundation for the next legal change, audit or management decision.
The A-R-C impulse is simple: select the ten AI use cases with the greatest impact or uncertainty. Test each for three things—an accountable role, a reasoned classification and retrievable evidence. Assign every gap an owner and a decision date. That is how AI governance becomes controllable, auditable and management-ready.
Scope and limitations
This article provides a professional governance perspective, not legal advice. It does not replace an assessment of the specific use case, the final legislative text, or advice from competent legal, regulatory or certification professionals. It does not guarantee compliance or any assessment outcome.
Sources
- European Commission, “AI Omnibus enters into force”, published 27 July 2026, checked 2 August 2026: https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
- European Union, AI Omnibus Regulation, Official Journal L 2026/1744, checked 2 August 2026: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744
- European Commission, “AI Act – Regulatory framework”, overview and timeline page, checked 2 August 2026: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- Federal Republic of Germany, AI Market Surveillance and Innovation Promotion Act (KI-MIG), Federal Law Gazette 2026 I No. 223, promulgated 28 July 2026, checked 2 August 2026: https://www.recht.bund.de/bgbl/1/2026/223/regelungstext.pdf?__blob=publicationFile&v=1
About the author
Andreas Rühl supports organizations as an interim CISO and ISMS/GRC advisor. His focus is making information security manageable, auditable and fit for management decisions.