Auf meine Frage, „Was benötigt die Welt an Software in Zeiten von AI/KI“ antwortet mir claude.ai und geht dabei besonders auf die KI-Verordnung der Europäischen Union für den EU AI Act ein.

Aktueller Stand (formell verabschiedet, Ende Juni 2026): Das Digital Omnibus zur KI-Verordnung wurde vom Rat der EU am 29. Juni 2026 final angenommen, nach Zustimmung des Europaparlaments am 16. Juni. Es tritt im Juli 2026 in Kraft. Das ändert einiges an dem, was ich dir vorhin genannt hatte.

Der aktuelle Fahrplan

• 2. August 2026 bleibt ein scharfes Datum – aber nur noch für GPAI-Pflichten (General Purpose AI), Transparenzvorschriften nach Art. 50 (z. B. Kennzeichnung KI-generierter Inhalte) und die vollen Durchgriffsrechte der nationalen Marktaufsichtsbehörden.
• Hochrisiko-KI-Systeme (Annex III) – ursprünglich auch für August 2026 geplant – wurden um 16 Monate auf 2. Dezember 2027 verschoben.
• In Produkte eingebettete Hochrisiko-KI (Annex I), z. B. Medizinprodukte oder Maschinen: verschoben auf 2. August 2028.
• Neu: Ein Verbot von KI-generierten nicht-einvernehmlichen intimen Inhalten („Nudifier“) und CSAM tritt bereits am 2. Dezember 2026 in Kraft – mit dem höchsten Bußgeldrahmen (bis 15 Mio. € bzw. 7% des weltweiten Jahresumsatzes).
• Bußgelder generell: bis zu 35 Mio. € oder 7% des weltweiten Umsatzes bei verbotenen Praktiken.

Was das für Compliance-Tooling bedeutet

Die Verschiebung ist keine Entwarnung, sondern verschafft Vorlaufzeit – die Pflichten selbst (Risikomanagement, Datenverwaltung, technische Dokumentation, Protokollierung, menschliche Aufsicht) bleiben bestehen, nur der Zeitpunkt verschiebt sich. Konkrete Ansatzpunkte für Tools:

• GPAI-Compliance-Dashboards: Da der 2. August 2026 für General-Purpose-AI-Anbieter scharf bleibt, gibt es kurzfristigen Bedarf an Tools für technische Dokumentation, Transparenzberichte und systemische Risikobewertung.
• Content-Provenance/Watermarking: Für die Kennzeichnungspflicht KI-generierter Inhalte (Art. 50) – Tools, die automatisiert Wasserzeichen setzen oder Herkunftsnachweise für Texte/Bilder/Audio erzeugen.
• Annex-III-Klassifizierungstools: Firmen müssen trotz der Fristverlängerung bis Dezember 2027 jetzt schon anfangen zu klassifizieren, ob ihre Systeme überhaupt als „hochriskant“ gelten – ein Tool, das das automatisiert anhand der Systembeschreibung einschätzt, hat Nachfrage.
• Bias-Test-Pipelines: Die Omnibus-Novelle erleichtert die Nutzung besonderer Kategorien personenbezogener Daten (Gesundheit, Ethnie usw.) zur Bias-Erkennung – das öffnet die Tür für Tools, die datenschutzkonforme Fairness-Testing-Pipelines bauen.
• Regulatorisches Monitoring/Change-Management: Weil sich die Zeitleiste gerade live verändert hat und viele Firmen noch nach dem alten Zeitplan planen, sind Tools gefragt, die Rechtsänderungen laufend verfolgen und automatisch auf die eigene Systemlandschaft mappen.

Wichtig für Entwickler: Der Markt ist hier noch wenig besetzt (unter 10 finanzierte Wettbewerber je nach Nische) – im Gegensatz zu übersättigten Bereichen wie Schreib-Assistenten. Der Bedarf ist real und terminlich getrieben, aber die Materie ist komplex und ändert sich schnell, ein Tool müsste die Rechtslage aktuell halten können, was selbst ein nicht-triviales Produktproblem ist.

Weitere Tool-Kategorie

