GenAI-Einführung – Compliance & Governance

Faercher IT begleitet den gesamten Prozess der GenAI-Einführung: von der Risikoanalyse über die Richtlinienentwicklung bis zur Implementierung – unter Berücksichtigung geltender Regularien wie EU AI Act und DSGVO.

Im Detail

Was diese Leistung umfasst

Bestandsaufnahme bestehender Prozesse und KI-Readiness-Bewertung
Erstellung von AI-Governance-Frameworks und Nutzungsrichtlinien
Risikobewertung und Klassifizierung gemäß EU AI Act
Datenschutz- und Compliance-konforme Integrationsstrategie
Schulung und Enablement von Mitarbeitenden

Warum Compliance vor dem ersten Prompt kommt

Die meisten gescheiterten GenAI-Initiativen scheitern nicht an der Technik, sondern an fehlender Governance: Ein Pilot läuft, begeistert das Fachteam — und wird vom Datenschutz oder der Revision gestoppt, weil niemand die regulatorische Seite mitgedacht hat. Der EU AI Act und die DSGVO setzen klare Leitplanken, und seit August 2024 gelten die ersten Pflichten verbindlich, gestaffelt bis 2026. Wer GenAI produktiv einsetzen will, braucht deshalb von Anfang an eine belastbare Antwort auf drei Fragen: In welche Risikoklasse fällt mein Use-Case, welche Daten dürfen das Unternehmen verlassen, und wer trägt die Verantwortung für die Ergebnisse?

Genau hier setzt die Begleitung an. Statt eines theoretischen Compliance-Berichts entsteht ein praktisch nutzbares Governance-Framework, das Entwicklungsteams und Fachbereiche im Alltag anwenden können — und das einer internen Revision oder externen Prüfung standhält.

Typisches Projektvorgehen

Den Einstieg bildet eine Risikoanalyse über 2–3 Wochen: Bestandsaufnahme der geplanten und bereits laufenden KI-Anwendungen, Klassifizierung jedes Use-Cases nach den vier EU-AI-Act-Risikostufen und eine erste DSGVO-Bewertung der Datenflüsse. Daraus entsteht ein priorisierter Maßnahmenkatalog.

Im Anschluss wird über 6–12 Wochen — abhängig von der Unternehmensgröße — das vollständige Governance-Framework aufgebaut: Nutzungsrichtlinien, Freigabeprozesse, ein Verzeichnis der eingesetzten Modelle samt Auftragsverarbeitungsverträgen, Schulungsmaterial und Auditpfade. Eine erste produktive Pilotanwendung läuft dabei bewusst parallel, damit Compliance kein Papierprojekt bleibt, sondern an einem echten Anwendungsfall erprobt wird.

Häufige Fragen

