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 seit dem 3. August 2026 produktiv (Migration 0038, Produktions-Readback im Nachweis docs/evidence/met-01-live-2026-08-03.md). 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.

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.

Nachtrag Adresssuche (ADR-0078, 05.10.2026): Auf Startseite und Report-Formular sendet die Adresssuche prefer=noe. Ohne ausdrückliche Standortfreigabe nutzt der Server dort nicht mehr den IP-Standort von Vercel, sondern einen festen Punkt in Niederösterreich (48,2 / 15,6); eine erteilte Freigabe bleibt maßgeblich. Das Report-Geocoding fragt Nominatim weiter genau einmal je Report ab (bis zu 10 Kandidaten, feste NÖ-viewbox nur als Ranking-Hinweis, kein Filter) und wählt den ersten Treffer in Niederösterreich, sonst den ersten Treffer überhaupt. Der Report nennt die gefundene Adresse sichtbar als „Gefunden: …“ (Web und PDF) und speichert sie strukturiert unter meta.address.resolved (Straße, Hausnummer, Postleitzahl, Ort). Das Feld ist Teil des Report-JSON und unterliegt der bestehenden Aufbewahrung (anonym 90 Tage, kontogebunden bis zur Löschung); es kommen keine neuen Empfänger hinzu. Standort-Check, PV-Rechner und Workspace senden kein prefer und nutzen den bisherigen IP-Bias.

