Kartschall Zurück zu Search

Datenschutz­erklärung

Search befindet sich in Entwicklung. Für den Kundenstart wird ein begrenzter Kontobetrieb auf search.kartschall.com vorbereitet: eine Appinstanz auf einem EU-Netcup-VPS, Supabase Auth für Anmeldung, bestehender Netcup-Mailversand und Stripe für Abonnements. Externe verschlüsselte Sicherung bei Hetzner und technische Überwachung mit Healthchecks.io sind geplant. Diese Seite beschreibt den Entwicklungsstand und erteilt keine Freigabe für einen öffentlichen gehosteten Betrieb. Dessen tatsächliche Anbieter-, Vertrags-, Speicher- und Löschbedingungen müssen vor dem Start bestätigt und hier ergänzt werden.

Verantwortlicher

Die bisherige lokale Anbieterkennzeichnung lautet wie folgt. Der tatsächliche Verantwortliche nach Art. 4 Nr. 7 DSGVO und seine Kontaktdaten sind für den geplanten Kundenbetrieb noch verbindlich zu bestätigen:

Kartschall Webdesign
Inhaber Kilian Kartschall
Am Torhaus 1
79379 Müllheim
info@kartschall.com

Zweck und Angaben

Search hilft Webdesign-Agenturen, Betriebe mit einer möglichen Chance für eine neue oder verbesserte Website zu finden. Verarbeitet werden erlaubte Betriebsnamen, Standorte, Websitehinweise, Quellenangaben und daraus abgeleitete Websitebewertungen. Bei Einzelunternehmen, Freiberuflern oder gemischten Geschäfts- und Privatangaben können diese Daten personenbezogen sein. Öffentliche Auffindbarkeit oder das Weglassen von Kontaktdaten macht sie nicht automatisch anonym.

Search ergänzt keine Telefon- oder E-Mail-Kontakte, versendet keine Werbung und nimmt selbst keinen Kontakt mit den recherchierten Betrieben auf. Ein Lead ist keine Erlaubnis zur Ansprache. Die Einordnungen betreffen den betrieblichen Webauftritt und können bei Einzelunternehmern personenbezogen sein. Sie belegen keine Bonität oder tatsächliche Kaufbereitschaft.

Suchgebiet und Quellen

Bitte nur einen Ort als Suchgebiet eingeben, keine Personen, privaten Adressen oder Kontaktdaten. Der Server bestimmt das Suchgebiet mit Overture Divisions und lädt Betriebsangaben aus den eingerichteten Beständen von OpenStreetMap, Foursquare Open Source Places und Overture Places. Bei aktiviertem DZT-Zugang kommen ausgewählte Betriebsangaben aus dem DZT Knowledge Graph hinzu. Der Umfang hängt von den vorhandenen Datenständen ab und ist kein Versprechen vollständiger regionaler Erfassung.

Die anschließende Websiteprüfung kann Brave nach dem bestehenden Betrieb und Ort oder nach einer beobachteten Website fragen. Öffentliche Seiten werden unter den technischen Abrufgrenzen vom ausführenden Server geladen. Bei Browseransichten können auch zugelassene eingebundene Ressourcen und Skripte geladen werden. Website- und Ressourcenanbieter können dabei Verbindungsdaten des Servers und Angaben zum Abruf erhalten. Die technischen Abrufgrenzen ersetzen keine erforderliche Nutzungsberechtigung. Eine Suchquery über einen Einzelunternehmer kann personenbezogen sein.

KI-gestützte Websiteprüfung

Eine KI beurteilt die bereitgestellten Belege und wählt bei Bedarf weitere zugelassene Such-, Seiten- oder Bildprüfungen. An die OpenAI API gehen Betriebsname und Ort, sparsame lokale Vergleichshinweise, minimierte kontaktbereinigte Seitentexte, technische Beobachtungen und nötige geprüfte Bildschirmansichten. Straßen und Postleitzahlen werden für lokale Vergleiche verwendet; zum Modell gehen daraus Vergleichshinweise, keine zusätzlichen strukturierten Adressfelder.

Erkannter sichtbarer Telefon- und E-Mail-Text wird vor Bildschirmaufnahmen verdeckt, ohne das Layout zu verschieben. Dies erfasst nicht zuverlässig Text innerhalb von Bildern und ist keine vollständige Bereinigung aller personenbezogenen Bildinhalte. Nicht ausreichend prüfbare Bilder werden nicht als freigegebene Belege behandelt. Rohmaterial und Texte aus Websites sind Belege, keine Anweisungen an die KI.

Die Anzeige unterscheidet begrenzte Recherche ohne gefundene eigene Website, Websites mit Verbesserungspotenzial, keinen belegten Bedarf und offene Fälle. Ein fehlgeschlagener Abruf ist kein Nachweis fehlender Website. Eigene Erfassungsfehler werden von beobachteten Problemen des Betriebsauftritts getrennt. Ergebnisse beziehen sich auf die vorhandenen Belege und deren Zeitpunkt.

Rechtsgrundlage und indirekte Erhebung

