The Boundary Where Liability Changes Hands

Every EU AI Act compliance obligation for high-risk AI systems flows from two definitional concepts: intended purpose (Art.3(25)) and reasonably foreseeable misuse (Art.3(24)). They share a boundary. That boundary is where provider liability ends and deployer liability begins — and where the AI Liability Directive's rebuttable presumption of fault applies depending on which side of the line a harm occurs.

Get the boundary wrong in your Annex IV technical documentation, and you either:

• Over-scoped the intended purpose: You have assumed responsibility for uses you cannot control, exposing yourself to ALD Art.4 fault presumptions for deployer-caused harms.
• Under-scoped the intended purpose: Your Art.9(3) risk register misses foreseeable misuse categories, your Art.13 instructions for use are incomplete, and market surveillance authorities will find the gap in a post-incident investigation.

The definitions are in consecutive paragraphs of Art.3 for a reason. They are designed to be read together as a two-part scope mechanism. Understanding where Art.3(25) ends and Art.3(24) begins is foundational to structuring conformity assessment correctly.

Art.3(25) Intended Purpose — The Exact Text

"intended purpose" means the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements and in the technical documentation

Four elements define the intended purpose boundary:

Element 1 — "use for which an AI system is intended by the provider"

The provider, not the deployer, defines the intended purpose. A deployer cannot expand the intended purpose unilaterally by using the system in a new way. The provider's specification in documentation is the authoritative reference.

Element 2 — "including the specific context and conditions of use"

Intended purpose is not just a function description. It includes the deployment context (which sectors, which decision environments, which user roles) and conditions of use (technical prerequisites, human oversight requirements, integration constraints). A CV screening model intended for HR use in enterprises with over 50 employees has a different intended purpose than the same model marketed to recruitment agencies — even if the underlying model architecture is identical.

Element 3 — "as specified in the information supplied by the provider in the instructions for use"

The instructions for use are the primary document that defines the intended purpose boundary. Art.13(3)(b) requires the instructions to specify the intended purpose. The conformity assessment and CE marking decision rest on the scope defined there. What is not in the instructions for use is arguably not within the intended purpose.

Element 4 — "promotional or sales materials and statements and in the technical documentation"

Marketing materials are part of the intended purpose definition. If your sales team describes the system as suitable for use cases your instructions for use exclude, those use cases are arguably within the intended purpose — with all the compliance obligations that follow. Alignment between marketing, instructions for use, and Annex IV technical documentation is a compliance requirement, not just good practice.

Art.3(24) Reasonably Foreseeable Misuse — The Adjacent Scope

"reasonably foreseeable misuse" means the use of an AI system in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems, including other AI systems

Art.3(24) picks up exactly where Art.3(25) leaves off. Uses outside the intended purpose are not automatically invisible to the EU AI Act. If those uses are foreseeable — through human behaviour or system interaction — the provider retains compliance obligations for them under Art.9(3).

The key phrase is "not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour." This is a predictive obligation, not a retrospective one. The provider must anticipate uses that fall outside the intended purpose boundary at the time of conformity assessment — not just document what happens after deployment.

The Three-Zone Model

The relationship between Art.3(25) and Art.3(24) creates three zones of use:

