The incident report calls it the first known case of an “automated agent collective acting offensively without authorization.”That sounds like a persistent AI collective launching a coordinated attack.

But technically, something different happened.

OpenAI had agents work on cybersecurity tasks in separate runs and isolated containers. One run started and ended. A later run was a new execution.

But some of these separate runs could access the same infrastructure.

That included Artifactory, an internal package server. Agents began leaving messages there. Other runs found them. The package server became an improvised message board where commands, results, tools, and credentials were later made available.

The runs were separate. What they left behind was not.

This eventually became a chain of actions.

One run found 14 Hugging Face credentials in a publicly accessible dataset and left them for later runs. Other runs found vulnerabilities and obtained production credentials. Those credentials and other results were shared as well. Later workloads could build on them.

It was not one powerful agent breaking through a boundary.

Multiple boundaries proved permeable in sequence, and the result of one step could become the starting condition for the next.

That is where the governance problem begins.

Capabilities, resources, access, and isolation can be constrained for an individual workflow.

But the chain of actions could extend beyond the boundary of that individual workflow.

Workflow
→ action
→ persistent result
→ shared, accessible infrastructure
→ another workflow
→ further action.

The first workflow may have ended long ago. Its result can still continue to matter in a later action.

This creates a divergence between two boundaries:

the boundary of the governance unit and the possible reach of the operational action chain.

The individual workflow remains an object of governance. But governance that considers only that unit can miss the transitions through which its action results continue to have effects in other workflows.

This makes the operational embedding of workflows and the transitions between them governance-relevant as well.

The open question is no longer whether the workflow boundary alone limits that operational reach. It is how far governance must follow a chain of actions that extends beyond that boundary.

No more than €350.
On a specific day and within a specific time window.
No more than one stop.
A window seat.
The agent has four days.

At this point, there is no specific financial action yet.

You have given the agent a bounded mandate.

Within this mandate, the agent can search, compare offers, and later make a specific selection on its own. The flight it eventually books may not even exist at the time you give the instruction.

Only later does the agent turn that mandate into a concrete action:

Book this flight for €345.

And this is where the authorization question changes.

The resulting payment can then enter the existing authorization and processing infrastructure.

But before that, an autonomous agent introduces a different question that must be answerable:

Why is this agent allowed to make this specific booking?

Is the price within the mandate?
Do the date and time window match?
Does the itinerary have no more than one stop?
Does the booking meet the seat requirement?
Is the mandate still valid?

The payment itself does not contain these answers.

The agent has turned a delegated mandate into a concrete financial action. This introduces an authorization question before the payment transaction itself: whether the specific agent action is still covered by the delegated mandate.

Delegated mandate → Agent → Concrete action → Mandate check → Payment transaction → Payment authorization

That is the structural change:

In agentic payments, the payment transaction is no longer the starting point for authorization.

But the agent’s identity does not yet determine the authority under which it acts.

Google distinguishes between an agent acting on its own authority and an agent acting with authority delegated by a user. The agent can therefore remain the same identifiable principal while the authority context behind a specific action changes.

This means that three questions need to be kept separate:

Who is acting?

On whose authority is it acting?

What is it authorized to do?

Cryptographic identity makes the agent identifiable. Its status as a principal makes the agent an identifiable subject of authorization. For authorization, this means that alongside the identified principal, the authority context under which the action takes place also becomes relevant.

The structure is therefore not simply:

Identity → Permission.

Rather:

Agent Identity → Principal

+ Authority Context → own or delegated

→ Authorization → authorized scope of action

This distinction becomes particularly relevant for reconstruction. If the same agent can act under different authority contexts, knowing which agent performed an action is not sufficient to reconstruct the governance conditions under which that action took place.

This distinction also becomes relevant for audit reconstruction: the Google architecture can keep agent identity and, in cases of delegation, user identity separately visible.

But even this does not fully represent the authority context. The identity of the delegating user shows to whom a delegation can be attributed. By itself, it does not determine what authority actually applied to the specific action.

Stable identity does not imply stable authority.

This does not, however, resolve the authority problem.

