From lawvable-awesome-legal-skills
Determines an organization's role under the EU AI Act (provider, deployer, etc.) and assesses Art. 25 quasi-provider risk via guided questioning.
How this skill is triggered — by the user, by Claude, or both
Slash command
/lawvable-awesome-legal-skills:eu-ai-act-roles-oliver-schmidt-prietzThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
LICENSE.txtREADME.mdreferences/case-studies.mdreferences/compliance-deadlines.mdreferences/employment-law-overlay.mdreferences/finetuning-assessment.mdreferences/quasi-provider-scenarios.mdreferences/role-definitions.mdreferences/sector-guidance-crossref.mdreferences/substantial-modification.mdreferences/value-chain-obligations.mdDetermine 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.
IMPORTANT NOTICE This assessment provides structured guidance based on the EU AI Act (Regulation (EU) 2024/1689) and Commission value chain guidance. It does not constitute legal advice. Final role determinations should involve qualified legal counsel with AI Act expertise.
Do you acknowledge this and wish to proceed?
Wait for acknowledgment before proceeding.
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
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):
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.
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]"
┌──────────────────────────────┐
│ 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.
Only proceed with this phase if:
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.
┌──────────────────────────────────┐
│ 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 │
└─────────────────────────────────────┘
## 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:
→ Run /ai-act-obligations for applicable requirements based on this role
→ Run /ai-act-report to generate formal assessment documentation
→ If quasi-provider risk is Medium/High: seek legal counsel for detailed Art. 25 analysis
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
npx claudepluginhub lawve-ai/awesome-legal-skillsMaps EU AI Act obligations based on role and risk tier into a compliance matrix with RACI assignments. Generates checklists for provider and deployer duties.
Determines EU AI Act obligations by role (provider/deployer) and risk class, and compiles Annex IV technical documentation for high-risk AI systems.
Determines when an entity becomes a provider under EU AI Act Article 25, with four case groups and practical checklists.