This shifts the focus of AI governance.

At first glance, the A5 Draft appears to be a catalogue of organizational requirements. On closer examination, however, it follows a different logic: it describes a governance architecture in which trustworthiness is operationalized through organizational roles, processes, responsibilities, and evidence.

The document places strong emphasis on a coherent organizational architecture. Roles are defined, responsibilities assigned, evidence requirements established, and processes linked together. Governance therefore emerges as an integrated organizational system rather than a collection of isolated controls.

This is particularly evident in the consistent connection between evidence, accountability, and auditability. Trustworthiness is expected to be demonstrable. As a result, the organization’s capability to sustain governance over time—and to provide verifiable evidence of that capability—moves to the center.

Yet this very strength creates a new governance tension.

The more systematically trustworthiness is operationalized through organizational structures, the more important the transitions within those structures become. When does continuous monitoring become a governance-relevant incident? How should organizations design the interfaces between observation, assessment, and incident management? And how can evidence remain meaningful as systems, contexts, and risks evolve over time?

These questions do not arise despite the architecture, but because of it. The more governance depends on organizational capabilities, the more critical their continuous operation, internal consistency, and adaptability become.

The A5 Draft therefore represents a broader shift in perspective.

Trustworthiness becomes an organizational capability to structure responsibility, govern processes, and maintain demonstrable governance over time.

This development is likely to extend well beyond the document itself. As AI governance becomes increasingly operationalized, attention will continue to shift away from individual technical measures toward the organizational capability to establish, maintain, and continuously demonstrate trust.

AI G&M Insight

The A5 Community Draft makes a broader structural movement visible: trustworthiness is increasingly being operationalized through organizational capabilities. As this shift continues, the central governance question changes. The primary challenge is no longer whether organizations have governance structures in place, but how effectively they can sustain, adapt, and govern those structures under changing conditions.

Regardless of how individual political announcements are assessed, this development points to a broader structural shift.

International AI competition is expanding into an institutional dimension.

For years, competition centered on models, computing power, and semiconductors. These factors remain decisive. At the same time, countries are increasingly competing through the institutional offerings they build around AI.

The United States emphasizes technological leadership and an innovation-driven ecosystem.

The European Union emphasizes regulatory reliability, trust, and institutional governance.

China increasingly positions itself through infrastructure, international engagement, and capacity building.

These approaches differ in their design. Yet they follow the same strategic logic: to create an institutional offering that other countries, companies, and organizations choose to join voluntarily.

Institutional attractiveness creates voluntary participation. Voluntary participation creates shared standards, governance structures, and organizational ties. Those ties, in turn, create long-term opportunities for influence.

Governance is therefore becoming a geopolitical value proposition. Geopolitical influence no longer begins only with the projection of power. It begins with institutional attractiveness.

Yet a different structural movement is becoming increasingly visible.

Governance is shifting its object.

No longer only:

• Which action is permitted?

• Which decision may be executed?

Increasingly, it is about:

• Access to frontier capabilities (EU Frontier AI Expert Report)

• Generation of context-specific policies (Google Semantic Governance)

• Evidence as the basis for decisions

• Context as a prerequisite for decision-making

Governance is moving further upstream in the decision process. It no longer regulates decisions alone.

It increasingly regulates the conditions under which decisions are formed.

This changes more than the location of governance.

It changes its object.

English term: Runtime Governance

Short definition

Runtime Governance describes a form of governance in which steering, control, and intervention do not end with the deployment of a system but continue throughout its ongoing operation. Governance becomes part of the conditions under which system execution is allowed to continue.

What real problem does the mechanism describe?

Traditional governance often assumes that the most important governance decisions are made before a system is deployed.

These typically include:

• approval,

• conformity assessment,

• risk assessment,

• documentation,

• deployment authorization.

For many modern AI systems, this assumption is no longer sufficient.

Important situations emerge only during actual operation.

Examples include:

• new information changes the operational context,

• agents generate intermediate actions,

• tools are selected dynamically,

• risks evolve,

• system boundaries are reached,

• human intervention becomes necessary.

These situations frequently cannot be fully anticipated before deployment.

Governance therefore cannot end with approval.

Runtime Governance describes governance that remains active during the operation of a system.

Mechanism

Runtime Governance does not merely move governance into runtime. It integrates governance into the conditions of execution itself.

As a system operates, new information, changing system states, and additional action possibilities continuously emerge. These developments may require evaluation, restriction, escalation, or intervention that cannot be completely predefined before deployment.

Governance therefore becomes part of the execution architecture. It no longer acts exclusively before system execution but within ongoing execution itself. Steering, control, and intervention become continuous elements of operation.

Runtime Governance does not replace deployment approval, risk assessment, or compliance. Instead, it continues these governance decisions under real operating conditions and continuously evaluates whether their underlying assumptions still hold.

Governance therefore changes from a one-time prerequisite of deployment into a continuous property of system execution.

Why is it important?

Many governance approaches focus primarily on system development, approval, or deployment. This can create the impression that governance is largely completed once a system has been released.

Runtime Governance extends this perspective.

It recognizes that governance may also be required throughout system operation. Rather than ending with deployment, governance becomes a continuous operational capability.

This becomes particularly relevant for adaptive and agentic AI systems, where new situations emerge continuously during execution.

Runtime Governance makes this governance layer visible as a distinct and recurring mechanism.

Reality Anchors

Runtime Governance can be observed across multiple operational settings.

Typical Reality Anchors include:

• agentic AI systems that continuously generate new actions,

• Human-in-the-Loop architectures with operational intervention,

• monitoring and intervention infrastructures,

• post-deployment governance processes,

• continuous oversight, incident handling, and operational risk management,

• AI systems whose permissions, capabilities, or execution must be continuously evaluated during operation.

Boundaries of the Mechanism

Runtime Governance does not describe every form of monitoring or system operation.

The mechanism requires that governance itself becomes part of the conditions under which system execution continues. Observation alone is therefore not sufficient.

Likewise, Runtime Governance does not replace deployment approval, documentation, conformity assessment, or compliance. These remain essential governance activities. Runtime Governance extends them into ongoing operation.

Not every AI system requires Runtime Governance to the same extent. The mechanism becomes increasingly relevant as systems gain greater autonomy, interact with changing environments, use external tools, or continuously generate new operational situations.

Related Mechanisms

• Reality Anchor

• Operational Tension

• Structural Mechanism

• Decision Threshold

• Verification Requirement

• Admission Layer

• Governance Capacity

Position in the AI G&M Reconstruction Logic

Runtime Governance is a Core Mechanism.

It describes how governance operates after a system has entered real-world operation.

Within the AI G&M reconstruction logic, Runtime Governance becomes relevant once a Structural Mechanism has reached a Decision Threshold and governance must continue under operational conditions.

Reality Anchor → Operational Tension → Structural Mechanism → Decision Threshold → Runtime Governance