Ö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.
Seit 04.10.2026 zählt der Standort-Check serverseitig kennungsfreie MET-01-Tagesaggregate: je bestätigter Prüfanfrage genau ein funnel_start und ein Endzustand (funnel_complete bei mindestens einer Karte mit Befund, sonst funnel_honest_terminal). Seit Migration 0065 kommt je bestätigter Anfrage genau ein server_run hinzu: fester Ergebniscode (success, rate_limited, internal_error), Laufzeitklasse, Instanz-Näherung und der signierte, grobe Bundeslandcode; Provider fest none, Kosten strukturell known_zero = 0. Keine Adresse, Koordinate, Gemeinde, Kartenergebnis, IP-, Cookie-, Session- oder User-Agent-Bezug, keine externen Analysedienste. Löschung der Tageswerte nach dem 30-Tage-Fenster wie bei MET-01; der feste 14-Tage-Ausgangswert enthält weder Tag noch Bundesland und bleibt erhalten (Vertrag site-check-v1, Abschnitt „Messung“; Datenschutzerklärung /datenschutz#standort-check). Eigene Prüfläufe von LandNutzen zählen seit 06.10.2026 getrennt (siehe „Eigene Prüfläufe“ unten); der Ausgangswert des Standort-Checks ist am 06.10.2026 neu verankert (Fenster 07.10. bis 20.10.2026, eingefroren ab 21.10.2026). Bis 04.10.2026 war der Standort-Check nicht in dieser Messung enthalten.
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. Auch die österreichweite Hochwasser-Lane hochwasser-at (außerhalb des NÖ-Piloten) liest einen bei LandNutzen gespeicherten, release-gebundenen Snapshot; Adresse und Koordinate gehen weder an Umweltbundesamt, BMLUK noch an den LFRZ-Kartendienst. Nur der Publisher fragt vor einer Aktivierung feste, öffentliche Kanarienpunkte beim amtlichen WMS ab – nie Nutzerstandorte. Ebenso lesen Radon, ÖV-Güteklassen und die Flächenwidmung Niederösterreich seit dem 27. September 2026 nur gespeicherte, release-gebundene Snapshots; AGES, ÖROK/AustriaTech und das Land Niederösterreich erhalten dafür weder Adresse noch Koordinate. Dasselbe gilt seit dem 30. September 2026 für die Wiener Widmungs-Lane widmung-wien (Migration 0063): Die Stadt Wien erhält weder Adresse noch Koordinate. Ebenso seit dem 4. Oktober 2026 für die Vorarlberger Widmungs-Lane widmung-vorarlberg (Migration 0064): Das Land Vorarlberg erhält weder Adresse noch Koordinate. Ebenso seit dem 8. Oktober 2026 für die oberösterreichische Widmungs-Lane widmung-oberoesterreich (Migration 0068): Das Land Oberösterreich erhält weder Adresse noch Koordinate. Die Denkmalschutz-Karte (ADR-0073, seit 30. September 2026 produktiv) liest ebenso nur einen gespeicherten, release-gebundenen Stand der BDA-Denkmalliste mit BEV-Grundstücksumrissen; Bundesdenkmalamt und BEV erhalten weder Adresse noch Koordinate. Die Breitband-Karte (ADR-0074, seit 30. September 2026 produktiv) liest nur den gespeicherten Breitbandatlas-Snapshot; Breitbandbüro, RTR-GmbH und der Atlas-Kartendienst erhalten weder Adresse noch Koordinate, nur der Publisher fragt feste, öffentliche Kanarienpunkte beim amtlichen WMTS ab. Dasselbe gilt für die Karte „Wildbach- und Lawinengefahrenzonen“ (wlv-gzp, ADR-0075, seit 30. September 2026 produktiv): Sie liest nur einen gespeicherten Snapshot des WLV-Gefahrenzonenplans; WLV, BMLUK und LFRZ erhalten keine Nutzerstandorte, nur der Publisher fragt feste, öffentliche Kanarienpunkte beim amtlichen WMS ab. Widmungs-WMS und Widmungs-Kartenausgabe (NÖGIS #413), sämtliche BEV-Exportfähigkeiten einschließlich des separat aktivierten DXF-Consumers sowie der nicht konfigurierte LCZ-Scope 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 (Stand 07.10.2026, Registry lib/content/articles.ts) zwölf menschlich freigegebene Beiträge, davon drei Datenstories; es gibt keine unfreigegebenen Entwürfe. Andreas Ostheimer hat die drei zuletzt ergänzten CON-02-Inhalte, alle drei CON-03-Datenstories und drei Erklärbeiträge ausdrücklich freigegeben; der CON-02-Freigabenachweis und die CON-03-Freigabenachweise (erste Datenstory, zweite Datenstory, dritte Datenstory und Erklärbeiträge) belegen 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.

Eigene Prüfläufe (ADR-0079, Migration 0066). Läufe von LandNutzen selbst zählen getrennt in tool_metrics_internal_daily (nur Tag, Tool-ID, Zählerart, Anzahl) und nicht in den öffentlichen Kennzahlen. Erkannt werden sie ausschließlich an einer signierten Markierung im Header X-LandNutzen-Internal-Run: dem Prüfmodus-Flag, das nur ein Plattform-Admin mit 2FA über /admin/metrics als Cookie ln_qa setzt (Ablaufzeit und HMAC-Signatur, keine Kennung, höchstens zwölf Stunden), oder einem Skript-Token aus METRICS_INTERNAL_RUN_TOKEN. Keine Erkennung über IP, Adresse, User-Agent oder Konto. Öffentliche Besucher erhalten weder Cookie noch Header; ihre Anfragen und Daten sind unverändert. Die Werkzeuganfragen bleiben auch im Prüfmodus cookielos. Löschung wie bei den Tageswerten (30-Tage-Fenster, metrics-prune).

Org-gebundene Workspace-Standorte (`workspace_sites`, ADR-0068 / Issue #570)

Der T06-Standortvergleich ist der einzige Pfad, der Standort-Check-Daten speichert — ausschließlich authentifiziert und org-gebunden; der öffentliche Standort-Check bleibt nach ADR-0052 nicht persistent.

Gespeichert werden je Standort: ausgewählte Adresse, Koordinate, Bundesland, optionales Label, der Datenpass-Snapshot (SiteCheckResult), organization_id, created_by und Zeitstempel. Keine Signaturen, keine IP-Hashes, keine Cookies.
Rechtsgrundlage: Art. 6 (1) (b) — Vertragsanbahnung/-erfüllung mit der Beta-Organisation; Adressen sind Objekt-, nicht Personenadressen, können aber personenbeziehbar sein und werden daher wie personenbezogene Daten behandelt.
Zugriff: nur Mitglieder der Organisation über bestehende memberships; jede Query filtert auf organization_id (wirksame Schranke, per kompilierter SQL und PostgreSQL-Test belegt). Die RLS-Policies nach Migration 0002 sind angelegt, greifen für die Neon-App-Rolle jedoch nicht. Nicht-Mitglieder erhalten 404.
Löschung: einzeln über DELETE /api/v1/org/{slug}/workspace/sites/{id} (Rollen owner/admin/member) oder per ON DELETE CASCADE mit der Organisation. Beim Löschen eines Kontos wird created_by genullt, der Standort bleibt Eigentum der Organisation. Keine automatische Frist; Snapshots gelten ab 30 Tagen als veraltet und sind zur Erneuerung markiert.
Aktivierung: nur mit WORKSPACE_COMPARE_ENABLED=true und Org-Slug in WORKSPACE_COMPARE_ORG_ALLOWLIST. Der Betriebsschalter ist in Produktion gesetzt (Beleg: Die Live-OpenAPI /api/v1/openapi.json führt die /org/{slug}/workspace/*-Pfade, Abruf 07.10.2026); freigeschaltet sind nur die Beta-Organisationen der Allowlist (ihr Inhalt ist hier nicht belegt), für alle anderen antworten Seite und API mit 404.

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` (nicht im öffentlichen Doku-Portal verfügbar), 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` (nicht im öffentlichen Doku-Portal verfügbar), `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` (nicht im öffentlichen Doku-Portal verfügbar). 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: true` und `Sunset: Wed, 31 Dec 2025 23:59:59 GMT` gesetzt; die Route `app/api/report/route.ts` ist im Code (Stand 07.10.2026) weiterhin vorhanden, im Repo ruft kein UI-Code sie mehr auf (Report-Seiten nutzen `/api/v1/report`). Entfernung offen

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 (nicht im öffentlichen Doku-Portal verfügbar): 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 + AI Gateway)	Hosting, Serverfunktionen (keine Edge-Runtime), LLM-Routing	Art. 6 (1) (b) Vertragserfüllung	Serverfunktionen: Region Frankfurt am Main (`fra1`, `vercel.json` `regions`) seit 06.10.2026, davor `iad1` (Washington, USA); Auslieferung über das weltweite Vercel-Netzwerk, keine ausschließliche EU-Verarbeitung (`/datenschutz`). AI Gateway routet pro Provider auf EU-Region (Zielzustand, siehe AVV-Matrix)
Neon (Postgres-Hosting)	PostgreSQL + PostGIS + pgvector	Art. 6 (1) (b)	Frankfurt am Main (AWS `eu-central-1`)
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
world4you (SMTP-Maildienst)	Magic-Link-Versand und automatische Betriebsmails (Pilotanfragen, Cron-/Renewal-Alarme, Datenquellen-Tagesdigest, Altlasten-Review) ausschließlich an `office@ostheimer.at`	wie Konto und Sicherheitsdaten in `/datenschutz`: Art. 6 (1) (b), Sicherheits- und Auditdaten zusätzlich (f)	Rechenzentrum und Vertragsrolle sind hier nicht belegt (offen, #290). Transport `EMAIL_SERVER` über `lib/mail/send.ts` (ADR-0038); ohne `EMAIL_SERVER` wird nichts versendet, einen Resend-Fallback für Betriebsmails gibt es nicht
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 — auf Startseite und Report-Formular (`prefer=noe`, ADR-0078) nicht einmal dieser, dort rankt ein fester Punkt in Niederösterreich. 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`). Genau eine Anfrage je Report (bis zu 10 Kandidaten; feste NÖ-`viewbox` nur als Ranking-Hinweis, keine zusätzlichen Personendaten, ADR-0078)
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.
AGES-Radonpotenzialkarte / LFRZ-OGC-API	Radon-Baustein des Standort-Reports (Live-Abfrage)	Art. 6 (1) (b)	Öffentlicher österreichischer Fachdienst (`gis.lfrz.gv.at`, Collection `i000101:radonpotenzialklassen`). Der Server überträgt je Report eine kleine WGS84-BBox von ±0,0005 Grad (rund 75 × 111 m) um die Koordinate sowie Collection-Kennung und technische Parameter (`f=json`, `limit=25`), niemals Adresstext, Konto, Cookie oder Report-ID. Die Antwort kann bis zu 24 Stunden im Data-Cache der Hosting-Plattform liegen (`revalidate: 86400`). Der Standort-Check nutzt diesen Dienst nicht, sondern den release-gebundenen Snapshot (Migration 0056). Aus dem öffentlichen Dienst wird kein Auftragsverarbeitungsverhältnis abgeleitet.
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)

Hosting und Datenbank (Stand 07.10.2026)

Serverfunktionen: Vercel-Region fra1 (Frankfurt am Main), gesetzt in vercel.json (regions). Bis zum 06.10.2026 liefen sie in iad1 (Washington, USA). Beleg für den Wechsel: docs/evidence/vercel-funktionsregion-fra1-2026-10-06.md (Antwort-Header x-vercel-id vorher fra1::iad1::…, also Edge-Knoten Frankfurt und Funktion in iad1, nachher fra1::fra1::…; am 07.10.2026 erneut so gelesen).
Datenbank: Neon, Region aws-eu-central-1 (Frankfurt am Main).
Auslieferung: Inhalte laufen weiterhin über das weltweite Vercel-Netzwerk. LandNutzen behauptet keine ausschließliche EU-Verarbeitung; die öffentliche Datenschutzerklärung (/datenschutz, Abschnitte „Website und Hosting“ und Empfänger) nennt dieselben Angaben und die Rechtsgrundlage für Übermittlungen außerhalb des EWR (Angemessenheitsbeschluss oder geeignete Garantien, insbesondere EU-Standardvertragsklauseln).
Datenschutzerklärung: Sie nennt den Verarbeitungsort Frankfurt am Main seit #673 (06.10.2026); davor stand dort nur, dass LandNutzen auf Vercel läuft und die Datenbank bei Neon betrieben wird, ohne Region.

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.
Der Snapshot wird täglich als Vercel-Cron erneuert (renew-altlasten-snapshot, ADR-0080). Eine Reviewpflicht meldet der Lauf per Betriebsmail an office@ostheimer.at statt als GitHub-Issue; bei Reviewpflicht bleibt die Aktivierung ein menschlicher Schritt. Reine Geometrie-Verschiebungen unter 1 cm an bereits veröffentlichten Flächen werden seit #660 ohne Review erneuert (Runbook). Rechte, Attribution und Scope ändern sich dadurch nicht.

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
Die offenen INSPIRE-Hochwasserflächen der Hochwasserrichtlinie und die BWV-Gefahrenzonen (hochwasser-at, siehe unten) nennen HORA zwar als eine Herleitungsquelle, sind aber eine eigenständige, vom BMLUK unter CC BY 4.0 veröffentlichte Distribution mit eigenem Review. Sie heben diese Sperre nicht auf: kein HORA-Aufruf, keine HORA-Kartenbilder, keine HORA-Aussage.

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 (nicht im öffentlichen Doku-Portal verfügbar) 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.

AGES-Radonpotenzialkarte — Report live, Standort-Check als Snapshot

Report (Legacy-Live-Pfad, report_lookup): lib/geo/radon.ts fragt je Report serverseitig die OGC API Features der LFRZ-Plattform ab. Empfänger ist der öffentliche Fachdienst gis.lfrz.gv.at; übertragen werden eine WGS84-BBox von ±0,0005 Grad um die Koordinate, die Collection-Kennung und technische Parameter, nie Adresstext, Konto, Cookie oder Report-ID. Rechtsgrundlage Art. 6 Abs. 1 lit. b DSGVO. Die Antwort kann bis zu 24 Stunden im Data-Cache der Hosting-Plattform liegen. Datenschutzerklärung (/datenschutz, Empfängertabelle) und VVT weisen den Datenfluss aus.
Standort-Check (point_lookup): liest ausschließlich den release-gebundenen Snapshot radon_gemeinde_current; an AGES oder LFRZ werden dafür keine Standortdaten übertragen.
Rechte-Review, seit 27.09.2026 eingespielt (Datei-SHA-256 60eb81fe…6a057, conditional, Recheck 25.09.2027): config/source-rights/radon-onrap.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) (CC BY 4.0 für die Karte, CC BY 3.0 für die Gemeindegrenzen, beide mit Lizenzlink). Die geplante Umstellung des Reports auf den Snapshot beendet die Live-Übermittlung (TODO in docs/DATA-SOURCES.md).

ÖV-Güteklassen (ÖROK/BMIMI) — „Keine Lizenz, nur Haftungsausschluss“

Geprüft ist ausschließlich die Distribution oev-gk-nap-polygone-werktag: der Polygon-Layer des Werktags-Stichtags 22.10.2025 (Ausgabe 2025_revised) der ÖROK gemeinsam mit dem BMIMI, bereitgestellt von AustriaTech über mobilitydata.gv.at. Der NAP-Eintrag nennt „Kein(e) Lizenz und kein Vertrag“; es gilt nur der ÖROK-Haftungsausschluss. Eine ausdrückliche Rechteeinräumung fehlt, eine CC-Lizenz wird nirgends behauptet. Der Review config/source-rights/oev-gueteklassen.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt deshalb nur public_display, point_lookup und Region AT, begrenzt auf die kostenlose Punktanzeige. Er ist seit 27.09.2026 nach menschlicher Freigabe per --apply --ack <SHA> eingespielt (conditional, Recheck 25.03.2027).

Verbindlich sind attribution, sourceLink, termsLink, liabilityDisclaimer, noServiceEntitlementNotice, modelledReferenceDayNotice, nonEndorsement und noGeometryRedistribution. Die Karte „Öffi-Anbindung“ nennt „Datenquelle: ÖROK/BMIMI, ÖV-Güteklassen (bereitgestellt von AustriaTech über mobilitydata.gv.at)“ ohne Lizenzlink, weil es keine Lizenz gibt.
Die Güteklasse ist ein Modell der Erschließungsqualität zu einem Stichtag, keine Fahrplanauskunft; eine Güteklasse begründet keinen Anspruch auf ein ÖV-Angebot.
Nicht freigegeben sind kommerzielle Ausgabe (commercialUseAllowed=false), Weitergabe und Export, abgeleitete Datensätze und ML/KI-Nutzung. Speicherung des Snapshots und Cache sind für den Punktlookup zulässig.
Standortabfragen lesen nur den lokalen Snapshot; es entsteht kein neuer Empfänger. Die Flächen werden weder ausgegeben noch exportiert.

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar).

Generalisierte Widmungsumhüllende Niederösterreich — Standort-Check

Geprüft ist ausschließlich die Distribution widmung-noe-wfs-snapshot: der WFS-Layer OGD:RRU_WI_HUELLE des Landes Niederösterreich unter CC BY 4.0 mit Ergänzungen des Landes (Nutzungsbedingungen, Seitenstand 24.08.2026). Der Review config/source-rights/widmung-noe.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt nur public_display, point_lookup und Region AT. Er ist seit 27.09.2026 nach menschlicher Freigabe per --apply --ack <SHA> eingespielt (conditional, Recheck 25.03.2027). Nicht Teil des Reviews sind der WMS-Kanal widmung-noe-wms, die Kartenausgabe zoning_geojson und jeder Export (NÖGIS #413).

Verbindlich sind attribution, licenseLink, changeNotice, nonEndorsement und legalDisclaimer. Die Karte nennt „Datenquelle: Land Niederösterreich - data.noe.gv.at“ mit Datensatz-, CC-BY- und Nutzungsbedingungs-Link, weist die Zuordnung der Kategorie der generalisierten Umhüllenden und das Grenzband von 5 m aus, stellt klar, dass das Land die Auswertung weder bestätigt noch unterstützt, und nennt den Rechtskraft-Stichtag. Maßgeblich ist allein der rechtsgültige Flächenwidmungsplan der Gemeinde.
Ein Nullbefund heißt nie „kein Bauland“ oder „Grünland“: Die Umhüllende enthält Grünland-Land- und Forstwirtschaft, Verkehrsflächen und Gewässer nicht. Die Quelle gilt höchstens 700 Tage ab dem Rechtskraft-Stichtag als frisch (maxStalenessDays).
Standortabfragen lesen nur den lokalen Snapshot; es entsteht kein neuer Empfänger, einen WMS-Fallback gibt es im Werkzeug nicht. Die Quelle enthält keine personenbezogenen Daten.
Die Bitte der Nutzungsbedingungen, Anwendungen dem Land zu melden, ist eine Aufforderung, keine Lizenzbedingung; die Meldung findet derzeit nicht statt (offen).

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar) und Quellenprüfung (nicht im öffentlichen Doku-Portal verfügbar).

Hochwasser Österreich (INSPIRE Wasser) — eigener CC-BY-4.0-Vertrag

Geprüft ist ausschließlich die Distribution lfrz-000801-hochwasser-gml-snapshot: fünf per SHA-256 gebundene INSPIRE-Downloads des Umweltbundesamts (Eigentümer BMLUK) mit den HQ30-/HQ100-/HQ300-Überflutungsflächen der Hochwasserrichtlinie (Meldung 2020) sowie den roten und gelben Gefahrenzonen der Bundeswasserbauverwaltung (Stand Oktober 2020), alle laut Metadaten unter CC BY 4.0. Der Review config/source-rights/hochwasser-at.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt nur public_display, point_lookup und Region AT. Er ist seit 27.09.2026 nach menschlicher Freigabe per --apply --ack <SHA> eingespielt (Datei-SHA-256 ba61ef43…95299, conditional, Recheck 25.03.2027); weil erst Migration 0059 die Registry-Zeile anlegt, lief die Migration vor dem Review.

Verbindlich sind attribution, sourceLink, licenseLink, changeNotice, nonEndorsement, floodScreeningDisclaimer und noGeometryRedistribution. Jede Hochwasserkarte zeigt „Datenquelle: BMLUK / Umweltbundesamt – Hochwasserüberflutungsflächen (Hochwasserrichtlinie 2020) und Gefahrenzonen der Bundeswasserbauverwaltung, CC BY 4.0“, verlinkt Quelle und Lizenz, nennt die Vereinfachung um höchstens 2 m und stellt klar, dass BMLUK und Umweltbundesamt die Auswertung weder unterstützen noch bestätigen.
Der Screening-Hinweis ist Pflicht: nur amtlich ausgewiesene Risikogebiete (APSFR) und gemeldete BWV-Gefahrenzonenpläne, keine WLV-Zonen, kein Starkregen; kein Treffer ist kein Nullrisiko; kein Ersatz für den Gefahrenzonenplan der Gemeinde oder ein Gutachten.
Standortabfragen lesen nur den lokalen Snapshot. Weder Adresse noch Koordinate verlassen LandNutzen; es entsteht kein neuer Empfänger. Die gespiegelten Geometrien werden nicht ausgegeben, exportiert oder als Karte dargestellt.
redistributionAllowed=false und mlAiAllowed=false sind interne Governance-Entscheidungen, keine Behauptung über die Lizenz.

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar), Quellen-Evidence (nicht im öffentlichen Doku-Portal verfügbar) und ADR-0072 (nicht im öffentlichen Doku-Portal verfügbar).

Generalisierte Flächenwidmung Wien — eigener CC-BY-4.0-Vertrag

Geprüft ist ausschließlich die Distribution widmung-wien-wfs-snapshot: der WFS-Layer ogdwien:GENFLWIDMUNGOGD der Stadt Wien unter CC BY 4.0 mit den OGD-Nutzungsbedingungen der Stadt. Der Review config/source-rights/widmung-wien.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt nur public_display, point_lookup und Region AT. Er ist seit 30.09.2026 nach menschlicher Freigabe per --apply --ack 59c05860…51d21a eingespielt (conditional, Recheck 28.03.2027); weil erst Migration 0063 die Registry-Zeile anlegt, lief die Migration vor dem Review.

Verbindlich sind attribution, licenseLink, changeNotice, nonEndorsement und legalDisclaimer. Jede Widmungskarte für Wien zeigt „Datenquelle: Stadt Wien – data.wien.gv.at“, verlinkt Datensatz, Lizenz und Nutzungsbedingungen, nennt den Grenzabstand von 5 m und stellt klar, dass die Stadt die Auswertung weder bestätigt noch unterstützt und dass allein das Plandokument des Gemeinderats maßgeblich ist.
Standortabfragen lesen nur den lokalen Snapshot; es entsteht kein neuer Empfänger. Die Geometrien werden nicht ausgegeben oder exportiert.
redistributionAllowed=false und mlAiAllowed=false sind interne Governance-Entscheidungen, keine Behauptung über die Lizenz.

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar), Quellenprüfung (nicht im öffentlichen Doku-Portal verfügbar) und ADR-0076 (nicht im öffentlichen Doku-Portal verfügbar).

Flächenwidmungsplan Vorarlberg — eigener CC-BY-4.0-Vertrag

Geprüft ist ausschließlich die Distribution widmung-vorarlberg-wfs-snapshot: der WFS-Layer vogis:fwp_flaeche des Landes Vorarlberg unter CC BY 4.0 (Distributionen, ISO-Metadaten und VoGIS-Seite des Landes). Der Review config/source-rights/widmung-vorarlberg.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt nur public_display, point_lookup und Region AT. Er ist seit 04.10.2026 nach menschlicher Freigabe per --apply --ack 5c339743…f88a7 eingespielt (conditional, Recheck 04.04.2027); weil erst Migration 0064 die Registry-Zeile anlegt, lief die Migration vor dem Review (Nachweis (nicht im öffentlichen Doku-Portal verfügbar)).

Verbindlich sind attribution, licenseLink, changeNotice, nonEndorsement und legalDisclaimer. Jede Widmungskarte für Vorarlberg zeigt den Quellvermerk „© Land Vorarlberg“, verlinkt Datensatz, Lizenz und die Lizenzseite des Landes, nennt den Grenzabstand von 5 m, stellt klar, dass das Land die Auswertung weder bestätigt noch unterstützt und dass allein der von der Gemeinde beschlossene und kundgemachte Plan maßgeblich ist, und nennt eine Ersichtlichmachung nie „Widmung“.
Ältere, restriktive „Nutzungsbestimmungen für Geodaten des Landes Vorarlberg“ (PDF vom 07.05.2025) sind im Rechte-Review bewertet: Für diesen Datensatz gilt die ausdrückliche CC-BY-4.0-Lizenz; eine Information an das Landesamt bleibt eine optionale Vorsichtsmaßnahme und ist offen.
Standortabfragen lesen nur den lokalen Snapshot; es entsteht kein neuer Empfänger. Die Geometrien werden nicht ausgegeben oder exportiert.
redistributionAllowed=false und mlAiAllowed=false sind interne Governance-Entscheidungen, keine Behauptung über die Lizenz.

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar), Quellenprüfung (nicht im öffentlichen Doku-Portal verfügbar) und ADR-0077 (nicht im öffentlichen Doku-Portal verfügbar).

Flächenwidmung Oberösterreich — eigener CC-BY-4.0-Vertrag

Geprüft ist ausschließlich die Distribution widmung-oberoesterreich-wfs-snapshot: der WFS-Layer HVD:FLWI_Widmungen_Flächen des Landes Oberösterreich (DORIS) unter CC BY 4.0 (ISO-Metadaten des Landes, data.gv.at-Eintrag, allgemeine Bedingungen „Open Oberösterreich“). Der Review config/source-rights/widmung-oberoesterreich.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt nur public_display, point_lookup und Region AT. Er ist seit 08.10.2026 nach menschlicher Freigabe per --apply --ack 0868d922…082022d eingespielt (conditional, Recheck 07.04.2027); weil erst Migration 0068 die Registry-Zeile anlegt, lief die Migration vor dem Review (Nachweis (nicht im öffentlichen Doku-Portal verfügbar)).

Verbindlich sind attribution, licenseLink, changeNotice, nonEndorsement und legalDisclaimer. Jede Widmungskarte für Oberösterreich zeigt den Quellvermerk „Datenquelle: Land Oö., doris.at“, verlinkt Datensatz, Lizenz und die Nutzungsbedingungen des Landes, nennt den Grenzabstand von 5 m und die Vereinfachung der Grenzen, stellt klar, dass das Land die Auswertung weder bestätigt noch unterstützt und dass allein der von der Gemeinde beschlossene und kundgemachte Plan maßgeblich ist.
Offener Vorbehalt: Der WFS steht in den ISO-Metadaten des Landes, ist aber im data.gv.at-Eintrag nicht als eigene Distribution geführt. Die Nutzungsbedingungen des DORIS-Portals (Vermerk „(c) DORIS“) betreffen das Kartenangebot DORIS WebOffice und sind im Review bewertet; eine Rückfrage an das Land bleibt eine optionale Vorsichtsmaßnahme.
Standortabfragen lesen nur den lokalen Snapshot; es entsteht kein neuer Empfänger. Die Geometrien werden nicht ausgegeben oder exportiert. Zweck und Zusatztext sind Freitexte der Gemeinden und werden nur für den abgefragten Punkt gezeigt.
redistributionAllowed=false und mlAiAllowed=false sind interne Governance-Entscheidungen, keine Behauptung über die Lizenz.

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar), Quellenprüfung (nicht im öffentlichen Doku-Portal verfügbar) und ADR-0081 (nicht im öffentlichen Doku-Portal verfügbar).

Denkmalliste des Bundesdenkmalamts mit BEV-Grundstücksumrissen — Standort-Check

Geprüft ist ausschließlich die Distribution bda-denkmalliste-csv-bev-dkm-snapshot: die neun per SHA-256 gebundenen Landeslisten der Denkmalliste nach § 3 DMSG (Stand 19.06./23.06.2026) und die Umrisse der darin genannten Grundstücke aus der BEV-Katastralmappe (Stichtag 01.04.2026). data.gv.at nennt für die Listen CC BY (ohne Version), das BDA bezeichnet sie als freies Werk nach § 7 Abs. 1 UrhG; LandNutzen erfüllt vorsorglich die CC-BY-Pflichten. Die Umrisse stehen unter CC BY 4.0 (BEV, schriftliche Bestätigung zur Spiegelung vom 04.08.2026). Der Review config/source-rights/bda-denkmalschutz.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt nur public_display, point_lookup und Region AT. Er ist seit 30.09.2026 nach menschlicher Freigabe per --apply --ack <SHA> eingespielt (Datei-SHA-256 4418712c…9ac22f, conditional, Recheck 01.10.2027); die Migration 0060 lief davor (Nachweis (nicht im öffentlichen Doku-Portal verfügbar)).

Verbindlich sind attribution, sourceLink, licenseLink, changeNotice, nonEndorsement, bevAttribution, notLegallyBindingDisclaimer, noGeometryRedistribution und noOwnerData. Jede Denkmalkarte nennt „Datenquelle: Bundesdenkmalamt, Denkmalliste gemäß § 3 DMSG (Stand Juni 2026)“ und „Grundstücksumrisse: BEV – Bundesamt für Eich- und Vermessungswesen (data.bev.gv.at)“ mit je eigenem Lizenzlink, beschreibt die Zuordnung als Bearbeitung und stellt klar, dass weder BDA noch BEV die Auswertung erstellt oder geprüft haben.
Pflichthinweis: Die Liste ist laut BDA rechtlich nicht verbindlich und nennt den Umfang des Schutzes nicht; die Karte ist ein Hinweis, keine Rechtsauskunft. Ein Nullbefund ist keine Entwarnung.
Standortabfragen lesen nur den lokalen Snapshot. Die Umrisse werden weder ausgegeben noch exportiert; Eigentümer- und Personendaten werden nicht übernommen (nur KG, GNR, RSTATUS, Geometrie).
redistributionAllowed=false und mlAiAllowed=false sind interne Governance-Entscheidungen, keine Behauptung über die Lizenz.

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar), Quellen-Evidence (nicht im öffentlichen Doku-Portal verfügbar) und ADR-0073 (nicht im öffentlichen Doku-Portal verfügbar).

Breitbandatlas (offene Daten) — Report live, Standort-Check als Snapshot

Geprüft ist ausschließlich die Distribution breitbandatlas-ogd-raster100m: die per SHA-256 gebundenen data.gv.at-Downloads Festnetz-Verfügbarkeit Q1/2026 (CSV) und geförderter Ausbau Stand 30.06.2026 (GeoPackage), laut Katalog je Distribution unter CC BY 3.0 AT. Der Review config/source-rights/rtr-breitband.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt nur public_display, point_lookup und Region AT. Er ist seit 30.09.2026 nach menschlicher Freigabe per --apply --ack <SHA> eingespielt (Datei-SHA-256 774bc37c…58b65f8d, conditional, Recheck 28.03.2027); die Migration 0061 lief davor (Nachweis (nicht im öffentlichen Doku-Portal verfügbar)).

Verbindlich sind attribution, sourceLink, licenseLink, changeNotice, nonEndorsement, reportedAvailabilityDisclaimer und noBulkRedistribution. Jede Befundkarte nennt „Datenquelle: Breitbandatlas, Breitbandbüro / BMWKMS; Festnetzdaten: Meldungen der Netzbetreiber an die RTR-GmbH (ZIB)“, verlinkt Datensatz und Lizenz, nennt die Zusammenfassung je Zelle und stellt klar, dass Breitbandbüro und RTR-GmbH die Auswertung weder erstellt noch geprüft haben.
Pflichtsatz „gemeldete Versorgbarkeit, kein Angebot“ in jedem Befund; der geförderte Ausbau trägt „keine Anschluss- oder Terminzusage“.
Fördernehmer (bei BBA2030: Connect teils einzelne Betriebe) und Antragsnummern werden weder gespeichert noch angezeigt.
redistributionAllowed=false und mlAiAllowed=false sind interne Governance-Entscheidungen, keine Behauptung über die Lizenz.
Der Report-Baustein Breitband bleibt ein Live-Verbraucher per WMTS-GetFeatureInfo und ist nicht Teil dieses Reviews.

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar), Quellen-Evidence (nicht im öffentlichen Doku-Portal verfügbar) und ADR-0074 (nicht im öffentlichen Doku-Portal verfügbar).

WLV-Gefahrenzonenplan Österreich — „Es gelten keine Bedingungen“

Geprüft ist ausschließlich die Distribution lfrz-000901-wlv-gzp-gpkg-snapshot: das per SHA-256 gebundene GeoPackage des Datensatzes „WLV Gefahrenzonenplan“ (Wildbach- und Lawinenverbauung, Dateneigentümer BMLUK). Die Metadaten nennen keine Lizenz, sondern „No limitations on public access“ und „No conditions apply to access and use“ (INSPIRE-Codelisten); der Datensatz ist ein hochwertiger Datensatz nach der Durchführungsverordnung (EU) 2023/138. Der Review config/source-rights/wlv-gzp.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt nur public_display, point_lookup und Region AT. Er ist seit 30.09.2026 nach menschlicher Freigabe per --apply --ack <SHA> eingespielt (Datei-SHA-256 f378637c…74a4, conditional, Recheck 28.03.2027); die Migration 0062, die die Registry-Zeile wlv-gzp anlegt, lief davor (Nachweis (nicht im öffentlichen Doku-Portal verfügbar)).

Verbindlich sind attribution, sourceLink, licenseLink, changeNotice, nonEndorsement, hazardScreeningDisclaimer und noGeometryRedistribution. licenseLink verweist mangels Lizenz auf den INSPIRE-Codelisteneintrag „Es gelten keine Bedingungen“; eine CC-Lizenz wird nicht behauptet.
Der Screening-Hinweis ist Pflicht: nur Wildbach- und Lawinengefahren im raumrelevanten Bereich von Gemeinden mit Gefahrenzonenplan; kein Treffer ist keine Garantie; kein Ersatz für den Gefahrenzonenplan der Gemeinde oder die Auskunft der WLV-Dienststelle.
Der Report-Baustein Wildbach & Lawine (wlv-lfrz) ruft den WMS weiter live ab und ist nicht Teil dieses Reviews.
redistributionAllowed=false und mlAiAllowed=false sind interne Governance-Entscheidungen, keine Behauptung über die Nutzungsbedingungen.

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar), Quellen-Evidence (nicht im öffentlichen Doku-Portal verfügbar) und ADR-0075 (nicht im öffentlichen Doku-Portal verfügbar).

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 (nicht im öffentlichen Doku-Portal verfügbar) sowie Quellenvertrag.

GeoSphere Erdbebenzonen (ÖNORM B 1998-1) — Report und Standort-Check

Die Quelle erdbeben-oenorm erlaubt ausschließlich die Distribution geophysik-bodenbeschleunigung-ref-orte der GeoSphere Austria unter CC BY 4.0. Der Review config/source-rights/erdbeben-oenorm.public-display.json (nicht im öffentlichen Doku-Portal verfügbar) erlaubt nur public_display, report_lookup und Region AT. Er ist seit 05.08.2026 eingespielt (conditional, Recheck 05.02.2027).

Verbindlich sind attribution („Datenquelle: GeoSphere Austria“), sourceLink, licenseLink, changeNotice und nonEndorsement.
Die Karte im Standort-Check (ADR-0071, seit 25.09.2026) zeigt Zone und Referenzwert des nächsten ÖNORM-Referenzorts aus dem lokalen Release-Snapshot; Adresse und Koordinate gehen nicht an GeoSphere. Der Rechte-Review wurde dafür nicht erneuert: Er unterscheidet nicht zwischen Report und Werkzeug (siehe Evidenz (nicht im öffentlichen Doku-Portal verfügbar)).

Siehe Rechte-Review (nicht im öffentlichen Doku-Portal verfügbar) und ADR-0071.

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)

Dieser Report ist eine unverbindliche Ersteinschätzung des Nutzungs-Potenzials.
Er ersetzt keine rechtsverbindliche Vermessung, keine Sachverständigenbewertung
und keine Detailkalkulation. Alle Werte sind Grob-Schätzungen mit angegebener
Bandbreite.

Der Wortlaut steht als statische Konstante DISCLAIMER_TEXT in lib/report/build.ts (REPORT-SPEC §13) und ist keine LLM-Ausgabe. Er ist ein Pflichtfeld jedes Reports (disclaimer.text); die Datengrundlage mit Lizenz und Stand steht im Report unter sources[]. Der Report bleibt hinter dem DisclaimerGate verdeckt, bis die Person den Hinweis bestätigt hat.