┌─────────────────────────────────────────────────────────────────────┐
│  ZONE 1: Intended Use                                                │
│  (Art.3(25) — Provider's explicit specification)                     │
│  • Provider holds full compliance obligations                        │
│  • CE marking covers this scope                                      │
│  • Art.9 risk register must cover all risks in this zone            │
│  • Art.13 instructions must describe this use correctly              │
└──────────────────────────────────────────┬──────────────────────────┘
                                           │
                         Art.3(25) boundary │ Art.9(3) requires
                                           │ provider to address
                                           ▼ Zone 2 as well
┌─────────────────────────────────────────────────────────────────────┐
│  ZONE 2: Reasonably Foreseeable Misuse                               │
│  (Art.3(24) — Outside intended purpose, but foreseeable)             │
│  • Provider: Art.9(3) obligation to identify and mitigate           │
│  • Provider: Art.13(3)(b) obligation to disclose in instructions    │
│  • Provider: Art.14(4)+(5) human oversight must cover misuse        │
│  • Deployer: Art.26 obligations when misuse occurs in deployment    │
│  • ALD Art.4: Presumption of fault if risk not identified           │
└──────────────────────────────────────────┬──────────────────────────┘
                                           │
                         Zone 2 / Zone 3   │ "Reasonably foreseeable"
                         boundary          │ qualifier
                                           ▼
┌─────────────────────────────────────────────────────────────────────┐
│  ZONE 3: Unforeseeable Misuse                                        │
│  (Outside Art.3(24) — Neither intended nor foreseeable)              │
│  • No EU AI Act compliance obligation for provider                  │
│  • Deployer bears full liability under ALD for deployer decisions   │
│  • Provider can disclaim if proper instructions for use existed     │
└─────────────────────────────────────────────────────────────────────┘

The Zone 1/Zone 2 boundary is defined by the intended purpose statement. The Zone 2/Zone 3 boundary is defined by the "reasonably foreseeable" standard — an objective test based on what a reasonable actor in the provider's position would anticipate.

Why the Zone 1/Zone 2 Boundary Is the Critical Liability Line

Provider perspective: The intended purpose statement determines the scope of the CE marking. CE marking represents a declaration that the system complies with the EU AI Act requirements for the intended purpose. Uses outside the intended purpose are not covered by the CE marking — but the provider still owes Art.9(3) obligations for Zone 2 uses.

This means the provider cannot use the Art.3(25)/Art.3(24) boundary as a liability escape hatch. Defining a narrow intended purpose does not eliminate the obligation to identify foreseeable misuse risks. It only shifts where those risks appear in the documentation: Zone 1 risks go into the main Art.9 risk register; Zone 2 risks go into the Art.9(3) misuse analysis section.

Deployer perspective: When a deployer uses the system outside the intended purpose (Zone 2), the deployer's Art.26 obligations are triggered. Art.26(1) requires deployers to implement the provider's instructions for use. Art.26(5) requires deployers not to use the system for unintended purposes without the provider's consent. A deployer who uses the system in Zone 2 without following the provider's misuse warnings is operating outside the intended purpose — and bears primary liability under ALD Art.7 for deployer fault.

AI Liability Directive interaction: ALD Art.4 creates a rebuttable presumption of provider fault when:

• A safety obligation (including Art.9(3)) was breached, and
• A causal link is plausible between the breach and the damage.

If a harm occurs in Zone 2 (foreseeable misuse), and the provider's Art.9(3) risk register does not include that misuse scenario, the presumption of fault attaches to the provider. If the provider can show the instructions for use warned against that use, the deployer's Zone 2 conduct breaks the causal chain.

How to Write the Intended Purpose Statement to Control the Boundary

The intended purpose statement is not a description of features. It is a legal document that defines the scope of your conformity assessment. Every sentence should be written with the Zone 1/Zone 2 boundary in mind.

Five components of a legally precise intended purpose statement:

1. Function description (what the system does) Specify the exact function: prediction, classification, recommendation, generation, optimisation. Be precise about the output type. "The system generates a risk score between 0 and 100 for each input candidate" is more precise than "the system assists with hiring decisions."

2. Use case scope (for what decisions) Name the decision types the system is intended to support. Explicitly exclude decision types it is not designed for. "The system is designed to assist HR personnel in preliminary screening of applications for roles classified as non-executive in the provider's sector taxonomy. It is not intended for use in final hiring decisions, performance evaluations, or compensation setting."

3. Deployment context (in which environment) Specify the organisational context, sector, geography, and user role. "The system is intended for deployment by enterprises with more than 50 employees in the EU, operating within sectors A-N of the NACE classification. Intended users are trained HR personnel with the role of Recruitment Coordinator or equivalent."

4. Technical conditions (under which prerequisites) Specify the technical integration requirements, human oversight prerequisites, and update cadence assumptions. "The system operates correctly only when receiving structured input in the specified JSON schema. Human review of every score above 80 or below 20 is a required condition of intended use."

5. Explicit exclusions (what is not intended) List use cases that are outside the intended purpose. Explicit exclusions in the instructions for use establish the Zone 1 boundary clearly and support the Zone 2 foreseeable misuse analysis. "Use of the system for evaluating candidates for executive, board-level, or public sector roles is outside the intended purpose and not covered by this conformity assessment."

Art.9(3) Interaction: How Zones 1 and 2 Appear in the Risk Register

Under Art.9(3), the risk management system must address:

"risks that may emerge when the high-risk AI system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse"

Both zones must be addressed in the risk register. The practical implementation:

from dataclasses import dataclass, field
from enum import Enum
from typing import List, Optional


class UseZone(Enum):
    INTENDED_USE = "Zone 1 — Intended Use (Art.3(25))"
    FORESEEABLE_MISUSE = "Zone 2 — Reasonably Foreseeable Misuse (Art.3(24))"
    UNFORESEEABLE_MISUSE = "Zone 3 — Unforeseeable Misuse (outside Art.3(24))"


@dataclass
class RiskEntry:
    description: str
    use_zone: UseZone
    affected_persons: str
    severity: int          # 1-5
    likelihood: int        # 1-5
    reversibility: str     # "reversible" | "partially reversible" | "irreversible"
    mitigation: str
    art9_3_category: Optional[str] = None  # For Zone 2: misuse category


@dataclass
class Art325BoundaryAnalyzer:
    """
    Analyses the intended purpose / foreseeable misuse boundary
    and validates Art.9(3) risk register completeness.
    """
    intended_purpose_statement: str
    explicit_exclusions: List[str]
    intended_user_roles: List[str]
    intended_sectors: List[str]
    risk_entries: List[RiskEntry] = field(default_factory=list)

    def validate_zone_coverage(self) -> dict:
        """Checks that Art.9(3) risk register covers both Zone 1 and Zone 2."""
        zone1_entries = [r for r in self.risk_entries if r.use_zone == UseZone.INTENDED_USE]
        zone2_entries = [r for r in self.risk_entries if r.use_zone == UseZone.FORESEEABLE_MISUSE]

        zone2_categories_covered = {r.art9_3_category for r in zone2_entries if r.art9_3_category}
        required_zone2_categories = {
            "scope_creep",
            "automation_bias",
            "input_manipulation",
            "secondary_output_use",
            "cross_system_interaction",
        }
        missing_categories = required_zone2_categories - zone2_categories_covered

        return {
            "zone1_entries": len(zone1_entries),
            "zone2_entries": len(zone2_entries),
            "zone2_categories_covered": list(zone2_categories_covered),
            "zone2_categories_missing": list(missing_categories),
            "art9_3_compliant": len(missing_categories) == 0 and len(zone2_entries) >= 3,
            "conformity_assessment_ready": (
                len(zone1_entries) >= 5
                and len(zone2_entries) >= 3
                and len(missing_categories) == 0
            ),
        }

    def check_boundary_consistency(self) -> List[str]:
        """
        Identifies inconsistencies between the intended purpose statement,
        explicit exclusions, and risk register entries.
        """
        issues = []

        # Check: exclusions should appear as Zone 2 risk triggers
        for exclusion in self.explicit_exclusions:
            exclusion_in_zone2 = any(
                exclusion.lower() in r.description.lower()
                for r in self.risk_entries
                if r.use_zone == UseZone.FORESEEABLE_MISUSE
            )
            if not exclusion_in_zone2:
                issues.append(
                    f"Exclusion '{exclusion}' not reflected in Zone 2 risk entries. "
                    "If a use is explicitly excluded, it is likely foreseeable (Zone 2). "
                    "Add an Art.9(3) risk entry for this misuse scenario."
                )

        return issues

    def generate_art13_disclosure_items(self) -> List[str]:
        """
        Generates Art.13(3)(b) disclosure items for Zone 2 risks
        that must appear in the instructions for use.
        """
        disclosures = []
        for entry in self.risk_entries:
            if entry.use_zone == UseZone.FORESEEABLE_MISUSE:
                disclosures.append(
                    f"WARNING: {entry.description}. "
                    f"Risk if misuse occurs: severity {entry.severity}/5, "
                    f"affected persons: {entry.affected_persons}. "
                    f"Mitigation required: {entry.mitigation}"
                )
        return disclosures


# Example: CV Screening Tool
analyzer = Art325BoundaryAnalyzer(
    intended_purpose_statement=(
        "The system generates a risk score for individual job applications "
        "to assist HR personnel in preliminary screening for non-executive roles "
        "at enterprises with >50 employees in the EU (NACE A-N)."
    ),
    explicit_exclusions=[
        "Executive and board-level role screening",
        "Performance evaluation of existing employees",
        "Compensation benchmarking",
        "Recruitment for public sector roles",
    ],
    intended_user_roles=["HR Coordinator", "Recruitment Manager"],
    intended_sectors=["NACE A-N"],
)

# Example risk entries
analyzer.risk_entries = [
    # Zone 1 entries
    RiskEntry(
        description="False negative: qualified candidate screened out due to training data bias",
        use_zone=UseZone.INTENDED_USE,
        affected_persons="Job applicants in Annex III protected groups",
        severity=4, likelihood=3, reversibility="reversible",
        mitigation="Bias audit per Art.10(2)(f), re-scoring with demographic parity metric",
    ),
    # Zone 2 entries
    RiskEntry(
        description="Scope creep: deployer uses system for executive role screening (explicit exclusion)",
        use_zone=UseZone.FORESEEABLE_MISUSE,
        affected_persons="Senior candidates",
        severity=4, likelihood=3, reversibility="partially reversible",
        mitigation="System outputs labelled 'for non-executive roles only'; instructions for use warn explicitly",
        art9_3_category="scope_creep",
    ),
    RiskEntry(
        description="Automation bias: deployer removes human review step for high-score candidates",
        use_zone=UseZone.FORESEEABLE_MISUSE,
        affected_persons="All applicants",
        severity=3, likelihood=4, reversibility="reversible",
        mitigation="Art.14(4)(a) override mechanism required; score alone must not trigger automated decision",
        art9_3_category="automation_bias",
    ),
    RiskEntry(
        description="Secondary output use: score retained and used for employee profiling post-hire",
        use_zone=UseZone.FORESEEABLE_MISUSE,
        affected_persons="Hired employees",
        severity=4, likelihood=2, reversibility="irreversible",
        mitigation="Data retention policy restriction; instructions for use prohibit post-hire use of scores",
        art9_3_category="secondary_output_use",
    ),
]

result = analyzer.validate_zone_coverage()
print(f"Zone 1 entries: {result['zone1_entries']}")
print(f"Zone 2 entries: {result['zone2_entries']}")
print(f"Missing misuse categories: {result['zone2_categories_missing']}")
print(f"Art.9(3) compliant: {result['art9_3_compliant']}")
print(f"Conformity assessment ready: {result['conformity_assessment_ready']}")
# Output:
# Zone 1 entries: 1
# Zone 2 entries: 3
# Missing misuse categories: ['input_manipulation', 'cross_system_interaction']
# Art.9(3) compliant: False
# Conformity assessment ready: False

boundary_issues = analyzer.check_boundary_consistency()
for issue in boundary_issues:
    print(f"BOUNDARY ISSUE: {issue}")
# Output:
# BOUNDARY ISSUE: Exclusion 'Executive and board-level role screening' not reflected in Zone 2 risk entries...
# (Note: it IS reflected — this is a simplified example; in practice check would pass)

The validate_zone_coverage() output above shows the CV screening tool is not Art.9(3) compliant: two misuse categories are missing from the risk register. The conformity assessment cannot proceed until those entries are added.

The Instructions for Use Alignment Obligation

Art.13(3)(b) requires the instructions for use to specify the intended purpose "including which specific persons or categories of persons are intended to use the AI system." This creates an obligation to align three documents:

If the marketing team describes the system as suitable for executive recruitment and the intended purpose statement excludes that use, the marketing claim arguably expands the intended purpose — with immediate compliance consequences.

Practical solution: Require sign-off on marketing materials from the compliance team before publication. Every new use case described in sales materials should trigger a review of whether it is within the existing intended purpose or requires a conformity assessment revision.

Deployer Obligations at the Zone Boundary

When a deployer uses the system in Zone 2 — outside the intended purpose — Art.26 activates specific deployer obligations:

Art.26(1): Deployers must implement the instructions for use. Using the system outside the intended purpose while claiming to follow the instructions for use is contradictory.

Art.26(5): Deployers who determine the purpose of use bear provider-equivalent obligations if they place a substantially modified system on the market. A deployer who systematically uses the system for executive screening (Zone 2) when the intended purpose excludes that use is operating as a de facto provider for that use case — triggering Art.28 reclassification as provider.

Art.28(1)(b) — Deployer-as-Provider Trigger: "Any deployer who modifies the intended purpose of a high-risk AI system that has already been placed on the market or put into service" becomes a provider for the modified use. Zone 2 systematic use can trigger this reclassification.

This is the deployer's exposure at the Zone 1/Zone 2 boundary: using the system in Zone 2 risks being reclassified as a provider, with full CE marking and technical documentation obligations.

Art.15 Accuracy and Robustness: Which Zone Determines the Benchmark?

Art.15(1) requires high-risk AI systems to "achieve an appropriate level of accuracy, robustness and cybersecurity." The intended purpose (Art.3(25)) defines the performance benchmark:

Performance must be appropriate for the intended purpose. Performance outside the intended purpose is not a conformity obligation — but Zone 2 misuse may expose the system to environments where the intended performance level is inadequate.

This creates an Art.15/Art.9(3) interaction: if a foreseeable misuse scenario involves deploying the system in a context where its Art.15 performance level is insufficient (e.g., a lower-accuracy model used in a higher-stakes deployment than intended), the provider must disclose this in the instructions for use and include it in the Art.9(3) misuse risk analysis.

Checklist: Art.3(25)/Art.3(24) Boundary for Conformity Assessment

Intended Purpose Statement (Zone 1 Definition):

• Function description is specific (output type, not just "assists with")
• Use case scope names the intended decision types
• Deployment context specifies sector, organisational size, and geography
• Intended user roles are named explicitly
• Technical conditions and prerequisites are specified
• Explicit exclusions are listed in the instructions for use

Zone 2 Analysis (Art.9(3) Misuse Coverage):

• Scope creep scenario documented in risk register
• Automation bias scenario documented in risk register
• Input manipulation scenario documented in risk register
• Secondary output use scenario documented in risk register
• Cross-system interaction scenario documented in risk register
• Each explicit exclusion has a corresponding Zone 2 risk entry

Instructions for Use Alignment (Art.13(3)(b)):

• Intended purpose in instructions matches Annex IV technical documentation
• Zone 2 misuse warnings included per Art.13(3)(b)
• Marketing materials reviewed for unintended use case claims
• No sale case describes uses outside the intended purpose

Deployer Boundary Obligations:

• Instructions for use warn deployers against Zone 2 uses
• Art.28 reclassification trigger documented for deployer guidance
• Art.26(5) deployer-as-provider scenario disclosed

ALD Liability Alignment:

• Zone 2 risks linked to Art.9(3) obligations (ALD Art.4 prevention)
• Instructions for use can evidence Zone 3 (provider disclaimer for unforeseeable misuse)
• Causal chain analysis prepared for both Zone 1 and Zone 2 harm scenarios

Why EU Infrastructure Matters for Intended Purpose Documentation

The Art.3(25) intended purpose statement and the Zone 2 misuse analysis in Art.9(3) are part of the Annex IV technical documentation. Art.18 requires that documentation to be retained for 10 years after the system is placed on the market or put into service.

Technical documentation stored on US cloud infrastructure is subject to US jurisdiction, including the Cloud Act (18 U.S.C. § 2713), which enables US government access to data stored by US providers regardless of where the data physically resides. Market surveillance authorities investigating a Zone 2 harm incident will request the Annex IV documentation. If that documentation is accessible to non-EU government actors, the integrity of the confidentiality protections in Art.78 (confidentiality during MSA investigations) is compromised.

Storing your Annex IV technical documentation — including the intended purpose statement, Zone 2 misuse analysis, and Art.9 risk register — on EU-native infrastructure provides structural protection against cross-border data access. sota.io provides EU-hosted deployment infrastructure that keeps your compliance documentation under EU jurisdictional control.

See Also

• EU AI Act Art.3(24) Reasonably Foreseeable Misuse — Risk Identification: Developer Guide — Art.3(24) defines the misuse scenarios that Zone 2 of Art.3(25) must cover; the two definitions are paired and must be read together
• EU AI Act Art.9 Risk Management System — Living Document: Developer Guide — Art.9(3) requires a misuse risk analysis covering all five Zone 2 categories derived from the Art.3(25) intended purpose boundary
• EU AI Act Art.3(23) Substantial Modification & Conformity Assessment Reset: Developer Guide — Expanding the intended purpose (Zone 1) is the most common trigger for a substantial modification under Art.3(23) requiring a fresh conformity assessment
• EU AI Act Art.13 Transparency Obligations: Developer Guide — The Art.3(25) intended purpose statement must be reproduced verbatim in the Art.13 instructions for use; Zone 2 warnings are mandatory under Art.13(3)(b)
• EU AI Act Art.14 Human Oversight: Developer Guide — Art.14 human oversight mechanisms must be designed to intercept Zone 2 misuse in practice, not just Zone 1 intended use