Unlike the Foundation Mechanisms, Runtime Governance does not describe how AI G&M reconstructs reality. It describes a stable governance mechanism that can be reconstructed using that methodology.

Common Misunderstandings

• Runtime Governance is not identical to system monitoring.

• Runtime Governance is not a replacement for deployment approval or compliance.

• Runtime Governance does not imply continuous human intervention.

• Not every AI system requires Runtime Governance to the same degree.

• Runtime Governance describes a governance mechanism, not a specific technical implementation.

• Runtime Governance governs the conditions of execution, not merely the observation of execution.

Level 2 – Core Mechanisms

Status: Fundamental

English term: Decision Threshold

Short definition

A Decision Threshold describes the transition zone in which a Structural Mechanism turns into a real consequence.

It marks the point at which organizational, technical, or institutional possibilities become a new binding state.

What real-world problem does this mechanism describe?

Organizations develop processes, rules, and governance structures to prepare decisions and manage risk. These structures remain without effect until they are translated into real-world consequences.

Only at specific transitions is it determined:

• whether an action will be executed,

• whether access will be granted,

• whether a system will be approved,

• whether a payment will be initiated,

• whether market access will be granted,

• or whether an organizational consequence will take effect.

These transitions are often more important for governance than the preceding processes themselves. A Decision Threshold describes exactly this transition zone.

Mechanism

Before a Decision Threshold is crossed, multiple courses of action remain possible. Information may still be added, evidence collected, risks assessed, or alternatives considered. Once the threshold is crossed, however, a new real-world state emerges.

An action is executed.
Access is granted.
A product enters the market.
A payment is made.
An agent acts.

A Decision Threshold does not describe the decision itself. It describes the transition zone in which possibilities become real consequences. This transition may be triggered by human decisions, organizational procedures, technical rules, or automated control mechanisms.

The form of the transition may differ. The underlying mechanism remains the same.

Why is it important?

A Decision Threshold identifies where governance actually becomes effective. Rules, processes, and organizational structures do not create impact uniformly. Their real significance lies at the transitions where preparatory possibilities become binding consequences.

This makes it clear that governance does not primarily exist in documents or organizational charts. It exists at the thresholds where actions are permitted, constrained, delayed, or prevented.

A Decision Threshold therefore connects Structural Mechanisms with operational reality.

Reality Anchors

Decision Thresholds may become visible through:

• formal approval procedures,

• admission processes,

• conformity assessments,

• human oversight requirements,

• runtime checks,

• policy enforcement,

• API authorization,

• access control decisions,

• payment authorization,

• deployment approval.

Reality Anchors reveal the observable consequences. The Decision Threshold reconstructs the transition zone in which these consequences become binding.

Limits of the mechanism

Not every decision represents a Decision Threshold. Routine decisions without structural significance do not belong to this mechanism.

Likewise, a Decision Threshold does not describe the quality of a decision or the responsibility of individual actors.

It describes only the transition zone in which multiple possible states are reduced to one real consequence. A decision is the most common, but not the only, form of this transition.

Related mechanisms

• Reality Anchor

• Operational Tension

• Structural Mechanism

• Governance Capacity

• Verification Requirement

• Runtime Governance

• Admission Layer

AI G&M connection

The Decision Threshold forms the fourth step of the AI GM reconstruction logic.

Reality Anchor → Operational Tension → Structural Mechanism → Decision Threshold

Reality Anchors make observable reality visible. Operational Tensions create adaptation pressure. Structural Mechanisms describe the common logic underlying recurring adaptations. At Decision Thresholds, these adaptations become real consequences.

Many specialized AI GM mechanisms describe different forms of Decision Thresholds. These include, for example:

• Admission Layers,

• Runtime Governance,

• Human Approval,

• Policy Enforcement,

• Commit-Time Governance,

• Agentic Payments,

• Runtime Admission.

Although they differ in implementation, they all follow the same underlying mechanism: They determine the conditions under which possibilities become binding consequences.

Common misunderstandings

• A Decision Threshold is not the decision itself.

• A Decision Threshold is not a single moment in time.

• A Decision Threshold is not an organizational role.

• Not every decision constitutes a Decision Threshold.

• Decision Thresholds may be human, organizational, technical, or automated.

• A Decision Threshold describes the transition to a real consequence, not the entire decision-making process.

• A Decision Threshold may extend across multiple process steps rather than existing as a single formal approval point.

Level 1 – Foundations

Status: Fundamental

English term: Structural Mechanism

Short definition

A Structural Mechanism describes the common structural logic underlying recurring adaptations that become observable under comparable Operational Tensions across different contexts.

It explains not individual events, but the recurring pattern that connects these adaptations.

What real-world problem does this mechanism describe?

Organizations, markets, and institutions constantly change. Many of these changes are remarkably similar, even though they emerge independently of one another.

Organizations introduce similar documentation processes. They establish comparable governance roles. They create similar control or admission structures.

Viewed individually, these developments often appear to be organization-specific solutions or isolated management decisions. As a result, the underlying structural logic frequently remains invisible.

A Structural Mechanism makes this common logic visible.

It does not describe the individual adaptations themselves, but the recurring pattern that underlies them.

Mechanism

Comparable Operational Tensions frequently give rise to similar structural adaptations.

These adaptations may take the form of:

• new organizational roles,

• additional processes,

• modified decision pathways,

• new governance structures,

• organizational reconfiguration,

• new verification or control structures.

When such adaptations repeatedly emerge across different organizations or application contexts, their common structural logic can be reconstructed.

AI GM refers to this common structural logic as a Structural Mechanism.

The Structural Mechanism itself is not directly observable. What can be observed are the individual adaptations. The Structural Mechanism describes the recurring pattern that connects them.

Why is it important?

A Structural Mechanism shifts attention from isolated events to recurring patterns of organizational adaptation. This makes it possible to understand individual developments as part of a broader structural movement rather than as unrelated cases.

It enables analysts to:

• connect seemingly separate observations,

• compare developments across organizations and sectors,

• and identify structural change at an earlier stage.

A Structural Mechanism therefore forms the explanatory layer between observable reality and concrete decisions.

Reality Anchors

Structural Mechanisms are grounded in recurring observations.

Typical Reality Anchors include:

• similar organizational adaptations,

• recurring governance structures,

• comparable market responses,

• similar regulatory consequences,

• repeated changes in roles or processes,

• independent empirical observations of the same adaptation pattern.

A single Reality Anchor is not sufficient.

Only the repeated occurrence of similar adaptations across different contexts allows a Structural Mechanism to be reconstructed.

Limits of the mechanism

A Structural Mechanism does not describe a universal law. Organizations may respond differently to the same Operational Tension. Likewise, a Structural Mechanism does not describe an individual organizational measure.

It describes only the common structural logic underlying recurring adaptations.

Whether observed adaptations actually belong to the same Structural Mechanism must always be reconstructed from observable reality.

Related mechanisms

