eu-ai-act-roles-oliver-schmidt-prietz

name	eu-ai-act-roles-oliver-schmidt-prietz
description	Determines the organization's role (provider, deployer, importer, distributor, or quasi-provider) and assesses Art. 25 quasi-provider risk of the EU AI Act. This skill should be used when the user asks to "determine AI Act roles", "check if we are provider or deployer", "assess quasi-provider status", "check Art. 25 substantial modification", "check value chain responsibilities", or mentions "Betreiber", "Anbieter", "wesentliche Veränderung", or finetuning implications under the AI Act.
metadata	{"author":"Oliver Schmidt-Prietz","license":"AGPL-3.0","version":"2026.06.05"}

EU AI Act Role Determination

Determine the organization's role under the AI Act (Regulation (EU) 2024/1689) — provider (Anbieter), deployer (Betreiber), importer, distributor, or quasi-provider — and assess Art. 25 quasi-provider risk.

Disclaimer (show at session start, do not block)

Important: This skill provides structured AI Act role-determination guidance based on Regulation (EU) 2024/1689 and Commission value chain guidance. It is not legal advice. Final role determinations should involve qualified legal counsel with AI Act expertise.

---

When to Search the Web

On activation — search for:

EU AI Act Commission guidance provider deployer roles value chain [current year]
EU AI Act Art. 25 substantial modification guidance latest

For finetuning assessment — search for:

EU AI Act finetuning substantial modification technical standards [current year]
EU AI Act open source model modification provider status

For value chain obligations — search for:

EU AI Act provider deployer responsibility allocation guidance [current year]
EU AI Act Art. 25(2) original provider support duty interpretation

---

Workflow: Ask Questions ONE AT A TIME

Phase 1: Context Gathering (Adaptive Intake)

Prior Assessment Context (optional):

"If you have previously run another EU AI Act skill, you may paste the Assessment Context block here. This pre-fills several fields and avoids redundant input."

If context is provided, pre-populate applicable fields and skip to confirmation. If any field conflicts with user answers, flag the inconsistency.

Batch 1 — Open-ended question (single prompt):

"Let's determine your organization's role under the EU AI Act."

You can answer in your own words — a short paragraph or bullet points. I'll ask follow-up questions only if needed.

Describe your organization's relationship to this AI system: how you obtained it, what you do with it, whether you've modified it, and how it reaches users.

Coverage Analysis (internal — do not show this table to the user):

After the user responds, silently extract these 4 fields from their natural-language answer:

#	Field	Normalized values
1	System acquisition	Self-developed · Commissioned · Purchased/licensed · Open-source · Third-party component
2	Organizational relationship	Developing for others · Deploying under own authority · Distributing · Importing · Integrating · Multiple
3	Market status	Already on EU market · First placement · First deployment · Already deployed
4	Modifications	None · Configuration · Finetuning/retraining · Changed purpose · Own brand · Substantial modification

Apply generous extraction — e.g., "bought from US vendor" covers System acquisition (Purchased/licensed) + Market status (First placement) + potential Importer dimension. "We finetuned it and sell it under our brand" covers Modifications (Finetuning/retraining + Own brand) + Organizational relationship (Developing for others / Distributing).

Batch 2 — Adaptive follow-up (only if needed):

• If all 4 fields are clearly covered → skip Batch 2 entirely. Confirm extractions: "Based on your description, I've identified: [field summary]. Does this look correct?"
• If 1-2 fields are partially covered → confirm partial extractions: "You mentioned [X] — is this specifically [normalized value]?"
• If 2+ fields are missing → ask about gaps only: "A couple of details I still need: [specific missing fields]"
• Maximum 2 interaction turns for intake.

Information Normalization (internal):

Before proceeding to Phase 2, normalize all extracted information into the 4 structured fields above. If a field remains unclear after Batch 2, mark it as [UNCLEAR — proceeding with cautious assumptions] and note which assumption was made.

---

Phase 2: Primary Role Determination

Read references/role-definitions.md for full legal definitions.

Apply the decision tree through Art. 3(3)-(7):

ROLE DETERMINATION DECISION TREE

System acquisition + Organizational relationship → Role mapping:

Develops or commissions development + places on market/puts into service
  under own name/trademark?
  └─ YES → PROVIDER (Anbieter) — Art. 3(3)

Uses AI system under own authority in professional capacity?
  └─ YES → DEPLOYER (Betreiber) — Art. 3(4)

Imports AI system from third country to place on EU market?
  └─ YES → IMPORTER (Einführer) — Art. 3(6)

Makes AI system available on EU market (not as provider/importer)?
  └─ YES → DISTRIBUTOR (Händler) — Art. 3(7)

Integrates AI system into product as manufacturer?
  └─ YES → Product manufacturer — Art. 25(3), treated as PROVIDER

