Nudifier-Verbot ab 2. Dezember 2026: Was Betreiber selbst gehosteter Bildmodelle jetzt bauen müssen
Die KI-Omnibus-Verordnung hat Artikel 5 des AI Act um einen neuen Verbotstatbestand erweitert, der ab Dezember 2026 gilt und in der höchsten Bußgeldstufe liegt. Entscheidend für den Mittelstand: Erfasst sind nicht nur Systeme, die dafür gebaut wurden, sondern auch solche, bei denen entsprechende Ausgaben vorhersehbar und reproduzierbar sind – wenn Schutzmaßnahmen fehlen.
Der AI Act bekommt ein neuntes Verbot: KI-Systeme, die nicht einvernehmliche intime Inhalte oder Missbrauchsmaterial erzeugen, sind untersagt – ab Dezember 2026, sanktioniert mit bis zu 35 Mio. Euro oder 7 % des weltweiten Jahresumsatzes.
Betroffen ist auch, wer ein offenes Bildmodell nur intern betreibt. Einen gesetzlichen Guardrail-Katalog gibt es nicht – maßgeblich ist, dass Sie geeignete Schutzmaßnahmen nachweisen können.
Am 24. Juli 2026 wurde die Verordnung (EU) 2026/1744 im EU-Amtsblatt veröffentlicht, drei Tage später trat sie in Kraft. Der „Digital Omnibus on AI" ist auf den ersten Blick ein Entlastungspaket: Er verschiebt die Hochrisiko-Pflichten für eigenständige Systeme nach Anhang III auf den 2. Dezember 2027 und für in Produkte eingebettete Systeme auf den 2. August 2028. Genau eine Verschärfung enthält das Paket – und die betrifft Bildmodelle.
Artikel 5 des EU AI Act listete bislang acht verbotene Praktiken, in Geltung seit dem 2. Februar 2025. Der Omnibus fügt ein neuntes Verbot hinzu. Die Kommission beschreibt es als Verbot von „KI-Systemen, die nicht einvernehmliche sexuell explizite und intime Inhalte oder Material über sexuellen Missbrauch von Kindern (CSAM) generieren, wie KI-Apps zur Nudifizierung". Das Europäische Parlament formuliert es als eine Bestimmung, die sowohl nicht einvernehmliche intime Darstellungen als auch Missbrauchsmaterial erfasst.
Wer in seinem Haus ein offenes Bildmodell betreibt – Stable Diffusion, FLUX, SDXL oder einen Community-Feintune davon – muss davon ausgehen, dass er in den Anwendungsbereich fällt. Nicht, weil das Werkzeug dafür gedacht wäre, sondern weil ein ungeschütztes Basismodell auf entsprechende Prompts entsprechend antwortet.
Was genau verboten wird
Der neue Tatbestand deckt zwei Fallgruppen ab, die technisch dieselbe Pipeline betreffen:
- Nicht einvernehmliche Intimdarstellungen identifizierbarer Personen. Das klassische Nudifier-Szenario: Ein reales Porträtfoto wird per Image-to-Image, Inpainting oder IP-Adapter in eine sexualisierte Darstellung überführt. Entscheidend ist die Identifizierbarkeit – nicht, ob das Ergebnis fotorealistisch ist.
- KI-generiertes Material sexuellen Kindesmissbrauchs. Hier ist die Erzeugung selbst verboten, unabhängig von Verbreitung oder Personenbezug. Das trifft auch synthetische Darstellungen ohne reale Vorlage.
Der praktisch heikle Punkt ist die Reichweite jenseits dedizierter Werkzeuge. Eine „Nudifier-App" zu verbieten wäre trivial – niemand im Mittelstand betreibt so etwas. Die relevante Frage lautet: Ab wann gilt ein allgemeiner Bildgenerator als System, das solche Ausgaben erzeugt? Nach unserer fachlichen Einschätzung – und das ist ausdrücklich eine Einordnung, kein Gesetzeszitat – läuft der Maßstab auf Vorhersehbarkeit und Reproduzierbarkeit hinaus: Wenn ein durchschnittlich versierter Nutzer mit wenigen Versuchen reproduzierbar zu verbotenen Ausgaben kommt und Sie nichts dagegen unternommen haben, wird sich schwer argumentieren lassen, das System erzeuge solche Inhalte nicht.
Framing-Punkt für die Geschäftsleitung: Der Digital Omnibus entlastet an fast allen Stellen – Fristen wandern nach hinten, Dokumentationspflichten werden gestrafft. Das Bildmodell-Verbot ist die einzige neue Verschärfung im gesamten Paket. Wer die Omnibus-Meldung als „alles später" abgelegt hat, hat genau den Punkt übersehen, der ihn betrifft.
Der Bußgeldrahmen
Verstöße gegen Art. 5 liegen in der höchsten Sanktionsstufe des AI Act. Art. 99 Abs. 3 sieht Geldbußen bis 35 Mio. Euro oder – wenn der Zuwiderhandelnde ein Unternehmen ist – bis zu 7 % des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Zum Vergleich: Alle übrigen Verstöße nach Art. 99 Abs. 4 liegen bei bis zu 15 Mio. Euro oder 3 %.
| Datum | Was gilt | Relevanz für Bildmodelle |
|---|---|---|
| 02.02.2025 | Die acht ursprünglichen Verbote des Art. 5 gelten | indirekt (z. B. biometrische Kategorisierung) |
| 02.08.2026 | AI Office und nationale Behörden sind für Umsetzung, Aufsicht und Durchsetzung zuständig; Transparenzregeln gelten | hoch – Durchsetzungsapparat steht |
| 02.12.2026 | Kennzeichnungspflicht nach Art. 50 auch für Systeme, die vor dem 02.08.2026 in Verkehr gebracht wurden | hoch – Altbestand wird erfasst |
| Dez. 2026 | Das neunte Verbot in Art. 5 wird wirksam (Kommission und EP nennen bislang nur den Monat) | sehr hoch – Bußgeldstufe 1 |
| 02.12.2027 | Hochrisiko-Pflichten für eigenständige Anhang-III-Systeme | mittel – je nach Einsatzzweck |
Ein Hinweis zum Datum in eigener Sache: Kommission und Parlament kommunizieren für das neunte Verbot bisher ausschließlich „Dezember 2026". Der in der Fachpresse kursierende 2. Dezember 2026 ist als Stichtag nur für die verschobene Kennzeichnungspflicht bei Altsystemen belegt. Beide Termine fallen in denselben Monat, und planerisch macht es keinen Unterschied – wer auf den 2. Dezember plant, liegt auf der sicheren Seite. Für die Rechtsabteilung lohnt trotzdem der Blick in den Amtsblatt-Text (OJ L, 24.7.2026, Reg. 2026/1744).
Warum es Sie trifft, wenn Sie ein offenes Bildmodell betreiben
Art. 5 knüpft an das Inverkehrbringen, die Inbetriebnahme und die Verwendung von KI-Systemen an. Damit adressiert die Norm Anbieter und Betreiber gleichermaßen. Wer ein Diffusionsmodell im eigenen Rechenzentrum installiert und Mitarbeitern zur Verfügung stellt, nimmt es in Betrieb und verwendet es. Auch die Open-Source-Privilegierung der KI-Verordnung hilft hier nicht weiter: Sie entlastet von bestimmten Anbieterpflichten, nicht von den Verboten des Art. 5.
Der entscheidende Unterschied zum Cloud-Betrieb ist banal und wird trotzdem regelmäßig übersehen. Wer Text-to-Image über eine kommerzielle API bezieht, kauft die Schutzschicht mit: Prompt-Moderation, Safety-Checker, Face-Sperren und Missbrauchserkennung laufen beim Anbieter und stehen in dessen Nutzungsbedingungen. Wer sich Gewichte von Hugging Face zieht und hinter der eigenen Firewall startet, bekommt genau das nicht.
Was ein Basismodell tatsächlich mitbringt
- Trainingsseitige Filterung. Neuere Basismodelle wurden auf gefilterten Datensätzen trainiert. Das reduziert die Wahrscheinlichkeit problematischer Ausgaben, eliminiert sie aber nicht – und lässt sich durch Feintuning wieder aufheben.
- Optionale Safety-Checker. Der bei Diffusers mitgelieferte Safety-Checker ist ein Modul, das mit einem einzigen Parameter deaktiviert wird. In vielen Tutorials und Community-Repos ist er standardmäßig aus, weil er False Positives produziert.
- Keinerlei Personenschutz. Kein gängiges Basismodell prüft, ob ein hochgeladenes Referenzbild eine identifizierbare reale Person zeigt. Genau das ist aber der Kern der ersten Fallgruppe.
Damit wird der Betreiber faktisch zu demjenigen, der die Schutzmaßnahmen liefern muss. Und die interne Bereitstellung ist keine Ausnahme: Der Verbotstatbestand knüpft nicht an Öffentlichkeit an. Ein Marketing-Team von zwölf Personen mit Zugriff auf ein internes Bildwerkzeug ist regulatorisch nicht besser gestellt als ein öffentlicher Dienst – nur schlechter überwacht.
Der Maßstab: angemessen, verhältnismäßig, wirksam
Hier ist Ehrlichkeit wichtiger als Marketing: Die KI-Verordnung schreibt für Art. 5 keinen technischen Katalog vor. Es gibt keine gesetzlich definierten Guardrail-Anforderungen, keine Mindestfilterquoten, kein vorgeschriebenes Prüfverfahren. Wer Ihnen erzählt, ein bestimmtes Produkt mache Sie „Art.-5-konform", verkauft Ihnen eine Behauptung.
Was der risikobasierte Ansatz der Verordnung stattdessen nahelegt, ist ein Dreiklang, an dem sich die Praxis in anderen Regulierungsfeldern seit Jahren orientiert:
- Angemessen – die Maßnahme passt zum konkreten Risiko des Systems. Ein Modell, das ausschließlich Produktfreisteller erzeugt, braucht andere Sperren als ein generalistischer Generator mit Bild-Upload.
- Verhältnismäßig – der Aufwand steht im Verhältnis zu Nutzung, Nutzerkreis und Missbrauchspotenzial. Ein Zwei-Personen-Prototyp ohne Bild-Upload erfordert nicht denselben Apparat wie ein hausweiter Dienst mit 300 Nutzern.
- Wirksam – die Maßnahme greift nachweislich. Das ist der Punkt, an dem die meisten Umsetzungen scheitern, weil niemand je getestet hat, ob der Filter überhaupt auslöst.
Für die Beweislage ist die einzelne Technik zweitrangig. Wichtiger ist, dass Sie die Eignung belegen können. Eine dokumentierte Testsuite mit 40 bis 60 Prompts, die den Sperrpfad gezielt provozieren, mit Datum, Modellversion, Trefferquote und Verantwortlichem, ist im Zweifel mehr wert als drei zusätzliche Klassifikatoren ohne jeden Nachweis. Wer bereits strukturiertes Red Teaming betreibt, hat den passenden Prozess im Haus – er muss ihn nur auf die Bildpipeline anwenden.
Technische Schutzschichten im Detail
Die folgenden Guardrails sind Compliance-Praxis, nicht Rechtspflicht. Sie sind das, was wir in Projekten als vertretbares Minimum umsetzen – und was sich gegenüber einer Marktüberwachungsbehörde erklären lässt.
Stufe 1: Prompt-Filter vor der Generierung
Der häufigste Umsetzungsfehler ist, nur den Output zu prüfen. Das ist teuer (die Generierung läuft trotzdem, 2 bis 6 Sekunden GPU-Zeit pro Bild) und schwächer, weil der Klassifikator nur das Ergebnis sieht, nicht die Absicht. Ein vorgelagerter Filter arbeitet zweistufig: eine deterministische Sperrliste für eindeutige Begriffe und Umgehungsschreibweisen, dahinter ein kleiner Textklassifikator, der Kombinationen erkennt – etwa die Verbindung aus einem Personennamen, einem Referenzbild und Kleidungsbezug. Erfahrungsgemäß fängt die Sperrliste 60 bis 70 % der eindeutigen Fälle ab, der Klassifikator den Rest.
Stufe 2: Gesichtsähnlichkeitssperre
Diese Schicht adressiert die erste Fallgruppe direkt. Sobald ein Referenzbild, ein IP-Adapter oder eine LoRA einer realen Person im Spiel ist, wird geprüft, ob das Eingangsbild ein menschliches Gesicht enthält und ob es einer identifizierbaren Person zuzuordnen ist. In der Praxis genügt zunächst die Gesichtserkennung als Trigger: Referenzbild mit Gesicht plus ein Prompt, der auch nur entfernt in Richtung Körper oder Kleidung geht, führt zum Abbruch. Der Abgleich gegen eine Referenzdatenbank ist datenschutzrechtlich heikel und in den meisten Fällen nicht nötig. Wichtig: Diese Sperre ist gleichzeitig Ihre wirksamste Maßnahme gegen Deepfakes von Führungskräften.
Stufe 3: Output-Klassifikator plus Abbruchpfad
Nach der Generierung, aber vor der Auslieferung, läuft ein NSFW-Klassifikator über das Bild. Moderne Modelle dieser Klasse brauchen 15 bis 40 Millisekunden pro Bild auf CPU – der Latenzbeitrag ist gegenüber der Generierung vernachlässigbar. Entscheidend ist der Abbruchpfad: Bei Treffer wird das Bild verworfen, nicht gespeichert, der Nutzer erhält eine neutrale Fehlermeldung, und der Vorfall wird protokolliert. Wer das beanstandete Bild „zur Prüfung" ablegt, produziert genau das Problem, das er verhindern wollte.
| Schutzschicht | Latenz je Anfrage | Aufwand Erstumsetzung | Deckt Fallgruppe |
|---|---|---|---|
| Sperrliste (deterministisch) | < 1 ms | 0,5 PT | beide |
| Prompt-Klassifikator | 10–30 ms | 2–3 PT | beide |
| Gesichtserkennung auf Referenzbild | 20–60 ms | 3–5 PT | Fallgruppe 1 |
| NSFW-Output-Klassifikator | 15–40 ms | 1–2 PT | beide |
| Adapter-Allowlist & Registry | 0 ms (Ladezeit) | 3–4 PT | beide |
Die Summe liegt bei rund 10 bis 15 Personentagen für eine bestehende Pipeline – überschaubar gegenüber dem Sanktionsrisiko, und deutlich weniger, als die meisten Geschäftsführer beim Stichwort „AI-Act-Compliance" erwarten. Details zur Absicherung selbst gehosteter Modelle behandeln wir unter KI-Sicherheit und Guardrails.
Modell- und Adapterhygiene
Ein Großteil des realen Risikos kommt nicht über das Basismodell, sondern über das, was daraufgesetzt wird. LoRAs, IP-Adapter, ControlNets und Community-Feintunes lassen sich in Minuten laden und verändern das Verhalten des Modells fundamental. Ein sauber gefiltertes SDXL wird durch eine einzige, in dreißig Sekunden geladene LoRA zu etwas völlig anderem – und Ihre trainingsseitige Sicherheit ist weg.
Praxisbeispiel: Marketingabteilung eines Konsumgüterherstellers
Ein Hersteller mit rund 400 Mitarbeitern betrieb seit Anfang 2026 einen internen Bildgenerator auf zwei RTX-6000-Karten für Kampagnenvisuals. Freigegeben war ein Basismodell – tatsächlich lagen im Modellverzeichnis nach vierzehn Monaten Betrieb 61 Dateien: 1 Basismodell, 4 Feintunes und 56 LoRAs, größtenteils aus Community-Quellen, ohne Dokumentation der Herkunft. Bei der Inventur ließ sich für 23 Adapter nicht mehr rekonstruieren, wer sie wann und warum geladen hatte. Vier davon stammten von Uploadern, die auf derselben Plattform explizit NSFW-Adapter anbieten. Die Konsequenz war kein neuer Filter, sondern eine Allowlist: Das Modellverzeichnis ist seither schreibgeschützt, Adapter werden über einen Merge-Request mit Vier-Augen-Freigabe aufgenommen, und die Inventur wurde von 61 auf 9 Dateien reduziert.
Drei Regeln haben sich als tragfähig erwiesen:
- Allowlist statt freier Upload. Das Modellverzeichnis gehört dem Betrieb, nicht den Nutzern. Wer Adapter per Weboberfläche hochladen kann, hat keine Kontrolle über das Systemverhalten – und damit auch keinen belastbaren Nachweis.
- Herkunftsnachweis für jedes Gewicht. Für jede Datei: Quelle (URL, Repository, Commit), Lizenz, SHA-256-Hash, freigebende Person, Datum. Das ist eine CSV-Datei, kein Projekt.
- Neubewertung bei jedem Modellwechsel. Ein Wechsel des Basismodells invalidiert Ihre Testergebnisse. Die Testsuite muss gegen die neue Version laufen, bevor sie in Produktion geht – sonst dokumentieren Sie die Wirksamkeit eines Systems, das Sie nicht mehr betreiben.
Logging und Nachweisführung
Auch hier gilt die saubere Trennung: Eine explizite Logging-Pflicht aus Art. 5 gibt es nicht. Die belastbaren gesetzlichen Anknüpfungspunkte für Bildmodelle sind zwei andere Normen.
Art. 50 AI Act verlangt die Kennzeichnung synthetischer Inhalte, einschließlich maschinenlesbarer Markierung. Anwendbar ist die Regel seit August 2026; für Systeme, die vor dem 2. August 2026 in Verkehr gebracht wurden, greift sie ab dem 2. Dezember 2026. Praktisch heißt das: C2PA-Manifest oder vergleichbare Provenance-Signatur in jedem ausgelieferten Bild. Wie das technisch aussieht, haben wir im Detail beschrieben.
Art. 79 AI Act regelt das Verfahren bei Systemen mit Risiko. Stellt eine Marktüberwachungsbehörde einen Verstoß fest, verlangt sie ohne unangemessene Verzögerung die geeigneten Korrekturmaßnahmen, die Rücknahme vom Markt oder den Rückruf – und zwar innerhalb des kürzeren Zeitraums von 15 Arbeitstagen oder der in den einschlägigen Harmonisierungsvorschriften vorgesehenen Frist. Das ist keine starre Frist, aber ein realistischer Planungsanker: Sie haben im Ernstfall drei Wochen, um zu belegen, was Sie getan haben. Wer dann erst anfängt zu suchen, verliert.
Was protokolliert wird – und was ausdrücklich nicht
- Blockierte Anfragen mit Klassifikatorergebnis. Zeitstempel, pseudonymisierte Nutzer-ID, auslösende Stufe, Regel- oder Modellname, Score, Entscheidung. Das ist Ihr Wirksamkeitsnachweis.
- Keine Speicherung der beanstandeten Inhalte. Weder das erzeugte Bild noch das hochgeladene Referenzbild noch der Volltext des Prompts. Ein Hash des Prompts genügt, um Wiederholungsmuster zu erkennen, ohne den Inhalt vorzuhalten. Andernfalls bauen Sie sich ein Archiv genau des Materials auf, dessen Erzeugung verboten ist.
- Aggregierte Wirksamkeitsberichte. Quartalsweise: Zahl der Anfragen, Blockquote je Stufe, False-Positive-Meldungen aus dem Nutzerkreis, Ergebnis des letzten Testlaufs, Änderungen an Modellen und Adaptern. Zwei Seiten, unterschrieben, abgelegt.
Die Aufbewahrungsdauer sollte mit dem Datenschutzbeauftragten festgelegt werden – 6 bis 12 Monate für Einzelereignisse und 3 Jahre für die aggregierten Berichte sind ein in der Praxis tragfähiger Zuschnitt. Beim On-Premise-Betrieb bleiben diese Protokolle ohnehin im eigenen Haus, was die datenschutzrechtliche Bewertung deutlich vereinfacht.
Zeitplan bis zum 2. Dezember 2026
Vom Redaktionsschluss dieses Beitrags aus bleiben rund 14 Wochen beziehungsweise gut 70 Arbeitstage bis Anfang Dezember 2026. Das reicht bequem – aber nur, wenn die Inventur nicht erst im Oktober beginnt.
| Phase | Zeitfenster | Ergebnis |
|---|---|---|
| 1. Inventur | 2 Wochen (bis KW 37) | Liste aller betriebenen Bild- und Videomodelle inkl. Adapter, Nutzerkreise, Zugangswege |
| 2. Risikoeinstufung | 1 Woche (KW 38) | Pro System: Bild-Upload möglich? Personenbezug möglich? Nutzerkreis offen? |
| 3. Umbau | 4–5 Wochen (KW 39–43) | Drei Schutzschichten in der Pipeline, Allowlist aktiv, Logging umgestellt |
| 4. Testsuite | 2 Wochen (KW 44–45) | 40–60 Testprompts, dokumentierte Trefferquote je Stufe, Red-Teaming-Protokoll |
| 5. Kennzeichnung | 2 Wochen (KW 45–46) | Art.-50-Markierung im Ausgabeweg, auch für Altsysteme |
| 6. Nachweispaket | 1 Woche (bis KW 47) | Systembeschreibung, Maßnahmenkatalog, Testprotokoll, Verantwortlichkeiten – abgelegt und unterschrieben |
Das Nachweispaket ist der Teil, den man am liebsten zuletzt macht und der im Ernstfall zuerst gebraucht wird. Es muss nicht schön sein: fünf bis zehn Seiten, die beschreiben, welche Systeme betrieben werden, welche Schutzmaßnahmen mit welcher Begründung gewählt wurden, wie deren Wirksamkeit geprüft wurde und wer verantwortlich ist. Einen breiteren Überblick über alle Fristen und Pflichten der Verordnung geben wir im EU AI Act 2026 im Überblick.
Wer heute noch gar kein Bildmodell betreibt, sollte die Reihenfolge umdrehen: erst die Schutzschichten und die Adapter-Governance konzipieren, dann in Betrieb nehmen. Nachrüsten ist in dieser Disziplin messbar teurer als von Anfang an mitbauen.
Quellen & Primärbelege
Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.
- Europäische Kommission – Regulatory framework on AI Inkrafttreten der Verordnung (EU) 2026/1744 am 27.07.2026, Zuständigkeit von AI Office und Mitgliedstaaten seit 02.08.2026
- Europäische Kommission – Regulierungsrahmen für KI (deutsche Fassung) Wortlaut des neunten Verbots und Geltungsbeginn „Dezember 2026"
- EP Legislative Observatory – Verfahren 2025/0359(COD) Verfahrensakte Digital Omnibus on AI: COM(2025)0836, Trilog 07.05.2026, Plenum 16.06.2026, Veröffentlichung 24.07.2026
- Europäisches Parlament – Legislative Train: Digital Omnibus on AI Beschreibung des neuen Verbotstatbestands und der verschobenen Hochrisiko-Fristen
- AI Act, Artikel 99 – Sanktionen Bußgeldrahmen Abs. 3 (35 Mio. EUR / 7 %) und Abs. 4 (15 Mio. EUR / 3 %)
- AI Act, Artikel 79 – Verfahren bei Systemen mit Risiko Korrekturmaßnahmen innerhalb des kürzeren Zeitraums von 15 Arbeitstagen
- AI Act, Artikel 5 – Verbotene Praktiken Anknüpfung an Inverkehrbringen, Inbetriebnahme und Verwendung; acht ursprüngliche Verbote seit 02.02.2025
- AI Act Implementation Timeline Stichtage 02.08.2026, 02.12.2026, 02.12.2027 und 02.08.2028
- EUR-Lex – Verordnung (EU) 2026/1744 (OJ L, 24.7.2026) Amtsblatt-Volltext; maßgeblich für den exakten Geltungsbeginn des neunten Verbots
Häufig gestellte Fragen zum Nudifier-Verbot
Gilt das auch für rein interne Bildgeneratoren?
Ja. Der Verbotstatbestand knüpft nicht an Öffentlichkeit an, sondern an das System und daran, ob entsprechende Ausgaben vorhersehbar und reproduzierbar sind.
Reicht ein NSFW-Filter auf dem Output?
In der Regel nicht. Angemessen ist eine mehrstufige Schutzschicht aus Prompt-Filter, Gesichtsähnlichkeitssperre und Output-Klassifikation, dokumentiert mit Testfällen.
Wie hoch sind die Bußgelder?
Verstöße gegen Art. 5 AI Act liegen in der höchsten Stufe: bis zu 35 Mio. Euro oder 7 Prozent des weltweiten Jahresumsatzes.
Ab wann muss das stehen?
Die beiden neuen Verbote gelten ab dem 2. Dezember 2026. Der Umbau der Pipeline und die Nachweisdokumentation sollten deutlich vorher abgeschlossen sein.
Bildmodell-Pipeline vor Dezember absichern
Wir inventarisieren Ihre Bild- und Videomodelle, bauen die Schutzschichten in Ihre Pipeline und übergeben ein prüffähiges Nachweispaket – On-Premise, DSGVO-konform, in 6 bis 8 Wochen.