• Watermarking
• Content-Provenance
• GPAI-Dokumentation

GPAI-Dokumentation

Im Bereich Tooling identifizierte Marktlücke zwischen manuellen Templates und automatisierten Lösungen

Hier die Details zu GPAI-Dokumentationspflichten und wo Tools ansetzen können:

Was genau gefordert ist (Art. 53 AI Act)

GPAI-Anbieter (Foundation Models, LLMs, multimodale Modelle) müssen vier Kernpflichten erfüllen:

1. Model Documentation Form (Annex XI) – ein gestuftes Dokumentationsformat mit technischen Eigenschaften, Trainingsprozess, Rechenressourcen und Energieverbrauch. Es unterscheidet, welche Infos an die AI Office, nationale Behörden oder nachgelagerte Anbieter gehen. Muss für jede Modellversion erstellt und 10 Jahre aufbewahrt werden.
2. Training Data Summary (Art. 53(1)(d)) – eine öffentliche Zusammenfassung der Trainingsdaten nach einem festen Kommissions-Template (seit 24. Juli 2025 verbindlich): allgemeine Modellinfos, Kategorien der Datenquellen (öffentliche Datensätze, lizenzierte Daten, gecrawlte Inhalte, Nutzerdaten, synthetische Daten), sowie Copyright-/Datenschutz-Governance. Muss mindestens alle 6 Monate oder bei wesentlichen Änderungen aktualisiert werden.
3. Copyright-Policy – Prozesse zur Beachtung von Rights-Holder-Opt-outs.
4. Zusätzliche Annex-XII-Pakete für systemisches Risiko (Trainingscompute ≥ 10²⁵ FLOPs) – deutlich umfangreicher.

Warum das ein Tooling-Problem ist, kein reines Rechtsproblem

• Die Formulare verlangen strukturierte, aber narrative Antworten – schwer aus verstreuten internen Docs (Trainingslogs, Datenpipeline-Configs, Eval-Reports) automatisiert zusammenzuführen.
• Halbjährliche Update-Pflicht bedeutet: kein einmaliges Dokument, sondern ein lebender Datensatz, der bei jedem Fine-Tuning/Retraining neu befüllt werden muss.
• FLOPs-Schwellenwert-Tracking (10²⁵) ist ein reines Rechenproblem, das direkt an Trainings-Infrastruktur hängen sollte, nicht manuell in Excel gepflegt werden sollte.
• Ich sehe aktuell vor allem manuelle Marken: z. B. ein Open-Source-Repo auf GitHub mit Markdown-Vorlagen für die Annex-XI/XII-Dokumentation – nützlich, aber kein automatisiertes Produkt. Echte SaaS-Player mit tiefer Automatisierung sind hier noch dünn gesät.

Konkrete Produktideen für Entwickler

• Auto-generierte Model Cards: Tool, das sich per API/Plugin an MLOps-Pipelines (MLflow, Weights & Biases, Hugging Face) hängt und die Annex-XI-Form direkt aus Trainingsmetadaten befüllt, statt dass jemand es von Hand ausfüllt.
• FLOPs-Schwellenwert-Monitor: Rechnet Trainingscompute laufend mit und warnt automatisch, wenn sich ein Modell der 10²⁵-Schwelle nähert – bevor es überraschend in die Systemic-Risk-Kategorie rutscht.
• Training-Data-Summary-Generator: Nimmt eine Liste von Datenquellen/Lizenzen entgegen und mappt sie automatisch auf das Kommissions-Template inklusive Versionierung für die 6-Monats-Updates.
• Diff-/Change-Tracking über Modellversionen: Da Dokumentation pro Version + 10 Jahre archiviert werden muss, ist ein Versionierungs-Layer speziell für Compliance-Docs (nicht nur Code) ein Alleinstellungsmerkmal.

Das ist ein Nischenmarkt mit klarer, terminlich getriebener Nachfrage (2. August 2026 ist scharf für GPAI), aber die Zielgruppe ist eher B2B/Foundation-Model-Anbieter als der breite Entwicklermarkt – kleiner, aber zahlungsbereiter Kundenkreis.

Fortsetzung folgt!