<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[AI Governance & Markets]]></title><description><![CDATA[AI is not a technology problem.
It is an organizational and procurement problem.

Structural analysis of how AI reshapes decision systems and market access.]]></description><link>https://aigovernanceandmarkets.org</link><image><url>https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png</url><title>AI Governance &amp; Markets</title><link>https://aigovernanceandmarkets.org</link></image><generator>Substack</generator><lastBuildDate>Thu, 11 Jun 2026 04:20:26 GMT</lastBuildDate><atom:link href="https://aigovernanceandmarkets.org/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[AI Governance & Markets]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[aigovernancemarkets@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[aigovernancemarkets@substack.com]]></itunes:email><itunes:name><![CDATA[AI Governance & Markets]]></itunes:name></itunes:owner><itunes:author><![CDATA[AI Governance & Markets]]></itunes:author><googleplay:owner><![CDATA[aigovernancemarkets@substack.com]]></googleplay:owner><googleplay:email><![CDATA[aigovernancemarkets@substack.com]]></googleplay:email><googleplay:author><![CDATA[AI Governance & Markets]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[Measuring Is Not Yet Steering]]></title><description><![CDATA[CADA Reconstruction | Part 3 of 3 - Short]]></description><link>https://aigovernanceandmarkets.org/p/measuring-is-not-yet-steering</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/measuring-is-not-yet-steering</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Tue, 09 Jun 2026 07:20:42 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>This analysis reconstructs the European Commission&#8217;s impact assessment for the Cloud and AI Development Act (CADA), published on 3 June 2026 as SWD(2026) 502 (Impact Assessment, Part 1 and Part 2 with Annexes).</p><p>The first part examined the tension between infrastructure and dependence.</p><p>The second part examined the diagnosis of a demand and coordination problem.</p><p>This leaves one final question. If the proposed measures are actually implemented, how would the Commission later determine whether they are working?</p><p>Reading the monitoring and evaluation section, one notices how systematically this question is intended to be answered.</p><p>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).</p><p>At first, this is unsurprising. Anyone who formulates ambitious goals must also be able to determine whether those goals are being achieved.</p><p>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.</p><p>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.</p><p>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).</p><p>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).</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p></p>]]></content:encoded></item><item><title><![CDATA[The Hidden Demand Logic Behind CADA]]></title><description><![CDATA[CADA Reconstruction | Part 2 of 3 - Short]]></description><link>https://aigovernanceandmarkets.org/p/the-hidden-demand-logic-behind-cada</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/the-hidden-demand-logic-behind-cada</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Sun, 07 Jun 2026 07:01:55 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>This analysis reconstructs the European Commission&#8217;s impact assessment for the Cloud and AI Development Act (CADA), published on 3 June 2026 as SWD(2026) 502 (Impact Assessment, Part 1 and Part 2 with Annexes).</p><p>The first part examined the tension between infrastructure and dependence.</p><p>This raises an obvious question: What is the actual problem from the Commission&#8217;s perspective?</p><p>Those who follow the public debate about Europe&#8217;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.</p><p>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.</p><p>The further one follows the argument, the clearer a recurring pattern becomes.</p><p>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.</p><p>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.</p><p>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.</p><p>The impact assessment describes precisely this connection several times. According to the Commission&#8217;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.</p><p>At this point, it becomes clear why the definition of sovereignty plays such a central role in the document.</p><p>At first glance, it appears to be a regulatory classification. Over the course of the impact assessment, however, it takes on another function.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>This is precisely where the majority of the proposed measures intervene.</p><p>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.</p><p>This also shifts the actual challenge. The central issue is not the existence of demand, but its organization.</p><p>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.</p>]]></content:encoded></item><item><title><![CDATA[The Capacity Gap and the Dependence Gap]]></title><description><![CDATA[CADA Reconstruction | Part 1 of 3 - Short]]></description><link>https://aigovernanceandmarkets.org/p/the-capacity-gap-and-the-dependence</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/the-capacity-gap-and-the-dependence</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Fri, 05 Jun 2026 06:30:45 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>This analysis reconstructs the European Commission&#8217;s impact assessment for the Cloud and AI Development Act (CADA), published on 3 June 2026 as SWD(2026) 502 (Impact Assessment, Part 1 and Part 2 with Annexes).</p><p>More infrastructure can be created without automatically reducing dependence on a small number of large providers.</p><p>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.</p><p>At first glance, the logic appears simple. More infrastructure should strengthen Europe&#8217;s position.</p><p>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).</p><p>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.</p><p>The document becomes more interesting elsewhere.</p><p>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.</p><p>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).</p><p>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.</p><p>One consequence follows from this distinction. Additional capacity can be created in Europe without automatically changing who controls the market.</p><p>The capacity gap and the dependence gap are therefore related, but they are not the same thing.</p><p>Closing one does not automatically mean closing the other.</p><p>If dependency cannot be reduced through infrastructure alone, a different question emerges. What problem is CADA actually trying to solve?</p><p>That question is the focus of Part 2.</p>]]></content:encoded></item><item><title><![CDATA[Governance at the Execution Boundary]]></title><description><![CDATA[One thing that stands out in recent AI governance discussions is that very different fields seem to be converging on a similar problem.]]></description><link>https://aigovernanceandmarkets.org/p/governance-at-the-execution-boundary</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/governance-at-the-execution-boundary</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Mon, 01 Jun 2026 05:58:36 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>One thing that stands out in recent AI governance discussions is that very different fields seem to be converging on a similar problem.</p><p>The language differs. Some discussions focus on human oversight, others on deployment approval, trust boundaries, traceability, uncertainty recognition, or Zero Trust architectures.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://aigovernanceandmarkets.org/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p>Yet the underlying concern increasingly looks the same.</p><p>The question is becoming less about evaluating a system in isolation and more about governing what happens when it acts.</p><p>Several recent signals point in that direction. OpenAI&#8217;s Frontier Governance Framework emphasizes deployment decisions, residual risk acceptance, and ongoing model review. Anthropic&#8217;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.</p><p>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.</p><p>Independent convergence does not prove a conclusion is correct.</p><p>It can, however, be a useful indication that a structural problem is becoming visible.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://aigovernanceandmarkets.org/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div>]]></content:encoded></item><item><title><![CDATA[EU AI Act]]></title><description><![CDATA[Architectural Review of an Administrative Risk Regime]]></description><link>https://aigovernanceandmarkets.org/p/eu-ai-act</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/eu-ai-act</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Sat, 23 May 2026 17:36:12 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><strong>Reference Version &#8211; English</strong></p><p>Isomorphic English translation based on the German reference version.</p><div><hr></div><h3><strong>Section 1 &#8211; Review Protocol</strong></h3><p>Object<br><br>Regulation (EU) 2024/1689 (EU AI Act) in its structure as a governance architecture: definition of the &#8220;AI system,&#8221; risk classification, duties and compliance regime, enforcement mechanism, as well as target and protected-interest structure.<br><br>Review Standard<br><br>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.<br><br>Methodology<br><br>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.</p><h3><strong>Section 2 &#8211; Reconstruction of the Object</strong></h3><p>With the definition of the &#8220;AI system,&#8221; 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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.</p><h3><strong>Section 3 &#8211; Diagnosis of Architectural Effects</strong></h3><p>The application of the review standard proceeds along the five categories of Review Architecture v1.0.<br><br>Abort Capability<br><br>The ontological stipulation of the &#8220;AI system&#8221; 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.<br><br>Cost Truthfulness<br><br>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.<br><br>Exit Capability<br><br>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.<br><br>Power Clarity<br><br>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.<br><br>Institutional Consequences<br><br>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.</p><h4><strong>Section 3a &#8211; Architectural Review</strong></h4><p>The regulatory architecture establishes several structural control axes:<br><br>Definition Power<br><br>With the legal stipulation of the &#8220;AI system,&#8221; a regulatable unit is ontologically fixed. Heterogeneous technical architectures are bundled into a normative category.<br><br>Classification Power<br><br>Risk classification determines the intensity of obligations and market access. Assignment to a risk category functions as the primary steering mechanism.<br><br>Conformity Power<br><br>Market access is tied to documented procedures, evidentiary obligations, and, where applicable, external review. Steering occurs through reviewability, not through direct system control.<br><br>Interpretive Power<br><br>Indeterminate legal concepts require interpretation. Effective steering power concentrates where interpretive authority is institutionally anchored.<br><br>Sanctioning Power<br><br>Administrative enforcement powers secure the binding force of the architecture.<br><br>Market Access Control<br><br>Access to the EU internal market functions as a structural lever through which adaptation pressure is generated.<br><br>Steerability Diagnostics<br><br>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 (&#8220;AI system&#8221;) 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.<br><br>Normative Pre-Structuring<br><br>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 &#8220;AI system&#8221; 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.<br><br>Architecture vs. Implementation<br><br>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.<br><br>System Constants<br><br>The following durable stipulations arise from the structure:<br><br>&#8226; stabilization of the category &#8220;AI system&#8221; as a regulatable unit<br>&#8226; risk-based core logic as the primary structure<br>&#8226; ex-ante compliance as the dominant steering mechanism<br>&#8226; documentation-centered reviewability<br>&#8226; administrative enforcement through market surveillance<br>&#8226; market access as a structural lever<br><br>These constants remain in force as long as the underlying architecture of the legal act is not legislatively revised.</p><h3><strong>Section 4 &#8211; Structural Fracture Points</strong></h3><p>Three structural fracture points emerge from the intersection of the five review categories.<br><br>System-Centeredness and Contextual Genesis of Risk<br><br>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 &#8220;AI system&#8221; without independently reviewing contextual relations. This results in limited abort capability, partial cost decoupling, and institutional densification under continued context dependence.<br><br>Procedural Review and Effectiveness Review<br><br>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.<br><br>Formal Decentralization and Interpretive Centrality<br><br>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.</p><h3><strong>Section 5 &#8211; Structural Dependencies of Effectiveness</strong></h3><p>The material effectiveness of the EU AI Act is tied to specific structural dependencies:<br><br>Context Sensitivity<br><br>Material effectiveness presupposes factual consideration of deployment and organizational contexts, although the primary address remains system-centered. Without context integration, risk addressing remains categorical.<br><br>Interpretive Coherence<br><br>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.<br><br>Effectiveness Proximity of Compliance<br><br>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.<br><br>Institutional Proportionality<br><br>A durable decoupling between regulatory burden and actual risk intensity structurally leads to market shifts or relative burden asymmetry.<br><br>Densification Dynamics<br><br>Subsequent adjustments may generate cumulative densification of obligations where no structural limiting logic is embedded.</p><h3><strong>Section 6 &#8211; Structural Limits</strong></h3><p>The EU AI Act is effective as an administrative ordering regime within its established architecture, yet exhibits structural limits in reach.<br><br>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.<br><br>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.<br><br>The ontological stipulation of the &#8220;AI system&#8221; 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.<br><br>The architecture does not extend into constellations in which risk primarily emerges within organizational and power architectures or dynamically develops beyond documented conformity.</p><h3><strong>Section 7 &#8211; Institutional Judgment of Sustainability</strong></h3><p>The EU AI Act constitutes an administratively coherent regulatory architecture whose sustainability lies in the categorical definition of the &#8220;AI system,&#8221; the risk-based classification, and the procedure-based logic of conformity. Steering effects emerge through classification, documented reviewability, and sanction-backed enforcement.<br><br>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.<br><br>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.<br><br>The institutional judgment is therefore as follows:<br><br>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.</p>]]></content:encoded></item><item><title><![CDATA[Governance After Integration]]></title><description><![CDATA[When organizational legitimacy stabilizes before intervention capacity - Short]]></description><link>https://aigovernanceandmarkets.org/p/governance-after-integration</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/governance-after-integration</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Sun, 17 May 2026 14:19:17 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>In many AI integrations, organizational legitimacy stabilizes earlier than organizational control and intervention capacity.</p><p>Operational plausibility emerges first:</p><p>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.</p><p>Many other questions remain unresolved at this stage. Not only technical questions, but organizational ones:</p><ul><li><p>Who controls later system changes?</p></li><li><p>How are problematic outputs reviewed or challenged?</p></li><li><p>Who intervenes once usage, responsibility, and oversight begin to diverge?</p></li></ul><p>These questions are often deferred into later working groups, guidelines, or governance processes.</p><p>This creates a structural asymmetry:</p><p>The organizational integration stabilizes while intervention, control, and accountability structures are only operationalized afterward.</p><p>Governance pressure therefore often becomes visible only once usage has already become organizationally stable.</p>]]></content:encoded></item><item><title><![CDATA[When AI decisions actually happen]]></title><description><![CDATA[Decision under pressure - Short]]></description><link>https://aigovernanceandmarkets.org/p/when-ai-decisions-actually-happen</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/when-ai-decisions-actually-happen</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Fri, 08 May 2026 07:30:53 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>AI systems are often discussed in terms of capability and performance. In practice, decisions about their use tend to emerge under pressure.</p><p>Pressure appears when systems move beyond controlled settings, when audits require formal verification, or when incidents expose behavior under risk.</p><p>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.</p><p>This shifts the object of the decision: uncertainty becomes something that needs to be located and carried within existing structures.</p><p>As long as this assignment holds, systems remain in use. When it becomes unclear, stability weakens.</p><p>Decisions follow from this condition. They take place across selection, approval, integration, and operation, and they are revisited when pressure returns.</p><p>AI deployment is shaped by how organizations handle uncertainty under pressure.</p>]]></content:encoded></item><item><title><![CDATA[AI Governance as Admission: Verification and Access under Real Conditions]]></title><description><![CDATA[How verification is translated into access through distributed decision structures - Open Analysis #02]]></description><link>https://aigovernanceandmarkets.org/p/ai-governance-as-admission-verification</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/ai-governance-as-admission-verification</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Wed, 06 May 2026 15:04:40 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em>Full PDF versions (EN/DE) are available at the end of the document.</em></p><div><hr></div><p><strong>Version Note</strong></p><p>This text is a derived version of the original German analysis.<br>The German version remains the reference text.</p><div><hr></div><h3><strong>1. Starting Point: Verification as a Capability</strong></h3><p>The AI Act shifts the evaluation logic of AI systems toward verification.</p><p>At the center is the question of whether the behavior of an AI system can be traced and assessed under risk conditions. AI systems are evaluated based on whether their outputs are reconstructable and whether intervention remains possible. It is also decisive whether their behavior can be stably assessed under changing conditions.</p><p>This shift changes the reference point of evaluation. Assessment is no longer primarily directed at the quality of individual outputs, but at whether an AI system can be reliably assessed under conditions of uncertainty.</p><p>This creates a new basis for the use of AI. Access depends on whether behavior can be reliably assessed under verification conditions.</p><h3><strong>2. Operationalization</strong></h3><p>This requirement is translated into operational structures. Verification emerges from the interaction of multiple elements. Documentation makes behavior reconstructable. Control mechanisms enable intervention. Conformity requirements link usage to these structures. These elements operate together and embed verification into ongoing operations.</p><p>This creates a central condition: AI systems must be able to maintain their own controllability in operation. Whether this structure is viable depends on how validation processes are designed. What is decisive is how independently the verification process is organized from the AI system being assessed.</p><p>With increasing integration of AI into both layers, this relationship changes. Validation can become part of the same AI system it is supposed to assess. The formal structure of verification remains intact, but its validity depends on whether the verification is actually independent.</p><h3><strong>3. Transition to Admission</strong></h3><p>At this point, the function of verification shifts. It becomes the object of decision-making. Organizations must determine whether an AI system is sufficiently controllable under risk to be deployed.</p><p>From this determination, admission emerges. It only operates where AI systems are actually integrated into this decision structure. Systems that are used outside of this structure - for example through shadow use or as embedded functions within existing products - evade this form of structured selection.</p><h3><strong>4. Admission as a Decision System</strong></h3><p>In practice, admission is distributed across multiple decision instances. This structure typically includes selection, approval, embedding, and operation. These instances operate in an overlapping and partially contradictory manner. Decisions can be revised, and responsibilities are distributed.</p><p>This leads to a fundamental shift. Access is no longer a one-time process, but a state that is continuously evaluated within these decision structures.</p><p>This structure only produces effects if decisions can be enforced. Without enforcement, formal decisions remain without operational consequence.</p><h3><strong>5. Object of Decision</strong></h3><p>At the center of the decision is not the performance of an AI system. What is decisive is whether uncertainty can be assigned to a specific instance and operationally managed by it.</p><p>An AI system remains admitted if it is clear who is responsible for the resulting uncertainty and can handle it in operation. This assignment forms the basis for whether a system can be operated in a responsible way.</p><p>If this assignment is missing, formal access becomes unstable. The AI system must then be reassessed within the decision structures.</p><h3><strong>6. Difference between Formal and Real Usage</strong></h3><p>A difference regularly emerges between formal admission and real usage. AI systems are used even when verification is incomplete, responsibility remains unclear, or formal admission is missing.</p><p>Such constellations can solidify and remain stable over longer periods of time. Formal and real layers therefore frequently diverge.</p><h3><strong>7. Pressure on the Difference</strong></h3><p>This difference rarely remains stable in practice. Selection emerges under pressure, not through automatic alignment. This pressure is potentially permanent, but often remains latent and is unevenly distributed. It becomes effective when concrete triggers occur, such as incidents, audits, scaling effects, or regulatory changes.</p><p>In such situations, the difference becomes visible and must be addressed. Pressure is then translated into decision pressure within the existing structures.</p><h3><strong>8. Decision Responses</strong></h3><p>Under this pressure, decision instances face three fundamental options.</p><p>They can carry the difference and continue operating the AI system despite existing deviations. Restriction occurs through adjustments, additional controls, or reduced use. Ultimately, access can be terminated.</p><p>Restriction is not unambiguous. It can mean that actual problems are reduced, or that only formal adjustments are made without changing the behavior of the AI system. In both cases, the AI system can initially remain admitted, but with different levels of stability under pressure.</p><p>Additionally, pressure can be absorbed. This occurs, for example, through documentation, formal risk assignment, or the shifting of responsibility, without changing the actual system behavior.</p><h3><strong>9. Selection Mechanism</strong></h3><p>Selection emerges when decision instances are forced to address this difference. An AI system remains admitted as long as uncertainty can be assigned to an instance and managed operationally. It falls out when this assignment disappears or no longer holds.</p><h3><strong>10. Conclusion</strong></h3><p>Verification is no longer solely a matter of formal requirements. It becomes the operational condition of access.</p><p>Admission defines the order in which uncertainty is assigned and decisions are made under pressure.</p><p></p><p>Ralf Brentf&#252;hrer</p><p>May 2026</p><div><hr></div><p>Download full paper (PDF):</p><div class="file-embed-wrapper" data-component-name="FileToDOM"><div class="file-embed-container-reader"><div class="file-embed-container-top"><image class="file-embed-thumbnail-default" src="https://substackcdn.com/image/fetch/$s_!0Cy0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Fattachment_icon.svg"></image><div class="file-embed-details"><div class="file-embed-details-h1">Open Analysis #02 - AI Governance as Admission</div><div class="file-embed-details-h2">1.1MB &#8729; PDF file</div></div><a class="file-embed-button wide" href="https://aigovernanceandmarkets.org/api/v1/file/073080b3-5590-4307-b9f5-14372452bfd0.pdf"><span class="file-embed-button-text">Download</span></a></div><div class="file-embed-description">Download the full analysis (PDF). The German version is the reference text. The English version is derived.</div><a class="file-embed-button narrow" href="https://aigovernanceandmarkets.org/api/v1/file/073080b3-5590-4307-b9f5-14372452bfd0.pdf"><span class="file-embed-button-text">Download</span></a></div></div><div class="file-embed-wrapper" data-component-name="FileToDOM"><div class="file-embed-container-reader"><div class="file-embed-container-top"><image class="file-embed-thumbnail-default" src="https://substackcdn.com/image/fetch/$s_!0Cy0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Fattachment_icon.svg"></image><div class="file-embed-details"><div class="file-embed-details-h1">Open Analysis #02 - KI-Governance als Zulassungsstruktur</div><div class="file-embed-details-h2">1.1MB &#8729; PDF file</div></div><a class="file-embed-button wide" href="https://aigovernanceandmarkets.org/api/v1/file/4576d791-1312-4535-8df5-a8cf1adc505c.pdf"><span class="file-embed-button-text">Download</span></a></div><div class="file-embed-description">Vollst&#228;ndige Analyse als PDF. Die deutsche Fassung ist die Referenzfassung. Die englische Fassung ist abgeleitet.</div><a class="file-embed-button narrow" href="https://aigovernanceandmarkets.org/api/v1/file/4576d791-1312-4535-8df5-a8cf1adc505c.pdf"><span class="file-embed-button-text">Download</span></a></div></div><p> </p>]]></content:encoded></item><item><title><![CDATA[AI Regulation as Value Chain Reconfiguration ]]></title><description><![CDATA[How the AI Act reshapes processes, cost structures, market logics, and labor - Open Analysis #01]]></description><link>https://aigovernanceandmarkets.org/p/ai-regulation-as-value-chain-reconfiguration</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/ai-regulation-as-value-chain-reconfiguration</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Fri, 03 Apr 2026 19:29:05 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em>Full PDF versions (EN/DE) are available at the end of the document.</em></p><div><hr></div><p>Version Note</p><p>This English text is a derived version of the original German analysis. <br>The German version remains the reference text.</p><p>This analysis examines how the AI Act restructures AI-related value chains through documentation, verification, and control requirements. Its focus is not on compliance as an isolated function, but on the organizational, economic, and labor effects of regulation as it moves through processes, operations, and market structures.</p><div><hr></div><h3><strong>1. Regulatory Framing</strong></h3><p>The AI Act establishes a regulatory approach to AI systems that is primarily organized through product law. Regulation does not primarily target contexts of use, but system properties and their verifiability. This approach is complemented by a risk-based framework that differentiates requirements across defined risk categories and thereby produces varying intensities of regulatory intervention (cf. Art. 5, Art. 6, Annex III).</p><p>At its core lies a shift from functional evaluation to structural requirement: systems must not only function, but their operation, development, and behavior must be documentable, traceable, and verifiable. These requirements take concrete form in obligations related to technical documentation, record-keeping, and traceability (cf. Art. 11, Art. 12, Annex IV).</p><p>This results in a fundamental transformation of regulatory access: regulation no longer primarily addresses outcomes, but the conditions of their production and their verification. This structure is further reinforced by requirements concerning human oversight and post-market monitoring, extending regulatory reach beyond the point of market entry to the entire lifecycle of a system (cf. Art. 14, Art. 61).</p><p>As a consequence, the AI Act establishes a continuous verification requirement as a central condition of regulatory conformity. This marks the transition to the mechanism layer: what matters is not the existence of requirements, but how they are translated into operational processes.</p><h3><strong>2. Value Chain Structure</strong></h3><p>The effects of the AI Act unfold across the entire value chain of AI systems. For analytical purposes, this chain is functionally divided into four stages: upstream, integration, application, and maintenance. This segmentation does not seek to mirror specific corporate structures, but to distinguish analytically between different functions within the development and use of AI systems.</p><p>The upstream stage covers model development and the generation of underlying capabilities. It is here that core preconditions for regulatory conformity emerge, particularly with regard to data requirements and data provenance, which must already be addressed during the development process (cf. Art. 10). Regulation therefore acts at this level primarily through requirements concerning the conditions under which systems are created.</p><p>The integration stage covers the embedding of models into concrete applications and systems. At this stage, regulatory requirements are translated into operational environments. Requirements concerning technical documentation and logging directly shape integration processes (cf. Art. 11, Art. 12). Integration thereby becomes not only a technical function, but also a regulatorily structured one.</p><p>The application stage refers to the operational use of AI systems. At this level, requirements arising from risk classification, as well as obligations concerning human oversight and transparency, become directly effective (cf. Art. 13, Art. 14). Regulation thereby becomes a permanent operational condition and structures the ongoing use of systems.</p><p>The maintenance stage includes system upkeep, updates, and the continuous monitoring of systems over their lifecycle. Requirements such as post-market monitoring and incident reporting mean that regulatory obligations persist even after deployment (cf. Art. 61, Art. 62). Changes to systems are therefore not unconstrained, but tied to renewed verification and review processes.</p><p>These four stages are functionally distinct, but structurally interconnected. Regulatory requirements do not act in isolation on individual parts of the chain, but propagate across the value chain as a whole. Decisions and constraints introduced in earlier stages shape the room for maneuver in later stages, while requirements emerging in operation feed back into development and integration.</p><h3><strong>3. Mechanism Layer</strong></h3><p>The regulatory effects of the AI Act unfold as an operational mechanism. Between regulatory requirement and real-economic consequence lies a translation layer in which legal provisions are transformed into concrete process requirements. This layer is decisive, because regulation only becomes effective once it has to be built into operational workflows.</p><p>The central mechanism of this translation is the verification requirement. Systems must be designed in a compliant manner, and this compliance must be structurally demonstrable. This produces a shift from functionality to verifiable operation. Requirements such as technical documentation, logging, and conformity assessment create new operational conditions (cf. Art. 11, Art. 12, Art. 16&#8211;19).</p><p>This verification requirement is integrated into processes and thereby structurally embedded in them. Verification structures are incorporated from the outset into system architecture, development, integration, and operation. What might previously have appeared as a technical or organizational workflow thereby becomes part of a regulatorily ordered process logic.</p><p>This embedding gives rise to process expansion and constraints. Processes become longer, more segmented, and tied to additional conditions. New decision points, requirements for human oversight, and obligations of continuous observability through monitoring and logging increase the number of points at which a system must be built, used, reviewed, documented, and secured (cf. Art. 12, Art. 14, Art. 61).</p><p>This marks the first real transformation layer of regulation: the AI Act changes the conditions of development, integration, and use. At this level, it acts as a mechanism for reshaping operational workflows. The result is additional complexity and, at the same time, a new process logic in which control, verification, and intervention capacity become durable components of value creation.</p><h3><strong>4. Organizational Impact</strong></h3><p>Once regulatory requirements are translated into operational mechanisms, they begin to reshape the internal structure of organizations. The AI Act therefore affects not only technical systems, but also the way organizations internally organize responsibility, control, and execution.</p><p>The starting point of this effect lies in the process expansion and constraints described above. Once processes become longer, more documentation-bound, and tied to additional review conditions, existing organizational forms often no longer suffice. What could previously be organized within relatively compact development, integration, or operational logics must now be translated into additional responsibilities, review pathways, and approval structures.</p><p>This gives rise to a structural layering of organizations. Between development, integration, and operation, new layers of control and coordination emerge that are oriented toward regulatory assurance. This layering takes concrete form in compliance layers, additional control functions, and a growing number of internal interfaces at which systems, processes, and responsibilities are reviewed for conformity.</p><p>One immediate consequence of this layering is role expansion and fragmentation. New requirements create additional roles or reshape existing role profiles. Activities such as documentation, validation, monitoring, approval, or the exercise of human oversight become distinct areas of work. Organizations must therefore accommodate more functions while also managing more handovers, coordination points, and allocations of responsibility.</p><p>The regulatory effect thus becomes visible in the changing internal architecture of organizations. What begins as a primarily execution-oriented structure gradually turns into an organization in which control, verification, and regulatory coordination become integral parts of the operating model. The AI Act thus acts as a trigger of internal reorganization.</p><h3><strong>5. Transition Dynamics</strong></h3><p>The changes triggered by the AI Act unfold through a phased structural transition. Between existing organizational and process logics and the regulated target structure, an intermediate condition emerges that is marked by overlap, friction, and temporary inefficiency.</p><p>The starting point lies in the introduction of new process constraints and verification requirements, which are initially integrated only selectively into existing workflows. These interventions do not produce an immediate reordering, but first create an overlap of old and new logics. Existing processes remain in place, but are supplemented by additional review, documentation, and control steps.</p><p>In this phase, a condition of structural tension emerges: organizations operate simultaneously with a logic oriented toward speed and efficiency and a progressively dominant logic of control and verifiability. This overlap produces inconsistencies, increased coordination burdens, and temporary losses of efficiency.</p><p>A central transitional phenomenon is re-manualization. Automated or partially automated processes are temporarily supplemented or replaced by manual review, control, and decision structures. This development is both the result of organizational reordering and a direct response to uncertainty, the absence of established procedures, and the need to secure regulatory requirements in the short term. Human control functions in this phase as a bridge between existing systems and future formalized verification structures.</p><p>The result is a phase of temporary inefficiency in which processes take longer, resources are tied up, and parallel structures remain in place. This inefficiency is not a flaw of the system, but a structural component of the transformation: it enables the gradual adaptation of processes, roles, and responsibilities to the new regulatory conditions.</p><p>Only at a later stage does a systemic reordering take place, in which regulatory requirements are no longer added onto existing structures, but become integral parts of newly designed processes. The transitional phase thereby loses importance, and the frictions that emerged earlier are partially translated into stable organizational and operational routines.</p><p>The transformation does not unfold linearly. Its speed, intensity, and form differ depending on organization, risk class, and field of application. Adaptation strategies, technological support, and regulatory interpretive flexibility lead to different transition paths. Even so, the underlying dynamic remains stable: regulation first creates overlap, then friction, and finally structural reordering.</p><h3><strong>6. Economic Effects</strong></h3><p>The economic effect of the AI Act manifests itself in a structural shift in the cost structure across the entire value chain. It emerges from the accumulation of process expansion, additional control requirements, and the adaptation dynamics that become effective during the transition phase.</p><p>Once processes become documentation-bound, more control-intensive, and tied to additional approval and review mechanisms, the resource requirements per development step, integration process, operational workflow, and system change increase. The previously dominant logic of scaling and automation is thereby overlaid by requirements of verifiability, control, and regulatory assurance, which are directly reflected in the cost structure.</p><p>This leads to cost intensification that includes both fixed and ongoing costs. Fixed costs arise from the establishment of documentation, review, and governance structures. Ongoing costs emerge in operation through continuous monitoring, validation, incident, and update processes. The economic effect therefore lies not in a one-off adjustment, but in a durable expansion of the cost base across the entire lifecycle of systems.</p><p>A significant part of these costs serves regulatory assurance. Resources are deployed to establish, demonstrate, and maintain conformity. This shifts the internal allocation logic: a growing share of expenditures is directed toward stabilization, documentation, and control rather than the development of additional functionality.</p><p>These cost effects also appear with time lags and differ significantly across organizations. Some burdens arise early through setup and implementation, while others only become effective in ongoing operation, for example through post-market monitoring, incident reporting, or the revalidation of modified systems (cf. Art. 61, Art. 62). The economic dynamic is therefore cumulative and not confined to individual phases.</p><p>The economic logic of AI applications thus shifts from a structure primarily oriented toward speed and declining marginal costs to a model in which controllability, verifiability, and regulatory robustness become distinct and durable cost factors. The question of cost thereby becomes the central mechanism through which regulatory requirements are translated into market and labor effects.</p><h3><strong>7. Market Mechanisms</strong></h3><p>The shift in cost structure described in the previous step does not remain confined to the level of individual organizations, but changes the conditions of market access and competitiveness. This marks the actual reordering of the market: regulation now acts no longer only within organizations, but on the structure of the field itself.</p><p>The central driver of this shift is the growing significance of regulatory costs and process requirements. Once the capacity for regulatory assurance becomes a prerequisite for development, integration, and operation, the conditions of market entry begin to change. New or smaller actors must not only build technological capability, but also the ability to meet and demonstrate regulatory requirements in a reliable manner.</p><p>This gives rise to entry barriers that are shaped not primarily by capital requirements in the classical sense, but by organizational, documentary, and process-related demands. Access to the market thereby becomes more tightly tied to structural resilience, internal coordination capacity, and regulatory maturity. Regulation thus produces not merely an additional requirement, but a change in the conditions of legitimate participation in the market.</p><p>This shift changes the market structure as a whole. Larger or already structurally resilient actors enjoy advantages because they can absorb regulatory requirements more easily, integrate them into existing governance structures, and distribute them across multiple process layers. At the same time, the attractiveness of standardized solutions, specialized intermediaries, and external support services increases, as these can partially externalize or bundle regulatory complexity.</p><p>The internal logic of competition is thereby altered. Alongside technological capability and innovation speed, the ability to integrate regulation gains strategic importance. Those who can translate requirements into operational processes more quickly, more stably, and more cost-effectively gain structural advantages in the market. Regulation thus becomes a competitive factor in its own right.</p><p>These market effects are not fully deterministic. Adaptation strategies, standardization, tooling, and new service segments can mitigate or redistribute some of the burdens. Even so, the direction of movement remains stable: the market shifts from a relatively open innovation logic toward a structure in which verifiability, organizational resilience, and regulatory compatibility become central conditions of economic positioning.</p><h3><strong>8. Changes in Work</strong></h3><p>Changes in market structure and internal organizational logic feed directly back into the structure of work. As processes become increasingly driven by verification requirements, not only tasks change, but also the distribution of responsibilities, roles, and qualification demands along the value chain.</p><p>The starting point is the combination of structural layering and changing market conditions. Once additional requirements for control, documentation, and validation are permanently integrated into processes, new areas of activity emerge, while existing tasks are redefined or expanded. Work shifts along existing functions and becomes more tightly coupled to regulatory requirements.</p><p>This development leads to task shifts. Activities that were previously organized in purely technical or operational terms are supplemented by elements of documentation, review, and assurance. At the same time, distinct areas of work emerge, for example in connection with monitoring, validation, documentation, and the exercise of human oversight. Work thereby becomes more fragmented and is broken down into more specialized components.</p><p>On this basis, capability profiles begin to shift. What is required is no longer solely technical expertise or domain knowledge, but increasingly hybrid capabilities that combine technical, regulatory, and organizational requirements. The ability not only to develop or operate systems, but also to document, explain, and situate their behavior within a regulatory context becomes more important.</p><p>This shift does not unfold uniformly. Depending on organization, sector, and risk class, different patterns of task distribution and qualification requirements emerge. In some areas, existing roles are expanded, while in others new specialized functions are created. At the same time, parts of the work induced by regulatory requirements can be externalized or supported through standardized tools, leading to further differentiation within the structure of work.</p><p>The AI Act therefore does not primarily transform the world of work through substitution, but through a reorganization of tasks and capability profiles. Work becomes more deeply embedded in processes oriented toward verifiability, control, and regulatory stability. The central shift thus lies not in the disappearance of work, but in its structural reordering along regulatory requirements.</p><h3><strong>9. Cross-Layer Logic</strong></h3><p>The preceding sections describe the individual layers of the transformation. Their full effect, however, only becomes visible when considered in their interconnection. The cross-layer logic captures the continuous causal structure that links regulatory requirements with organizational, economic, and labor-related changes.</p><p>At the center lies a vertical chain of derivation that extends from regulatory access to changes in work. The starting point is product law, which establishes a verification requirement through control-related obligations. This requirement is translated into operational processes and leads to the embedding of verification structures, which in turn produce process expansion and additional constraints. As a result, organizational structures change, structural layering emerges, and re-manualization appears as a transitional phenomenon.</p><p>This dynamic condenses into a distinct cost logic that, through entry barriers, shapes the structure of the market. The resulting market conditions then feed back into the organization of work and lead to shifts in tasks and capability profiles.</p><p>Alongside this vertical chain, feedback structures emerge that reinforce and stabilize the dynamics of the system. Requirements arising at the application stage, for example through monitoring or incident reporting, feed back into decisions at the development stage, as systems must be designed from the outset to meet verification and regulatory requirements. At the same time, market changes exert pressure on organizations to further adapt their internal structures and processes.</p><p>Across all layers, the logic of verification acts as the unifying principle. It is the common denominator that connects regulatory requirements, operational processes, organizational structures, cost dynamics, and market mechanisms. What emerges is not a loose collection of effects, but an interconnected system in which each layer prepares and reinforces the next.</p><p>The cross-layer logic thus shows that the AI Act cannot be understood as a collection of isolated rules. Its effect arises from the chaining of mechanisms that unfold along the value chain and stabilize one another. In this model, regulation acts as a continuous transformation pathway rather than a discrete intervention.</p><h3><strong>10. Reality Anchor</strong></h3><p>The reconstructed logic of effects describes the structural direction of the transformation. It does not, however, claim uniformity across all real-world contexts. The reality anchor marks the boundary between analytical coherence and empirical variability and thereby preserves the model&#8217;s applicability across different organizational, regulatory, and economic settings.</p><p>The effects of the AI Act do not unfold with identical intensity in all cases. Differences in risk class, field of application, organizational scale, sectoral context, and regulatory interpretation mean that individual mechanisms appear with varying strength. The chain described above therefore does not represent a uniform reality, but a structural pattern whose concrete expression can vary.</p><p>The transformation does not unfold linearly in practice. Between regulatory requirements and organizational or economic effects, there are often time lags, adjustment loops, and transitional phases in which old and new logics coexist. Real-world development is therefore characterized by temporal offsets and uneven transitions, without this undermining the overall direction of the transformation described.</p><p>Actors do not respond passively to regulation. Firms, service providers, integrators, and other market participants develop strategies to absorb, standardize, or partially externalize regulatory burdens. Such adaptation dynamics can mitigate, redistribute, or reshape individual effects. They do not, however, alter the underlying mechanism that regulatory requirements must be translated into processes, costs, and market structures.</p><p>The reality anchor thus fulfills a dual function: it limits the scope of the model while increasing its robustness. The analysis does not describe a mechanical necessity in every individual case, but a structurally plausible transformation logic that explicitly incorporates real-world variation, temporal shifts, and strategic adaptation. In this way, the reconstruction remains analytically precise without ignoring the variability of actual developments.</p><h3><strong>11. Systemic Condensation</strong></h3><p>The preceding analysis unfolds the effects of the AI Act across multiple layers and mechanisms. Systemic condensation reduces these elements to their underlying directional movements. The aim is to make the structural transformation visible through a small number of overarching shifts without abandoning the causal logic developed earlier.</p><p>The primary movement can be described as a transition from an execution logic to a verification logic. In the initial structure, the development, integration, and use of AI systems are primarily oriented toward functionality and performance. Under regulatory conditions, the ability to make these processes verifiable, controllable, and auditable becomes central. Verifiability thus becomes an independent organizing principle of value creation.</p><p>A second movement concerns the structure of systems themselves. Flexible systems, characterized by rapid iteration, adaptability, and low formal constraint, evolve into structured systems with clearly defined process steps, control points, and documented procedures. Flexibility is not eliminated, but becomes increasingly bound to formal requirements.</p><p>The third movement concerns the distribution of capabilities within the market. A relatively broad and low-threshold capacity to develop and use AI systems is replaced by a reconfigured distribution of capabilities. Capabilities concentrate where regulatory requirements can be integrated, sustained, and scaled. At the same time, new forms of specialization and support structures emerge that address these requirements.</p><p>These three movements are not independent, but interlinked. The dominance of verification logic produces structured systems, and structured systems, in turn, favor a different distribution of capabilities within the market. Systemic condensation thus makes visible that the transformation does not consist of isolated effects, but of a coherent reordering of central principles of value creation.</p><h3><strong>12. Core Relation</strong></h3><p>The entire analysis can be condensed into a central relation of effects. Its starting point is the verification requirement established by the AI Act, which acts as the unifying principle structuring all downstream layers. From this follows process expansion, as development, integration, operation, and maintenance must all be supplemented by additional review, documentation, and control steps.</p><p>This process expansion does not remain confined to the level of individual workflows, but leads to the structural layering of organizations. New roles, interfaces, control functions, and coordination demands arise as a direct consequence of the regulatory logic of verification. Organizations thereby become not only more complex, but internally configured in different ways.</p><p>This internal reorganization produces a shift in cost structure. The capacity to meet, demonstrate, and maintain regulatory requirements across the lifecycle of a system becomes a distinct cost factor. This cost structure, in turn, feeds back into the conditions of market access and competitiveness.</p><p>At the end of this chain lies a reconfiguration of the market, in which the conditions of legitimate participation, the distribution of capabilities, and the logic of competition are altered. The core relation thus shows in compressed form where the actual effect of the AI Act lies: not in isolated obligations or prohibitions, but in the structural translation of verification requirements into changes in process, organization, cost, and market structure.</p><h3><strong>13. Source Architecture</strong></h3><p>The present analysis is based on a clear distinction between externally grounded regulatory concepts and model-internal terminology. External concepts and mechanisms are traced, where central to the structure of the argument, to the relevant regulatory components of the AI Act. Model-internal terms, by contrast, serve the purpose of analytical reconstruction and do not claim direct grounding in the wording of the regulation itself.</p><p>The central regulatory basis consists of the provisions relating to risk classification, prohibited practices, the requirements for high-risk AI systems, as well as technical documentation, record-keeping, human oversight, conformity assessment, post-market monitoring, and incident reporting (cf. Art. 5, Art. 6, Art. 8&#8211;15, Art. 16&#8211;19, Art. 61, Art. 62; Annex III, Annex IV).</p><p>For individual lines of argument, adjacent regulatory and technical frameworks may also be drawn upon, for example in the area of product liability or in standards that further specify auditability, traceability, and risk management. These supplementary references do not serve to expand the model, but to sharpen its regulatory applicability.</p><p>The function of sources is therefore clearly limited: they anchor central mechanisms, but do not replace analytical derivation. The analysis should accordingly not be understood as a commentary on the legal text, but as a structural reconstruction of its likely logic of effects along the value chain.</p><p></p><p>Ralf Brentf&#252;hrer</p><p>April 2026</p><div><hr></div><p>Download full paper (PDF):</p><div class="file-embed-wrapper" data-component-name="FileToDOM"><div class="file-embed-container-reader"><div class="file-embed-container-top"><image class="file-embed-thumbnail-default" src="https://substackcdn.com/image/fetch/$s_!0Cy0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Fattachment_icon.svg"></image><div class="file-embed-details"><div class="file-embed-details-h1">Open Analysis #01 - AI Regulation As Value Chain Reconfiguration (EN)</div><div class="file-embed-details-h2">1.13MB &#8729; PDF file</div></div><a class="file-embed-button wide" href="https://aigovernancemarkets.substack.com/api/v1/file/3a52c257-062f-4bfd-b75b-fdf297ea801d.pdf"><span class="file-embed-button-text">Download</span></a></div><div class="file-embed-description">Download the full analysis (PDF).
The German version is the reference text. The English version is derived.</div><a class="file-embed-button narrow" href="https://aigovernancemarkets.substack.com/api/v1/file/3a52c257-062f-4bfd-b75b-fdf297ea801d.pdf"><span class="file-embed-button-text">Download</span></a></div></div><div class="file-embed-wrapper" data-component-name="FileToDOM"><div class="file-embed-container-reader"><div class="file-embed-container-top"><image class="file-embed-thumbnail-default" src="https://substackcdn.com/image/fetch/$s_!0Cy0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Fattachment_icon.svg"></image><div class="file-embed-details"><div class="file-embed-details-h1">Open Analysis #01 - KI-Regulierung als Umbau der Wertsch&#246;pfungskette (DE)</div><div class="file-embed-details-h2">1.14MB &#8729; PDF file</div></div><a class="file-embed-button wide" href="https://aigovernancemarkets.substack.com/api/v1/file/769b1362-3304-432e-9e12-77e92383e1fe.pdf"><span class="file-embed-button-text">Download</span></a></div><div class="file-embed-description">Vollst&#228;ndige Analyse als PDF.
Die deutsche Fassung ist die Referenzfassung. Die englische Fassung ist abgeleitet.</div><a class="file-embed-button narrow" href="https://aigovernancemarkets.substack.com/api/v1/file/769b1362-3304-432e-9e12-77e92383e1fe.pdf"><span class="file-embed-button-text">Download</span></a></div></div><p></p>]]></content:encoded></item><item><title><![CDATA[The AI Act as Organizational Regulation]]></title><description><![CDATA[Real-economy analysis of the organizational and economic impacts of the EU AI Act. - Reference Framework]]></description><link>https://aigovernanceandmarkets.org/p/the-ai-act-as-organizational-regulation</link><guid isPermaLink="false">https://aigovernanceandmarkets.org/p/the-ai-act-as-organizational-regulation</guid><dc:creator><![CDATA[AI Governance & Markets]]></dc:creator><pubDate>Fri, 20 Mar 2026 16:19:29 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!c8YD!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6eb38de-3e95-46b3-b0bb-88b74566fe43_900x900.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em>Full PDF version (EN/DE) at the end of the document.</em></p><h3><strong>1. Executive Summary</strong></h3><h4><strong>A. Organizational regulation instead of technology regulation</strong></h4><p>The EU AI Act regulates less the technology itself than the organizational conditions of its deployment.</p><h4><strong>B. New governance and decision structures</strong></h4><p>Risk classification, documentation requirements and human oversight reshape processes, responsibilities and organizational control mechanisms within organizations.</p><h4><strong>C. Transition frictions and emerging markets</strong></h4><p>The adjustment phase introduces temporary remanualization of processes and longer development cycles, while new markets for governance, certification and infrastructure emerge simultaneously.</p><h3><strong>2. Perspective Framework</strong></h3><p>The EU AI Act establishes a comprehensive legal framework for the development and deployment of AI systems within the European internal market.</p><p>Public discourse often frames the AI Act as a technology regulation. For organizations, its primary impact lies in the governance and decision structures within which AI systems are deployed.</p><p>The AI Act therefore operates less as a regulation of technology itself and more as a regulation of the organizational conditions of its deployment. Organizations must define responsibilities, document decision processes and establish organizational control mechanisms for AI-assisted decisions.</p><p>This analysis examines the AI Act from a real-economy perspective: which organizational adjustments emerge within organizations, which transition frictions occur and which economic structures develop around the regulated deployment of AI systems.</p><h3><strong>3. Regulatory Mechanism</strong></h3><p>The EU AI Act governs the deployment of AI systems through a combination of risk classification, documentation requirements, human oversight and conformity assessment (Art. 6&#8211;7, Art. 14, Art. 43). This structure generates concrete organizational requirements.</p><p>The classification of AI systems into risk categories is the central regulatory element. Systems with higher risk are subject to stricter requirements regarding transparency, documentation and human oversight (Art. 6&#8211;7).</p><p>For organizations, three operational requirements follow:</p><ul><li><p>Documentation to ensure traceability: development processes, training data, model changes and decision processes are documented in a traceable manner</p></li><li><p>Human oversight: AI-assisted decisions remain subject to human review and potential override (Art. 14)</p></li><li><p>Conformity assessment: organizations must demonstrate compliance with regulatory requirements for certain systems (Art. 43)</p></li></ul><p>This regulatory mechanism shifts the focus from the technical development of individual models to the organizational conditions of their deployment.</p><p>Regulatory mechanism:</p><p>The regulatory logic of the AI Act operates through a clear sequence: risk classification, documentation requirements and human oversight shift requirements for AI systems from technical performance to organizational integration. This results in new governance structures, additional review and approval processes and expanded organizational control mechanisms. During the transition phase, these adjustments create frictions and extended development cycles, while simultaneously enabling new markets for governance, audit and infrastructure services.</p><p>Example:</p><p>An AI system for credit risk assessment requires more than technical performance. Organizations must document training data, decision processes and control mechanisms that enable human review.</p><h3><strong>4. Organizational Adjustments</strong></h3><p>The primary adjustments triggered by the EU AI Act occur not within the technology itself, but within the organization of its deployment: defined responsibilities, documented decision processes and regulatory control mechanisms.</p><h4><strong>Responsibilities for AI systems</strong></h4><p>Organizations must define regulatory responsibility for each AI system, a function that often lacks clear allocation.</p><p>New interfaces emerge between:</p><ul><li><p>AI development teams</p></li><li><p>operational business units</p></li><li><p>risk and compliance functions</p></li></ul><p>Example:</p><p>An AI system for credit risk assessment is developed by a data science team, deployment by a credit department and overseen by risk and compliance functions.</p><h4><strong>New review and approval processes</strong></h4><p>Organizations must assess whether an AI system falls under a regulated risk category and which requirements apply.</p><p>Typical adjustments include:</p><ul><li><p>internal approval processes for new AI systems</p></li><li><p>regulatory assessments prior to deployment</p></li><li><p>additional reviews for model changes</p></li></ul><p>These processes extend the time between technical development and operational deployment.</p><p>Example:</p><p>A newly developed credit risk model must undergo risk classification, documentation and internal approval before deployment.</p><h4><strong>Integration into risk and compliance structures</strong></h4><p>AI systems integrate more strongly into existing control structures. Risk management, compliance and internal audit functions gain influence over their deployment.</p><p>AI systems thereby become organizationally comparable to other regulated decision infrastructures.</p><p>Example:</p><p>An AI system for prioritizing incoming medical findings in a hospital integrates into clinical workflows. Decisive is process integration: defined human review at specific thresholds, documented overrides of automated prioritization and clear responsibilities for monitoring and incident handling.</p><h3><strong>5. Transition Regime</strong></h3><p>Between existing AI deployment and full regulatory integration, organizations operate within a transition phase. Existing systems undergo review, processes adapt and governance structures emerge.</p><p>These adjustments introduce temporary review layers, organizational frictions and partial constraints on automation.</p><h4><strong>System inventory and retrospective documentation</strong></h4><p>Organizations must establish a structured inventory of existing AI systems. Applications previously treated as technical tools require reclassification and documentation within a regulatory context.</p><p>Typical steps include:</p><ul><li><p>systematic identification of existing AI systems</p></li><li><p>retrospective documentation of training data and model logic</p></li><li><p>internal assessment of regulatory risk classification</p></li></ul><p>Example:</p><p>A fraud detection system in long-term deployment must undergo retrospective documentation of training data, model changes and monitoring responsibilities.</p><h4><strong>Temporary remanualization of decisions</strong></h4><p>Organizations may temporarily limit automated processes until regulatory requirements are fully implemented.</p><p>Remanualization refers to the temporary shift of automated decisions back to human review and decision-making processes during regulatory adjustment phases.Typical situations include:</p><ul><li><p>additional human review of automated decisions</p></li><li><p>parallel manual assessments during transition phases</p></li><li><p>temporary restriction of automated decision-making</p></li></ul><p>This particularly affects decisions with direct impact on individuals.</p><p>Example:</p><p>An automated applicant screening system continues to operate, but each decision undergoes human review until documentation and control processes are fully implemented.</p><h4><strong>Extended development and deployment cycles</strong></h4><p>Regulatory documentation and review requirements extend development and deployment cycles of AI systems.</p><p>Additional coordination and review phases emerge between technical completion and operational deployment.</p><p>Example:</p><p>A credit risk model must undergo documentation, risk classification and internal approval before deployment.</p><h4><strong>Stabilization after the adjustment phase</strong></h4><p>These frictions primarily occur during the integration of regulatory requirements. With increasing experience and established governance processes, they become established organizational processes.</p><h3><strong>6. Emerging Market Mechanisms</strong></h3><p>When organizations simultaneously establish governance, control and documentation structures for AI systems, new markets emerge for services and infrastructure.</p><h4><strong>Phase 1 &#8211; Governance and implementation consulting</strong></h4><p>Initial demand focuses on regulatory implementation.Typical services include:</p><ul><li><p>inventory of existing AI systems</p></li><li><p>assessment of regulatory risk classification</p></li><li><p>development of internal AI governance structures</p></li></ul><p>Example:</p><p>An organization using multiple AI systems receives external consulting for systematic identification and regulatory classification of these systems.</p><h4><strong>Phase 2 &#8211; Audit and certification structures</strong></h4><p>With increasing regulatory integration, formal audit and certification structures emerge. Organizations must demonstrate that certain AI systems comply with regulatory requirements (Art. 43).</p><p>Markets develop for:</p><ul><li><p>conformity assessments</p></li><li><p>independent auditing bodies</p></li><li><p>specialized certification services</p></li></ul><h4><strong>Phase 3 &#8211; Infrastructure markets</strong></h4><p>Technical infrastructure emerges to support monitoring, documentation and traceability of AI systems.</p><p>Typical solutions include:</p><ul><li><p>monitoring systems for AI-assisted decisions</p></li><li><p>platforms for documenting model changes</p></li><li><p>software for managing regulatory documentation</p></li></ul><h4><strong>Temporal dynamics of market formation</strong></h4><p>The development of these markets typically unfolds over several years:</p><ul><li><p>0&#8211;2 years: governance and implementation consulting</p></li><li><p>2&#8211;4 years: audit and certification structures</p></li><li><p>3&#8211;6 years: technical infrastructure markets</p></li></ul><h3><strong>7. Conclusion</strong></h3><p>The AI Act reshapes not only the deployment of individual AI systems, but also the organizational and economic conditions of their deployment. Organizations establish new governance structures and control mechanisms, while new markets for services and infrastructure emerge.</p><p>The AI Act operates less as a regulation of technology itself and more as a regulation of the organizational and economic structures surrounding AI deployment.</p><h3><strong>8. Legal References</strong></h3><p>EU AI Act</p><ul><li><p>Art. 6&#8211;7 &#8211; Risk classification of AI systems</p></li><li><p>Art. 9 &#8211; Risk management system</p></li><li><p>Art. 14 &#8211; Human oversight</p></li><li><p>Art. 43 &#8211; Conformity assessment</p></li></ul><div><hr></div><p>Download full paper (PDF):</p><div class="file-embed-wrapper" data-component-name="FileToDOM"><div class="file-embed-container-reader"><div class="file-embed-container-top"><image class="file-embed-thumbnail-default" src="https://substackcdn.com/image/fetch/$s_!0Cy0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Fattachment_icon.svg"></image><div class="file-embed-details"><div class="file-embed-details-h1">Full paper (EN)</div><div class="file-embed-details-h2">1.11MB &#8729; PDF file</div></div><a class="file-embed-button wide" href="https://aigovernancemarkets.substack.com/api/v1/file/b8405885-ae16-4a7a-9ee9-37850869fdcf.pdf"><span class="file-embed-button-text">Download</span></a></div><div class="file-embed-description">Download the complete reference framework (PDF).</div><a class="file-embed-button narrow" href="https://aigovernancemarkets.substack.com/api/v1/file/b8405885-ae16-4a7a-9ee9-37850869fdcf.pdf"><span class="file-embed-button-text">Download</span></a></div></div><div class="file-embed-wrapper" data-component-name="FileToDOM"><div class="file-embed-container-reader"><div class="file-embed-container-top"><image class="file-embed-thumbnail-default" src="https://substackcdn.com/image/fetch/$s_!0Cy0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Fattachment_icon.svg"></image><div class="file-embed-details"><div class="file-embed-details-h1">Full paper (DE)</div><div class="file-embed-details-h2">1.11MB &#8729; PDF file</div></div><a class="file-embed-button wide" href="https://aigovernancemarkets.substack.com/api/v1/file/e88ac87f-bddb-4a2f-a056-7cf3326bc744.pdf"><span class="file-embed-button-text">Download</span></a></div><div class="file-embed-description">Download the complete reference framework (PDF).</div><a class="file-embed-button narrow" href="https://aigovernancemarkets.substack.com/api/v1/file/e88ac87f-bddb-4a2f-a056-7cf3326bc744.pdf"><span class="file-embed-button-text">Download</span></a></div></div><div><hr></div><p>Related analysis: <a href="https://open.substack.com/pub/aigovernancemarkets/p/ai-regulation-as-value-chain-reconfiguration?r=7uso1r&amp;utm_campaign=post&amp;utm_medium=web&amp;showWelcomeOnShare=true">OA #01 - AI Regulation as Value Chain Reconfiguration</a></p><p></p><p></p>]]></content:encoded></item></channel></rss>