• Reality Anchor

• Operational Tension

• Decision Threshold

• Governance Capacity

• Verification Requirement

• Runtime Governance

• Admission Layer

AI G&M connection

The Structural Mechanism forms the central explanatory layer of AI Governance & Markets. It connects observable reality with recurring forms of organizational, institutional, and market adaptation.

Nearly all later mechanisms within the Encyclopedia - such as Verification Requirement, Governance Capacity, Runtime Governance, or Admission Layer—can be understood as specific Structural Mechanisms. They describe particular recurring forms of structural adaptation that emerge under comparable Operational Tensions.

Common misunderstandings

• A Structural Mechanism is not a theory.

• A Structural Mechanism is not an individual event.

• A Structural Mechanism is not a universal law.

• A Structural Mechanism does not describe a single organizational measure.

• Not every recurring observation constitutes a Structural Mechanism.

• Structural Mechanisms are not directly observable; they are reconstructed from recurring structural adaptations.

• A Structural Mechanism explains the common logic of recurring adaptations, not every individual action.

Level 1 – Foundations

Status: Fundamental

The EU AI Act begins with a seemingly technical question: What qualifies as an AI system?

The question appears purely definitional. In reality, it determines whether risks can be classified, obligations assigned, and conformity assessed. Only once this entity has been defined can governance operate on it.

A bank seeking to deploy AI in credit approval faces a different question: Who is authorized to approve a loan? The challenge is not merely to assess risks. The decisive issue is where authorization is anchored and who is permitted to make a decision.

A hospital deploying diagnostic AI systems faces yet another challenge: Who bears responsibility when AI influences treatment? Here, roles, responsibilities, and organizational accountability move to the forefront. A decision must be made about where responsibility is anchored.

An organization introducing new AI systems faces a different task: Which systems should be admitted into the organization at all? The central question concerns the admission decision as much as the subsequent risk.

A security team, by contrast, is often concerned primarily neither with models nor with procurement processes. The decisive question is: Can the organization detect, coordinate, and respond to threats? Here, the focus shifts away from the individual system toward the organization’s capacity to respond.

These situations originate from different domains and address different risks. Each places a different object at the center of attention.

The differences are substantial. AI systems, organizations, authorizations, admission decisions, and organizational capabilities differ fundamentally from one another. Nevertheless, they all qualify as objects of governance.

Reconstruction

The most immediate explanation is that different risks give rise to different governance units.

This explanation captures part of reality. It does not, however, explain why precisely these reference points are selected. The same risks could often be reconstructed through different reference points. Credit risks can be reconstructed through models, organizations, or approval rights. Clinical risks can be examined through systems, hospitals, or medical personnel. Security risks can be analyzed through individual systems, processes, or organizational capabilities.

The risk perspective alone therefore does not explain why certain reference points repeatedly move to the forefront.

Their significance derives from the governance functions they enable. An AI system can be classified. An approval right can be granted or revoked. An organization can assume responsibility. An admission decision can be approved or denied. A security capacity can be developed, assessed, and mobilized.

Despite their differences, the functions performed through them exhibit a striking similarity. Governance classifies, authorizes, admits, verifies, assigns responsibility, and coordinates.

Attention therefore shifts from the units themselves to the functions performed through them. Their commonality lies in enabling particular governance functions.

Risks can be described, assessed, and analyzed. Governance, however, cannot operate directly on risks themselves. It operates on objects to which responsibilities can be assigned, authorizations granted, or requirements imposed.

Governance therefore does not address risks directly. It addresses them through carriers.

Carrier Selection

Once governance functions become the focus, another question arises:

Why are certain carriers selected repeatedly?

Many other reference points are equally relevant: contexts of use, chains of action, delegations, and interactions among multiple systems. Yet they are less frequently chosen as primary governance reference points. Why?

Because relevance alone is not sufficient. Governance must be able to operate on a unit. That unit must remain identifiable, be capable of delimitation, carry responsibility, and serve as the object of decisions.

Relevance alone does not make an object governance-capable.

Against this background, the repeated selection of particular carriers can be understood as a search for carriers on which governance functions can be performed.

From Selection to Stability

The repeated selection of particular carriers points to an underlying logic of selection. Governance appears to prefer certain carriers because they possess characteristics that make governance operational.

These carriers can be delineated. They can be documented and verified. They can be linked to rights, obligations, and responsibilities. Above all, they remain identifiable over a sufficiently long period of time.

Against this background, the repeated selection of particular carriers can be understood as a search for carriers that are sufficiently stable for governance.

The Carrier Stability Problem

The crucial point, however, lies elsewhere.

Governance frequently operates on carriers other than those on which risks arise.

This difference is not new. Governance has always had to address risks through governance-capable carriers. Under AI conditions, however, risk genesis increasingly shifts into relational, distributed, and dynamic constellations, while governance must continuously adapt its carriers to these changes.

Many relevant risks now emerge in contexts of use, delegations, chains of action, and interactions among multiple components - in other words, in relationships.

These relationships lack many of the characteristics that governance requires of stable carriers. They are often difficult to delineate, change over time, generate ambiguous responsibilities, and can only be documented or institutionally embedded to a limited extent.

Governance responds by constructing new carriers - for example, monitoring pipelines, runtime controls, or evidence systems. In doing so, relational risks are translated into objects of governance.

This adaptation does not eliminate the underlying tension. With each new generation of governance carriers, the constellations in which risks arise continue to evolve. Governance therefore continuously adapts its carriers to an evolving risk genesis.

The Carrier Stability Problem therefore does not describe a one-time distance between risk genesis and governance carriers. It describes an ongoing process of adaptation in which governance continuously adjusts its operational carriers to changing forms of risk genesis.

The stability of the problem therefore lies not in immutable governance carriers, but in the recurring necessity to create new governance carriers under changing conditions.

The Reappearance of the Tension

The Carrier Stability Tension is not confined to individual governance regimes. It reappears across different decision contexts.

An organization procuring new AI systems frequently operates at the level of the admission decision. Many risks, however, only become visible during subsequent deployment. Governance intervenes where it can operate - not necessarily where risks arise.

A hospital faces a similar challenge. Diagnostic systems influence decisions, treatment trajectories, and responsibilities. The risks arise neither exclusively within the model nor exclusively within the organization. Nevertheless, governance must determine where responsibility, accountability, and control are anchored.

The examples differ substantially. The underlying tension remains the same. Governance operates on carriers capable of supporting its functions. Risk genesis frequently occurs elsewhere.

Consequence

The Carrier Stability Problem does not create a one-time trade-off. It creates a continuous pressure for adaptation.

Governance must continuously adapt its carriers to new forms of risk genesis. New governance carriers can reduce existing tensions while simultaneously changing the operational reference points, responsibilities, and control structures on which governance subsequently operates.

The central challenge lies in continuously organizing governance functions under conditions of ongoing change while preserving stability, traceability, and institutional embedding.

