Skip to content
Content
Skill

/data-act-nutzerdatenzugang

Zugangsanspruch des Nutzers nach der EU-Datenverordnung – Konzeptionspflicht Art. 3 Abs. 1 und vorvertragliche Informationspflichten Art. 3 Abs. 2, 3, Bereitstellung an den Nutzer Art. 4 Abs. 1, Weitergabe an Dritte auf Verlangen des Nutzers Art. 5 mit Torwächtersperre Art. 5

From plugin
ai-skills-german-law
30200 skills3 agents1 MCP
Install
$ npx -y skills add borghei/AI-Skills-German-Law --skill data-act-nutzerdatenzugang --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/data-act-nutzerdatenzugang

Context preview

The summary Claude sees to decide when to auto-load this skill.

Zugangsanspruch des Nutzers nach der EU-Datenverordnung – Konzeptionspflicht Art. 3 Abs. 1 und vorvertragliche Informationspflichten Art. 3 Abs. 2, 3, Bereitstellung an den Nutzer Art. 4 Abs. 1, Weitergabe an Dritte auf Verlangen des Nutzers Art. 5 mit Torwächtersperre Art. 5

SKILL.md

data-act-nutzerdatenzugang.SKILL.md
name: data-act-nutzerdatenzugang
description: "Zugangsanspruch des Nutzers nach der EU-Datenverordnung – Konzeptionspflicht Art. 3 Abs. 1 und vorvertragliche Informationspflichten Art. 3 Abs. 2, 3, Bereitstellung an den Nutzer Art. 4 Abs. 1, Weitergabe an Dritte auf Verlangen des Nutzers Art. 5 mit Torwächtersperre Art. 5 Abs. 3, Pflichten des Dritten Art. 6, Schutz von Geschäftsgeheimnissen Art. 4 Abs. 6–8 und Art. 5 Abs. 9–11, technische Schutzmaßnahmen Art. 11, Beschwerde bei der Bundesnetzagentur Art. 38 iVm §§ 2, 6 DADG. Use when ein Nutzer Zugang zu Produktdaten verlangt oder ein Dateninhaber ein Zugangsverlangen beantworten, beschränken oder ablehnen will."
language: de
agents:
  researcher: ../../agents/researcher.md
  drafter: ../../agents/drafter.md
  reviewer: ../../agents/reviewer.md
provider_variants: [claude, gemini, openai]
test: ./test.md

/datenwirtschaftsrecht:data-act-nutzerdatenzugang

Zweck

Der Skill bearbeitet das Zugangsverlangen selbst: er prüft, welche Daten „ohne Weiteres verfügbar" sind, in welcher Qualität und Frist sie bereitzustellen sind, wie Geschäftsgeheimnisse geschützt werden, ohne den Anspruch leerlaufen zu lassen, und wann eine Verweigerung tragfähig ist. Er entwirft die Antwort des Dateninhabers oder das Verlangen des Nutzers und benennt den Rechtsweg.

Eingaben

  • Wortlaut und Datum des Zugangsverlangens, Absender und dessen Rolle
  • Datenkatalog: welche Daten das Produkt erzeugt, welche der Dateninhaber tatsächlich vorhält
  • Ob ein Dritter benannt ist, und ob dieser Torwächter nach VO (EU) 2022/1925 ist
  • Vorhandene Schnittstellen: API, Portal, Direktzugriff am Gerät
  • Als Geschäftsgeheimnis gekennzeichnete Datenfelder samt Schutzmaßnahmen
  • Sicherheitsrelevanz der Daten iSd Art. 4 Abs. 2
  • Ob personenbezogene Daten Dritter enthalten sind

Sub-Agent-Architektur

Der Researcher liefert Normtext, Erwägungsgründe und Behördenverlautbarungen. Der Drafter trennt den Datenbestand in „ohne Weiteres verfügbar", „abgeleitet" und „gesperrt" und entwirft Antwortschreiben oder Verlangen. Der Reviewer kontrolliert, dass keine Verweigerung ohne Rechtsgrundlage ausgesprochen, keine Mitteilungspflicht an die Bundesnetzagentur übergangen und kein Geschäftsgeheimnisschutz behauptet wird, für den die Kennzeichnung nach Art. 4 Abs. 6 fehlt.

Ablauf

1. Datenkatalog bilden — „ohne Weiteres verfügbar" ist der Schlüsselbegriff

Der Anspruch aus Art. 4 Abs. 1 erfasst **ohne Weiteres verfügbare Daten** einschließlich der zur Auslegung und Nutzung erforderlichen **Metadaten**. Das sind Produktdaten und verbundene Dienstdaten, die der Dateninhaber rechtmäßig erlangt oder rechtmäßig erlangen kann, ohne unverhältnismäßigen Aufwand über einen einfachen Vorgang hinaus.