Für personenbezogene Betriebsrecherche kommt ein berechtigtes Interesse nach Art. 6 Abs. 1 lit. f DSGVO nur nach konkreter Prüfung von Zweck, Erforderlichkeit und Interessenabwägung in Betracht. Ein Vertrag mit einer Agentur rechtfertigt die Verarbeitung recherchierter Personen nicht automatisch. Die vollständigen Nachweise für das tatsächliche Geschäftsmodell sind offen.

Bei indirekter Erhebung müssen betroffene Personen nach Art. 14 DSGVO rechtzeitig informiert werden oder die Voraussetzungen einer Ausnahme nachgewiesen sein. Eine allgemein abrufbare Datenschutzerklärung belegt diese Information nicht automatisch. Das Verfahren muss auch Empfänger, abgeleitete Bewertungen und spätere Kundenausgabe erfassen. Der offene Freigabestand ersetzt keine bereits bestehenden Pflichten.

Anmeldung und Zahlung, sofern aktiviert

Im optionalen Kontobetrieb werden Konto-E-Mail, Name, Nutzer- und Kontokennungen sowie erforderliche Authentifizierungs-, Sitzungs- und Sicherheitsdaten verarbeitet. Beim Supabase-Verfahren übermittelt das Backend die für Registrierung und Passwortprüfung benötigten Angaben an Supabase Auth. Die Anmeldung setzt den dort gemeldeten bestätigten E-Mail-Status voraus. Für den geplanten Kundenbetrieb bleibt Supabase Auth vorgesehen. Die lokale Zuordnung und erforderliche Anbietersitzungstokens liegen zusätzlich im privaten Appserverbestand; Supabase wird durch diesen Adapter nicht zum Speicher der Firmenrechercheakten.

Bestätigungs- und Wiederherstellungsmails sollen von Supabase über das bestehende Netcup-Postfach versandt werden. Dabei werden Empfängeradresse, Mailinhalt und sichere Bestätigungs- oder Wiederherstellungslinks verarbeitet. Tarif, Versandkonfiguration, Zustellung und Fristen sind noch am tatsächlichen Konto zu bestätigen. Suchläufe, gespeicherte Auswahl und Kosten werden im Kontobetrieb dem berechtigten Konto zugeordnet.

Wenn Stripe eingerichtet ist, führen Checkout und Aboverwaltung auf dessen gehostete Oberfläche. Das Backend übermittelt die Konto-E-Mail, eine interne Kontoreferenz und die erforderliche Tarif- und Abonnementzuordnung. Rechercheakten werden über diesen Zahlungsweg nicht an Stripe übermittelt. Vertragspartner, aktivierte Funktionen, Datenschutzrollen sowie Rechnungs- und Aufbewahrungsverfahren müssen vor dem bezahlten Betrieb konkret dokumentiert sein.

Empfänger und Verarbeitungsländer

Je nach tatsächlich aktiviertem Datenweg sind Geodatenanbieter, Brave, aufgerufene Website- und Ressourcenanbieter, OpenAI, Supabase Auth sowie Hosting-, Zahlungs- und Versanddienste beteiligt. Supabase Auth ist dabei vom Speicher der recherchierten Firmenbestände getrennt. Netcup ist als Apphost und Maildienst vorgesehen, Supabase mit einem EU-Authprojekt. Die geplante EU-Projektregion schließt weltweite Support- und Betriebsverarbeitung nicht aus. Für externe Sicherungen ist clientseitige Verschlüsselung vor Übertragung zu Hetzner vorgesehen. Healthchecks.io soll nur technische Pings und erforderliche Betreiberalarmdaten erhalten, keine Firmen- oder Kundennutzdaten. Konkrete Vertragspartner, Regionen, Zugriffe, Unterauftragnehmer und einschlägige Übermittlungsgrundlagen sind vor dem gehosteten Start zu dokumentieren. Diese Entwicklungsbeschreibung ist noch keine vollständig ausgefüllte Erklärung für einen bestimmten Produktionsbetrieb.

OpenAI-Anfragen verwenden store:false. Das ist kein Versprechen vollständiger Speicherfreiheit: gesonderte Missbrauchsprotokolle und modell- oder funktionsabhängige Caches können bestehen. Eine Verarbeitung in Europa braucht passende Account-, Projekt- und Kontrollvoraussetzungen; ein EU-Endpunkt allein beweist sie nicht. OpenAI-Datenkontrollen.

Brave nennt bis zu 90 Tage Query-Aufbewahrung und nimmt Suchquery-Daten aus seinem DPA aus. Diese Anbieterposition beseitigt den möglichen Personenbezug unserer Betriebsqueries nicht. Konkrete Quellen-, Account-, Inferenz- und Kundenanzeigerechte bleiben gesondert zu klären. Brave-Datenschutzhinweise.

Für eine aktivierte Zahlung gelten zusätzlich die tatsächlichen Bedingungen und Rollen von Stripe. Es wird keine Such- oder Firmenakte zum Zweck der Zahlung an Stripe gesendet.

Speicherung, Löschung und Sperren

