The AI Act Capital Allocation Worksheet

On August 2, 2026, the EU AI Act stops being a future regulation and becomes a present cost.

Episode 5 made the argument: the Act is not a compliance event. It is a re-pricing event. Any AI investment in an Annex III high-risk use case inherits a nine-component obligation cost stack. Organizations that have not priced this stack into capital approval decisions will absorb it as overrun after the capital is committed.

This issue delivers the operational instrument: the AI Act Capital Allocation Worksheet. Four fields, each with a small number of yes/no determinations and supporting questions, designed to be run against any active or proposed AI investment before it reaches the investment committee. The output is a four-part status reading on whether the investment is in scope, what role your organization is taking, which obligations apply, and whether the vendor contract assigns the pass-through risk.

HOW TO USE THE WORKSHEET

Pick one specific AI investment in your organization’s active portfolio or current approval queue. Not the AI portfolio in aggregate — one investment. This is an instrument for individual investment classification.

Work through the four fields in order. Each field returns a determination. The pattern of determinations tells you where the obligation cost lands, who carries it, and what is unpriced.

Run the same worksheet against every active or pending AI investment in your portfolio. The investments that return high-risk determinations on Fields 1 through 3 and unresolved risk on Field 4 are the ones whose business cases need to be revisited before the next approval cycle.

THE AI ACT CAPITAL ALLOCATION WORKSHEET

FIELD 1.  Intended Use

Core question: Does this AI investment’s intended use fall under any of the eight Annex III high-risk areas?

•  Is the system’s intended use in: biometrics; critical infrastructure; education and vocational training; employment and workers’ management; access to essential private or public services and benefits; law enforcement; migration, asylum or border control; or administration of justice and democratic processes?

If yes to any — in scope. If no — likely out of scope, but verify against Annex III sub-categories before concluding (Article 6(2) classifies by intended use, not technology type).

•  Within an in-scope area, does the specific use case match an Annex III sub-category — for example, recruitment screening, credit scoring, life and health insurance pricing, or asylum/visa application assessment?

Annex III breaks each of the eight areas into named use cases. Match yours to the specific sub-category, not just the broad area heading.

•  If your organization deploys the same technology (e.g., the same large language model) across multiple use cases, are any of those use cases high-risk while others are not?

Same technology can carry different obligation tiers depending on intended use. Do not assume uniformity across the portfolio.

What this returns: In scope under Annex III = high-risk; full obligation stack applies. Out of scope under Annex III = the high-risk obligation stack does not apply, though transparency obligations under Article 50 may still apply where the system interacts with natural persons or generates synthetic content. Other regulatory regimes (sectoral, data protection, consumer protection) may still apply independently. If uncertain, flag as in scope until verified \u2014 the cost of being wrong on the high side is documentation. The cost of being wrong on the low side is material regulatory exposure: under Article 99, non-compliance with high-risk system obligations can carry administrative fines of up to EUR 15 million or 3 percent of worldwide annual turnover, whichever is higher \u2014 alongside the remediation and reputational costs that typically accompany regulatory findings.

FIELD 2.  Role Assignment

Core question: Is your organization the provider, the deployer, or both — and could the role change mid-lifecycle?

•  Does your organization build the system, substantially modify a vendor-built system, or place a vendor-built system on the market under your own name?

Any ‘yes’ here places you in the provider role under Article 16. The full provider obligation stack applies.

•  Does your organization use a vendor-built high-risk AI system under its own authority — without modifying it materially or placing it on the market under your own name?

This is the deployer role under Article 26. The deployer obligation set applies, including Article 27 fundamental rights impact assessment in employment, essential services, law enforcement, migration, and justice contexts.

•  Does your roadmap include configuration, fine-tuning, or customization that could constitute substantial modification under Article 25 — shifting you from deployer to provider mid-lifecycle?

Article 25 substantial-modification threshold is still hardening in implementation guidance. If the answer is plausibly yes, the obligation stack on your side increases materially. Document the modification boundary in the investment business case.

What this returns: Provider = full Article 9–15 obligations plus Article 72 post-market monitoring. Deployer = oversight, log retention, and Article 27 FRIA where applicable. Provider-and-deployer (both roles for different use cases) = both obligation sets, separately. Article 25 mid-lifecycle shift = unpriced risk if not addressed in the contract.

FIELD 3.  Obligation Stack

Core question: Which of the nine obligation components apply, and is each one priced in the business case?

