Compliance

DSGVO

Öffentliche Rechtsinformationen und gemeinsame Verantwortlichkeit

Seit 3. August 2026 sind die öffentlichen Seiten /impressum und /datenschutz implementiert. Grundlage ist die ausdrückliche Bestätigung, dass die Atelier Deubner Lopez ZT OG und die Ostheimer OG LandNutzen gemeinsam betreiben und als gemeinsame Verantwortliche im Sinn von Art. 26 DSGVO Zwecke und Mittel der Verarbeitung gemeinsam festlegen. Die kanonischen Unternehmensangaben liegen in lib/legal/operators.ts.

Die öffentliche Datenschutzerklärung beschränkt sich bei der Beschreibung der gemeinsamen Verantwortlichkeit auf den bestätigten Sachverhalt: Beide Gesellschaften betreiben LandNutzen gemeinsam, legen Zwecke und wesentliche Mittel gemeinsam fest und sind jeweils Anlaufstelle für Betroffenenrechte. Eine nicht belegte interne Aufgabenverteilung wird nicht veröffentlicht.

Die Datenschutzerklärung beschreibt die im Code belegten Datenflüsse für Hosting, Adressvorschläge, Report, PV-Werkzeug, Konto, E-Mail und optionale KI-Unterstützung. Die kennungsfreie MET-01-Werkzeugmessung ist im aktuellen Arbeitsstand vorbereitet; ihr Produktions-Readback steht bis zum Deployment noch aus. Damit stehen die öffentlichen Basisinformationen bereit. Das formale Rechts-Gate bleibt jedoch offen, bis der wesentliche Inhalt der tatsächlichen Art.-26-Vereinbarung, die internen Beteiligungs-/Stimmrechtsverhältnisse der Atelier Deubner Lopez ZT OG und die operative AVV-/DPA- und SCC-Nachweiskette aus #290 dokumentiert sind. Kommerzielle Produkt-, Vertrags-, Tarif- und Zahlungsfreigaben bleiben separat gegatet.

Login-lose Adresseingabe — der Sonderfall

Auch ohne User-Konto ist die Adresse ein personenbezogenes Datum im Sinne der DSGVO, sobald sie mit Kontextdaten (Kataster, Leerstand, Förderhinweise) verknüpft wird — sie lässt indirekt Rückschlüsse auf den Eigentümer zu.

Pflichten vor Phase-2-Launch:

Privacy-Notice klar sichtbar vor Eingabe
Opt-in-Checkbox („Ich verstehe, dass die Auswertung keine rechtsverbindliche Vermessung ersetzt")
AVV mit allen Sub-Prozessoren (Hosting, LLM, Geo-APIs)
Klarer Speicher-/Löschzyklus (anonymer Report einschließlich Adresse max. 90 Tage; konto-gebundener Report bis zur Nutzerlöschung)
Rate-Limit zur Verhinderung von Mass-Scraping: anonym 10 / Tag pro pseudonymem IP-Bucket; mit bestehender gültiger Kontositzung 10 / Tag pro pseudonymem Account-Bucket; API-Keys behalten ihr eigenes Datenbanklimit

Umsetzungsstand Adresseinstieg (Issue #283 / ADR-0039, 2026-07-15):

Die wiederverwendete Adresskomponente zeigt den Datenschutzhinweis auf Landingpage und Reportseite direkt vor dem Eingabefeld.
Der Hinweis nennt Photon (Komoot) für Vorschläge, Nominatim für das finale Report-Geocoding. Das SPARTACUS-v3-Klimaprofil wird aus dem qualifizierten LandNutzen-Snapshot gelesen; GeoSphere Austria erhält im Reportpfad keine Koordinaten mehr.
Die Browser-Geolokation wird nicht mehr bei Fokus oder Texteingabe angefragt. Sie startet ausschließlich nach dem ausdrücklichen Klick auf „Standort verwenden"; übertragen werden auf ungefähr 1 km gerundete Koordinaten. Ohne Freigabe bleibt die Adresssuche über den groben serverseitigen IP-Bias voll funktionsfähig.
Der Hinweis unterscheidet die nicht serverseitig gespeicherte Suggest-Eingabe vom erzeugten anonymen Report: Der Report einschließlich Adresse wird gemäß ADR-0022 90 Tage gespeichert und danach automatisch gelöscht. Konto-gebundene Reports bleiben bis zur Nutzerlöschung erhalten.
Die statischen Briefing-Seiten laden keine Google Fonts mehr zur Laufzeit. Sie verwenden datenschutzfreundliche lokale Systemschrift-Fallbacks.
Der technische Fix ist automatisiert abgedeckt; die produktive End-to-End-Neubewertung von POC-Kriterium B3 erfolgt nach dem Deployment.

Öffentlicher PV-Ertragsrechner

Der Rechner unter /werkzeuge/pv-ertrag ist bewusst vom persistierten Reportpfad getrennt:

Photon erhält die Texteingabe ausschließlich für Vorschläge. Der Rechner akzeptiert nur einen ausgewählten Vorschlag samt österreichischer Koordinate; er ruft weder Nominatim auf noch geokodiert er Freitext. Der gemeinsame Suggest-Endpunkt besitzt ebenfalls keinen Nominatim-Typeahead-Fallback.
PVGIS des Joint Research Centre erhält nur Breiten- und Längengrad sowie die technische Verlustannahme, niemals den Adresstext.
LandNutzen schreibt Adresse, Koordinate und Ergebnis in keine Datenbank oder den persistenten Next Data Cache. Die API antwortet Cache-Control: private, no-store; die Eingaben stehen nicht in URL, Analytics-Events oder Share-Links.
Die Share-Ansicht /werkzeuge/pv-ertrag/teilen liest ausschließlich ein versioniertes URL-Fragment im Browser. Dieses Fragment enthält technische Annahmen, Ergebniswerte, Quelle und minutengenaue Abfragezeit, aber keine Adresse, Koordinate, Region oder Auswahlbelege. Fragmente werden nicht mit dem HTTP-Request an LandNutzen/Vercel übertragen; sie können bewusst in Browser-Historie, Zwischenablage oder der gewählten Teilen-App verbleiben. Die Ansicht ist noindex, fragt PVGIS nicht erneut ab und persistiert nichts. Der Snapshot ist nicht kryptografisch bestätigt; technische Fragmentwerte können verändert werden und werden deshalb nicht als Nachweis bezeichnet.
Ein eigener pseudonymer IP-Hash-Bucket limitiert die kostenlose Berechnung unabhängig vom Report. Der Suggest-Endpunkt besitzt ebenfalls Längen- und Tageslimits.
Das Ergebnis nennt sichtbar, dass es ein Standortmodell bei optimaler Ausrichtung und keine Dachvermessung, Ertragsgarantie, Statik-, Netz-, Genehmigungs-, Tarif- oder Förderprüfung ist.
Die sichtbare Attribution verlinkt die OpenStreetMap-Mitwirkenden, die ODbL und Photon (Komoot).

Öffentlicher Standort-Check ohne Report-Persistenz

Der Standort-Datenpass unter /werkzeuge/standort-check ist vom gespeicherten Report und vom PV-Ertragsrechner getrennt:

Der bestehende Photon-Suggest verarbeitet das Adressfragment wie bisher. Das Werkzeug akzeptiert nur eine ausgewählte österreichische Adresse mit signierter Koordinate und separat signiertem Bundesland; es geokodiert keinen Freitext und ruft weder Nominatim noch einen neuen Provider auf.
POST /api/tools/standort-check verarbeitet Adresse, Koordinate, Signaturen und Quellenkarten ausschließlich für die konkrete Anfrage. Es schreibt diese Angaben weder als Report, Suchhistorie, Session noch als Ergebnis in eine Datenbank. Die Antwort enthält keine Koordinate oder Signatur und trägt Cache-Control: private, no-store sowie noindex.
Ausschließlich auf /werkzeuge/standort-check wird kein clientseitiger Auth-SessionProvider gemountet; der Browser fragt /api/auth/session nicht im Hintergrund ab. Header, Footer und statische Seitenlinks unterbinden spekulatives prefetch für die sensiblen Zielpfade /report und /login. Vor einer bewussten Navigation entstehen keine neuen Auth-, ln_anon-, Report- oder Session-Cookies.
Der serverseitige ImpersonationBanner bleibt unverändert sichtbar, wenn bereits eine aktive Impersonation vorliegt. Die normale Authentifizierung, TOTP, Report-/Login-Cookies und Session-Provider aller anderen Seiten bleiben erhalten.
Es gibt weder Permalink noch Share-Fragment, Eigentümerdaten, Parzellenexport oder Standortübertragung an einen neuen externen Datenprovider.
Der vorhandene Missbrauchsschutz speichert im getrennten tool:site-check-Bucket ausschließlich einen pseudonymen SHA-256(IP + Geheimnis + Scope)-Hash mit Tagesdatum und Zähler in der bestehenden Tabelle rate_limits. Das Werkzeuglimit beträgt 30 Anfragen pro Tag. Der bestehende wöchentliche Löschlauf entfernt Zählerdaten älter als 90 Tage; ein verspäteter Lauf kann die tatsächliche Aufbewahrung verlängern.
Der Standort-Check erzeugt keine Funnel-Events, keine Server- Produkttelemetrie und keine neue Baseline. MET-01 bleibt ausdrücklich auf pv-yield begrenzt.
Anwendungsseitige API- und Adapterfehler werden nur statisch oder redigiert protokolliert; rohe Exception-/SQL-Payloads mit Standortparametern werden nicht ausgegeben. Allgemeine technisch notwendige Hosting- Verbindungsprotokolle bleiben davon unabhängig.
Snapshot-Lookups lesen ausschließlich bereits qualifizierte, matrixgebundene öffentliche Bestände. Hochwasser verwendet keinen WMS-Fallback. NÖGIS #413, sämtliche BEV-Exportfähigkeiten einschließlich des release-gebunden vorbereiteten, betrieblich deaktivierten DXF-Consumers sowie nicht konfigurierte Erdbeben-/LCZ-Scopes bleiben aus dem Standort-Check ausgeschlossen.
Rechtsgrundlagen sind Art. 6 Abs. 1 lit. b DSGVO für die angeforderte Auswertung und Art. 6 Abs. 1 lit. f DSGVO für Missbrauchsschutz. Der öffentliche Hinweis steht unter /datenschutz#standort-check.

Menschlich freigegebene Wissensinhalte und geschützte Entwürfe

Der öffentliche Wissensbereich enthält sechs menschlich freigegebene Beiträge; aktuell gibt es keine unfreigegebenen Entwürfe. Andreas Ostheimer hat die drei zuletzt ergänzten Inhalte ausdrücklich freigegeben; der CON-02-Freigabenachweis belegt Person, Zeitpunkt und menschliche Entscheidung. Künftige Entwürfe bleiben auf explizite geschützte Preview-/Entwicklungsumgebungen beschränkt und sind in Production, RSS-Feed, Sitemap und llms.txt nicht enthalten. Preview-Seiten tragen noindex, nofollow, nocache; Canonicals und BlogPosting-JSON-LD werden nicht ausgegeben.

Ein benannter menschlicher Schlussreview und ein SHA-256-gebundenes Artefakt aus Themenbrief, Quellenpaket, Text, Bild und sichtbaren Metadaten sind Voraussetzung jeder Veröffentlichung.
Materielle Änderungen bei Lizenz, Rechten, Quellenstand, Coverage, Datenlücken oder Qualität erzeugen review_required für alle betroffenen Beiträge. Ein reiner Pointer-Wechsel mit gleicher fachlicher Aussage bleibt source_refreshed; eine fehlende Quelle ergibt source_unavailable und blockiert die Neufreigabe fail-closed. Bereits veröffentlichte Beiträge bleiben bis zur redaktionellen Entscheidung unverändert; der Audit depubliziert keine Inhalte automatisch.
Der einzige öffentliche Korrekturweg bleibt /impressum#kontakt. Es gibt weder ein neues Formular noch eine neue Content-API, einen neuen personenbezogenen Speicher oder automatische Veröffentlichung beziehungsweise Depublikation.
npm run content:audit läuft deterministisch offline. Der explizite --live-Modus verwendet ausschließlich lesende GET-Abfragen öffentlicher Provenienz und verarbeitet keine neuen Nutzerdaten.
KI-Unterstützung, Primärquellen, Bildrechte, fachliche Grenzen und verantwortliche Freigaben bleiben in veröffentlichten Beiträgen transparent. Inhalte ersetzen keine amtliche oder fachliche Auskunft.

Der öffentliche Content-Pipeline-Vertrag und Wissensbereich und Redaktion dokumentieren dieselben Freigabe- und Datenschutzgrenzen.

Kennungsfreie Werkzeugmetriken (MET-01 / ADR-0042)

Für Funnel-, Qualitäts-, Laufzeit- und Kostenaussagen nutzt LandNutzen eine eigene, datensparsame Aggregation in Neon. Es werden keine einzelnen Werkzeugereignisse gespeichert. Die Tabelle tool_metrics_daily enthält nur Tag, stabile Tool-/Statuscodes, einen groben Bundeslandcode, feste Laufzeitklassen, Zähler, Summen und direkt zurechenbare Kosten. Die separate Tabelle tool_metric_baselines hält je Tool nur den ersten Funnel- und Server-Messtag. tool_metric_baseline_aggregates schreibt ausschließlich während D+1 bis einschließlich D+14 nach diesem gemeinsamen Anker dieselben fest vorgegebenen Funnel-, Fehler-, Provider-, Runtime-, Laufzeit- und Kostendimensionen sowie die zugehörigen Zähler und Summen fort. Mit Ablauf von D+14 ist der Ausgangswert vollständig und bleibt ab D+15 unverändert. Tag und Bundesland sind darin nicht enthalten.

Ausgeschlossen sind insbesondere Adresse, Koordinate, Eingabeparameter, Berechnungsergebnis, URL, Referrer, Freitext, JSON-Metadaten sowie Nutzer-, Konto-, Organisations-, Session-, Request-, IP- und User-Agent-Kennungen. Der öffentliche Funnel-Endpunkt verwendet auch keinen persistenten IP-Hash für seine Begrenzung. Externe Analytics-, Werbe- und Session-Replay-Dienste bleiben inaktiv; ihre Einführung bleibt durch #290 gegatet.

Der tägliche Vercel-Cron /api/cron/metrics-prune löscht Aggregate, deren Tag älter als der aktuelle und die 29 vorhergehenden Kalendertage ist. Ein verspäteter oder fehlgeschlagener Lauf kann die tatsächliche Speicherdauer vorübergehend verlängern und ist über die Cron-Telemetrie sichtbar. Der kennungsfreie Baseline-Anker und sein fester 14-Tage-Dimensionssnapshot bleiben unabhängig von dieser Tageswert-Retention als dauerhafte Vergleichsreferenz erhalten. Zugriff auf die Auswertung besteht nur über die 2FA-geschützte Plattform-Admin-Oberfläche oder einen API-Key mit admin-Scope. Der Browser sendet Funnel-Ereignisse ohne Credentials; der Endpunkt liegt außerhalb der Auth.js-Hülle. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO: berechtigtes Interesse an Produktverbesserung, zuverlässigem Betrieb und Kostenkontrolle bei konsequenter Datenminimierung.

Anonyme Sessions (`anonymous_sessions`, ADR-0026 / Issue #105)

/report ist login-los, der Anonymous→Registriert-Funnel braucht trotzdem eine wiedererkennbare Pseudo-Session, um beim späteren Login den bisherigen Report-Verlauf zum User zu migrieren. Stand 2026-05-21 aktiv (Issue #105 — vormals dokumentierter Folge-Schritt aus ADR-0026).

Aspekt	Umsetzung
Cookie	`ln_anon`, HttpOnly, SameSite=Lax, Secure (in Prod), Path=`/`, `Max-Age=90` Tage; gesetzt in `proxy.ts` beim ersten `/report`-Aufruf, wenn der Cookie fehlt
Token-Format	32 Bytes Web-Crypto → 64 Hex-Zeichen (passt zu `anonymous_sessions.cookie_token varchar(64) unique`)
DB-Zeile	`anonymous_sessions(cookie_token, last_seen_at)`; UPSERT über `cookie_token` via `POST /api/anon/touch` (Node), Folge-Aufrufe aktualisieren nur `last_seen_at`
Datenminimierung	IP-Adresse und User-Agent werden für die Session-Zuordnung nicht benötigt und nicht gespeichert. Migration `0037_anonymous_session_minimization.sql` entfernt die früher vorhandenen, ungenutzten Hash-Spalten samt Altbestand. Pseudonyme IP-Hashes bestehen separat nur für tatsächlich ausgewertete Rate-Limits.
Conversion	beim ersten Post-Login (`/go`) setzt `convertAnonymousByEmail` `converted_to_user_id`; danach gehört die Zeile dem User
Retention (DSGVO)	Hard-Delete nach 12 Monaten ohne Conversion (`created_at < now() - interval '12 months' AND converted_to_user_id IS NULL`). Konvertierte Zeilen bleiben — sie sind Teil der User-Historie und unterliegen der allgemeinen Account-Retention. Automatisiert via täglichem Vercel-Cron `30 3 * * *` (`/api/cron/anon-cleanup`, ADR-0026 §3 / Issue #105) — analog zum reports-cleanup-Cron (`runCron`-Wrapper, `cron_runs`-Telemetry, Failure-Alert). Der Cron löscht ausschließlich `converted_to_user_id IS NULL` → konvertierte Zeilen bleiben unberührt.
Fail-open	DB-Fehler beim Touch crashen `/report` nie (`POST /api/anon/touch` antwortet 204, `console.error`-Log); manipulierte Cookies (≠ 64-Hex) werden ignoriert, der nächste GET stellt einen frischen Cookie aus

API-Sicherheits-Hardening (ADR-0023)

Maßnahme	Umsetzung
Eingabe-Caps	Adresse max 180 Zeichen + Control-Char-Strip; lat/lon nur innerhalb Österreich-BBox; JSON-Body max 2 KB (`lib/api/guard.ts`); PV 0,5–100 kWp und 0–40 % Verluste
Scraping-Schutz GeoJSON	Karten-Endpunkte (`parcel-/widmung-geojson`) jetzt rate-limitiert (eigener `map:`-Bucket, Default 300/Tag)
CORS	bewusst offen für `/api/v1/` (öffentliche, KI-nutzbare API) ohne Credentials*; Schutz = Rate-Limit/Key, nicht Origin
Header	`X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY` global; Report-Antworten `Cache-Control: private, no-store` (keine Adress-Zwischenspeicher)
Pseudonyme Limits	Anonyme Reports verwenden einen mit Geheimnis gebildeten pseudonymen Request-IP-Bucket; eine sicher aufgelöste bestehende Kontositzung verwendet stattdessen einen domänenseparierten HMAC-SHA-256-Bucket aus `users.id` und `AUTH_SECRET`. User-ID und E-Mail stehen nicht in `rate_limits`. Beide Modi haben zehn Reports pro Tag; API-Keys behalten ihren eigenen Datenbankwert. Ein ungültiger oder widerrufener Key antwortet vor jedem Cookie-Fallback mit `401`; Sitzungsfehler oder gelöschte Nutzer fallen auf den anonymen IP-Bucket zurück. Die historisch benannte Spalte `rate_limits.ip_hash` enthält den generischen Bucket-Schlüssel; `reports.ip_hash` bleibt davon getrennt das Pseudonym der tatsächlichen Request-IP. Tagesbasierte Zähler (Migration 0006) werden automatisiert via wöchentlichem Vercel-Cron `30 2 * * 0` (`/api/cron/ratelimit-prune`, `DELETE … WHERE day < (now() - interval '90 days')::date`) entfernt. Keine Compliance-Frist — pseudonyme Zähler, reine Wachstumsbegrenzung der Tabelle; ein verspäteter Lauf kann die tatsächliche Aufbewahrung verlängern (Report-Quota-Vertrag).
Permalink-IDs (für Report-Persistenz, ADR-0022)	CSPRNG ≥128 Bit base62 — nicht enumerierbar (IDOR-Schutz); `/r/{id}` `noindex`; Retention `expires_at` Default 90 Tage (anonyme Reports), Hard-Delete automatisiert via täglichem Vercel-Cron `0 3 * * ` (`/api/cron/reports-cleanup`, Issue #107). Konto-gebundene Reports* (`reports.user_id` gesetzt — eingeloggt erstellt oder per `?claim=1` beansprucht, Migration 0021) haben `expires_at = NULL` und laufen nicht ab: sie sind Teil der User-Daten (Speicherung auf Wunsch des Nutzers, abrufbar unter „Meine Reports") und unterliegen der allgemeinen Account-Retention, nicht der 90-Tage-Frist. Der Cron löscht ausschließlich `expires_at < now()` → NULL-Zeilen bleiben unberührt. Anonyme Reports tragen optional `reports.anon_token` (= `ln_anon`-Cookie, Migration 0022) für den Funnel-Auto-Claim beim Login; der Token wird beim Claim auf NULL gesetzt (Datenminimierung) und verschwindet spätestens mit dem 90-Tage-Hard-Delete. Granulares Einzel-Löschen (DSGVO Art. 17 / Datenminimierung): Nutzer können einen einzelnen Konto-Report owner-scoped hard-löschen (`DELETE /api/v1/me/reports/{id}` bzw. „Löschen" auf `/account/reports`, `… WHERE id AND user_id`) — unabhängig von der kompletten Kontolöschung; ebenso Label/Notiz setzen (`PATCH`, Migration 0024). Beim Konto-Löschen werden die zugehörigen Reports mitentfernt (siehe nächste Zeile).
Recht auf Vergessenwerden (DSGVO Art. 17)	Konto-Löschung über `/account/delete` (UI, Server-Action) und `DELETE /api/v1/me` (headless, AI-Parität) — Single Source `lib/account/delete.ts`. Erasure-Kaskade in FK-sicherer Reihenfolge: `reports`, nutzergebundene `foerder_entitlement`-Zeilen (Testmodus), `memberships` (nur eigene Zeilen löschen; auf fremden Zeilen nur `invited_by` nullen — sonst verlöre ein eingeladener Nutzer seinen Org-Zugang), `invitations` (selbst versendet oder an die Konto-E-Mail gerichtet), `anonymous_sessions` (konvertiert), der deterministisch abgeleitete Account-Quota-Bucket in `rate_limits`, `verification_tokens` (per E-Mail), `users`; `accounts`, `sessions` und `authenticator` (Passkey-Public-Keys und Metadaten) cascaden per DB-FK (`ON DELETE CASCADE`). Der Account-Bucket wird vor `users` entfernt und nicht erst dem 90-Tage-Prune überlassen; fremde Account-, anonyme IP- und API-Key-Buckets bleiben unberührt. Einzelne Passkeys sind zuvor owner-scoped unter `/account` widerrufbar. Bestätigung durch erneute Eingabe der eigenen E-Mail (Schutz vor versehentlicher/automatischer Löschung). Guard: blockiert (409), solange der Nutzer alleiniger `owner` einer Organisation ist (Eigentum erst übertragen) — fail-closed bei DB-Fehler (im Zweifel NICHT löschen). Bewusst aufbewahrt (Art. 17 Abs. 3 lit. e, Rechtsansprüche): Betriebs-/Audit-Logs (z. B. `impersonation_log`, `cron_runs`) — keine FK auf `users`, enthalten keine Report-Inhalte.
Legacy `/api/report`	`Deprecation`/`Sunset`-Header gesetzt; Entfernung nach UI-Umzug auf v1

Der Konto-Bucket trägt zusätzlich die nicht personenbezogene Typkennung account:v1:. Migration 0051 hält die Lifecycle-Zuordnung in account_rate_limit_buckets: Dort ist jede aktuelle oder nach einer AUTH_SECRET-Rotation ältere HMAC-Generation per user_id an das Konto gebunden. rate_limits.account_bucket verweist mit ON DELETE CASCADE auf diese Zuordnung. Die historische Spalte rate_limits.ip_hash enthält damit weiterhin keine rohe User-ID; Mapping und alle Konto-Zähler werden bei der Kontolöschung atomar mit dem User entfernt. Anonyme IP- und API-Key-Buckets bleiben unberührt.

Migration 0051 bindet außerdem reports.user_id mit ON DELETE CASCADE an users.id. Dadurch kann ein parallel zur Kontolöschung laufender Session-POST keinen adresshaltigen, dauerhaften Waisenreport (expires_at = NULL) erzeugen: Der FK blockiert den Insert oder die User-Löschung cascadiert ihn atomar.

Datenminimierung im LLM-Pipeline

Pflicht	Umsetzung
Keine PII im LLM-Prompt	Adresse → Koordinate → Hash; Eigentümer-Name nie an LLM
Anonymisierung der Gemeinderatsprotokolle	NER-basierte Klarnamen-Entfernung vor RAG-Indexing
Retention der Logs	Anthropic 7 Tage Abuse-Monitoring; eigene Logs ≤ 30 Tage
Aggregat-Daten dürfen nicht re-identifizierbar sein	Benchmark-Daten nie auf Einzeladresse runterbrechen (z. B. „14 Brachflächen in dieser Gemeinde", nicht „diese eine Adresse")

Verzeichnis von Verarbeitungstätigkeiten (VVT)

Pflicht gemäß Art. 30 DSGVO. Eintrag pro Sub-Prozessor:

Statushinweis 15.07.2026: Die folgende Tabelle ist das über die Zeit gewachsene Zielinventar, nicht der Beleg für aktuell aktive Dienste. Für die POC-B6-Abnahme gilt die laufzeitbasierte AVV-Matrix: R2, Upstash, Inngest, Sentry, BetterStack und PostHog sind derzeit nicht als Runtime-Nutzung belegt. In das operative VVT gehören nur tatsächlich aktive Empfänger; geplante Dienste bleiben separat als „vor Aktivierung“ markiert.

Sub-Prozessor	Zweck	Rechtsgrundlage	Rechenzentrum
Vercel (Hosting + Edge + AI Gateway)	Hosting, Edge Functions, LLM-Routing	Art. 6 (1) (b) Vertragserfüllung	global, EU-Region wählbar; AI Gateway routet pro Provider auf EU-Region
Neon (Postgres-Hosting)	PostgreSQL + PostGIS + pgvector	Art. 6 (1) (b)	EU (Frankfurt)
Cloudflare R2 (Object Storage)	PDF-Reports, Förderrichtlinien, Fassaden-Uploads	Art. 6 (1) (b)	EU-Jurisdiction-Buckets (Western Europe). SCCs als Annex zum AVV — US-Muttergesellschaft, daher Schrems-II-Argumentation dokumentieren
Upstash Redis	Cache	Art. 6 (1) (b)	EU-Region
Inngest (Background-Jobs)	Workflow-Orchestrierung, Job-Queues	Art. 6 (1) (b)	EU-Cloud-Region (eu.app.inngest.com); SCCs als Annex zum AVV
Sentry (Error-Tracking + APM)	Error-Reporting, Performance-Monitoring	Art. 6 (1) (f) berechtigtes Interesse	EU-Region Frankfurt; PII-Scrubbing über `beforeSend`-Hook
BetterStack (Phase 3+ Logs + Uptime)	zentrale Log-Aggregation, Status-Page	Art. 6 (1) (f)	EU-Region; AVV vor Aktivierung
Posthog (Phase 3+ Product Analytics)	Funnel-Analyse, Cohort-Tracking	Art. 6 (1) (a) Einwilligung (Cookie-Banner)	EU-Cloud (eu.posthog.com); Session-Replay nur opt-in
Stripe	Payments	Art. 6 (1) (b)	EU + global
Anthropic (LLM-Modelle)	Standard- und Premium-Reports, Tool-Use	Art. 6 (1) (b)	über AWS Bedrock EU (Frankfurt) oder Vertex AI EU; SCCs
OpenAI (LLM-Modelle)	Klassifikation, Embeddings, Standard-Reports (Alternative)	Art. 6 (1) (b)	EU-Region (direkte OpenAI EU-API); SCCs
Google (LLM-Modelle, Gemini)	PDF-/Bild-Extraktion, Klassifikation	Art. 6 (1) (b)	Vertex AI EU-Region; SCCs
AWS (falls Bedrock aktiv für Anthropic)	Hosting für Anthropic-Modelle	Art. 6 (1) (b)	Frankfurt
Komoot (Photon) (Geo-API)	Adress-Autovervollständigung (Type-Ahead, login-loser Free-Pfad)	Art. 6 (1) (b)	Komoot GmbH (DE/EU); öffentliche Instanz `photon.komoot.io`. Eingabe wird nicht serverseitig gespeichert (`no-store`). Für das Ranking wird ein grober Standort-Bias mitgesendet (IP-Geo stadtgenau bzw. Browser-Geolocation auf ~1 km gerundet — keine hausgenaue Position). Die Browser-Geolokation wird ausschließlich nach ausdrücklichem Klick auf „Standort verwenden" angefragt; ohne Freigabe greift nur der serverseitige IP-Bias. AVV vor Launch zu klären, alternativ Self-Hosting (`PHOTON_BASE_URL`) für volle Datenkontrolle
OpenStreetMap Foundation (Nominatim) (Geo-API)	Einzel-Geocoding ausschließlich im Reportpfad	Art. 6 (1) (b)	OSMF (UK; EU-Angemessenheitsbeschluss UK). Kein Autocomplete und kein PV-Rechner-Pfad; Eingabe nicht serverseitig gespeichert (`no-store`)
European Commission Joint Research Centre (PVGIS)	Standortbezogene PV-Ertragsschätzung	Art. 6 (1) (b)	EU-Dienst; übertragen werden ausschließlich Koordinate und technische Anlagenannahmen, niemals der Adresstext. LandNutzen persistiert Anfrage und Ergebnis nicht.
Lärminfo.at / LFRZ-WMS	Strategische Umgebungslärm-Abfrage und Kartenbild	Art. 6 (1) (b)	Öffentlicher österreichischer Fachdienst. Beim `report_lookup`/GetFeatureInfo wird eine kleine WGS84-BBox um die Koordinate übertragen; GetMap/PNG für Web- und PDF-Karten überträgt den angeforderten Kartenbereich als BBox in EPSG:3857. Hinzu kommen Layerkennung und technische WMS-Parameter, niemals Adresstext, Konto, Cookie oder Report-ID. Requests und WMS-Rohantworten bleiben `no-store` und werden von LandNutzen nicht persistiert. Der Dienst ist als externer Empfänger/Fachdienst dokumentiert; aus dem öffentlichen WMS wird kein Auftragsverarbeitungsverhältnis abgeleitet.

EU Data Residency (Schrems II)

Multi-Provider über Vercel AI Gateway

Mit Multi-Provider-Strategie (ADR-0004) muss jeder aktiv genutzte Provider einzeln EU-konform konfiguriert sein:

Provider	EU-Daten-Residency	Wie konfiguriert
Anthropic Claude	über AWS Bedrock EU (Frankfurt) oder Vertex AI EU	AI Gateway routet, Region pro Provider in Vercel-Settings
OpenAI	direkte EU-Region-API (verfügbar seit 2024)	bei API-Aufruf EU-Region setzen; Gateway routet
Google Gemini	Vertex AI EU-Regionen	über AI Gateway oder direkt Vertex

Vercel AI Gateway sitzt davor und garantiert Zero Data Retention: Daten werden nicht protokolliert, nicht für Training verwendet, nicht länger als für die Antwort nötig zwischengespeichert.

Standardvertragsklauseln (SCCs)

Trotz EU Data Residency formaler Abschluss von:

AVV / DPA mit Vercel gemäß Art. 28 DSGVO (deckt Gateway ab)
AVV mit jedem aktiv genutzten Provider (Anthropic, OpenAI, Google) — auch wenn nur über Gateway aufgerufen
AVV mit AWS (falls Bedrock für Anthropic-Modelle verwendet)
SCCs als Annex zu allen AVVs (EU-Kommissions-Beschluss 2021/914)
Subprocessor-Liste aktuell halten (alle drei Provider publizieren das)

Training-Opt-out

Nicht nötig — API-Daten aller drei Provider (anders als Consumer-Pläne) werden default nicht für Modelltraining verwendet. Im AVV bestätigen lassen. Vercel AI Gateway leitet ohne Logging an die jeweilige API weiter.

Lizenz-Attribution

Pflichten pro CC-BY-4.0-Quelle

Pflicht	Wo
Quellen-Block im Frontend (Footer-Komponente)	Persistent, sichtbar auf jeder Seite
Datenquellen-Block in PDF-Reports	Letzte Seite oder Footer
`/datenquellen`-Seite	Vollständige Liste mit Lizenz, Version, Last-Update
`docs/DATA-SOURCES.md` als Quelle der Wahrheit	Maintenance-Pflicht beim Einbinden neuer Quellen
Link zur Lizenz	`https://creativecommons.org/licenses/by/4.0/` mindestens auf der Datenquellen-Seite
Hinweis bei Änderungen	„Abgeleitete Karte basierend auf basemap.at Orthofoto" o. Ä.

Was wir explizit NICHT dürfen

Endorsement implizieren (so tun, als ob basemap.at uns empfiehlt)
Attribution entfernen / verstecken (auch in Cache, API, PDF)
Strengere Lizenz darüberlegen („all rights reserved" auf einem CC-BY-Bündel)
DRM verwenden, das Lizenzrechten widerspricht

Quellen-spezifische Lizenz-Gates

BEV Kataster

Anzeige und Lookup okay
Kommerzieller Planer-Export lizenzrechtlich kritisch — vor Phase 3 klären
Speichern, Anzeigen, Exportieren, kommerzielle Weitergabe sind getrennte Fragen

Altlastenportal-WFS — bedingte UBA-Weiterverwendung

Die schriftliche Bestätigung des Umweltbundesamts vom 11. August 2026 gilt ausschließlich für die Distribution altlastenportal-wfs-kontaminierte-flaechen, den Zweck public_display, die Capability report_lookup und Österreich. Sie ist keine CC-, OGD- oder pauschale kommerzielle Lizenz.

In Web, API und PDF muss die Attribution exakt „Datenquelle: Umweltbundesamt" sichtbar bleiben.
Erlaubt sind die zweckgebundene Speicherung und der Report-Lookup innerhalb des geprüften Scopes. Rohgeometrieexport, Weiterverteilung, Derivate, ML-/AI-Nutzung und eine pauschale kommerzielle Freigabe bleiben geschlossen.
Der Report prüft den Adresspunkt und die definierte Nähe bis 1 km, nicht die vollständige Parzellengeometrie. Eine Nicht-Listung garantiert keine Schadstofffreiheit.
Der Abrufzeitpunkt ist technische Provenienz und kein fachlicher Datenstand. Fehlt der Active Pointer oder scheitert ein Frische-, Rechte-, Qualitäts- oder Scope-Gate, muss der Consumer fail-closed degradieren.
Die Rechteprüfung ist spätestens am 11. Februar 2027 zu erneuern. Bis zu einem erfolgreichen Recheck darf ein abgelaufenes Gate nicht übergangen werden.

HORA / LFRZ

Reseller-Vertrag möglicherweise nötig für kommerzielle Nutzung
Workaround: WFS-Vektoren ziehen, eigene Intersection berechnen, keine WMS-Bilddaten reproduzieren
Status klären vor Phase-3-Launch

Lärminfo-WMS — eigener CC-BY-4.0-Vertrag

Die allgemeine HORA-/LFRZ-Sperre wird nicht pauschal aufgehoben. Geprüft ist ausschließlich die Lärminfo-Distribution laerminfo-wms-000804 mit den acht strategischen 2022-Layern für Straße, Schiene, Flug und Industrie/IPPC. Der versionierte Vertrag config/source-rights/laerm.public-display.json erlaubt unter CC BY 4.0 nur public_display in country:AT und exakt report_lookup, map_tile sowie legend.

Verbindlich sind attribution, sourceLink, licenseLink, changeNotice, nonEndorsement, strategicScreeningDisclaimer und noRawPersistence. Sichtbar bleiben „Datenquelle: www.laerminfo.at“, der CC-BY-4.0-Link, der LandNutzen-Änderungshinweis und die Klarstellung, dass Lärminfo.at die Auswertung weder bestätigt noch unterstützt.
Die Anzeige ist ein Screening aus berechneten Mittelungspegeln in vier Metern Höhe. Sie ist keine Messung, deckt nur strategisch kartierte Hauptquellen oberhalb der Meldeschwellen ab und ersetzt kein schalltechnisches Gutachten. Insbesondere Industrie/IPPC ist nur in den ausgewiesenen Ballungsräumen kartiert; ein No-Hit ist keine Ruhegarantie.
Für report_lookup/GetFeatureInfo erhält der LFRZ-WMS eine kleine WGS84-BBox um die ausgewählte Koordinate. GetMap/PNG für Web- und PDF-Karten überträgt den angeforderten Kartenbereich als BBox in EPSG:3857; hinzu kommen jeweils Layerkennung und technische WMS-Parameter. Übertragen werden weder Adresstext, Konto, Cookie noch Report-ID. Dieser bereits im Legacy-Pfad vorhandene externe Datenfluss wird durch den Release-Cutover um keinen neuen Empfänger und keine neue personenbezogene Datenkategorie erweitert. Datenschutzhinweis und VVT weisen die tatsächliche Empfängerrolle seit dem Consumer-Go-live aus; aus dem öffentlichen WMS folgt nicht automatisch ein Auftragsverhältnis.
storageAllowed=false, cacheAllowed=false und retentionDays=0 verbieten einen WMS-Rohdatenbestand oder persistenten Provider-Cache. Requests laufen no-store; Quality-Evidence speichert nur Prüfsummen und Ergebnis-Summaries. Davon getrennt darf der vom Nutzer angeforderte Report die abgeleiteten Pegelbänder und den Abrufzeitpunkt nach seinem bestehenden Lösch- und Kontolifecycle enthalten.
Das Kartierungsjahr 2022 ist der fachliche Quellenstand. Die maximal 24-stündige Release-Freshness und die achtstündige Erneuerung belegen nur die technische Erreichbarkeit und Vertragskonformität des Live-Dienstes; sie dürfen nicht als jüngere Lärmkartierung dargestellt werden.

Die Rechteprüfung belegt den distributions- und zweckgenauen Review. Der getrennte Produktionsnachweis belegt seit 26. August 2026 zusätzlich Pointer, öffentliche Provenienz sowie Report-, Karten-, Legenden-, Web- und PDF-Consumer. Die Initial-Aktivierung erfolgte manuell bestätigt per GitHub Actions; sie wird nicht als bereits ausgeführter Vercel-Cron dargestellt. Der erste planmäßige Acht-Stunden-Renewal bleibt bis zu seinem eigenen Readback offen.

GeoSphere HORA-Hitzelayer — separate CC-BY-4.0-Distribution

Die Quelle geosphere-hora-hitzelayer erlaubt ausschließlich die eigenständig geprüfte GeoSphere-Distribution hora_hitzelayer-v1-1km unter CC BY 4.0 Legalcode. Dieser Rechtevertrag eröffnet weder HORA 3.0 noch HORA-Pass oder den LFRZ-WMS; HORA 3.0, HORA-Pass und LFRZ-WMS bleiben unverändert gesperrt.

Verbindlich sind attribution, sourceLink, licenseLink, termsLink, changeNotice, nonEndorsement, neutralPresentation, historicalClimatePeriodDisclaimer und regionalClimateIndicatorDisclaimer.
Erlaubt sind nur public_display, report_lookup und country:AT auf Basis eines eigenständigen qualifizierten Active Pointers.
Die historischen 1-km-Schwellentage 1991–2020 bleiben neutral: keine Ampel, keine Prognose, keine Preiswirkung, keine parzellenscharfe Messung. Der Klima-Block 2025 beschreibt ausdrücklich eine andere Periode.
Standortabfragen senden weder Adresse noch Koordinate an GeoSphere; ein lokaler Snapshot erzeugt keine zusätzliche personenbezogene Persistenz. Die Produktionsaktivierung belegt den qualifizierten Quellenrelease und Pointer sowie getrennt den späteren öffentlichen Consumer-Readback auf Merge 08d55c3. Dafür wurde ein nicht persistierender GET mit dem bereits versionierten öffentlichen Referenzpunkt verwendet; kein Report, Permalink oder Kundendatensatz wurde gespeichert. Ein Rechte-Review oder Pointer allein bleibt weiterhin kein Auslieferungsnachweis.

Siehe Rechteprüfung sowie Quellenvertrag.

Google Street View · Bing Streetside

Maps Platform ToS verbieten ML-Training, Bulk-Download, dauerhaftes Caching > 30 Tage, Datenbank-Aufbau
Verstoß = API-Konto-Sperre + zivilrechtliche Schritte
Nicht für AI-Auswertung verwenden
Saubere Alternative: Mapillary (CC BY-SA) + eigene Fassaden-Erfassung

Microsoft Building Footprints (ODbL)

Kommerziell erlaubt
Share-Alike-Klausel auf abgeleitete Datensätze beachten — wenn wir aus Building Footprints eine eigene DB ableiten, muss die unter ODbL stehen

KPC / LEADER / Förderungen

Keine offizielle API
Web-Scraping verstößt gegen ToS mancher Portale
Sauberer Weg: RAG mit kuratierten PDF-Richtlinien, manuelle quartalsweise Validierung

Output-Disclaimer (in jedem Report)

Diese Auswertung dient ausschließlich der Information und ersetzt keine
rechtsverbindliche Vermessung, behördliche Auskunft oder fachliche
Prüfung durch Ziviltechniker oder Sachverständige. Datengrundlage:
[Auflistung der verwendeten Quellen mit Lizenz und Stand].

Diese Disclaimer-Zeile ist technisch erzwingbar über System-Prompt der LLM-Pipeline und HTML-Template — nicht optional.