Der Prüfer legt keine dauerhaften Rohbestände von Suchtexten, Webseiten, Bildschirmansichten, Prompts, vollständigen Modellantworten oder Gedankengängen an. Gespeichert werden notwendige abgeleitete Ergebnisangaben, Quellenlinks, Beobachtungszeitpunkte, technische Diagnosen und Kosten. Arbeitslisten, Kontodaten, bewusste Auswahl, Sicherungen, Diagnoseexporte und Anbieterhaltung sind eigenständige Bestände.

Davon getrennt bestehen Quellenbestände, regionale Datencaches und gegebenenfalls gesonderte Laufarchive. Vorgelagerte Quellenbestände können Kontaktfelder enthalten. Neue regionale Foursquare-Caches enthalten keine Telefon-, E-Mail- oder Socialfelder; unsichere Websitehinweise werden vor Speicherung ausgelassen. Bereits vorhandene ältere Dateien und Sicherungen benötigen eine kontrollierte Bereinigung. Umfang, Aufbewahrung und Rechteverfahren müssen sämtliche tatsächlich vorhandenen Kopien erfassen.

Das Entfernen aus „Gespeichert“ entfernt diese Auswahl; ein bestehender Suchlauf bleibt davon unberührt. Der Kontodialog bietet einen Export eigener Daten und Quellenunterlagen sowie eine Löschanfrage mit Referenz. Diese bestätigt weder abgeschlossene Löschung noch Kündigung. Quellenunterlagen können den aktuellen Lauf, erfasste frühere Regionen und gespeicherte Auswahl umfassen; hierfür gelten eigene begründete Aufbewahrungsentscheidungen und Rechteverfahren. Beim Supabase-Adapter verlangt die Kontolöschung einen Betreiberprozess mit gesonderter Providerlöschung und lokaler Bereinigung. Kontolöschung erfasst nicht automatisch externe Zahlungsobjekte, gesetzlich erforderliche Belege, gemeinsame Caches, Sicherungen oder getrennte Diagnosekopien. Aktive Jobs und Abonnements sind gesondert zu behandeln.

Konkrete Speicherfristen oder Kriterien, Löschereignisse, Verantwortliche und Wiederherstellungsverfahren sind für den tatsächlichen Betrieb noch festzulegen. Verschlüsselte Sicherungen bleiben ein eigener Bestand; sie ersetzen weder die getrennte Löschung noch die Wiederherstellung des externen Supabase-Authbestands. Vor einer Wiederöffnung wiederhergestellter Daten sind aktuelle Sperren und Rechteentscheidungen erneut zu berücksichtigen. Technische Sitzungslaufzeiten ersetzen keine allgemeine Aufbewahrungsregel. Berechtigte Berichtigungen, Löschungen und Widersprüche müssen über alle betroffenen Bestände beachtet werden. Minimale Sperrinformationen können eine erneute unzulässige Aufnahme verhindern und benötigen einen eigenen begrenzten Zweck und Zugriff. Lokale Werkzeuge unterstützen die Prüfung und Anwendung über ausgewählte Bestände; daraus folgt keine bereits ausgeführte Bearbeitung aller tatsächlichen Kopien oder Empfängermitteilungen.

Rechte und Kontakt

Betroffene Personen können sich über den oben genannten Kontakt an Kartschall wenden. Auskunft, Berichtigung, Löschung, Einschränkung, gegebenenfalls Datenübertragbarkeit und Widerspruch werden nach ihren Voraussetzungen bearbeitet. Außerdem besteht das Beschwerderecht bei einer zuständigen Datenschutzaufsicht. Ein Kontoexport ist keine vollständige Auskunft über recherchierte Dritte. Die praktische Bearbeitung und Verantwortlichkeit für den gehosteten Betrieb bleiben vor dessen Start nachzuweisen. EU-Kommission: Betroffenenanfragen.

Bewertung und Ansprache bleiben getrennt. Für Werbung gelten zusätzlich die Anforderungen aus § 7 UWG; eine Websitechance erteilt keine Werbeerlaubnis.

Browserablage und Sitzungen

Die lokale Funktion „Mein Fortschritt“ speichert Betriebskennungen und von Ihnen gesetzte Kalendertage im Browserprofil. Entfernen der Markierung, „Fortschritt löschen“ oder Löschen der Browserdaten entfernt diese Ablage. „Teilen“ erstellt auf Ihre Aktion ein Bild mit aggregierten Zahlen und Kurven. Bereits weitergegebene Bilder können durch späteres Löschen nicht zurückgeholt werden. Diese lokale Funktion ist im Kontobetrieb nicht verfügbar. Der Client liest und schreibt diesen Bestand erst nach bestätigter lokaler Moduskonfiguration; bei fehlgeschlagener Konfiguration und in Testansichten greift er nicht darauf zu. Die konkrete Rechtsgrundlage der Endgerätezugriffe ist für die angebotene Betriebsform festzulegen.

Bei aktivierter Anmeldung dienen Sitzungskennungen dem angeforderten Zugang und seinem Schutz. Die konkreten Cookie-/Endgerätezugriffe werden für die reale Betriebsform geprüft. Durch diese Entwicklungsfassung wird kein Analyse- oder Marketingtracking freigegeben.