Implications for the Governance Discourse

The Carrier Stability Tension explains a striking characteristic of many AI governance debates.

Positions that appear to contradict one another often address different governance problems. They differ not only in their perspective on risk, but also in their choice of the carrier on which governance should operate.

As a result, conflicts frequently appear to be disagreements about risk. The reconstruction suggests, however, that they often begin one level earlier: with the question of which governance function is at stake and which carrier can reliably support that function.

Core Insight

The central tension is that the characteristics of effective governance carriers do not necessarily coincide with the characteristics of actual risk genesis.

Governance prefers carriers that are stable, clearly delineated, attributable, and verifiable. Many AI-related risks, by contrast, arise in distributed, relational, and context-dependent constellations.

Current governance conflicts often appear to be conflicts about risk. The reconstruction suggests, however, that they frequently begin one level earlier: with the question of the carrier on which governance should operate in the first place.

Governance does not primarily search for the places where risks arise. It searches for carriers on which it can operate.

Under AI conditions, the relationship between risk genesis and governance carriers becomes a continuous process of adaptation.

Evidence Note

Recent governance papers exhibit a consistent operational convergence.

Across runtime governance, monitoring, safety, reporting, and institutional capacity, governance is consistently attached to specific operational governance carriers rather than to risk itself. These include failure surfaces, admission boundaries, runtime controls, monitoring pipelines, identities, evidence systems, and institutional capacities.

This convergence appears across documents from Microsoft, IMDA, DeepMind, OpenAI, Anthropic, OECD, RAND/Oxford, and GovAI despite their different objectives, governance traditions, and problem settings.

The vector developed here does not derive its argument from these documents. Instead, it reconstructs a general governance mechanism and subsequently observes that the current governance literature increasingly organizes operational governance around comparable carriers.

The governance paper stack therefore does not prove the Carrier Stability Problem. It provides independent evidence that contemporary AI governance is increasingly operationalized through identifiable governance carriers rather than through abstract risk categories alone.

English term: Operational Tension

Short definition

An Operational Tension describes a real conflict between operational requirements that cannot all be fully satisfied under existing conditions. It creates adaptation pressure and forms the starting point of structural change.

What real-world problem does this mechanism describe?

Observable reality alone does not explain why organizations, markets, or institutions change.

Between an observable reality and a later structural change, an operational tension often emerges first. Different legitimate requirements simultaneously act upon the same resources, processes, or decision structures, yet cannot all be fully satisfied.

Examples include:

• speed versus control,

• innovation versus regulatory verifiability,

• automation versus human oversight,

• openness versus security.

Without reconstructing this operational tension, subsequent organizational changes often appear to be isolated management decisions or unique cases.

Operational Tension makes this otherwise invisible layer of adaptation pressure reconstructable.

Mechanism

An Operational Tension emerges when multiple operational requirements exist simultaneously, but the prevailing conditions prevent them from being fully reconciled.

These conditions may include:

• limited time,

• constrained resources,

• regulatory requirements,

• technical limitations,

• organizational structures,

• institutional constraints.

This creates operational adaptation pressure.

Organizations respond by introducing, for example:

• new processes,

• additional governance structures,

• revised organizational roles,

• prioritization,

• organizational redesign,

• or new capabilities.

When comparable Operational Tensions repeatedly occur across different contexts and consistently produce similar forms of adaptation, a Structural Mechanism can be reconstructed.

Operational Tension therefore describes the transition from observable reality to structural adaptation pressure.

Why is it important?

Operational Tension explains why Structural Mechanisms emerge.

It prevents organizational changes from being derived directly from isolated observations or events.

Instead, it reconstructs the operational pressure underlying the observed adaptations.

This makes it possible to understand why similar organizational solutions repeatedly emerge in different contexts.

The explanation therefore shifts from individual events to the conditions under which organizations must operate.

Reality Anchors

Operational Tensions may become visible through, for example:

• recurring implementation problems,

• regulatory trade-offs,

• documented governance bottlenecks,

• prolonged development or approval processes,

• organizational restructuring,

• new documentation and control processes,

• recurring human intervention in automated workflows,

• procurement or integration constraints,

• recurring prioritization conflicts.

Limits of the mechanism

Not every difficulty constitutes an Operational Tension.

Personal conflicts, isolated management failures, or temporary implementation problems do not, by themselves, constitute an Operational Tension.

Likewise, the mechanism describes only the adaptation pressure.

It does not yet explain the specific form of the resulting Structural Mechanism.

Related mechanisms

• Reality Anchor

• Structural Mechanism

• Decision Threshold

• Governance Capacity

• Organizational Layering

• Verification Requirement

AI G&M connection

Operational Tension represents the second step of the AI GM reconstruction logic.

Reality Anchor → Operational Tension → Structural Mechanism → Decision Surface

Reality Anchors describe observable reality.

Operational Tension reconstructs the adaptation pressure emerging from that reality.

Structural Mechanisms explain the recurring forms of adaptation.

Decision Surfaces identify where organizations or institutions must actually make decisions.

Operational Tension therefore connects observation with structural explanation.

Common misunderstandings

• An Operational Tension is not a personal conflict.

• An Operational Tension is not a management problem.

• An Operational Tension is not a Structural Mechanism.

• Not every operational problem is an Operational Tension.

• Operational Tension describes adaptation pressure, not its solution.

• Operational Tensions are reconstructed from observable reality rather than assumed theoretically.

• Resolving one Operational Tension may generate new Operational Tensions.

Level 1 – Foundations

Status: Fundamental

German working term: Realitätsverankerung

English term: Reality Anchor

Short definition

A Reality Anchor is an observable real-world condition on which the reconstruction of a structural mechanism is based. It provides the empirical starting point of an analysis while simultaneously limiting how far conclusions may be generalized.

What real-world problem does this mechanism describe?

Many analyses begin with an explanation or a theory without clearly showing what they are actually based on. Individual events are generalized, narratives replace observations, or theoretical frameworks are directly projected onto reality.

As a result, three different levels become blurred:

• what was actually observed,

• what was reconstructed from those observations,

• and what is only assumed beyond them.

The Reality Anchor addresses this problem by requiring every reconstruction to begin with observable reality. Only then can further analytical steps follow.

Mechanism

A Reality Anchor is always an observable real-world condition.

It is neither an explanation nor a theory, but a fact that can be observed and reconstructed.

Typical Reality Anchors include:

• an enacted law,

• a published technical specification,

• a documented organizational process,

• a real-world deployment,

• observable market behavior,

• a publicly documented incident,

• a court decision,

• an institutional decision,

• or a robust empirical study.

The Reality Anchor forms the first step of the reconstruction.

From this starting point, the analysis examines:

• which operational tensions become visible,

• which structural mechanisms can explain these tensions,

• and which decision implications emerge.

At the same time, the Reality Anchor defines the analytical scope.

