Eine öffentliche Frage zur Sichtbarkeit eines Unternehmens ist eine andere Verarbeitung als das Hochladen eines Vertrags mit Personendaten. Beschreiben Sie vor einem Projekt, welche Angaben übertragen werden, wer sie erhält, zu welchem Zweck und für welche Dauer. Auch eine öffentliche Frage kann personenbezogene Informationen enthalten.
Einordnung und Geltungsbereich
No-Training-Aussagen brauchen eine passende vertragliche und technische Grundlage. Ein Schweizer Serverstandort allein beschreibt nicht automatisch die Verarbeitung sämtlicher externer Dienste. Prüfen Sie Modellzugriff, Hosting, E-Mail, Analytics und Protokolle einzeln.
Ein Proxy kann die direkte Netzwerkverbindung zum nachgelagerten Dienst übernehmen. Er anonymisiert jedoch keine Namen oder Vertragsdetails im Text. Für Tests genügen oft öffentliche Leistungsfragen oder klar gekennzeichnete synthetische Beispiele. Kundendokumente gehören nur mit geklärter Freigabe in den passenden Arbeitsablauf.
SOURCE/01 dokumentiert diese Flüsse und offenen Fragen. Die Analyse stellt keine pauschale Datenschutz-Zertifizierung aus. Die eigene GlasBox-Datenschutzerklärung beschreibt Hosting und Verarbeitung bei Infomaniak in der Schweiz sowie die getrennten Fristen für Protokolle, E-Mail-Leads und Browser-Speicherung.
Datenmatrix vor einem Sichtbarkeitstest
Diese Vorlage unterscheidet vier Datenarten. Tragen Sie vor der Nutzung die tatsächlichen Anbieter und Fristen des konkreten Projekts ein. «Schweiz» ohne benannte Verarbeitung und «nur Session» ohne definierte Dauer reichen als technische Dokumentation nicht aus. Die Vorlage ersetzt keine projektbezogene Prüfung der gesetzlichen Pflichten.
| Prüfpunkt | Beispiel / Gegenstand | Einordnung |
|---|---|---|
| Öffentliche Leistungsfrage | Name und öffentliches Angebot | Übertragung an die gewählte Suchoberfläche bewusst festlegen. |
| Synthetischer Testvertrag | Erfundene, nicht rückführbare Angaben | Als Testdaten kennzeichnen; keine echten Kundendetails übernehmen. |
| Reale Vertragsakte | Vertrauliche oder personenbezogene Daten | Freigabe, Rollen, Empfänger und Löschfrist vorab klären. |
| Technisches Protokoll | Zeit, Kennung, Fehler und gegebenenfalls Anfrageinhalt | Zugriff und tatsächliche Aufbewahrung dokumentieren. |
So wenden Sie das an
- Für jeden Test die benötigten Daten minimieren.
- Hosting und nachgelagerte Empfänger getrennt erfassen.
- Aufbewahrung, Löschung und zuständige Person festlegen.
- Produktive Datenschutzhinweise nach Konfigurationsänderungen erneut prüfen.
Quellen und nächste Lektüre
Die Quelle belegt die dort beschriebenen Regeln. Die Arbeitsvorlagen in diesem Artikel sind eigene methodische Beispiele, keine Ergebnisse eines Kundentests.
RAG-Readiness ist nicht GEO
Nächster Schritt
Der kostenlose Kurzcheck liefert eine erste Einschätzung zu einer Domain, drei kaufnahen Fragen und drei Beobachtungen. Im Erstgespräch klären wir, ob eine vertiefte Analyse sinnvoll ist.
Erstgespräch anfragen