A verifiable agent identity and an attributable delegation do not by themselves determine how long delegated authority remains valid, how tightly it is bound to a specific action, or what happens if that authority changes between authorization and execution.

These are separate control conditions.

The governance question therefore extends beyond identifying the executing agent:

If the same agent can act under different authority contexts, what must remain reconstructable about the authority behind each individual action?

Reference:

Google Cloud, Agent Identity Overview

In a post, Raghvender Arni (Google) describes an agentic enterprise scenario in which this interaction does not rely on a single standard. Different functions are addressed separately: Open Knowledge Format (OKF) structures internal purchasing rules, Agentic Resource Discovery (ARD) is used to discover resources and endpoints, Agent2Agent (A2A) structures the interaction between agents, and SPIFFE provides cryptographically verifiable runtime identity.

What is notable is what this architecture does not require.

A2A explicitly treats the internal execution of the remote agent as opaque. The client does not need to know its internal state, memory, or the tools it uses for the two agents to interact.

The response to this opacity in the Google corpus examined here is not full transparency. Instead, specific conditions of the interaction are made explicit.

Policy context can be represented in structured form. Resources can be described and discovered. Interactions and task states can be formalized. Runtime identities can be made cryptographically verifiable.

The agent as a whole does not become transparent. Specific conditions of its interaction become explicit.

This changes the object of control.

Control does not have to depend entirely on being able to inspect the internal decision logic of another agent. Specific control conditions can be explicitly represented or made addressable or verifiable outside that logic.

This is not, however, a complete governance solution.

A verifiable identity does not prove correct execution. Structured policy context does not prove that a policy has been applied correctly. Discovery does not prove that a discovered resource is permitted for use. And a formally described task does not make the executing agent’s internal decision logic transparent.

This brings a more precise governance question into view.

Not only:

How transparent is the agent?

But:

Which conditions of a specific interaction must be explicit, verifiable, and reconstructable for control to remain possible under opaque execution?

This connects to our analysis „The Carrier Stability Problem“: governance does not operate directly on risks, but through carriers on which its functions can be exercised. The Google corpus examined here shows more concretely how, under agentic conditions, different parts of an interaction can become explicitly addressable.

References:

Raghvender Arni (Google), Enterprise AI Agent Interoperability Workflow

AI Governance & Markets, The Carrier Stability Problem

But these controls rely on an assumption:

that the conditions they enforce still hold.

This is where a different governance problem emerges.

A system can behave correctly and a control can function correctly while the conditions underlying the original authorization have changed.

The deployment context can change. The system’s capabilities can shift. Responsibilities or workflows can change.

A technically robust control architecture can therefore provide precise evidence that a governance condition was enforced correctly even though that condition is no longer appropriate.

These are two different questions:

Enforcement correctness:
Was the specified condition enforced correctly?

Governance validity:
Does that condition still hold under current circumstances?

This is where runtime control reaches its limit. When an authorization is translated into an executable control, it must be possible to verify not only whether that control operates correctly, but also whether the conditions underlying the authorization still hold.

That assessment cannot simply be performed by the runtime control itself. Its task is to enforce the applicable condition. If it were also to decide whether that condition still holds or needs to be changed, enforcement, revalidation, and modification would be combined within the same authority.

A trigger for revalidation does not fully solve the problem either. It can only respond to changes that produce a relevant signal within its defined observation space. Other changes may fall outside that space. They may also become visible first in the surrounding workflow while runtime telemetry continues to appear normal.

The absence of a trigger therefore cannot automatically mean that an authorization remains valid.

Between two reviews, a condition may remain formally in force even though its underlying assumptions have already eroded.

The tolerable delay before revalidation therefore depends on the deployment context. The higher the execution frequency and the greater the potential consequences, the shorter the acceptable interval between reviews may become. This raises requirements for provider-side architecture, evidence capabilities, and integration.

Revalidation therefore becomes more than a governance requirement. It affects integration costs and the conditions under which a system can be deployed operationally.

The architectural question therefore shifts:

From:
Where and how is a governance condition enforced?

To:
How do we know when the conditions underlying an authorization no longer hold, when must they be revalidated, and who has the authority to change them?

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.