REGULATION → OPERATING PRACTICE · OCTOBER 2026

The EU AI Act is in force: what should an enterprise actually do now?

The useful management question is no longer whether the AI Act matters. It is which AI systems, decisions, people and controls need to change now—and which obligations need to be engineered before later high-risk deadlines arrive.

Decision Note · Published 17 Oct 2026 · Regulatory position checked 21 Oct 2026

Start with the operating system, not the regulation binder

The EU AI Act became generally applicable on 2 August 2026, but its obligations arrive on different clocks. Prohibited practices and AI-literacy provisions have applied since 2 February 2025. Governance and general-purpose AI obligations began applying on 2 August 2025. Article 50 transparency requirements and enforcement powers took effect on 2 August 2026. Following the AI Omnibus changes, rules for Annex III high-risk systems apply from 2 December 2027, while high-risk systems embedded in regulated products move to 2 August 2028.

That sequencing creates a management problem. Enterprises need to comply with obligations already in force while building enough visibility and control to prepare systems that will enter stricter regimes later. A policy document alone cannot do this. The organization needs an AI operating system: inventory, classification, ownership, controls, evidence, monitoring and escalation.

The practical sequence

Discover → Classify → Assign → Control → Evidence → Monitor → Reassess

1. Build an AI inventory that describes work, not just software

A vendor list is not an AI inventory. The same product can support a low-consequence drafting task, an employment decision, a customer-facing chatbot and an autonomous workflow. Those uses do not carry the same regulatory or operational implications.

For each material use, record at minimum: business process; purpose; user population; affected people; provider and model; data used; outputs produced; whether the system recommends or executes actions; human decision point; integrations and connectors; owner; geography; current control environment; and evidence retained.

This also exposes Shadow AI. If employees are using personal accounts for organizational work, the inventory process must discover the work demand rather than merely record approved licences.

2. Classify the use case before designing the control

Prohibited

Identify uses that fall within prohibited practices and prevent them from entering operation. This is a hard boundary, not a risk-acceptance decision.

Transparency-triggering

Identify interactive AI, deepfakes, certain public-interest text and specified biometric/emotion uses where Article 50 creates disclosure or marking duties.

High-risk / preparing

Map Annex III and product-linked high-risk uses early enough to engineer logging, documentation, human oversight, monitoring and other requirements before their application dates.

Other enterprise AI

Most AI uses are not high-risk under the Act, but still need proportionate controls for data, security, authority, quality and organizational accountability.

Figure 01 — Obligation-to-control field

Regulation becomes operational only when each obligation is tied to an owner, an executable control and evidence produced by the work.

01 · DISCOVER

Use + role

Process, purpose, affected people, model/platform, data, geography and legal role.

02 · CLASSIFY

Obligation

Prohibited, transparency-triggering, high-risk candidate, GPAI-related or other enterprise AI.

03 · CONTROL

Executable boundary

Identity, permissions, disclosure, human authority, logging, monitoring and escalation.

04 · EVIDENCE

Operating record

Inventory, approvals, configuration, training/literacy measures, logs, incidents and change history.

REASSESSMENT GATE · A material change in purpose, model, data, integration, geography or autonomy sends the use case back through classification and control design.

DENFORTH synthesis · Regulatory basis checked against European Commission AI Act implementation guidance, 21 Oct 2026.

3. Separate legal role from organizational ownership

The Act distinguishes actors such as providers and deployers. Inside the enterprise, however, implementation still needs named operational ownership. Every material AI use should have a business owner accountable for purpose and outcome, a technical owner for the system and integration, and control functions engaged according to the risk.

Procurement cannot own the use case simply because it bought the licence. IT cannot own the business decision merely because it administers the platform. Legal cannot operate the workflow merely because regulation applies. Ownership has to follow the work and the authority being exercised.

4. Close the obligations that are already live

AI literacy

Article 4 requires providers and deployers to take measures that support the development of AI literacy among relevant staff and other persons dealing with AI systems on their behalf. The 2026 AI Omnibus simplified the provision: no specific or “sufficient” individual level is mandated. Treat literacy as role- and context-based operating capability rather than a generic awareness course; developers, recruiters, executive users, service-desk operators and control specialists face different AI decisions and risks.