Multiple roles: An organization can hold multiple roles simultaneously (e.g., provider of one system and deployer of another). Assess each system separately.

Output after primary role determination:

"Based on your answers, your primary role appears to be [Role] under Art. 3([X]) AI Act. [Brief reasoning based on answers]"

Role Determination Visual Decision Tree

                ┌──────────────────────────────┐
                │ Did your org DEVELOP or       │
                │ COMMISSION the AI system?     │
                └──────────────┬───────────────┘
                               │
              ┌── YES ─────────┼─────────── NO ──┐
              │                                   │
              ▼                                   ▼
   ┌──────────────────┐              ┌──────────────────────┐
   │ Place on market / │              │ How does your org    │
   │ put into service  │              │ interact with the    │
   │ under OWN name?   │              │ system?              │
   └────────┬─────────┘              └──────────┬───────────┘
            │                                   │
     YES ───┤                    ┌──────────────┼──────────────┐
            ▼                    │              │              │
   ┌────────────────┐   Uses under      Imports from    Makes available
   │ PROVIDER       │   own authority   non-EU to EU    on EU market
   │ (Anbieter)     │        │              │              │
   │ Art. 3(3)      │        ▼              ▼              ▼
   └────────────────┘  ┌──────────┐  ┌──────────┐  ┌──────────┐
                       │ DEPLOYER │  │ IMPORTER │  │DISTRIBUTOR│
                       │(Betreiber)│  │(Einfuehrer)│ │(Haendler)│
                       │ Art. 3(4)│  │ Art. 3(6)│  │ Art. 3(7)│
                       └──────────┘  └──────────┘  └──────────┘

   Note: Product manufacturers integrating AI → Art. 25(3) → PROVIDER

For sector-specific role determination nuances, see references/sector-guidance-crossref.md. For worked role determination examples, see references/case-studies.md.

---

Phase 3: Quasi-Provider Risk Assessment (Art. 25)

Only proceed with this phase if:

1. The system is high-risk, AND
2. The user is not already classified as the original provider

Read references/quasi-provider-scenarios.md and references/substantial-modification.md.

"I will now assess whether your organization could be treated as a new provider under Art. 25 ('quasi-provider'). This applies when certain modifications or actions cause a deployer, distributor, or importer to assume provider obligations."

Scenario 1 — Own Name/Brand — Art. 25(1)(a):

"Have you put your own name, trademark, or brand on the AI system, or do you present it to end users under your own branding?"

If YES → quasi-provider under Art. 25(1)(a). Organization assumes full provider obligations.

Scenario 2 — Substantial Modification — Art. 25(1)(b):

"Have you made a substantial modification (wesentliche Veränderung) to the AI system?"

Read references/substantial-modification.md for the 3-step checklist.

Apply the 3-step determination:

Step 1: Identify the change

"What specific changes were made to the AI system? (technical parameters, data, architecture, deployment context)"

Step 2: Assess foreseeability

"Were these changes foreseen or covered in the original provider's conformity assessment or intended purpose documentation?"

Step 3: Evaluate risk impact

"Did the changes affect compliance with requirements in Chapter III, Section 2 (Art. 8-15), or did they alter the system's risk profile?"

If finetuning is involved → apply graduated assessment from references/finetuning-assessment.md:

Finetuning Level	Risk of Substantial Modification
PEFT/Adapter (LoRA, QLoRA)	Low — typically does not constitute substantial modification
Layer-wise finetuning	Medium — may constitute substantial modification depending on scope
Full model retraining	High — likely constitutes substantial modification

Scenario 3 — Changed Intended Purpose — Art. 25(1)(c):

"Have you changed the intended purpose (Zweckbestimmung) of the AI system from what the original provider specified?"

If YES → quasi-provider under Art. 25(1)(c). A change of intended purpose always triggers provider status for the entity that changed the purpose.

Scenarios 4-5 — Product Manufacturer Integration — Art. 25(3)(a-b):

"Are you a product manufacturer who:"

• "(a) places on the market or puts into service a high-risk AI system together with your product under your own name or trademark?"
• "(b) puts into service a high-risk AI system bearing your name or trademark after it has already been placed on the market?"

If YES to either → provider obligations apply to the product manufacturer.

Art. 25(4) Exception:

"Were the changes you made already foreseen and covered in the original provider's conformity assessment?"

If YES → Art. 25(4) applies — the original conformity assessment remains valid, and Art. 25(1)(b) does not trigger quasi-provider status.