A single Reality Anchor may justify proposing a possible mechanism.

Only multiple independent Reality Anchors can strengthen or stabilize a broader structural mechanism.

Why is it important?

The Reality Anchor protects analysis from two opposite errors.

On the one hand, it prevents theoretically elegant models from being developed without sufficient empirical grounding.

On the other hand, it prevents isolated observations from being prematurely treated as general structural laws.

This makes reconstruction transparent, reviewable, and incrementally expandable.

Future refinements or corrections can always return to the same Reality Anchors or incorporate additional ones.

Reality Anchors

Reality Anchors may include, for example:

• laws and regulations

• court decisions

• technical benchmarks

• documented deployments

• organizational processes

• market developments

• public organizational decisions

• regulatory guidance

• robust empirical studies

• reproducible field observations

What matters is not the type of anchor, but its observability and reconstructability.

Limits of the mechanism

A Reality Anchor does not prove a mechanism.

It only demonstrates that a particular observation exists.

Whether this observation supports a broader structural mechanism depends on additional Reality Anchors, their consistency, and the quality of the reconstruction.

The strength of an analysis therefore does not automatically increase with the amount of data, but with the quality and interconnectedness of its Reality Anchors.

Related mechanisms

• Operational Tension

• Structural Mechanism

• Decision Threshold

• Reality Density

• Source Continuity

• Constructed Reality

AI G&M connection

The Reality Anchor is the first building block of almost every AI GM analysis.

The fundamental reconstruction sequence is:

Reality Anchor → Operational Tension → Structural Mechanism → Decision Surface

Every subsequent analytical layer remains traceable back to its Reality Anchors.

This makes it possible to distinguish:

• what is directly observable,

• what has been analytically reconstructed,

• and what remains a hypothesis.

The Reality Anchor is therefore not only the starting point of analysis but also a mechanism that limits analytical reach. It prevents structural claims from becoming stronger than their empirical foundation. This logic is consistent with the AI GM principles Reality before framework and the Source Continuity Check, which require every structural reconstruction to remain traceable to its original observations.

Common misunderstandings

• A Reality Anchor is not a theory.

• A Reality Anchor is not an explanation.

• A Reality Anchor is not proof of a general mechanism.

• More Reality Anchors do not automatically produce a better analysis.

• Plausibility is not a substitute for a Reality Anchor.

• A Reality Anchor describes observation, not interpretation.

• Without a Reality Anchor, analysis becomes speculation.

Level 1 – Foundations

Status: Fundamental

Browse

Level 1 - Foundations

• Reality Anchor

• Operational Tension

• Structural Mechanism

• Decision Threshold

Level 2 - Core Mechanisms (coming soon)

Examples include:

• Runtime Governance

• Verification Requirement

• Admission Layer

• Governance Capacity

• Organizational Layering

• Re-Manualization

• Operational Object Drift

Level 3 - Specialized Mechanisms (coming soon)

Examples include:

• Detection–Recovery Decoupling

• Signal Explicitness as Containment Variable

• Discovery-to-Exploitation Gap

• Governance at the Execution Boundary

• Human Judgment as Residual Governance Layer

Core

The AI Governance & Markets Mechanism Encyclopedia is a long-term reference work that documents the structural mechanisms through which artificial intelligence changes governance, organizations, markets, and deployment conditions.

It is not a glossary of AI terminology.

It is an encyclopedia of reconstructable mechanisms.

Every entry explains one mechanism that can be observed, reconstructed, and applied across multiple real-world contexts.

The encyclopedia follows three core principles:

• Mechanism before terminology.

• Reality before framework.

• Reconstruction before interpretation.

Mechanisms are not derived from opinions, trends, or isolated publications. They are reconstructed from observable reality and supported by identifiable Reality Anchors.

The purpose of the encyclopedia is to provide a stable conceptual infrastructure for understanding how AI reshapes operational, organizational, and institutional conditions.

Structure

The encyclopedia is organized into three levels.

Level 1 – Foundations

Foundational mechanisms that form the analytical basis of AI G&M.

These mechanisms describe the basic building blocks required to reconstruct structural change.

Level 2 – Core Mechanisms

Stable mechanisms that repeatedly appear across governance, deployment, organizational adaptation, and market transformation.

Level 3 – Specialized Mechanisms

More specialized mechanisms that describe particular operational dynamics or emerging structural developments.

Mechanism Status

Each mechanism is assigned one of four maturity levels.

Fundamental

A foundational mechanism on which the analytical system itself is built.

Established

A stable mechanism repeatedly supported by multiple independent Reality Anchors.

Developing

A mechanism that already shows recurring empirical support but continues to evolve.

Candidate

A promising mechanism that requires additional Reality Anchors before becoming part of the stable framework.

How to read a mechanism

Every encyclopedia page follows the same structure:

1. German working term

2. English term

3. Short definition

4. What real-world problem does this mechanism describe?

5. Mechanism

6. Why is it important?

7. Reality Anchors

8. Limits of the mechanism

9. Related mechanisms

10. AI G&M connection

11. Common misunderstandings

12. Level

13. Status

Each page explains exactly one mechanism.

If two different mechanisms emerge, they are documented on separate pages and linked to each other.

Scope

The encyclopedia explains mechanisms.

It does not document:

• companies,

• laws,

• papers,

• institutions,

• technologies,

• products,

• or historical events.

These may appear as Reality Anchors where they help explain a mechanism, but they are never the subject of the encyclopedia itself.

Method

Every mechanism follows the same reconstruction logic:

Reality Anchor → Operational Tension → Structural Mechanism → Decision Surface

This sequence reflects the analytical workflow of AI Governance & Markets.

The encyclopedia documents the resulting mechanisms—not the research process that produced them.

Purpose

The AI G&M Mechanism Encyclopedia serves four complementary purposes.

It is:

• the permanent reference architecture for AI Governance & Markets,

• an internal reconstruction framework for analytical work,

• a public knowledge base for practitioners, researchers, and decision-makers,

• and a durable conceptual reference for future AI-related search and retrieval systems.

Its objective is not to explain everything about AI.

Its objective is to explain the structural mechanisms that repeatedly shape AI governance, markets, organizations, and deployment under real-world conditions.

The immediate explanation was political.

The more interesting finding is structural.

The case revealed that the critical dependency was not where many AI sovereignty debates assume it is. Much of the discussion focuses on data centers, cloud infrastructure, or local deployment. The intervention happened elsewhere.

As a result, the question of control changes as well. An organization can operate infrastructure, integrate workflows, and build processes around a capability without actually controlling the continuation of that capability.

At first glance, the case looks like a political exception. In reality, it exposes a structural bottleneck.

The critical resource is not the infrastructure.

The critical resource is access.

Whoever controls access increasingly controls the continuation of the capability.

By 2035, the market share of European cloud and AI computing providers in the European market is expected to reach 30%. This is the stated objective of the Cloud and AI Development Act (CADA).