Transparency

Article 50 has applied since 2 August 2026. Organizations should identify where people interact directly with AI and where deployer obligations apply to deepfakes, certain AI-generated public-interest text, emotion recognition or biometric categorisation. Build disclosure into the interface or publishing workflow rather than relying on users to remember it manually.

Prohibited practices

Convert prohibitions into enforceable boundaries: procurement criteria, platform configuration, use-case approval rules, monitoring and escalation. A prohibition that exists only in policy is fragile when employees can activate new AI features or external tools without review.

5. Use the runway before high-risk deadlines

The later application dates should be treated as implementation runway. The Commission lists requirements for high-risk systems including risk management, data quality, logging, technical documentation, information to deployers, human oversight, robustness, cybersecurity and accuracy. These capabilities are difficult to bolt onto a live system at the last minute.

For candidate high-risk uses, create a readiness backlog now: classification basis; system and data documentation; logging architecture; human-oversight design; monitoring; incident path; vendor evidence; change management; and retention of the evidence needed to demonstrate operation.

2026
Inventory, prohibitions, literacy, transparency, ownership

2027
Engineer and validate Annex III high-risk controls before 2 Dec

2028
Complete product-linked high-risk readiness before 2 Aug

6. Design human oversight around authority, not presence

A human somewhere in the process is not necessarily meaningful oversight. The control question is whether the person has the information, competence, time and authority to understand the system’s role, challenge its output and prevent or reverse an inappropriate action.

For each consequential workflow, map the authority progression:

Generate

Recommend

Prepare action

Execute bounded action

Close consequential decision

The further AI moves toward action and closure, the more explicit decision rights, permissions, logging, exception handling and human intervention need to become.

7. Make evidence a by-product of operation

Compliance evidence should emerge from the operating system: inventory records, approvals, configuration, logs, training records, incidents, monitoring results, vendor documentation and change history. If evidence has to be reconstructed manually during an audit, the control system is probably too detached from the work.

This is also better management. The same evidence can show where employees are bypassing approved tools, where an AI workflow is creating exceptions, whether human review is meaningful, and whether a deployment is producing enough value to justify continued operation.

A minimum enterprise implementation architecture

Operating mechanism	Minimum output
AI inventory	Use-case record tied to process, data, model/platform, people, authority and owner
Classification	Prohibited / transparency-triggering / high-risk candidate / other, with rationale
Ownership	Named business and technical accountability
Acceptable use	Rules linked to work, data, environment, authority and action
AI literacy	Role-based capability and evidence of delivery
Transparency	Disclosure/marking embedded where Article 50 applies
Human oversight	Decision rights, intervention points and escalation
Technical controls	Identity, permissions, data protection, logging, connector/action boundaries
Monitoring	Performance, incidents, exceptions, material changes and control effectiveness
Change governance	Reassessment when model, vendor, data, workflow, autonomy or purpose changes

What management should do in the next 30 days

Appoint one accountable executive owner for the enterprise AI control system.
Build or reconcile the AI use-case inventory, including unmanaged use.
Screen active uses for prohibited practices and Article 50 transparency triggers.
Identify plausible Annex III and product-linked high-risk uses and assign readiness owners.
Replace generic AI awareness with role-based AI-literacy measures.
Connect acceptable-use rules to platform, identity, data and action controls.
Define human authority and escalation for consequential workflows.
Create an evidence register that points to operational records rather than duplicate compliance documents.
Establish a change trigger: material changes to purpose, model, data, integration or autonomy require reassessment.
Review the portfolio quarterly as regulation, Commission guidance and AI capabilities evolve.

The larger implication

The AI Act does not eliminate the need for enterprise AI transformation design. It makes that design more explicit. Organizations still have to decide which work should change, which systems should be used, what authority AI receives, how people intervene, what evidence is retained and when a deployment should scale or stop.

The strongest implementation therefore does two jobs at once: it satisfies applicable regulatory obligations and improves the organization’s ability to govern AI as an operating capability.