Seit mehr als zwei Jahrzehnten arbeite ich an der Schnittstelle von Produktarchitektur, regulatorischer Governance und Go-to-Market in regulierten europäischen Märkten. Ich habe früh an der Entstehung und operativen Interpretation der ersten deutschen KRITIS-Regulierungen mitgewirkt und begleite seither Unternehmen beim strukturierten Markteintritt in Deutschland und Europa – dort, wo Technologie auf Haftungsrealität trifft. Was ich in diesem Artikel beschreibe, ist keine Theorie. Es sind Muster, die ich wiederholt am Verhandlungstisch erlebt habe.
Es ist nicht die Technologie, die scheitert
Ein israelisches Cybersecurity-Unternehmen. Starkes Produkt. Solide Architektur. Referenzkunden aus dem US-amerikanischen und britischen Markt. Seed-Finanzierung abgeschlossen, Series A in Vorbereitung. Und ein vielversprechendes Gespräch mit einem deutschen Energieversorger – einem der größten in Europa. Ich saß als externer Berater mit am Tisch.
Das Gespräch lief gut. Die Technologie überzeugte. Die Demo war stark. Und dann stellte jemand aus der Rechtsabteilung eine Frage, die niemand im Raum erwartet hatte: „Können Sie uns zeigen, wie das System dokumentiert, wer welche Entscheidung autorisiert hat – und was bei einem Audit gegenüber der Bundesnetzagentur nachgewiesen werden kann?“ Stille. Und dann der Satz, der Deals beendet, bevor sie beginnen: „Das ist bei uns aktuell nicht vorgesehen, aber wir können das nachrüsten.“ Es gab keine zweite Einladung.
Das Produkt war stark. Die Entscheidungslogik war es nicht – zumindest nicht in der Form, die ein regulierter deutscher Betreiber rechtlich verantworten kann. Keine Genehmigungsworkflows. Keine Rollentrennungen. Kein dokumentierter Pfad von der KI-Empfehlung zur menschlichen Freigabe. Technisch lösbar? Ja. Aber zu diesem Zeitpunkt war es zu spät.
Das ist kein Einzelfall. Es ist ein Muster – und es wiederholt sich mit beunruhigender Regelmäßigkeit, wenn israelische Tech-Unternehmen den deutschen Markt mit der gleichen Direktheit angehen, die sie im Silicon Valley oder in Tel Aviv erfolgreich gemacht hat. Ich habe es mehr als einmal erlebt.
Die israelische Mentalität – eine Stärke mit einem blinden Fleck
Um zu verstehen, warum dieses Muster so persistent ist, muss man ehrlich über kulturelle Unterschiede sprechen. Nicht wertend. Aber klar.
Die israelische Tech-Kultur ist geprägt von Geschwindigkeit, Pragmatismus und einer tiefen Überzeugung, dass gute Technologie sich selbst verkauft. „Ship fast, iterate faster“ – dieser Ansatz hat Israel zu einer der produktivsten Startup-Nationen der Welt gemacht. Er hat Unicorns hervorgebracht. Er hat Märkte disrupted. Und er funktioniert hervorragend in Umgebungen, in denen Geschwindigkeit belohnt wird und Regulierung als nachgelagerte Compliance-Aufgabe gilt.
Deutschland ist eine andere Umgebung. Hier gilt: Wer nicht von Anfang an im regulatorischen Rahmen denkt, denkt nicht für diesen Markt. Das ist keine Kritik an israelischer Innovationskraft – im Gegenteil. Es ist eine Einladung, eine vorhandene Stärke um eine neue Dimension zu erweitern.
Die konkrete Manifestation dieses blinden Flecks zeigt sich immer wieder in denselben Momenten: Ein israelischer Gründer erklärt in einer Verhandlung, dass das System „natürlich DSGVO-konform“ sei – ohne zu wissen, dass ein deutsches Unternehmen im KRITIS-Bereich nicht nur DSGVO-Konformität benötigt, sondern zusätzlich BSI-Grundschutz-Nachweise, NIS2-Meldepflichten und eine dokumentierte Business-Continuity-Architektur, die im Ernstfall vor Gericht standhält.
Oder: Ein CTO erklärt, dass das Produkt „offline-fähig“ sei – und meint damit, dass es auch ohne Internetverbindung läuft. Was der deutsche KRITIS-Betreiber aber hören will, ist: vollständige Datensouveränität, keine externen API-Calls, keine Cloud-Abhängigkeiten, keine Datenabflüsse in Drittländer – dokumentiert, geprüft, auditiert.
Dasselbe Wort. Zwei völlig verschiedene Bedeutungsräume. Diese Lücke ist lösbar. Aber man muss sie zuerst erkennen – und zwar bevor man im Raum sitzt.
Deutschland: Der härteste Markt – und deshalb der wertvollste
Deutschland ist kein Markt wie jeder andere. Es ist der regulatorisch anspruchsvollste Markt in Europa – und genau das macht ihn so wertvoll. Ein Produkt, das hier unter den Bedingungen von BSI IT-Grundschutz, NIS2 und KRITIS-Regulierung erfolgreich zertifiziert und betrieben wird, hat einen Vertrauensvorsprung, den kein Marketing ersetzen kann.
Und hier kommt ein Punkt, den viele unterschätzen: In keinem anderen europäischen Markt ist persönliche Organhaftung so real wie in Deutschland. Vorstände, Geschäftsführer und leitende Sicherheitsverantwortliche haften persönlich für Entscheidungen, die sie im Zusammenhang mit kritischen Systemen treffen – auch wenn diese Entscheidungen durch ein technisches System vorbereitet oder unterstützt wurden. Das verändert die Einkaufsdynamik fundamental. Kein CISO in Deutschland kauft ein System, das ihn persönlich exponiert. Keiner.
Der Umkehrschluss ist genauso wahr: Wer in Deutschland scheitert, scheitert oft still. Niemand sagt „Ihr Produkt ist schlecht.“ Man sagt: „Wir haben uns anders entschieden.“ Und geht nicht mehr ans Telefon.
Wer Deutschland überspringt, erklärt sich selbst zum Nischenanbieter – oder erlebt dieselben regulatorischen Anforderungen später, unter schlechteren Bedingungen, in einem anderen europäischen Markt.
NIS2, KRITIS und BSI: Was das in der Praxis bedeutet
Mit der Verschärfung der deutschen KRITIS-Regulierung, der Umsetzung der NIS2-Richtlinie und den Anforderungen des BSIG §8a haben sich die Pflichten für Betreiber kritischer Infrastrukturen und ihre Technologielieferanten fundamental verändert. §8a BSIG verpflichtet KRITIS-Betreiber, angemessene organisatorische und technische Vorkehrungen zu treffen – und diese alle zwei Jahre durch Audits, Prüfungen oder Zertifizierungen nachzuweisen. Was das für Technologieanbieter bedeutet: Ihr Produkt muss diese Nachweiskette unterstützen. Es muss in die Audit-Logik des Betreibers integrierbar sein. Und es muss dokumentieren, was es tut – nicht nur was es kann.
Die typischen Dealbreaker in deutschen Vergabeprozessen sind kein nachweisbares Change-Management nach IT-Grundschutz, kein dokumentiertes Rollen- und Rechtekonzept, keine Klarheit über Datenlokalisierung und EU-Cloud-Konformität, kein Human-in-the-Loop bei autonomen Systemaktionen, keine dokumentierten Tests unter Stressbedingungen und kein Notfallkonzept, das den Anforderungen des Betreibers entspricht. Einzeln betrachtet wirken diese Punkte technisch lösbar. Zusammen sind sie ein Showstopper – und sie kommen selten einzeln.
Ein Anbieter von KI-gestützter Anomalieerkennung für industrielle Steuerungssysteme – technisch exzellent, mit nachweisbaren Erkennungsraten weit über dem Marktstandard – scheiterte im Vergabeprozess eines deutschen Wasserversorgers nicht an der Technologie, sondern an einer einzigen fehlenden Anforderung: Es gab kein dokumentiertes Verfahren dafür, wie das System auf einen False Positive reagiert, der zu einer automatischen Systemabschaltung führen könnte. Der Betreiber hätte haftungsrechtlich nicht erklären können, warum ein Algorithmus eine Entscheidung getroffen hat, die den Betrieb unterbricht. Das Unternehmen arbeitet heute daran, diese Lücke zu schließen. Der Auftrag ging an einen Wettbewerber.
Der regulatorische Rahmen im Überblick – sechs Anker, die zählen
Für israelische Tech-Unternehmen ist es hilfreich, den deutschen und europäischen Regulierungsrahmen nicht als diffuse Bürokratie zu verstehen, sondern als sechs konkrete Anker, an denen jede Produktarchitektur gemessen wird.
BSI-Gesetz / §8a BSIG verpflichtet KRITIS-Betreiber, angemessene organisatorische und technische Vorkehrungen zu treffen – und diese alle zwei Jahre durch Audits, Prüfungen oder Zertifizierungen gegenüber dem BSI nachzuweisen. Es reicht nicht, sicher zu sein. Es muss nachweisbar sicher sein.
BSI IT-Grundschutz ist das operative Rückgrat der deutschen Informationssicherheit. Er definiert nicht nur technische Maßnahmen, sondern auch Prozesse, Rollen, Verantwortlichkeiten und Dokumentationspflichten. Wer als Anbieter in einem KRITIS-Umfeld tätig werden will, muss zeigen, dass sein Produkt diese Prozesse unterstützt – nicht stört.
NIS2 erweitert den Kreis der betroffenen Unternehmen erheblich und verschärft Melde- und Nachweispflichten. Für Technologieanbieter bedeutet das: Auch wenn sie selbst nicht als kritische Infrastruktur gelten, sind sie Teil der Lieferkette eines Unternehmens, das es ist. Und diese Lieferkette wird geprüft.
KRITIS-Dachgesetz (seit 2025) ist die sektorübergreifende Neuregelung des Schutzes kritischer Anlagen in Deutschland und löst die alte KRITIS-Verordnung strukturell ab. Es erweitert den betroffenen Kreis, verschärft Meldepflichten und führt einheitliche Mindeststandards für physische und digitale Sicherheit ein. Für Technologieanbieter bedeutet das: Wer bisher nur sektoral gedacht hat – etwa ausschließlich Energie oder Wasser – muss jetzt sektorübergreifend denken. Das Dachgesetz schafft eine gemeinsame Anforderungslogik, die in Vergabeprozessen zunehmend als Referenz genannt wird.
BSI C5 – Cloud Computing Compliance Controls Catalogue ist für jedes Produkt mit Cloud-Komponente faktisch nicht mehr optional. Der C5-Testat ist in regulierten deutschen Umgebungen zur informellen Eintrittsvoraussetzung geworden – nicht weil er gesetzlich vorgeschrieben ist, sondern weil Einkäufer ihn als Nachweis akzeptieren und Alternativen erklärungsbedürftig sind. Wer eine Cloud-Architektur betreibt und keinen C5-Nachweis vorlegen kann, muss in jeder Verhandlung dasselbe erklären: warum nicht. Das kostet Vertrauen – noch bevor die eigentliche technische Diskussion beginnt.
EU AI Act – Hochrisiko-Systeme nach Anhang III der Verordnung: Wer KI in sicherheitsrelevanten oder infrastrukturkritischen Kontexten einsetzt, ist mit hoher Wahrscheinlichkeit im Hochrisiko-Bereich. Das bedeutet verpflichtende Konformitätsbewertung, Risikomanagementsystem über den gesamten Lebenszyklus nach Artikel 9, Transparenz und Nachvollziehbarkeit nach Artikel 13, menschliche Aufsicht als technisches Designprinzip nach Artikel 14 und vollständige technische Dokumentation nach Artikel 17.
Diese sechs Anker sind keine Checkliste. Sie sind die Koordinaten, an denen jede Kaufentscheidung in regulierten deutschen Umgebungen ausgerichtet wird.
Haftung ist nicht delegierbar – und das ist keine Floskel
In Deutschland kann Verantwortung nicht an eine KI, an einen Algorithmus oder an einen externen Anbieter abgegeben werden. Jede systemgestützte Entscheidung – insbesondere in kritischen oder irreversiblen Situationen – muss durch einen Menschen verantwortet, dokumentiert und im Zweifelsfall vor einer Aufsichtsbehörde oder einem Gericht verteidigt werden können.
Wenn ein automatisiertes System in einem deutschen Krankenhaus eine Dosierungsempfehlung ausspricht und diese Empfehlung falsch ist – wer haftet? Wenn ein KI-gestütztes System in einem Energienetz einen Schaltvorgang empfiehlt und dieser Schaltvorgang zu einem Ausfall führt – wer trägt die Verantwortung? Die Antwort des deutschen Rechtssystems ist eindeutig: der Mensch, der die Entscheidung getroffen oder freigegeben hat. Und dieser Mensch muss nachweisen können, dass er nicht blind dem System gefolgt ist, sondern eine informierte, dokumentierte Entscheidung getroffen hat.
Was das für Systeme bedeutet: Sie müssen technisch so gestaltet sein, dass dieser Nachweispfad existiert und nicht umgangen werden kann. Ein Vier-Augen-Prinzip, das nur in der Prozessdokumentation steht, genügt nicht. Ein Genehmigungsworkflow, der unter Zeitdruck übersprungen werden kann, genügt nicht. Eine Audit-Log-Funktion, die nur auf Nachfrage aktiviert wird, genügt nicht.
Ein fehlender Genehmigungsworkflow kostet in Deutschland nicht Zeit. Er kostet Vertrauen – und damit den Deal. Manchmal kostet er mehr: nämlich die Marktzulassung überhaupt.
Was das architektonisch bedeutet – konkret
Regulatorische Anforderungen sind keine abstrakten Rechtsfragen. Sie haben direkte, konkrete Implikationen für die Systemarchitektur. Und genau hier liegt die eigentliche Herausforderung für viele Anbieter: nicht das Verstehen der Normen, sondern die Übersetzung in technische Designentscheidungen.
Nachvollziehbare Entscheidungslogik bedeutet, dass das System dokumentieren kann, auf welcher Datenbasis und nach welchem Regelwerk eine Empfehlung oder Aktion entstanden ist. Nicht für den Entwickler. Für den Auditor.
Audit-fähige Logs sind nicht dasselbe wie System-Logs. Sie müssen unveränderbar, vollständig, strukturiert und über definierte Zeiträume archiviert sein – nach Maßstäben, die eine Aufsichtsbehörde als Nachweis akzeptiert.
Rollen- und Rechtekonzepte müssen technisch erzwungen sein. Ein System, das theoretisch Rollentrennung unterstützt, aber praktisch von jedem Administrator umgangen werden kann, erfüllt die Anforderung nicht.
Human-in-the-Loop ist kein UX-Feature. Es ist ein Architekturprinzip. Für irreversible oder hochrelevante Aktionen muss das System eine menschliche Freigabe nicht nur ermöglichen, sondern erzwingen – mit Dokumentation, wer freigegeben hat, wann, und auf welcher Informationsbasis.
Change-Management-Dokumentation bedeutet, dass jede Änderung am System – Software-Updates, Konfigurationsänderungen, Modell-Updates bei KI-Systemen – nachvollziehbar, genehmigt und dokumentiert ist. In einer regulierten Umgebung ist ein undokumentiertes Update ein Sicherheitsvorfall.
Wer diese fünf Punkte in der Architektur verankert hat, bevor er den ersten deutschen Kunden anspricht, spricht eine andere Sprache. Wer sie nachrüsten muss, verliert Zeit, Glaubwürdigkeit – und meist den Auftrag.
KI-Entscheidungslogik und der EU AI Act: Das neue Spielfeld
„Wo endet die Maschine – und wo beginnt die menschliche Entscheidungsverantwortung?“
Das ist nicht nur eine technische Frage. Es ist die zentrale Compliance-Frage für jedes KI-System, das in einer regulierten europäischen Umgebung betrieben werden soll. Und mit dem EU AI Act hat diese Frage eine neue rechtliche Qualität bekommen.
Dabei ist die Unterscheidung zwischen assistierender KI und agentischer KI entscheidend und wird von vielen Anbietern noch immer unterschätzt. Ein System, das Anomalien erkennt und dem Operator anzeigt, wird nach EU AI Act anders bewertet als eines, das auf Basis dieser Erkennung selbstständig Aktionen auslöst – auch wenn die Auslösung innerhalb eines definierten Regelwerks erfolgt. Bei agentischen Systemen, die eigenständig im digitalen oder physischen Raum handeln, gelten deutlich höhere Anforderungen an Kontrollierbarkeit, Unterbrechbarkeit und – für irreversible Aktionen – ein technisch erzwungenes Vier-Augen-Prinzip, das nicht durch Benutzerfreundlichkeit oder Zeitdruck ausgehebelt werden kann.
Ein konkretes Beispiel: Ein israelisches Unternehmen mit einem KI-gestützten Sicherheitssystem für Industrieumgebungen befand sich in fortgeschrittenen Gesprächen mit einem deutschen Automobilhersteller. Das System war in der Lage, auf erkannte Bedrohungen automatisch zu reagieren – Netzwerksegmentierung, Prozessunterbrechung, Isolierung betroffener Systeme. Technisch beeindruckend. Regulatorisch problematisch. Die Frage, wie das System mit einem False Positive umgeht, der zur Unterbrechung einer Produktionslinie führt, war nicht beantwortet. Und die Frage, ob ein Mensch diese automatische Reaktion hätte verhindern können – in welchem Zeitfenster und mit welcher Dokumentation – ebenfalls nicht. Der Deal wurde nicht abgeschlossen. Das System war zu autonom für einen Markt, in dem Autonomie ohne Kontrollierbarkeit keine Tugend ist, sondern ein Haftungsrisiko.
Die Investor-Perspektive: Regulatorische Reife als Bewertungs- und Multiplikator-Faktor
Europäische Investoren – insbesondere solche mit Portfoliounternehmen in regulierten Märkten – schauen im Due-Diligence-Prozess zunehmend auf regulatorische Reife. Nicht nur als Risikominimierung, sondern als Indikator für Marktreife insgesamt.
Die Fragen, die dabei gestellt werden, sind konkret: Gibt es eine dokumentierte Compliance-Roadmap für den deutschen und europäischen Markt? Ist ein Datenschutzbeauftragter benannt? Liegt eine Einschätzung der Risikoklassifizierung nach EU AI Act vor? Sind die Kernarchitekturentscheidungen – Datenlokalisierung, Entscheidungslogik, Human-in-the-Loop – bereits getroffen und dokumentiert? Und: Wie lange würde es dauern, das Produkt in einem regulierten deutschen Umfeld einzusetzen?
Die finanziellen Implikationen sind direkt und messbar. Regulatorische Reife verkürzt den Due-Diligence-Prozess erheblich. Sie reduziert Escrow-Anforderungen und Risikorückstellungen, die Investoren für regulatorische Ungewissheiten einpreisen. Sie erhöht den Multiplikator bei der Bewertung, weil europäische Expansion nicht mehr als Risikoszenario, sondern als eingepreiste Möglichkeit gilt. Und sie verändert die Verhandlungsposition in einer Series B fundamental: Ein Unternehmen, das nachweisen kann, dass es in einem der anspruchsvollsten regulierten Märkte der Welt deployed werden kann, ist kein Versprechen mehr – es ist ein Faktum.
Umgekehrt: Ein Unternehmen, das auf regulatorische Due-Diligence-Fragen mit „das klären wir dann“ antwortet, signalisiert ungewollt, dass der europäische Markteintritt noch Jahre entfernt ist. Das verändert die Risikoklasse der Investition – und damit die Bewertung.
Frühe regulatorische Architektur senkt nicht nur Audit-Kosten. Sie ist ein Re-Risking-Instrument für Investoren, ein Beschleuniger für Enterprise-Verkaufszyklen und ein Differenzierungsmerkmal in einem Markt, in dem technische Parität zunehmend die Norm ist. Wer sie früh etabliert, verhandelt anders. Und wird anders bewertet.
Es funktioniert – wenn man es ernst nimmt
Bisher haben wir beschrieben, was schiefgeht. Das ist wichtig. Aber es wäre unehrlich, nicht auch zu beschreiben, was funktioniert – denn es funktioniert.
Ein israelisches Unternehmen im Bereich industrieller Netzwerksicherheit entschied sich früh, den deutschen Markt nicht als Verkaufsprojekt zu behandeln, sondern als Architekturprojekt. Bevor der erste deutsche Kundentermin stattfand, wurde eine externe Readiness-Analyse durchgeführt. Das Ergebnis: drei kritische Lücken – keine vollständige Offline-Fähigkeit, kein dokumentiertes False-Positive-Handling, kein rollenbasiertes Freigabeprinzip für kritische Aktionen.
Diese drei Lücken wurden in der Architektur geschlossen. Nicht als Feature-Update, sondern als Designänderung. Der Prozess dauerte vier Monate und war intern umstritten – zu langsam, zu teuer, zu bürokratisch, so die Kritik.
Achtzehn Monate später war das Unternehmen in zwei deutschen KRITIS-Umgebungen produktiv deployed. Es war der erste Enterprise-Abschluss in Europa. Die Vertriebszeit vom ersten Kontakt bis zur Vertragsunterzeichnung betrug elf Monate – kurz für diesen Markt. Und der Grund, warum der Prozess nicht länger dauerte: Die regulatorischen Fragen waren bereits beantwortet, bevor sie gestellt wurden.
Die vier Monate Vorlaufzeit hatten nicht verzögert. Sie hatten beschleunigt.
Das ist kein Einzelfall. Es ist die andere Seite desselben Musters: Wer regulatorische Architektur als Investition behandelt, erntet sie als Wettbewerbsvorteil. Nicht irgendwann. Sondern genau dann, wenn der Wettbewerber im Raum sitzt und schweigt.
Was jetzt zu tun ist – konkret und ohne Umwege
Für israelische Tech-Unternehmen, die den deutschen Markt ernsthaft erschließen wollen, lassen sich die notwendigen Schritte auf wenige, aber konsequente Maßnahmen reduzieren.
Der erste Schritt ist eine ehrliche Bestandsaufnahme: Wo steht das Produkt heute – technisch, architektonisch, dokumentatorisch – im Vergleich zu den Anforderungen, die ein regulierter deutscher Betreiber stellen wird? Diese Analyse sollte nicht intern durchgeführt werden. Sie sollte von jemandem durchgeführt werden, der die Anforderungen aus echten deutschen Vergabeprozessen kennt – nicht aus Compliance-Handbüchern.
Der zweite Schritt ist die Entscheidung, welche regulatorischen Anforderungen in die Kernarchitektur integriert werden – nicht als Add-on, sondern als Designprinzip. Human-in-the-Loop ist keine Feature-Flag-Entscheidung. Audit-Logging ist kein optionales Modul. Datenlokalisierung ist keine Konfigurationsoption. Diese Entscheidungen müssen in der Architektur verankert sein, bevor der erste Pilot in Deutschland beginnt.
Der dritte Schritt ist die regulatorische Positionierung: Wie wird das Produkt kommuniziert? Ein Produkt, das als „Decision-Grade AI for regulated environments“ positioniert ist, spricht eine andere Sprache als eines, das als „AI-powered security platform“ beschrieben wird. Beide könnten dasselbe Produkt sein. Aber nur eines davon landet in der richtigen Inbox – und führt zu einem zweiten Termin.
Fazit: Regulierung ist kein Filter – sie ist eine Marktstruktur
Deutschland ist kein einfacher Markt. Aber das ist präzise der Punkt.
Regulierung ist in Deutschland nicht primär ein bürokratisches Hindernis. Sie ist ein struktureller Selektionsmechanismus – und dieser Mechanismus arbeitet unabhängig von Produktqualität, Finanzierungsstärke oder Referenzen aus anderen Märkten. Er fragt eine einzige Frage: Kann dieses System in einem regulierten deutschen Umfeld betrieben werden, ohne dass die verantwortliche Person ihr Amt, ihre Reputation oder ihre persönliche Haftungsfreiheit riskiert?
Wer diese Frage beantworten kann – mit Dokumentation, mit Architektur, mit nachvollziehbarer Entscheidungslogik – hat weniger Wettbewerb. Nicht weil die anderen schlechter sind, sondern weil sie nicht antworten können.
Wer regulatorische Architektur nicht frühzeitig integriert, wird in Deutschland strukturell aussortiert – unabhängig von Produktqualität. Das ist keine Warnung. Das ist eine Marktbeschreibung.
Und genau deshalb ist die Frage für israelische Tech-Unternehmen nicht: „Müssen wir das wirklich?“ Die Frage ist: „Wollen wir in einem Markt spielen, in dem technische Exzellenz allein nicht ausreicht – und genau deshalb die Hürde für jeden gilt, der es nicht ernst nimmt?“ Wer ja sagt, hat einen Wettbewerbsvorteil, den kein Pitch-Deck erzeugt.
In Deutschland gibt es kein Später. Es gibt: strukturell qualifiziert – oder strukturell ausgeschlossen.
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar