EU AI Act fuer Software-Anbieter: Was du jetzt umsetzen musst

Der EU AI Act (Verordnung EU 2024/1689) ist seit dem 2. August 2024 in Kraft. Verbotene Praktiken gelten seit dem 2. Februar 2025, GPAI-Pflichten seit dem 2. August 2025, Hochrisiko-Systeme ab dem 2. August 2026. Anders als bei der DSGVO 2018 gibt es diesmal keine zweijaehrige Schonfrist mehr — die Pflichten greifen gestaffelt und sind teils schon scharf gestellt. Wer 2026 KI in seinem Produkt einsetzt, muss handeln. Dieser Artikel ist ein technischer Leitfaden fuer Software-Anbieter im EU-Markt.

Vier Risikoklassen, vier Pflichtenkataloge

Der AI Act klassifiziert KI-Systeme in vier Risikoklassen — verboten, hoch, begrenzt, minimal — und legt fuer jede Klasse Pflichten fest. Verstoesse kosten bis zu 35 Mio. EUR oder 7 % des weltweiten Konzernumsatzes.

• Verboten (Art. 5): Manipulation, Social Scoring, ungezielte Gesichtserfassung, Emotion Recognition am Arbeitsplatz oder in der Bildung.
• Hochrisiko (Art. 6 + Annex III): Biometrie, kritische Infrastruktur, Bildung, Beschaeftigung, Sozialleistungen, Strafverfolgung, Migration, Rechtspflege.
• Begrenztes Risiko: Chatbots, Bildgenerierung, Deepfakes — Transparenzpflichten nach Art. 50.
• Minimales Risiko: Spam-Filter, KI in Spielen, alltaegliche Empfehlungssysteme — keine spezifischen Pflichten.

In der Praxis trifft "begrenztes Risiko" die meisten Software-Anbieter. Das ist der Bereich, in dem die meisten unbewussten Verstoesse passieren.

Was ein Chatbot- oder KI-Feature heute haben muss

1. Transparenzhinweis (Art. 50)

Nutzer muessen erkennen koennen, dass sie mit einer KI interagieren — nicht mit einem Menschen. Das gilt fuer Chatbots, Voice-Assistenten, KI-Bewerber-Vorscreening, alles. Reicht ein einmaliger Hinweis am Konversationsstart oder eine Kennzeichnung im UI? Beide Wege sind moeglich, aber er muss aufgefallen sein.

2. Kennzeichnung KI-generierter Inhalte (Art. 50 Abs. 2-4)

KI-generierte Texte, Bilder, Audio oder Video muessen als solche gekennzeichnet werden. In Schwankl-Software-Projekten ist das die ``-Komponente:

export function AiBadge({ model }: { model?: string }) {
  return (
    <span className="inline-flex items-center gap-1.5 rounded-full bg-amber-50
                     px-2.5 py-0.5 text-xs font-medium text-amber-900">
      <svg width="12" height="12" viewBox="0 0 24 24" fill="currentColor">
        <path d="M12 2l3 7h7l-5.5 4 2 7-6.5-4.5L5.5 20l2-7L2 9h7z" />
      </svg>
      KI-generiert{model ? ` · ${model}` : ""}
    </span>
  );
}

Beim Anwenden: jede AI-Antwort, jede generierte Zusammenfassung, jeder KI-uebersetzte Inhalt bekommt das Badge. Im Backend wird mitprotokolliert, welches Modell wann den Inhalt erzeugt hat.

3. Human Oversight (Art. 26)

Kundensichtbare Inhalte — Blog-Posts, E-Mails, Rechnungen, Vertraege — duerfen nicht ohne menschliche Freigabe versendet werden. Die Architektur sieht so aus: KI generiert einen Vorschlag, der landet in einer Approval-Queue, ein Mensch klickt "Senden". Erst dann geht es raus.

4. Dokumentation (Art. 11, 13)

Pro KI-Feature dokumentiere ich: welches Modell, welche Trainingsdaten, welche Genauigkeit, welche Risiken, welche Mitigations. Bei Schwankl-Software liegt das in `docs/history/` als Markdown-Eintrag pro Feature.

DSGVO Art. 22 — der oft uebersehene Zwilling

Der AI Act regelt KI-Systeme insgesamt. DSGVO Art. 22 verbietet zusaetzlich vollautomatisierte Einzelentscheidungen mit rechtlicher Wirkung — zum Beispiel automatische Bonitaetspruefung, automatische Bewerber-Vorauswahl. Wer KI fuer Personalentscheidungen einsetzt, kombiniert beide Regelwerke und muss in der Regel:

• einen Opt-In des Betroffenen einholen,
• einen Human-in-the-Loop garantieren,
• ein Recht auf manuelle Pruefung anbieten,
• eine DSFA (Datenschutzfolgenabschaetzung) durchfuehren.

Audit-Trail in Postgres

Jeder KI-Lauf landet in einem Audit-Log. Das ist sowohl AI-Act-Pflicht (Art. 12) als auch DSGVO-relevant (Art. 30):

CREATE TABLE ai_audit_log (
  id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  feature         TEXT NOT NULL,
  model           TEXT NOT NULL,
  input_hash      TEXT NOT NULL,
  output_preview  TEXT,
  user_id         UUID REFERENCES auth.users(id),
  approved_by     UUID REFERENCES auth.users(id),
  approved_at     TIMESTAMPTZ,
  status          TEXT NOT NULL CHECK (status IN ('pending', 'approved', 'rejected')),
  created_at      TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_ai_audit_log_status ON ai_audit_log (status);

Der Input-Hash erlaubt Reproduzierbarkeit ohne sensible Daten zu speichern. Aufbewahrungsfrist: typischerweise 30 Tage — laenger nur bei Hochrisiko-Systemen.

EU-Hosting fuer Sensitive Workloads

Bei sensiblen KI-Anwendungen (Personal, Gesundheit, Finanzen) bevorzuge ich EU-hosted Modelle. Scaleway Paris bietet Mistral und Pixtral mit DSGVO-konformer Datenverarbeitung — kein Drittlandstransfer in die USA, keine Schrems-Risiken, kein Transfer Impact Assessment noetig. Fuer weniger sensible Use Cases sind US-Modelle (OpenAI, Anthropic) mit Standardvertragsklauseln oft akzeptabel.

Was ich konkret mache

Bei einem AI-Act-Audit fuer dein Projekt klassifiziere ich jedes Feature in eine Risikoklasse, dokumentiere Annex-III-Naehe, pruefe Transparenz- und Kennzeichnungspflichten, schaue auf Human-Oversight-Architektur und Audit-Trail.

Implementierungs-seitig liefere ich die ``-Komponente, eine Approval-Queue fuer kundensichtbare Inhalte, das Audit-Log-Schema in Postgres mit Such-UI fuer Admins, und eine Datenschutzerklaerung mit KI-Abschnitt. Hochrisiko-Systeme bekommen zusaetzlich ein vollstaendiges Risikomanagement-System nach Art. 11.

Mehr unter /compliance/ai-act.