Was Kund:innen vorab wissen wollen

  1. 01 Was ist der EU AI Act und betrifft er mein Unternehmen?

    Der EU AI Act ist die erste umfassende KI-Regulierung der EU. Er klassifiziert Anwendungen in vier Risikoklassen: minimal (z.B. Spam-Filter, weitgehend unreguliert), begrenzt (z.B. Chatbots, mit Transparenzpflicht), hoch (z.B. KI in HR, Bonität, Bildung, mit umfangreichen Dokumentations-, Aufsichts- und Konformitätspflichten) und verboten (z.B. Social Scoring). Betroffen ist praktisch jedes Unternehmen, das KI einsetzt — die entscheidende Frage ist nur, in welche Klasse der konkrete Use-Case fällt. Die verbotenen Praktiken gelten bereits, die Pflichten für Hochrisiko-Systeme greifen gestaffelt bis August 2026. Wer KI-Systeme einsetzt, die Personenentscheidungen beeinflussen, sollte sich frühzeitig vorbereiten. Der erste Schritt jeder Compliance-Strategie ist deshalb die saubere Klassifizierung Ihrer Use-Cases — sie entscheidet über den gesamten weiteren Aufwand und ist die Grundlage, auf der alles andere aufbaut.

    EU AI Act – vier Risikoklassen, steigende Pflichten VERBOTEN HOCH BEGRENZT MINIMAL Social ScoringHR · BonitätChatbotsSpamfilterPFLICHTEN
    EU AI Act – vier Risikoklassen, steigende Pflichten
  2. 02 Wie lange dauert eine regelkonforme GenAI-Einführung typischerweise?

    Eine erste Risikoanalyse mit Use-Case-Klassifikation und einer DSGVO-Bewertung der Datenflüsse lässt sich in 2–3 Wochen abschließen. Sie liefert einen priorisierten Maßnahmenkatalog und schafft die Entscheidungsgrundlage, bevor größer investiert wird. Das vollständige Governance-Framework — inklusive Nutzungsrichtlinien, Freigabeprozessen, einem Verzeichnis der eingesetzten Modelle samt Auftragsverarbeitungsverträgen, Schulungsmaterial und Auditpfaden — braucht je nach Unternehmensgröße und Anzahl der Use-Cases 6–12 Wochen. Wichtig ist, dass eine erste produktive Pilotanwendung dabei bewusst parallel aufgesetzt wird: So bleibt Compliance kein Papierprojekt, sondern wird an einem echten Anwendungsfall erprobt und die Mitarbeitenden erleben von Beginn an, dass die Regeln den produktiven Einsatz ermöglichen statt ihn zu blockieren. Diese Parallelität verkürzt die Zeit bis zum messbaren Nutzen erheblich.

  3. 03 Welche Daten dürfen mit Foundation Models verarbeitet werden?

    Das hängt von der Sensibilität der Daten und der Anbieterkonstellation ab. Personenbezogene Daten erfordern eine Rechtsgrundlage nach DSGVO und einen Auftragsverarbeitungsvertrag (AVV) mit dem Modellanbieter — bei US-Anbietern zusätzlich eine Absicherung über das EU-US Data Privacy Framework. Entscheidend ist außerdem, dass der Anbieter Ihre Eingaben nachweislich nicht zum Training verwendet; das bieten etwa Anthropic, OpenAI Enterprise und Vertex AI vertraglich zu. Geschäftsgeheimnisse und besonders sensible Daten sollten bevorzugt in EU-gehosteten Modellen oder On-Premises-Lösungen verarbeitet werden, um das Risiko klein zu halten. In der Praxis bewährt sich eine abgestufte Strategie: unkritische Inhalte über Standard-APIs, sensible über EU-Regionen, hochsensible self-hosted. Welche Daten in welche Kategorie fallen, klären wir gemeinsam in der Risikoanalyse und halten es in den Nutzungsrichtlinien verbindlich fest.

  4. 04 Bin ich „Anbieter" oder „Betreiber" — und was ändert das an meinen Pflichten?

    Der EU AI Act unterscheidet klar zwischen Rollen, und Ihre Pflichten hängen davon ab, welche Sie einnehmen. Anbieter („Provider") ist, wer ein KI-System entwickelt oder unter eigenem Namen in Verkehr bringt — auf ihn entfällt der Großteil der Pflichten: Konformitätsbewertung, technische Dokumentation, Risikomanagement und Registrierung. Betreiber („Deployer") ist, wer ein KI-System im Rahmen seiner beruflichen Tätigkeit einsetzt; seine Pflichten sind schlanker, aber real: bestimmungsgemäße Nutzung, menschliche Aufsicht, Informationspflichten gegenüber Betroffenen und das Beobachten des laufenden Betriebs. Der entscheidende Fallstrick liegt dazwischen: Wer ein zugekauftes System wesentlich verändert, es unter eigenem Namen anbietet oder seinen Zweck ändert, kann vom Betreiber zum Anbieter werden — mit dem vollen Pflichtenkatalog. Gerade beim Einsatz von Foundation Models über eine fremde API ist deshalb früh zu klären, wo genau Ihre Rolle endet und beginnt. Diese Rollenklärung steht bewusst am Anfang jeder Governance-Arbeit, weil sie den gesamten weiteren Aufwand bestimmt.

    EU AI Act – Rollen Anbieter und Betreiber mit ihren Pflichten wesentliche Änderung / eigener Name ANBIETER Provider · entwickelt / bringt in Verkehr · Konformitätsbewertung· technische Doku· Risikomanagement· Registrierung Großteil der Pflichten BETREIBER Deployer · setzt System ein · bestimmungsgemäße Nutzung· menschliche Aufsicht· Info an Betroffene· Betrieb beobachten schlankere Pflichten
    EU AI Act – Rollen Anbieter und Betreiber mit ihren Pflichten
  5. 05 Was sind die OWASP LLM Top 10 und warum gehören sie in die Compliance?

    Die OWASP LLM Top 10 sind eine herstellerunabhängige Liste der zehn häufigsten Sicherheitsrisiken von Anwendungen mit Sprachmodellen — das Pendant zu den etablierten OWASP-Listen für Web-Sicherheit. Ganz oben steht Prompt Injection: das Unterschieben von Anweisungen über manipulierte Eingaben oder Dokumente, mit denen ein Angreifer das Modell zu unerwünschten Aktionen bringt. Weitere Punkte sind unsichere Weiterverarbeitung der Modellausgaben, das Vergiften von Trainings- oder Retrieval-Daten, das Abfließen sensibler Informationen, eine übermäßige Handlungsvollmacht von Agenten und ein zu blindes Vertrauen in Modellausgaben. Für die Compliance sind sie doppelt relevant: Sie liefern eine konkrete, prüfbare Checkliste für das vom EU AI Act geforderte Risikomanagement, und sie übersetzen abstrakte Sicherheitsanforderungen in Maßnahmen, die Entwicklungsteams direkt umsetzen können — Eingaben validieren, Ausgaben filtern, Agenten-Rechte minimieren, kritische Aktionen absichern. In der Governance-Arbeit dienen sie als Brücke zwischen der regulatorischen und der technischen Seite: Sie machen aus dem Satz „das System muss sicher sein" eine Liste bearbeitbarer Punkte.

Interesse geweckt?

Lassen Sie uns besprechen, wie ich Sie bei diesem Thema unterstützen kann.

Jetzt anfragen