Quasi-Provider Trigger Assessment Decision Tree

              ┌──────────────────────────────────┐
              │ Is the system HIGH-RISK and       │
              │ obtained from another provider?   │
              └───────────────┬──────────────────┘
                              │
               NO ────────────┼──────────── YES
               │                             │
               ▼                             ▼
    ┌─────────────────┐       ┌──────────────────────────┐
    │ Art. 25 does    │       │ Check 3 triggers:        │
    │ not apply.      │       └──────────┬───────────────┘
    │ Stay in primary │                  │
    │ role.           │    ┌─────────────┼─────────────┐
    └─────────────────┘    │             │             │
                           ▼             ▼             ▼
                   ┌────────────┐ ┌────────────┐ ┌────────────┐
                   │ Own name/  │ │ Substantial│ │ Changed    │
                   │ brand?     │ │ modifica-  │ │ intended   │
                   │ Art.25(1a) │ │ tion?      │ │ purpose?   │
                   └─────┬──────┘ │ Art.25(1b) │ │ Art.25(1c) │
                         │        └─────┬──────┘ └─────┬──────┘
                    YES ─┤         YES ─┤          YES ─┤
                         │              │               │
                         │         ┌────▼─────┐        │
                         │         │Art. 25(4)│        │
                         │         │Foreseen? │        │
                         │         └────┬─────┘        │
                         │         YES ─┤── NO         │
                         │              │    │         │
                         │    No quasi- │    │         │
                         │    provider  │    │         │
                         │              │    │         │
                         ▼              │    ▼         ▼
                   ┌─────────────────────────────────────┐
                   │  QUASI-PROVIDER                     │
                   │  Full Art. 16 provider obligations  │
                   │  New conformity assessment required  │
                   └─────────────────────────────────────┘

---

Phase 4: Role Determination Dashboard

## AI Act Role Determination
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Organization:    [name]
AI System:       [name]
Date:            [date]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Primary Role:            [Provider / Deployer / Importer / Distributor]
Legal Basis:             [Art. 3(x)]
Quasi-Provider Risk:     [None / Low / Medium / High]
Art. 25 Scenario:        [N/A / Scenario 1-5 with detail]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ANALYSIS SUMMARY:
[2-3 sentence summary of role determination reasoning]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FLAGS:
[e.g., "Finetuning detected — layer-wise modification may trigger Art. 25(1)(b)"]
[e.g., "Purpose change from manufacturer's intended use detected"]
[e.g., "Own branding on third-party system — Art. 25(1)(a) quasi-provider"]
[e.g., "Product manufacturer integration — Art. 25(3) applies"]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RESPONSIBILITIES:
Original provider support obligation: [Art. 25(2) — must provide technical docs and cooperation]
New conformity assessment required: [Yes / No / Potentially]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ASSESSMENT CONTEXT (paste into next skill)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
System: [name]
Classification: [from prior assessment or TBD]
Basis: [from prior assessment or TBD]
Role: [role]
Quasi-Provider: [risk level]
Sector: [sector]
Jurisdiction: [list]
Org Size: [size]
Art. 50: [from prior assessment or TBD]
GPAI: [from prior assessment or TBD]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
NEXT STEPS:
→ Map the applicable obligations to this role and risk tier
→ Generate formal assessment documentation
→ If quasi-provider risk is Medium/High: seek legal counsel for detailed Art. 25 analysis
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

---

Critical Reminders

1. An organization can be both provider and deployer — for different systems or even the same system in different contexts
2. Art. 25 quasi-provider is a trap — many organizations unknowingly become providers through finetuning or rebranding
3. Art. 25(2) mutual support obligation — even when quasi-provider status triggers, the original provider must cooperate and provide technical documentation
4. Intended purpose is the key anchor — any change from the provider's documented intended purpose triggers Art. 25(1)(c)
5. Configuration ≠ modification — using a system within the provider's intended configuration range does not constitute substantial modification
6. Open-source models — downloading and deploying an open-source model under own brand likely triggers Art. 25(1)(a)
7. Search for latest guidance — the Commission is expected to publish detailed Art. 25 guidance
8. Jurisdiction-specific employment law — role determination has national employment law implications. Reference references/employment-law-overlay.md Section 3 for per-country works council requirements (DE: BetrVG, AT: ArbVG, FR: Code du Travail, NL: WOR, IT: Statuto dei Lavoratori, ES: Ley Rider) that apply in addition to AI Act role obligations
9. Compliance timeline — reference references/compliance-deadlines.md for applicable deadlines based on role and risk tier

Part of the EU AI Act suite

This skill works on its own, but it's designed to interlock with my other EU AI Act skills — install any individually, or use them together for an end-to-end workflow:

• EU AI Act Quick Assessment — 15–25 min preliminary triage
• EU AI Act System Classifier — risk-tier classification across all five tiers
• EU AI Act High-Risk Classifier — depth Annex I / Annex III assessment
• EU AI Act Obligations Mapper — obligations by role and risk tier
• EU AI Act Examination Report Generator — audit-ready compliance report
• EU AI Act Knowledge Base — Q&A over the Act + Commission guidelines

Each is available as a separate skill — install only what you need.