WeLoveReal — Beschwerde & Einspruch (Digital Services Act)

Geltende Fassung. Revision R7, Stand 03.09.2026.

Anbieter: KI-Shield UG (haftungsbeschränkt), Ritterstraße 2, 99718 Greußen, Deutschland Vollständige Anbieterkennung: siehe Impressum. Kontaktstelle: info@ki-shield.de (Kommunikationssprache: Deutsch) Rechtsgrundlage: Verordnung (EU) 2022/2065 über einen Binnenmarkt für digitale Dienste (Digital Services Act, „DSA"), anwendbar seit 17.02.2024. Stand: 2026-09-03 · Version: 1.7

1. Worum es auf dieser Seite geht

WeLoveReal ist eine datensparsam konzipierte Dating-App. Der aktuelle Store-Kandidat arbeitet beim technischen Foto-Prüfpfad fail-closed: Solange die vollständige Produktionsprüfung nicht integriert und freigegeben ist, kann ein technisch nicht vollständig prüfbares Beweisbündel (NICHT_LESBAR) zwar als sichtbares Hauptfoto gespeichert werden, es entsteht aber kein neues Foto-Siegel (seal_verified=false) und kein neuer technisch verifizierter Status. Ein solches Foto macht keine Aussage über Echtheit, Lebendheit, Alter oder Identität. Als verändert bewertete Uploads (VERAENDERT) werden abgelehnt. Kontakt und Chat setzen kein Foto-Siegel voraus. Die separate 18+-Selbstauskunft ist ebenfalls kein amtlicher Alters- oder Identitätsnachweis und beweist weder Charakter noch Absichten.

Diese Seite beschreibt den geplanten Melde- und Beschwerdeprozess und benennt offen, welche Teile im lokalen Kandidaten bereits technisch vorhanden sind und welche vor einer Veröffentlichung noch fehlen:

• wie du aus Profil- oder Chatansichten derzeit das betroffene Konto meldest und warum eine stabile Nachrichtenreferenz noch fehlt (Melde- und Abhilfeverfahren, Art. 16 DSA),
• welchen Kontostatus die App derzeit anzeigen kann und welche detaillierte Begründungsfunktion noch fehlt (Art. 17 DSA),
• wie du gegen eine Moderations- oder Sperrentscheidung Einspruch einlegst — inklusive aller Fristen (internes Beschwerdeverfahren, Art. 20 DSA),
• welche weiteren Wege dir offenstehen: außergerichtliche Streitbeilegung, der Gerichtsweg und die Beschwerde bei einer Behörde,
• wie transparent wir über Moderation berichten (Art. 15 DSA).

Diese Seite ist Teil der WeLoveReal-Rechtsdokumente. Die ausführlichen Verhaltensregeln stehen in den AGB/Community-Richtlinien; welche Daten wir überhaupt verarbeiten, steht in der Datenschutzerklärung.

2. Kontaktstelle (Art. 11, 12 DSA)

Für alle Anliegen rund um Meldungen, Moderation, Einsprüche sowie für Anfragen von Behörden gibt es eine zentrale Kontaktstelle:

• E-Mail: info@ki-shield.de
• Post: KI-Shield UG (haftungsbeschränkt), Ritterstraße 2, 99718 Greußen, Deutschland
• Telefon: 0175 6486634 (schriftliche Anfragen per E-Mail werden bevorzugt)
• Kommunikationssprache: Deutsch Im lokalen Kandidaten sind ein Melde-Dialog, eine einfache Sperr-Statusanzeige und die elektronische Einreichung eines Einspruchs vorhanden. Eine automatische Eingangsbestätigung per E-Mail, eine verbindlich überwachte Zwei-Werktage-Reaktion und die Zustellung von Moderationsentscheidungen sind dagegen noch nicht implementiert.

Wichtig zur Architektur: WeLoveReal erhebt bei der App-Registrierung weder deine E-Mail-Adresse noch deine Telefonnummer. GET /v1/moderation/status liefert aktuell nur Kontostatus, Sperrende und Pausenart. Der Endpunkt liefert kein Ergebnis einer von dir abgegebenen Meldung, keinen Einspruchsstatus und keine Entscheidungsbegründung. Wenn du uns selbst per E-Mail schreibst, kann eine Antwort an die dabei verwendete Adresse erfolgen; die operative Zuordnung zu einem pseudonymen App-Vorgang muss vor Launch verbindlich geregelt und getestet werden.

3. Wie WeLoveReal moderiert (Datensparsamkeit — ehrlich erklärt)

WeLoveReal trennt unterschiedliche Datenarten und behauptet nicht pauschal, der Server könne überhaupt nichts lesen:

• Chats sind Ende-zu-Ende-verschlüsselt. Nur du und dein Match könnt sie lesen — wir nicht.
• Der Textprofil-Blob mit Anzeigename/Pseudonym, Bio und optionalen Freitextangaben wird auf dem Gerät mit dem ProfileKey verschlüsselt. Der Live-Server speichert nur Chiffrat und kann diesen Blob nicht entschlüsseln.
• Davon getrennt werden wenige Discovery-Facetten serverseitig lesbar verarbeitet: insbesondere die exakte selbst angegebene Alterszahl, eigenes und gesuchtes Geschlecht, grobe Region und Suchpräferenzen. Ein Geburtsdatum wird nicht erhoben.
• Für Store 1.0 speichert der Server zusätzlich eine versionierte 18+-Selbstauskunft: den aktiven oder widerrufenen Wahrheitswert, bei aktiver Erklärung den Zeitpunkt und die Erklärungsversion. Der Kontaktzugang wird nur abgeleitet, wenn die aktuelle Erklärung aktiv ist und die getrennte selbst angegebene Alterszahl zwischen 18 und 120 liegt. Diese Regel ist keine Alters- oder Identitätsprüfung, ändert den Foto-/Verifikationsstatus nicht und setzt kein Foto-Siegel voraus. Ein Betriebssystemsignal kann, soweit verfügbar, lokal bei der Nutzerführung helfen, ist aber kein amtlicher Nachweis und nicht die Quelle von age_self.
• Die serverseitig lesbaren Profilfoto-Renditions (Display/Thumbnail) werden mit einem Server-Schlüssel verschlüsselt „at rest" und zugriffskontrolliert ausgeliefert. Sie können je nach Auffindbarkeit nicht nur Matches, sondern auch berechtigten Personen in Discovery und Profilansicht angezeigt werden. Da der Live-Server den Schlüssel hält, hat der Betreiber technischen Zugriff; dies ist keine Ende-zu-Ende-Verschlüsselung. Die At-rest-Verschlüsselung schützt gegen den isolierten Diebstahl von Datenbank oder Backup, nicht gegen den laufenden Server. Ein sichtbares ungesiegeltes Foto macht keine Echtheits-, Lebendheits-, Alters- oder Identitätsaussage.

Was das für Meldungen bedeutet: Wir können eine einzelne Ende-zu-Ende-verschlüsselte Chat-Nachricht oder ein geteiltes Chat-Bild nicht lesen und im aktuellen Datenmodell auch nicht gezielt als konkretes Objekt löschen. Der aktuelle Meldevertrag adressiert ein Konto mit Kategorie und optionalem Safety-Team-Hinweis; er trägt keine stabile Referenz auf die konkret gemeldete Nachricht. Maßnahmen setzen daher technisch auf Konto-Ebene an. Ein Art.-16-tauglicher, hinreichend genauer Hinweisweg samt elektronischem Fundstellenbezug ist vor Launch noch rechtlich zu prüfen und technisch zu vervollständigen.

Damit wir gemeldeten Hinweisen trotzdem nachgehen können, kannst du beim Melden freiwillig einen Hinweis für das Sicherheitsteam beilegen (siehe Abschnitt 4). Wenn du diese Option aktivierst, wird genau dieser Text über HTTPS übertragen und serverseitig lesbar gespeichert, damit das Sicherheitsteam ihn prüfen kann. Die gemeldete Person erhält ihn nicht; auf den restlichen Ende-zu-Ende-verschlüsselten Chatverlauf hat das Team weiterhin keinen Zugriff.

4. Inhalte und Verhalten melden (Notice-and-Action, Art. 16 DSA)

4.1 Wer kann was melden?

Jede angemeldete Person kann aus einer Profil- oder Chat-Ansicht eine Kontomeldung absenden. Eine Verifikation ist für eine Meldung nicht nötig. Der aktuelle Backend-Vertrag speichert dabei das Zielkonto, aber noch keine stabile Referenz auf eine einzelne Nachricht; diese Lücke ist in Abschnitt 13 als Launch-Gate benannt. Das stärkere, gewichtete „Flaggen", das direkt in das automatische Sperrsystem einfließt, setzt eine aktuelle, serverseitig abgeleitete 18+-Kontaktberechtigung und einen vorherigen Kontakt mit der gemeldeten Person voraus. Als Kontakt zählt ein Match oder, sobald die Anfrage-Nachricht freigeschaltet ist, eine von der gemeldeten Person erhaltene Anfrage-Nachricht. Wer angeschrieben wurde, braucht dann also nicht erst zu antworten, um gewichtet flaggen zu können. Der Absender einer unbeantworteten Anfrage erwirbt umgekehrt kein Flag-Recht gegen die angeschriebene Person. Die Kontaktberechtigung beruht auf aktiver versionierter 18+-Selbstauskunft plus selbst angegebener Alterszahl von 18 bis 120. Sie bestätigt nur den gespeicherten Zugangsstatus und ist keine Alters-, Identitäts- oder Fotoverifikation; ein Foto-Siegel ist auch für das gewichtete Flaggen nicht erforderlich.

4.2 So meldest du

Im Melde-Dialog der App kannst du:

1. eine Kategorie wählen (z. B. Belästigung, anstößige Bilder, Betrugsverdacht, Verdacht auf Minderjährigkeit, Gewaltandrohung),
2. das betroffene Konto angeben (es ist bereits vorausgewählt, wenn du aus einem Profil oder Chat heraus meldest),
3. optional einen Hinweis für das Sicherheitsteam hinzufügen; dieser freiwillig freigegebene Text ist für die Prüfung serverseitig lesbar,
4. die Meldung absenden.

Du erhältst im Melde-Dialog eine technische Eingangsbestätigung. Die API liefert zusätzlich einen internen Zielzeitstempel; mangels produktiver SLA-Überwachung zeigt der Client ihn nicht als garantierte Bearbeitungsfrist an. Die Bestätigung belegt nur den Eingang, nicht die rechtliche Bewertung oder das Ergebnis.

Wenn die App im selben Vorgang zusätzlich ein gewichtetes Flag senden darf, übermittelt sie als Korrelationsanker ausschließlich die exakte Vorgangs-ID der soeben angelegten Meldung. Der Server akzeptiert diese Referenz nur für denselben Melder, dasselbe Ziel, eine passende Kategorie und einen offenen Vorgang. Er ergänzt den vorhandenen Report, sodass die kombinierte Nutzeraktion in genau einem offenen Queue-Fall landet. Die Referenz enthält keine Chat- oder Bildinhalte und gewährt keinen Zugriff auf fremde Meldungen.

4.3 Was nach deiner Meldung passiert

Der technische und operative Zielprozess für eine sorgfältige, nicht willkürliche Bearbeitung besteht aus:

• Einordnung der Meldung in unser gewichtetes, anonymes Punktesystem,
• priorisierter Team-Queue bei kritischen Kategorien (z. B. Verdacht auf Minderjährigkeit, Gewaltandrohung) — unabhängig vom Punktestand,
• Auswertung deines freiwillig freigegebenen Safety-Team-Hinweises, falls du einen beigelegt hast,
• gegebenenfalls einer menschlich und rechtlich geprüften Eskalation an die zuständigen Behörden bei strafrechtlich relevanten Verdachtsmomenten (siehe Abschnitt 8).

Aktueller technischer Stand: Der Server versieht normale Reports mit einer 24-Stunden-SLA; priorisierte und kritische Kategorien erhalten kürzere Warteschlangenfristen. Eine token-geschützte Team-Queue und Sperraktionen sind lokal implementiert. Es gibt jedoch noch keine produktive SLA-Überwachung/Alarmierung und kein Ergebnis einer von dir abgegebenen Meldung in der App. Die nach Art. 16 Abs. 5/6 gegebenenfalls erforderliche Mitteilung an die meldende Person ist deshalb ein Launch-Gate. Die Identität der meldenden Person wird der gemeldeten Person nicht angezeigt.

4.4 Was du selbst sofort tun kannst

Unabhängig von einer Meldung kannst du jede Person blockieren. Eine Blockierung macht dich für diese Person plattformweit unsichtbar und unterbindet jeden weiteren Kontakt. Sobald die Anfrage-Nachricht freigeschaltet ist, löscht sie zusätzlich offene Anfrage-Nachrichten in beide Richtungen. Bei akuter Gefahr wähle den Notruf 112.

Sobald die Anfrage-Nachricht freigeschaltet ist, kannst du eine Anfrage-Nachricht außerdem still ablehnen. Das Ablehnen löscht die Anfrage sofort und sendet dem Absender kein Signal: Für ihn ist Ablehnen von Ignorieren nicht unterscheidbar. Du musst dich also nicht erklären. Wer dich einmal angeschrieben hat, kann dich danach nicht erneut anschreiben, auch nicht nach Ablauf der Anfrage und auch nicht nach einer aufgehobenen Blockierung.

5. Mögliche Abhilfemaßnahmen

Weil wir Ende-zu-Ende-verschlüsselte Chat-Inhalte nicht im Klartext sehen, richten sich die vorhandenen Maßnahmen gegen das Konto bzw. das Gerät, nicht gegen einzelne Chat-Inhalte. Im aktuellen Backend sind vorhanden:

• eine reversible Schutz-Pause bei bestimmten einzelnen schweren Signalen,
• zeitlich befristete Sperren für 30 oder 90 Tage,
• eine dauerhafte, gerätegebundene Sperre,
• Schließen einer Meldung ohne Sperre und Aufheben einer Schutz-Pause.

Erst mit der Freischaltung der Anfrage-Nachricht: Die Anfrage-Nachricht zum Interesse ist vorbereitet, aber noch nicht freigeschaltet. Erst ab dem Zeitpunkt der Freischaltung kommen hinzu: das Löschen offener Anfrage-Nachrichten in beide Richtungen, sobald eine Blockierung gesetzt wird; das stille Ablehnen einer Anfrage durch die angeschriebene Person (Abschnitt 4.4); und das einseitige Flag-Recht des Empfängers einer Anfrage (Abschnitte 4.1 und 9). Bis dahin gibt es keine Anfrage-Nachrichten, und diese drei Maßnahmen können niemanden betreffen.

Grenze des Geräte-Banns: App Attest und Play Integrity sind deaktiviert. Der Geräte-Bann ist deshalb nicht hardwarefest. Seine Sperrkennung wird aus dem öffentlichen Ed25519-Geräteschlüssel abgeleitet. Bei einer Kontolöschung entfernt die App die Konto-Verknüpfung. Die Inhalts-, Profil- und Sitzungsschlüssel werden gelöscht; ausschließlich der private Ed25519-Schlüssel bleibt lokal zur Sperrumgehungsabwehr erhalten. Damit ist die Sperrkennung innerhalb derselben App-Installation stabil. Deinstallation oder Zurücksetzen können das Schlüsselmaterial jedoch entfernen oder unzugänglich machen; eine manipulierte App kann neues Material erzeugen und die Bindung umgehen beziehungsweise aushebeln. Die Maßnahme erschwert eine Neuanmeldung, ist aber keine dauerhaft stabile Identifikation eines physischen Geräts.

Eine Verwarnungsfunktion, eine frei konfigurierbare Sichtbarkeitseinschränkung und eine pauschale sofortige Sperre bei jedem einzelnen kritischen Flag sind nicht implementiert. Ein einzelnes kritisches Signal wird priorisiert menschlich geprüft; bestimmte schwere Signale können sofort eine reversible Schutz-Pause auslösen. Automatische Sperren folgen den im Backend festgelegten Schwellen bzw. der Bestätigung durch mehrere unabhängige kritische Meldungen.

Die genaue Gewichtung von Meldungen (leicht / schwer / kritisch), die Berücksichtigung der Verlässlichkeit der meldenden Person und die Eskalationsstufen sind in den AGB/Community-Richtlinien beschrieben. Maßgeblich und veröffentlicht ist stets der tatsächlich angewandte Maßstab.

6. Begründung bei einer Einschränkung deines Kontos (Art. 17 DSA)

Der aktuelle Kandidat zeigt im Konto- und Moderationsbereich lediglich:

• den Kontostatus (active, paused, befristet oder dauerhaft gesperrt),
• bei einer befristeten Sperre das Enddatum,
• ob eine Pause freiwillig oder als reversible Schutz-Pause gesetzt wurde,
• den Zugang zum Einspruchsformular bei einer Sperre.

Er liefert keine detaillierte Art.-17-Begründung, insbesondere keine kategorisierte Entscheidungsgrundlage, keine Kennzeichnung „automatisiert/menschlich", keine Regelreferenz und keine fallbezogenen Rechtsbehelfshinweise. Auch eine über die Sperrdauer hinaus abrufbare Begründungshistorie existiert nicht. Eine fallbezogene Begründung und deren Zustellung sind daher Launch-Gates. Bis diese Funktion vorhanden und getestet ist, darf der Kandidat nicht mit einer bereits verfügbaren Art.-17-Begründung werben.

7. Einspruch gegen eine Moderations- oder Sperrentscheidung (internes Beschwerdeverfahren, Art. 20 DSA)

Da Sperren automatisiert oder durch eine Team-Aktion ausgelöst werden können, ist ein Einspruchsweg ein wichtiger Schutz. Auch wenn dein Konto gesperrt ist, kannst du im aktuellen Kandidaten einen Einspruch einreichen.

7.1 So legst du Einspruch ein

• In der App: über die Einspruchs-Funktion in der Sperr-Statusanzeige. Du wirst über dein gerätegebundenes Schlüsselpaar authentifiziert — ein Login mit persönlichen Daten ist nicht nötig. Deine Begründung wird über HTTPS übertragen und serverseitig lesbar gespeichert, damit eine geschulte Person sie prüfen kann; sie wird mit einer Vorgangsnummer quittiert und nur für das Beschwerdeverfahren verwendet.
• Alternativ per E-Mail: an info@ki-shield.de, falls du keinen Zugriff mehr auf die App-Funktion hast. Die operative Zuordnung einer E-Mail zu einem pseudonymen App-Konto ist noch als Launch-Gate zu definieren; private Schlüssel oder Geheimnisse dürfen niemals per E-Mail versandt werden.

7.2 Wie wir entscheiden

• Das Backend stellt eine token-geschützte Einspruchs-Queue und Entscheidungsaktionen für das Sicherheitsteam bereit. Damit ist eine menschliche Prüfung technisch möglich; Personal, Rollen, Vier-Augen-Regel, Schulung und Betriebsprozess sind vor Launch organisatorisch festzulegen und nachzuweisen.
• Mögliche Ergebnisse:
  • Sperre bestätigt: Die Maßnahme bleibt bestehen; das Backend markiert den Einspruch als upheld.
  • Sperre aufgehoben: Das Backend markiert den Einspruch als overturned, entsperrt Konto und Geräte-Bann und setzt eine technische Baseline gegen sofortige Wiederholung durch dieselben Alt-Flags. Die Gewichte zugehöriger Melder werden herabgesetzt.
• Mitteilung: Der Nutzer-Client kann den Status oder das Ergebnis eines Einspruchs derzeit nicht abrufen. Er erhält nur bei der Einreichung eine Vorgangsnummer. Eine begründete Ergebniszustellung in der App ist ein Launch-Gate.
• Dokumentation: Einspruch und Entscheidung werden pseudonym zum App-Konto sowie zusätzlich als gehashtes Audit-Ereignis protokolliert. Eine vollständige Transparenzbericht-Pipeline existiert noch nicht.

7.3 Fristen im Überblick

Die Backend-SLA für Reports ist ein Zeitstempel, keine automatische Fristüberwachung. Die hier genannten Reaktionsziele sind deshalb vor Launch operativ abzusichern; sie sind im aktuellen Store-Kandidaten noch keine technisch überwachten Service-Level.

8. Schwerwiegende und strafrechtlich relevante Meldungen (Art. 18 DSA)

Bei einem konkreten Verdacht auf eine Straftat, die eine Gefahr für das Leben oder die Sicherheit von Personen begründet — etwa Darstellungen sexuellen Missbrauchs von Kindern oder eine konkrete Gewaltandrohung — ist eine rechtliche und menschliche Einzelfallprüfung erforderlich. Ein bloßer Altersverdacht ist nicht automatisch mit diesem Straftatbestand gleichzusetzen.

Der aktuelle technische Stand:

1. Das Backend legt kritische Meldungen in eine priorisierte Krisen-Queue. Bestimmte einzelne schwere Signale lösen eine reversible Schutz-Pause aus; eine gerätegebundene Sperre entsteht nicht pauschal bei jedem einzelnen kritischen Flag.
2. Vorhandene technische Daten sind auf Zeitstempel, pseudonyme Kennungen, Kategorie und einen etwaigen freiwillig freigegebenen Hinweis begrenzt. Ende-zu-Ende-verschlüsselte Chat- und Bildinhalte stehen dem Betreiber nicht zur Verfügung; serverseitig lesbare Profilfoto-Renditions sind davon zu unterscheiden.
3. Eine Meldung an zuständige Strafverfolgungs- oder Justizbehörden kann nur nach rechtlicher und menschlicher Prüfung erfolgen. Ein automatischer Behörden-Übermittlungsweg ist nicht implementiert.
4. Die App weist bei akuter Gefahr auf den Notruf 112 hin.

Ein interner Krisen- und Eskalationsentwurf ist dokumentiert. Rufbereitschaft, Entscheidungsbefugnis, rechtliche Prüfung, Behördenkontakt und Protokollierung sind vor Launch als tatsächlich gelebter Prozess einzurichten und zu testen.

9. Schutz vor Missbrauch des Meldesystems

Das Meldesystem ist gegen Missbrauch (z. B. koordinierte Falschmeldungen, „Flag-Mobs", Racheaktionen) abgesichert:

• Gewichtete Flags, die unmittelbar in Sperren einfließen, können nur Personen mit aktueller, serverseitig abgeleiteter 18+-Kontaktberechtigung und nur gegenüber Personen mit nachgewiesenem Kontakt abgeben. Nachgewiesener Kontakt ist ein Match oder, sobald die Anfrage-Nachricht freigeschaltet ist, eine erhaltene Anfrage-Nachricht; das Recht ist bewusst einseitig, damit gerade der unerwünschte Erstkontakt meldbar bleibt. Die Kontaktberechtigung beruht auf Selbstauskunft plus plausibler eigener Altersangabe und bestätigt weder tatsächliche Volljährigkeit noch Identität oder Foto-Echtheit; ein Foto-Siegel ist dafür nicht erforderlich;
• pro Personenpaar ist nur eine solche Wertung möglich;
• Massenanschreiben werden zusätzlich mengenmäßig begrenzt, sobald die Anfrage-Nachricht freigeschaltet ist: je Konto höchstens 50 Kaltkontakte lebenslang und ein unentgeltliches Kontingent von 300 gesendeten Nachrichten; ohne Antwort ist dann kein Nachfassen möglich. Diese Grenzen gelten auch mit einem aktiven Abonnement. Bis zur Freischaltung greift keine dieser Mengengrenzen;
• die Moderations-Endpunkte sind zusätzlich durch technische Ratenlimits und Größenlimits je Verbindungsquelle und, soweit mitgeführt, pseudonymer Kontokennung geschützt;
• kritische Kategorien werden unabhängig vom Punktestand priorisiert geprüft;
• wird eine Sperre im Einspruchsverfahren aufgehoben, reduziert das Backend die künftige Gewichtung der zugehörigen Melder. Eine allgemeine automatische Erkennung „wiederholt grundloser" Meldungen außerhalb dieses Einspruchspfads existiert nicht.

Wir bitten dich, das Meldesystem verantwortungsvoll zu nutzen. Missbräuchliche oder offensichtlich unbegründete Meldungen können ihrerseits Maßnahmen nach sich ziehen.

10. Außergerichtliche Streitbeilegung und Gerichtsweg

• Interner Einspruch zuerst: Bitte nutze zunächst das Einspruchsverfahren (Abschnitt 7) — das ist meist der schnellste Weg.
• Außergerichtliche Streitbeilegung (Art. 21 DSA): Ob und in welchem Umfang dieser Weg eröffnet werden muss, hängt von der konkreten Dienste- und Unternehmensklassifizierung ab. Soweit Art. 21 DSA anwendbar ist, können adressierte Nutzer eine zertifizierte Streitbeilegungsstelle wählen; nähere Informationen müssen dann leicht zugänglich in der App bereitstehen.
• Gerichtlicher Rechtsweg: Unabhängig von allen vorgenannten Verfahren steht dir jederzeit der ordentliche Rechtsweg offen. Gegenüber Verbraucherinnen und Verbrauchern gelten die gesetzlichen Gerichtsstände.
• Verbraucherschlichtung (§ 36 VSBG): Wir sind nicht bereit und nicht verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen.

11. Beschwerde bei einer Behörde

Du kannst dich auch an die zuständigen Aufsichtsbehörden wenden:

• Digitale-Dienste-Aufsicht (DSA): Koordinierungsstelle für digitale Dienste bei der Bundesnetzagentur, Tulpenfeld 4, 53113 Bonn. Für Jugendschutzfragen ist zusätzlich die Bundeszentrale für Kinder- und Jugendmedienschutz (BzKJ) zuständig.
• Datenschutz: Da unser Sitz in Thüringen liegt, ist der Thüringer Landesbeauftragte für den Datenschutz und die Informationsfreiheit (TLfDI), Häßlerstraße 8, 99096 Erfurt, zuständig. Du kannst dich grundsätzlich auch an die Datenschutz-Aufsichtsbehörde deines Wohnsitzes wenden.

12. Transparenz über Moderation (Art. 15 DSA)

Im aktuellen Kandidaten gibt es noch keinen veröffentlichten Moderations-Transparenzbericht und keine fertige Export-/Aggregationsfunktion für einen solchen Bericht. Ob eine gesetzliche Berichtspflicht oder eine Ausnahme für Kleinst-/Kleinunternehmen greift, richtet sich nach der tatsächlichen Unternehmens- und Diensteeinordnung.

Ein späterer freiwilliger Bericht könnte ausschließlich belastbar erhobene, anonyme Gesamtzahlen enthalten, insbesondere:

• Zahl der eingegangenen Meldungen (nach Kategorie),
• Zahl der automatischen Sperren (befristet / dauerhaft),
• Zahl der Einsprüche und deren Ausgang (bestätigt / aufgehoben),
• Zahl der Meldungen an Strafverfolgungs- bzw. Justizbehörden.

Eine Veröffentlichung darf erst zugesagt werden, wenn Erhebung, Anonymisierung, Freigabeprozess und Veröffentlichungsort implementiert sind.

13. Einordnung, Geltung und Launch-Gates

Die Anwendbarkeit der abgestuften Pflichten und möglicher Kleinst-/Kleinunternehmens-Ausnahmen richtet sich nach der genauen Einordnung von WeLoveReal als Vermittlungsdienst oder Hosting-Dienst/Online-Plattform. Die folgenden Punkte bleiben unabhängig von der abschließenden Rechtsklassifizierung Produkt- und Freigabe-Gates:

1. präziser, nutzerfreundlicher Meldeweg mit belastbarer Referenz auf den konkret beanstandeten Inhalt, soweit rechtlich erforderlich;
2. Mitteilung der Entscheidung an die meldende Person, einschließlich Rechtsbehelfen;
3. fallbezogene Art.-17-Begründung mit Maßnahme, Grund, Regelbezug, Automatisierungs-/Menschenhinweis und Rechtsbehelfen;
4. nutzerseitig abrufbarer Einspruchsstatus und begründete Ergebniszustellung;
5. produktive Team-Authentisierung, Rollen, Schulung, Vertretung, SLA-Monitoring und getesteter Krisen-/Behördenprozess;
6. Bestätigung der Punkte, die von der endgültigen Diensteeinordnung abhängen und die dieses Dokument selbst offenlässt: der Umfang der außergerichtlichen Streitbeilegung nach Art. 21 DSA (Abschnitt 10) und eine etwaige Berichtspflicht nach Art. 15 DSA (Abschnitt 12);
7. rechtliche Bestätigung der Anfrage-Nachricht vor ihrer Freischaltung: 14-Tage-Verfall des Chiffrats, der über Verfall, Ablehnung und Blockierung fortbestehende Paar-Zustand sowie das einseitige Flag-Recht des Empfängers.

Bis diese Launch-Gates erfüllt und getestet sind, beschreibt dieses Dokument den heutigen Umsetzungsstand und keine bereits angebotene DSA-konforme Ende-zu-Ende-Leistung.

14. Änderungen dieser Seite

Wir können diese Seite anpassen, etwa wenn sich Verfahren, Fristen oder rechtliche Vorgaben ändern. Maßgeblich ist die jeweils tatsächlich veröffentlichte Fassung mit dem angegebenen Stand. Wesentliche Änderungen werden in der App und auf https://welovereal.de kenntlich gemacht.

Anbieter: KI-Shield UG (haftungsbeschränkt), Ritterstraße 2, 99718 Greußen · Geschäftsführerin: Johanna Bringezu · Registergericht: Amtsgericht Jena, HRB 524511 · EUID: DEY1206.HRB524511 · USt-IdNr.: DE463549661 · Kontakt: info@ki-shield.de. Verantwortlich nach § 18 Abs. 2 MStV: Johanna Bringezu, Anschrift wie vor. Vollständige Angaben im Impressum.