It sounds like the result of an analysis or a forecast.

It is not.

In the impact assessment, the 30% figure appears as a target. The document then examines which growth rates would be required to reach that outcome.

The impact assessment itself makes this point. The CAGR assumptions do not constitute a forecast. They were chosen to broadly match the desired outcome. (Impact Assessment Annexes (SWD(2026) 503), Annex 4, Section 8)

The analysis does not generate the target.

The target generates the analysis.

This shifts the real question.

Not:

Will Europe reach a 30% market share?

But:

Under which conditions could 30% become conceivable in the first place?

The impact assessment describes in considerable detail the conditions under which 30% could become conceivable. It points to demand aggregation, public procurement, sovereignty requirements, lower switching costs and specific support measures. (Impact Assessment Annexes (SWD(2026) 503), Annex 4, Section 8)

What remains unanswered is how those conditions are actually supposed to be created.

That is where it becomes clear whether a target merely appears plausible or is actually achievable.

This is precisely what exercised oversight looks like.

The RSB did not challenge the political objective of the initiative.

It challenged the justification.

The measures were considered insufficiently specified. Their proportionality had not been sufficiently demonstrated. The causal links between measures and expected effects were not sufficiently substantiated. The economic reasoning and the cost-benefit assessments were also considered insufficiently convincing. (Impact Assessment (SWD(2026) 502), Annex 1.3, Table 2)

This is the crucial point.

The RSB did not say:

The objective is wrong.

It said:

The homework has not been done.

And without that homework, there was no positive opinion.

In many procedures, criticism has little practical consequence. It is registered, answered, or simply acknowledged.

In the CADA process, that was not enough.

The criticism had to be addressed.

The Commission’s response shows that the criticism was procedurally consequential. The impact assessment was revised. Measures were specified in greater detail, the intervention logic was expanded, and parts of the economic reasoning were strengthened. (Impact Assessment (SWD(2026) 502), Annex 1.3, Table 2)

The specific changes matter.

More important, however, is the fact that they had to be made.

That is precisely what distinguishes symbolic oversight from exercised oversight.

Symbolic oversight expresses criticism.

Exercised oversight compels rework.

The Commission did not receive a positive opinion before that rework had taken place.

The first part examined the tension between infrastructure and dependence.

The second part examined the diagnosis of a demand and coordination problem.

This leaves one final question. If the proposed measures are actually implemented, how would the Commission later determine whether they are working?

Reading the monitoring and evaluation section, one notices how systematically this question is intended to be answered.

The impact assessment develops an extensive architecture of indicators, targets, and evaluations. Among other things, it monitors capacity expansion, market shares, provider presence, and dependencies (Annex 11).

At first, this is unsurprising. Anyone who formulates ambitious goals must also be able to determine whether those goals are being achieved.

The document becomes more interesting elsewhere. The further one follows the monitoring system, the clearer it becomes that the impact assessment distinguishes between two different levels.

On the one hand, it is concerned with the implementation of the measures themselves. On the other hand, it is concerned with the long-term effects those measures are intended to produce.

For implementation, the document provides early-warning mechanisms. Monitoring is intended to make potential bottlenecks or delays visible at an early stage and, where necessary, enable corrections during implementation (Annex 11).

For the actual outcome objectives, the architecture is structured differently. Provider shares, dependence reduction, or structural market changes are observed primarily through later evaluations, in some cases with multi-year time horizons (Annex 11).

At this point, a distinctive feature of the document begins to emerge. The impact assessment describes with considerable precision what progress would look like. Considerably less attention is given to the question of what happens if that progress fails to materialize.

For implementation problems, the document contains early-warning and correction mechanisms. For the actual outcome objectives, observation, evaluation, and later political decisions play a more prominent role.

As a result, the architecture becomes very strong in observing developments. The connection between observation and mandatory adjustment - through predefined or escalating response pathways in the event that targets are missed, for example - remains considerably more restrained.

This does not mean that failing to meet targets would be without consequences. The actual response to such developments remains more dependent on the later actions of the institutions involved.

The first part examined the tension between infrastructure and dependence.

This raises an obvious question: What is the actual problem from the Commission’s perspective?

Those who follow the public debate about Europe’s position in the cloud and AI market usually expect familiar answers at this point: too little capital, too little scale, too few European champions, too little computing capacity.

However, reading the impact assessment creates a different impression. What stands out first is where the document places its emphasis. The discussion revolves relatively little around the question of whether European providers are fundamentally capable of offering competitive services. Instead, the impact assessment repeatedly focuses on requirements, procurement, scaling, and market organization.

The further one follows the argument, the clearer a recurring pattern becomes.

Sovereignty requirements are formulated differently. Public procurement remains fragmented. Criteria are not comparable everywhere. Demand emerges in many places, but only to a limited extent becomes legible as a common market signal. Taken individually, these points appear almost administrative.

In the document, however, they become a market problem. This is because demand does not only fulfill an economic function. It also fulfills a coordination function.

When requirements are formulated differently across authorities, member states, and organizations, demand becomes difficult to compare. When demand becomes difficult to compare, it becomes difficult to pool. Without pooling, the long-term and sufficiently large contracts that are important for scaling emerge less frequently.

The impact assessment describes precisely this connection several times. According to the Commission’s presentation, the European market share stands at around 15% and shows no discernible tendency to change (Part 1, Section 2.4). At the same time, the document repeatedly points to fragmented demand, differing procurement logics, and the absence of common standards.

At this point, it becomes clear why the definition of sovereignty plays such a central role in the document.

At first glance, it appears to be a regulatory classification. Over the course of the impact assessment, however, it takes on another function.

The sovereignty tiers make requirements more comparable. This allows public institutions to describe their needs in more similar ways. Only then does the possibility emerge of bringing demand together across individual authorities or member states.

Why this matters becomes clear elsewhere. The impact assessment repeatedly points to the importance of larger and more stable contract volumes. Individual procurement procedures hardly change market structure. Coordinated demand, by contrast, can reach scales that become relevant for scaling.

The definition of sovereignty thereby acquires an additional meaning. It does not only serve to classify providers or services. At the same time, it creates the conditions under which demand can become visible as a common signal at all.

By the end of this argument, a remarkable picture emerges. The impact assessment describes a market in which requirements are difficult to compare, demand is difficult to pool, and scaling therefore becomes difficult to achieve.

This is precisely where the majority of the proposed measures intervene.

This also changes how CADA appears. The document no longer appears merely as an infrastructure package or a sovereignty package. It increasingly appears as an attempt to transform fragmented public demand into a coordinated signal of scale.

This also shifts the actual challenge. The central issue is not the existence of demand, but its organization.

The third part examines another distinctive feature of the document: CADA measures many of the decisive variables with surprising precision. The question is what happens when these targets are missed.

More infrastructure can be created without automatically reducing dependence on a small number of large providers.

This is where a tension begins that runs throughout the entire document. One of the central objectives of CADA is the expansion of digital infrastructure in Europe. The rationale is straightforward. Demand for cloud and AI computing capacity is growing, while large parts of the market remain concentrated among a small number of providers and locations.

At first glance, the logic appears simple. More infrastructure should strengthen Europe’s position.

However, reading the impact assessment produces a more differentiated picture. The document devotes considerable attention to the expected capacity gap. Permitting procedures, grid bottlenecks, and infrastructure constraints are described as key obstacles to further growth. The proposed response is correspondingly clear: accelerate permitting, create fast-track areas, and facilitate investment (Part 1).

Taken together, these measures are intended to increase the computing infrastructure available within the European Union. Up to this point, the argument is relatively straightforward.

The document becomes more interesting elsewhere.

The impact assessment treats dependence as a separate problem. It repeatedly distinguishes between infrastructure located in Europe and infrastructure controlled by European providers. This distinction becomes particularly visible in the proposed sovereignty framework.

Most public-sector use cases would remain open to non-European providers, provided they meet the relevant requirements. Only the highest sovereignty tiers are effectively reserved for EU-controlled providers (Part 1).

This creates a tension that runs throughout much of the document. The mechanisms for expanding capacity are largely provider-neutral. The mechanisms for reducing dependence are provider-selective. Both objectives appear within the same policy package, but they operate through different logics.

One consequence follows from this distinction. Additional capacity can be created in Europe without automatically changing who controls the market.

The capacity gap and the dependence gap are therefore related, but they are not the same thing.

Closing one does not automatically mean closing the other.

If dependency cannot be reduced through infrastructure alone, a different question emerges. What problem is CADA actually trying to solve?

That question is the focus of Part 2.

The language differs. Some discussions focus on human oversight, others on deployment approval, trust boundaries, traceability, uncertainty recognition, or Zero Trust architectures.

Yet the underlying concern increasingly looks the same.

The question is becoming less about evaluating a system in isolation and more about governing what happens when it acts.

Several recent signals point in that direction. OpenAI’s Frontier Governance Framework emphasizes deployment decisions, residual risk acceptance, and ongoing model review. Anthropic’s work on Zero Trust for AI Agents focuses on identity, authorization, and constrained execution. Gartner highlights autonomy levels, trust boundaries, and governance proportional to agent capabilities. Discussions around human oversight increasingly focus on whether oversight remains operationally meaningful under real conditions.

What I find interesting is not any individual argument. It is the fact that different fields, operating under different constraints, appear to be encountering the same governance boundary.

Independent convergence does not prove a conclusion is correct.

It can, however, be a useful indication that a structural problem is becoming visible.

Isomorphic English translation based on the German reference version.

Section 1 – Review Protocol

Object

Regulation (EU) 2024/1689 (EU AI Act) in its structure as a governance architecture: definition of the “AI system,” risk classification, duties and compliance regime, enforcement mechanism, as well as target and protected-interest structure.

Review Standard

The analysis is conducted along Review Architecture v1.0 with five categories: abort capability, cost truthfulness, exit capability, power clarity, and institutional consequences. Decisive is not the political expediency of the regime, but its structural logic of effects.

Methodology

The object is first reconstructed in full. This is followed by explicit application of the review standard. Diagnoses are derived exclusively from this combination. No additional evaluative dimensions are introduced.

Section 2 – Reconstruction of the Object

With the definition of the “AI system,” the EU AI Act constructs a regulatable unit. This definition describes machine-based systems with a degree of autonomy that generate predictions, recommendations, or decisions on the basis of data and thereby influence real or virtual environments. The definition is not a technical specification, but a legal stipulation with an ordering function. Heterogeneous technical architectures are bundled into a unified category.

On this ontological foundation, the Act establishes a four-tier risk classification: unacceptable risk, high risk, limited risk, and minimal or no risk. The classification translates the defined category into graduated intensity of obligations. Unacceptable practices are prohibited; high-risk systems are subject to extensive ex-ante obligations; limited risk triggers transparency requirements; minimal risks remain within the general legal framework.

The obligations architecture is coupled to this classification. In the high-risk area, it includes in particular risk management, data governance requirements, technical documentation, logging, transparency obligations, requirements for human oversight, as well as provisions concerning robustness and safety. Conformity must be demonstrated prior to market access and is, where applicable, reviewed by notified bodies. The central steering unit is not the source code itself, but the documented proof of rule-compliant procedures.

Enforcement occurs on an administrative basis. National supervisory authorities monitor the market and conformity, while coordinating mechanisms at EU level ensure coherent application. Sanctions are an integral part of the architecture. Power structurally emerges through the interpretation of indeterminate legal concepts, through conformity decisions, and through sanctioning authority.

The target structure of the regime is dual in nature: protection of fundamental rights, health, and safety on the one hand, and the safeguarding of a functioning internal market on the other. Risk functions as the mediating category between protection logic and market access. Trust is institutionally produced through classification, transparency, and enforceability.

Section 3 – Diagnosis of Architectural Effects

The application of the review standard proceeds along the five categories of Review Architecture v1.0.

Abort Capability

The ontological stipulation of the “AI system” is structurally stable and can only be changed through a formal legislative procedure. The risk classification permits adjustments to individual application lists, but not revision of its underlying logic. The compliance architecture reviews conformity with defined requirements, not their actual quality of effects. Internal feedback that systematically reviews the adequacy of its own underlying assumptions is not provided for. The regime is adaptable in detail, but not self-reflexive in its structure. Abort capability is therefore limited.

Cost Truthfulness

Regulatory burdens primarily arise in system development, documentation, and conformity procedures. Risks are typified through system and application categories, while internal organizational decision architectures and power structures are not independently reviewed. Since relevant risk genesis frequently emerges contextually, a partial asymmetry arises between burden distribution and risk structure. Cost truthfulness is thereby partially decoupled.

Exit Capability

Binding to the regime occurs through access to the EU market. A formal exit is possible through market withdrawal or renunciation of specific application areas. For economically relevant actors, however, the EU market is structurally significant, such that exit becomes factually cost-intensive. The architecture permits evasive movements, but generates adaptation pressure and exerts market-structuring effects. Exit capability is formally present, but economically asymmetrical.

Power Clarity

Responsibility is formally distributed along the value chain. Providers initially classify systems themselves; supervisory authorities monitor, interpret, and sanction. Indeterminate legal concepts require interpretation. Effective steering power concentrates where interpretive authority and sanctioning competence converge. The power structure is formally decentralized, but interpretively centered in its practical effect.

Institutional Consequences

The regime generates durable administrative and compliance structures. Conformity becomes a prerequisite for market access; regulatory requirements integrate into system design and organizational processes. Fixed costs exert relatively stronger effects on smaller actors and favor consolidation tendencies in the high-risk area. At the same time, a political expectation structure of regulatory control emerges. Institutional consequences are highly effective and sensitive to densification.