•  For provider-role investments: are all eight provider obligations addressed — risk management system (Art. 9), data governance (Art. 10), technical documentation (Art. 11), record-keeping (Art. 12), transparency to deployers (Art. 13), human oversight (Art. 14), accuracy/robustness/cybersecurity (Art. 15), and post-market monitoring (Art. 72)?

Each component has a cost — labor, system, process redesign. Mark each as: priced in the business case, identified but unpriced, or not yet identified.

•  For deployer-role investments: are the four deployer obligations addressed — human oversight, appropriate input data, log retention, and Article 27 FRIA where applicable?

FRIA is required for deployers in employment, essential services, law enforcement, migration, and justice contexts. Confirm whether your specific use case triggers it.

•  For each obligation component you have marked ‘identified but unpriced’ or ‘not yet identified’: what is the cost owner — IT, business unit, legal/compliance, or shared?

Unowned cost is the failure mode this field exists to surface. If no one is assigned to a component, the cost will arrive as overrun against whoever is closest to the system at the time of audit or incident.

What this returns: A complete obligation stack with priced components and named owners = the investment is governance-ready. A stack with unpriced components or unowned costs = the business case understates the true investment cost by the unpriced sum. The capital approval is being made against incomplete economics.

FIELD 4.  Vendor Contract Clause

Core question: If a vendor is involved: does the contract address Article 25 substantial-modification risk and assign pass-through liability?

•  Does the current or proposed vendor agreement explicitly address what happens to liability and obligation responsibility if your organization substantially modifies the system under Article 25?

Most AI vendor contracts negotiated before mid-2024 do not. The default position is that the contract is silent and the risk is unassigned.

•  Does the contract address vendor responsibility for incorrect outputs, regulatory non-compliance on the provider side (where applicable), and post-market monitoring data sharing?

Articles 25 and 26 create obligations on both sides. Whichever party did not internalize these costs at contract time will push them to the other at modification, renewal, or incident.

•  Does the contract survive renewal cycles — i.e., are the AI Act–specific clauses durable, or do they reset to the vendor’s standard terms at next renewal?

A clause that exists today and disappears at renewal is a clause that does not exist. Confirm durability.

What this returns: Contract addresses all three = pass-through risk is assigned. Partial coverage = pass-through risk is allocated for some failure modes and unallocated for others. None of the above = the obligation cost will arrive on your side regardless of who caused it. Renegotiation or contract amendment is the corrective action.

APPLIED EXAMPLE

Consider a VP of Talent Acquisition at a multinational consumer-goods company whose organization has deployed an AI-powered resume screening and candidate-evaluation system across European operations. The investment is in active deployment; the FY2026 renewal is on the procurement calendar for Q3.

Running the worksheet:

Field 1 (Intended Use): The system’s intended use is recruitment and candidate evaluation — explicitly named in Annex III, Area 4, sub-category 4(a). The investment is in scope as high-risk. → IN SCOPE.

Field 2 (Role Assignment): The system is built by a vendor and used by the organization under its own authority across European subsidiaries. No substantial modification at present — but the roadmap includes custom scoring weights tuned to the company’s competency model. That customization may meet the Article 25 substantial-modification threshold. → DEPLOYER, with possible mid-lifecycle shift to provider.

Field 3 (Obligation Stack): Deployer obligations — human oversight by recruiters, log retention through the ATS, appropriate input data. Article 27 FRIA is required (employment context). The FRIA has not been completed. None of the obligation costs are in the investment business case; HR owns the system, compliance has been told to ‘get to it before August.’ → UNPRICED AND UNOWNED.

Field 4 (Vendor Contract Clause): The contract was negotiated in 2023, pre-Act. It addresses standard data protection but not Article 25 substantial modification, vendor responsibility for incorrect outputs, or post-market monitoring data sharing. The Q3 renewal is the natural point to amend, but the AI Act–specific clauses have not yet been drafted. → UNASSIGNED RISK.

THREE QUESTIONS TO ASK MONDAY

WHAT’S NEXT

Episodes 4 and 5 established the classification and re-pricing layers. The AI Risk Classification Matrix (Episode 4) maps an investment by risk profile. The AI Act Capital Allocation Worksheet (this issue) prices the regulatory obligation stack for in-scope investments.

Episode 6 — publishing in two weeks — consolidates these instruments into a single decision tool for investment committee use. Five episodes of analysis converge into one operational artifact: the classification gate, sized for the back of a board meeting page.