| Kategorie | Erfasst? | |---|---| | Rohdaten aus Sensorik, Zustands- und Nutzungsdaten | ja | | Für Auslegung nötige Metadaten | ja | | Daten, die erst durch komplexe Aufbereitung entstehen | regelmäßig nein — Begründung erforderlich | | Stark abgeleitete oder rückgeschlossene Daten (inferred / derived) | nein | | Daten aus Tests noch nicht in Verkehr gebrachter Produkte (Art. 5 Abs. 2) | für die Drittweitergabe nein, außer vertraglich gestattet |

Die Einordnung ist datenfeldweise zu dokumentieren. Eine pauschale Behauptung „alles ist abgeleitet" trägt nicht.

2. Konzeptionspflicht und vorvertragliche Information prüfen (Art. 3)

Nach Art. 3 Abs. 1 sind vernetzte Produkte und verbundene Dienste so zu konzipieren, dass die Daten **standardmäßig, einfach, sicher, unentgeltlich, in einem umfassenden, strukturierten, gängigen und maschinenlesbaren Format** und – soweit relevant und technisch durchführbar – **direkt** zugänglich sind. Diese Pflicht gilt nach Art. 50 nur für Produkte und Dienste, die **nach dem 12.09.2026** in Verkehr gebracht wurden.

Unabhängig davon bestehen die vorvertraglichen Informationspflichten:

  • **Art. 3 Abs. 2** — vor Abschluss eines Kauf-, Miet- oder Leasingvertrags über das Produkt: Art, Format und geschätzter Umfang der Daten; ob kontinuierlich und in Echtzeit generiert wird; ob auf dem Gerät oder einem entfernten Server gespeichert wird und wie lange; wie zugegriffen, abgerufen und gelöscht werden kann.
  • **Art. 3 Abs. 3** — vor Abschluss eines Vertrags über einen verbundenen Dienst: Art, Umfang und Häufigkeit der Erhebung, Zugriffsmodalitäten, geplante Eigennutzung durch den künftigen Dateninhaber und deren Zwecke.

Diese Informationen gehören in Produktinformation und Vertragsunterlagen, nicht in die Datenschutzerklärung.

3. Bereitstellung an den Nutzer (Art. 4 Abs. 1)

Soweit der Nutzer nicht direkt am Produkt zugreifen kann, hat der Dateninhaber bereitzustellen: **unverzüglich, einfach, sicher, unentgeltlich, in einem umfassenden, gängigen und maschinenlesbaren Format** und, falls relevant und technisch durchführbar, **in gleicher Qualität wie für den Dateninhaber, kontinuierlich und in Echtzeit**. Das Verlangen kann formlos elektronisch gestellt werden.

Flankierend:

  • **Art. 4 Abs. 4** — Verbot, die Rechtsausübung unangemessen zu erschweren, ausdrücklich einschließlich manipulativer Oberflächengestaltung („dark patterns").
  • **Art. 4 Abs. 5** — Identitätsprüfung nur im erforderlichen Maß; keine über das Nötige hinausgehende Protokollierung der Zugriffe.
  • **Art. 4 Abs. 2** — vertragliche Beschränkungen sind zulässig, wenn die Verarbeitung gesetzliche Sicherheitsanforderungen des Produkts beeinträchtigen und zu schwerwiegenden Gesundheits- oder Sicherheitsfolgen führen könnte. Verweigert der Dateninhaber deshalb, **teilt er dies der nach Art. 37 benannten zuständigen Behörde mit** — in Deutschland der Bundesnetzagentur (§ 2 Abs. 1 DADG).

4. Weitergabe an Dritte (Art. 5, Art. 6)

Auf Verlangen des Nutzers stellt der Dateninhaber die Daten einem **Dritten** bereit — für den Nutzer unentgeltlich, in derselben Qualität, strukturiert, gängig und maschinenlesbar, soweit relevant kontinuierlich und in Echtzeit. Das Verhältnis Dateninhaber ↔ Drit

Read more
Ships withai-skills-german-law

AI skills for German legal practice and EU compliance. 66 plugins, 291 skills: general law, Fachanwaltschaften, high-volume practice areas, EU frameworks (KI-VO, NIS2, KRITIS, DORA, CSRD, Data Act, BFSG, MiCAR) and VDuG collective redress. Claude, Gemini, GPT. Statutes linked to primary sources; case law marked verified or [unverifiziert].

Get the whole plugin

Other skills on ai-skills-german-law.