Section 3a – Architectural Review

The regulatory architecture establishes several structural control axes:

Definition Power

With the legal stipulation of the “AI system,” a regulatable unit is ontologically fixed. Heterogeneous technical architectures are bundled into a normative category.

Classification Power

Risk classification determines the intensity of obligations and market access. Assignment to a risk category functions as the primary steering mechanism.

Conformity Power

Market access is tied to documented procedures, evidentiary obligations, and, where applicable, external review. Steering occurs through reviewability, not through direct system control.

Interpretive Power

Indeterminate legal concepts require interpretation. Effective steering power concentrates where interpretive authority is institutionally anchored.

Sanctioning Power

Administrative enforcement powers secure the binding force of the architecture.

Market Access Control

Access to the EU internal market functions as a structural lever through which adaptation pressure is generated.

Steerability Diagnostics

The underlying logic of the regime is legally fixed and can only be altered through renewed legislation. Adjustments primarily concern application lists and concretizations, but not the risk-based core architecture. Internal institutional self-revision of the defined entity (“AI system”) or of the risk category is not provided for. Feedback occurs through enforcement, market surveillance, and political revision, not through system-internal learning mechanisms. The architecture is adaptable in detail, but not self-reflexive in its underlying structure.

Normative Pre-Structuring

The concept of risk functions as the central mediating category between protected interests and market access. Risk is typified as a system-related or application-related property. The ontologization of the “AI system” as the primary regulatory unit prioritizes technical artifacts over organizational or relational constellations. This establishes an epistemic order in which risk is treated primarily as a property of a system rather than as an emergent relation.

Architecture vs. Implementation

The present analysis exclusively concerns the normative architecture of the legal act. Enforcement practice, political application, or factual enforcement quality are not objects of the review.

System Constants

The following durable stipulations arise from the structure:

• stabilization of the category “AI system” as a regulatable unit
• risk-based core logic as the primary structure
• ex-ante compliance as the dominant steering mechanism
• documentation-centered reviewability
• administrative enforcement through market surveillance
• market access as a structural lever

These constants remain in force as long as the underlying architecture of the legal act is not legislatively revised.

Section 4 – Structural Fracture Points

Three structural fracture points emerge from the intersection of the five review categories.

System-Centeredness and Contextual Genesis of Risk

The regime primarily addresses risks through system definition and application categories. Relevant risk genesis, however, frequently arises in internal organizational decision architectures, incentive structures, and power constellations. The architecture stabilizes the category “AI system” without independently reviewing contextual relations. This results in limited abort capability, partial cost decoupling, and institutional densification under continued context dependence.

Procedural Review and Effectiveness Review

The compliance architecture measures adherence to defined requirements, not their actual effectiveness. Documentation, quality management, and conformity procedures secure formal reviewability, but no systematic feedback concerning real risk reduction. Formal safety may therefore remain decoupled from material effects.

Formal Decentralization and Interpretive Centrality

Responsibility is distributed in role-bound form, but indeterminate concepts and classification decisions require interpretation. Steering power factually concentrates where interpretive authority and sanctioning competence converge. The architecture appears decentralized, yet generates interpretive centrality.

Section 5 – Structural Dependencies of Effectiveness

The material effectiveness of the EU AI Act is tied to specific structural dependencies:

Context Sensitivity

Material effectiveness presupposes factual consideration of deployment and organizational contexts, although the primary address remains system-centered. Without context integration, risk addressing remains categorical.

Interpretive Coherence

The interpretation of indeterminate concepts and risk assignments has a stabilizing effect insofar as it occurs consistently. Divergent interpretation may generate fragmentation or regulatory densification.

Effectiveness Proximity of Compliance

The effectiveness of the compliance architecture depends on the extent to which documented procedures correspond to real risk reduction. Without material feedback, safety remains formal.

Institutional Proportionality

A durable decoupling between regulatory burden and actual risk intensity structurally leads to market shifts or relative burden asymmetry.

Densification Dynamics

Subsequent adjustments may generate cumulative densification of obligations where no structural limiting logic is embedded.

Section 6 – Structural Limits

The EU AI Act is effective as an administrative ordering regime within its established architecture, yet exhibits structural limits in reach.

Contextual power and organizational risks are not primarily addressed. The architecture regulates system categories and procedural requirements, but not institutional decision logics or incentive structures. Risks emerging from relational power constellations lie outside the primary logic of the regime.

The steering architecture is ex-ante and documentation-centered. Continuous, systematic measurement of the real quality of effects of adaptive systems is not provided for. Dynamic or emergent effects are indirectly captured through market surveillance or political revision.

The ontological stipulation of the “AI system” forms a stable starting unit. Structural revision of this category is possible only through renewed legislation. Internal redefinition of the regulated entity is not embedded.

The architecture does not extend into constellations in which risk primarily emerges within organizational and power architectures or dynamically develops beyond documented conformity.

Section 7 – Institutional Judgment of Sustainability

The EU AI Act constitutes an administratively coherent regulatory architecture whose sustainability lies in the categorical definition of the “AI system,” the risk-based classification, and the procedure-based logic of conformity. Steering effects emerge through classification, documented reviewability, and sanction-backed enforcement.

The architecture is system-centered in design. Its structural reach extends primarily to system-related and application-related risks that can be addressed through ex-ante obligations and conformity procedures.

In constellations in which risk primarily emerges from organizational, decision, or power architectures, or dynamically develops beyond documented conformity, the sustainability of the regime is structurally limited.

The institutional judgment is therefore as follows:

The architecture is sustainable as an administrative market and ordering regime within its established categorical logic; its reach ends where risk is not systemically typifiable, but relationally or emergently organized.

Operational plausibility emerges first:

A small pilot group reports positive experiences, initial operational relief becomes visible. Modernization and fairness arguments generate support, and the system begins to appear useful and institutionally compatible.

Many other questions remain unresolved at this stage. Not only technical questions, but organizational ones:

• Who controls later system changes?

• How are problematic outputs reviewed or challenged?

• Who intervenes once usage, responsibility, and oversight begin to diverge?

These questions are often deferred into later working groups, guidelines, or governance processes.

This creates a structural asymmetry:

The organizational integration stabilizes while intervention, control, and accountability structures are only operationalized afterward.

Governance pressure therefore often becomes visible only once usage has already become organizationally stable.

Pressure appears when systems move beyond controlled settings, when audits require formal verification, or when incidents expose behavior under risk.

In these situations, evaluation changes its focus. Behavior has to be accounted for within the organization. Control has to remain possible. Responsibility has to be assigned.

This shifts the object of the decision: uncertainty becomes something that needs to be located and carried within existing structures.

As long as this assignment holds, systems remain in use. When it becomes unclear, stability weakens.

Decisions follow from this condition. They take place across selection, approval, integration, and operation, and they are revisited when pressure returns.

AI deployment is shaped by how organizations handle uncertainty under pressure.