Die Governance von Standortdaten entscheidet, welche geografischen Fakten ein Spatial-AI-Produkt erfassen darf, mit welcher Genauigkeit und für welchen Zweck, wer sie sehen darf, wie lange jede Kopie bestehen bleibt und welcher Analytics- oder Modellpfad sie erhalten darf. Eine Browser-Abfrage beantwortet nur, ob eine Origin den Standort des Geräts lesen darf. Das Betriebsdesign umfasst jede danach entstehende Kopie.
Die folgenden Abschnitte klassifizieren Standortfakten, legen für jede Aufgabe eine Mindestgenauigkeit fest und trennen eine Browser-Abfrage von der späteren Nutzung. Inventar, Datenherkunft und Zugriffskontrolle kommen, bevor ein Modell einen privaten Datensatz sieht. Aufbewahrung, Löschung und Analytics erhalten anschließend jeweils eigene Regeln. Kaleidr sitzt neben den Host-Systemen, die Identität, Richtlinien und Transaktionen bereits besitzen.
Grundlagen der Governance von Standortdaten
- Von der Aufgabe ausgehen: Benennen Sie, warum ein Standortfeld existiert, bevor Sie eine Koordinate, einen Ort oder eine Region wählen.
- Vor dem Kopieren klassifizieren: Öffentliche Orte, private Geschäftsdaten, Gerätestandort, Bewegung und Ableitungen folgen nicht derselben Regel.
- Die geringste ausreichende Genauigkeit behalten: Analytics kann grob bleiben, wenn Live-Betrieb einen Ort oder eine Adresse benötigt.
- Vor dem Abruf autorisieren: Ein Plattform-Credential ist keine Endnutzerberechtigung, und Zeilen zu verbergen, nachdem ein Modell sie gesehen hat, ist zu spät.
- Löschung als Weitergabe behandeln: Caches, Indizes, Exporte, Telemetrie und Provider brauchen einen Pfad; Backups folgen ihrer eigenen Aufbewahrung.
Was ist Governance von Standortdaten?
Governance von Standortdaten ist die Gesamtheit der Kontrollen, die festlegen, warum ein geografischer Fakt erfasst wurde, wie genau er sein muss, wer ihn nutzen darf, welches System eine Kopie erhalten darf und wann diese Kopie endet. Der Fakt kann ein ausgewähltes Geschäft, eine eingegebene Adresse, eine Gerätekoordinate, eine Route, ein Servicegebiet oder eine Ableitung wie ein wahrscheinlicher Heimatmarkt sein. Governance wirkt auf Feld und Zweck, nicht auf die Karte als einen einzigen Datenblock. Ein Basemap-Pin und der private Ausgangspunkt eines Kunden können denselben Bildschirm teilen und dennoch unterschiedlichen Regeln folgen.
Das Titelbild ordnet diese Kontrollen um einen Karten-Workflow an: Zweck, Klassifizierung, Genauigkeit, Berechtigung, Autorisierung, Datenherkunft, eine AI-Grenze, Aufbewahrung, Analytics, Löschung, Incident Response und Überprüfung. Die Callout-Elemente in diesem Diagramm sind als Illustration zu verstehen. Die beispielhafte Orts-ID, die 50-Meter-Genauigkeitslinie und die Reduktion der Fahrzeit sind Beispielbeschriftungen, keine gemessenen Kaleidr-Ergebnisse. Ein brauchbares Programm kann erklären, warum der Standort dort sein durfte, nicht nur, was die Karte geantwortet hat.
Wie bleiben Datenschutz, Sicherheit und AI-Governance voneinander getrennt?
Datenschutz, Sicherheit, Datenmanagement und AI-Governance treffen sich am Standortdatensatz, und keines ersetzt die anderen. Datenschutz fragt nach Risiken für Menschen und nach angemessener Nutzung. Sicherheit fragt, wer auf den Datensatz zugreifen kann und ob er intakt bleibt. Datenmanagement fragt nach Identität, Qualität, Datenherkunft und Lebenszyklus. AI-Governance fragt, welche Modelle, Tools und Provider einen minimierten Kontext sehen dürfen und wie diese Nutzung bewertet wird. Eine gesperrte Datenbank kann für die Aufgabe immer noch die falsche Genauigkeit haben, und ein Datenschutzhinweis kann einen Modell-Provider dennoch mit einer Kopie zurücklassen, die niemand inventarisiert hat.
Das Diagramm ordnet Standortdatensätze zwischen Datenschutz, Sicherheit, Datenmanagement und AI-Governance ein. Datenschutz umfasst Risiken für Menschen und angemessene Nutzung. Sicherheit umfasst unbefugten Zugriff und Integrität. Datenmanagement umfasst Identität, Qualität, Datenherkunft und Lebenszyklus, während AI-Governance Modelle, Tools, Provider und Bewertung umfasst.
NIST beschreibt das AI Risk Management Framework als zur freiwilligen Nutzung bestimmt, um die Fähigkeit zu verbessern, Vertrauenswürdigkeitsaspekte in Design, Entwicklung, Nutzung und Bewertung von AI-Produkten, -Diensten und -Systemen einzubeziehen. Dieselbe Seite nennt den 26. Januar 2023 als Veröffentlichungsdatum des Frameworks (NIST, 2023). Dieses Framework ist kein Standortdaten-Gesetz und legt weder eine Genauigkeit noch ein Aufbewahrungsfenster für ein Kartenprodukt fest. Nutzen Sie es als Erinnerung daran, dass Modellnutzung, Provider und Bewertung in dieselbe Prüfung wie die Datenerhebung gehören. Die geografischen Regeln müssen weiterhin für das Produkt geschrieben werden.
Welche Standortfakten brauchen eine Klasse?
Klassifizieren Sie den Standort, bevor Sie entscheiden, wer ihn sehen darf. Ein öffentlicher Ort wie ein Geschäft, ein Flughafen oder ein Park ist nicht derselbe Datensatz wie ein privater Unternehmensstandort, ein Lager oder eine eingeschränkte Einrichtung. Ein vom Nutzer eingegebener oder ausgewählter Ort ist nicht derselbe Datensatz wie eine Gerätekoordinate aus Browser oder Telefon. Bewegung, etwa eine Route oder ein wiederholter Ausgangspunkt, kann ein Muster offenlegen, auch wenn jeder einzelne Punkt gewöhnlich wirkt. Ein abgeleiteter Standort, etwa ein wahrscheinlicher Heimatmarkt, ist eine abgeleitete Aussage. Ein Betriebszustand, etwa ein Fahrzeug, ein Vorfall oder Bestand nach Ort, ist ein an Geografie gebundener Geschäftsfakt.
Die sieben Klassen sind öffentlicher Ort, privates Unternehmen, vom Nutzer angegebener Ort, Gerätestandort, Bewegung, abgeleiteter Standort und Betriebszustand. Ein Park und ein Lager tragen nicht dieselben Kontrollen. Eine eingegebene Adresse und eine Gerätekoordinate ebenfalls nicht. Der Kontext verändert die Anforderung, und die Beispieladresse in der Abbildung ist nur eine Illustration.
Eine Karte kann mehrere Klassen gleichzeitig enthalten. Ein Filialfinder kann in derselben Antwort eine öffentliche Filiale, den vom Nutzer ausgewählten Ausgangspunkt und einen privaten Bestandsindikator zeigen. Governance sollte jedes Feld benennen, statt dem gesamten Bildschirm ein einziges Label zu geben. Kombinationen erhöhen die Sensitivität: Eine genaue Koordinate plus Zeit plus Konto kann einen Besuch beschreiben, den keines der Felder allein beschreibt. Leiten Sie aus dem Klassennamen allein keine universelle rechtliche Bezeichnung wie personenbezogen oder nicht personenbezogen ab. Rechtsraum, Vertrag und Zweck entscheiden diese Frage weiterhin, und dieser Leitfaden ist ein Betriebsrahmen, keine Rechtsberatung.
Wie genau sollte jede Aufgabe sein?
Verwenden Sie die ungenaueste Darstellung, die die angegebene Aufgabe noch erfüllt. Eine Region, eine Stadt oder ein Postleitzahlengebiet kann eine Marktsicht unterstützen. Ein Stadtviertel oder ein Servicegebiet kann Filialauswahl und Routenvergleich unterstützen. Eine Orts-ID, eine Adresse oder eine exakte Koordinate gehört zu Live-Betrieb, Fulfillment oder einem Vor-Ort-Erlebnis, das ohne dieses Detail nicht funktioniert. Wetter, eine Kampagne auf Stadtebene oder ein regionales Nachfrage-Dashboard benötigen selten ein Dach auf den Meter genau. Notfalldisposition und Bordstein-Übergabe möglicherweise schon. Genauigkeit ist eine Kontrolle, keine Trophäe für den präzisesten verfügbaren Sensor.
Die Leiter verläuft von Region und Stadt in Richtung Ort, Adresse und exakter Koordinate. Analytics kann häufig grob bleiben. Für die Filialauswahl kann ein Stadtviertel oder Servicegebiet genügen. Live-Betrieb kann eine Orts-ID, Adresse oder Koordinate benötigen, und der Beispiel-Breitengrad in der Abbildung ist kein Kaleidr-Ergebnis.
Eine eingegebene Adresse, ein ausgewähltes Geschäft oder eine aktive Immobilie kann viele Aufgaben erfüllen, ohne das Gerät überhaupt auszulesen. Halten Sie neben jeder Koordinate eine kanonische Orts- oder Asset-ID, damit eine spätere Korrektur nicht vom Abgleich roher Breiten- und Längengrade abhängt. Die Stufen der Leiter sind keine universellen Sensitivitätskategorien. Eine Stadt kann in einem Kontext sensibel sein, während eine präzise Koordinate in einem anderen angemessen sein kann, wenn Zweck, Zielgruppe und Aufbewahrung ausdrücklich festgelegt sind. Reduzieren Sie Genauigkeit, die Risiko hinzufügt, aber die Entscheidung nicht verändert.
Regelt eine Browser-Abfrage jede spätere Nutzung?
Eine Browser-Geolocation-Abfrage beantwortet eine enge Frage: Darf diese Origin den Gerätestandort erhalten? Die W3C Geolocation Recommendation vom 24. März 2026 bezeichnet Geolocation als leistungsfähige Funktion, die eine ausdrückliche Erlaubnis verlangt, bevor Standortdaten mit einer Webanwendung geteilt werden (W3C, 2026). Die Empfehlung sagt außerdem, Empfänger sollten Positionsinformationen nur dann anfordern, wenn dies erforderlich ist, und sie nur für die Aufgabe verwenden, für die sie bereitgestellt wurden. Empfänger sollten sie nach Abschluss der Aufgabe entsorgen, sofern der Nutzer die Aufbewahrung nicht ausdrücklich erlaubt, und gespeicherte Standortinformationen vor unbefugtem Zugriff schützen. Wenn Informationen gespeichert werden, müssen Nutzer sie aktualisieren und löschen können, und Empfänger sollten sie ohne ausdrückliche Erlaubnis des Nutzers nicht weiterübermitteln.
Die linke Seite ist eine Browser-Abfrage, die einer Origin erlaubt, den Gerätestandort zu erhalten. Die rechte Seite nennt spätere Entscheidungen zu Aufbewahrung, Weitergabe, Modellnutzung, CRM-Verknüpfung, Analytics, Training und Löschung. Die Browser-Berechtigung beantwortet diese Entscheidungen nicht. Die Quellenzeile zitiert die W3C Geolocation Recommendation vom 24. März 2026.
Diese Plattform-Signale entscheiden nicht, ob die Organisation die Koordinate ein Jahr lang behalten, mit einem CRM-Datensatz verbinden, an einen Modell-Provider senden, für Werbung verwenden, einem anderen Mitarbeiter zugänglich machen oder zum Trainieren eines Modells nutzen darf. Jede dieser Entscheidungen braucht einen Produktzweck, einen Vertrag und die Regeln, die für diesen Einsatz gelten. Behandeln Sie die Browser-Abfrage als ein technisches Gate. Inventar, Aufbewahrungsplan und Provider-Liste müssen weiterhin die Kopien benennen, die nach dem Klick auf „Zulassen“ bestehen.
Wann braucht ein präziser Standort besondere Vorsicht?
Präzise Standortdaten werden sensibler, wenn sie Bewegungen oder Besuche im Zusammenhang mit persönlichen Aktivitäten offenlegen. Am 4. Mai 2026 erklärte die Federal Trade Commission, sie werde dem Datenbroker Kochava und seiner Tochtergesellschaft verbieten, sensible Standortdaten ohne ausdrückliche affirmative Einwilligung der Verbraucher zu verkaufen, zu teilen oder offenzulegen, um Vorwürfe beizulegen, die Unternehmen hätten Standortdaten von Hunderten Millionen Mobilgeräten verkauft, mit denen sich Bewegungen von Personen nachverfolgen ließen (FTC, 2026). Diese Maßnahme betrifft einen Datenbroker-Fall. Lesen Sie sie nicht als universelle Regel für jedes First-Party-Produkt, das eine Karte auf ein vom Kunden ausgewähltes Geschäft zentriert.
Die Vorsicht gehört dennoch in die Designprüfung. Fragen Sie, ob der Workflow eine Koordinate, eine Orts-ID oder nur eine vom Host bereits berechnete Fahrzeit benötigt. Fragen Sie, ob ein Dritter die Übertragung aufbewahren, für einen anderen Zweck verwenden oder eine spätere Löschung verweigern darf. Ein abgeleiteter Wert wie Fahrminuten oder eine Routenabweichung kann eine Erklärung ermöglichen, ohne den exakten Ausgangspunkt des Kunden zu übertragen. Substitution ist eine Kontrolle. Ein Richtliniensatz wie „Vorsicht walten lassen“ ist erst dann eine Kontrolle, wenn sich die Nutzlast ändert.
Was sollte ein Standortinventar erfassen?
Ein Inventar benennt jedes Standortfeld, das das Produkt tatsächlich hält, nicht die Felder, die eine Präsentation gern sammeln würde. Erfassen Sie für jedes Feld Klasse, Zweck, Quellsystem, kanonische ID, erforderliche Genauigkeit, vorhandene Kopien und den Eigentümer, der die Regel ändern kann. Kopien umfassen Primärspeicher, Cache, Suchindex, Export, Prompt, Embedding, Analytics-Tabelle und Provider-Log. Ein Feld ohne Zweck ist ein Kandidat für die Entfernung. Ein Feld mit zwei Zwecken braucht beide schriftlich, denn eine Betrugsprüfung und ein Marketing-Aggregat sind nicht dieselbe Entscheidung.
Überprüfen Sie das Inventar, wenn sich das Produkt ändert, nicht nur wenn ein Richtliniendokument neu veröffentlicht wird. Ein neues Modell-Tool, ein neues Analytics-Diagramm oder ein neuer Connector kann eine Kopie erzeugen, die die letzte Prüfung nie gesehen hat. Prompts und Embeddings sind Kopien des Standortkontexts, auch wenn niemand sie Datenbank nennt. Auch die Integrationsgrenze ist hier wichtig. Der Leitfaden zur Datenintegration belässt jeden operativen Fakt bei dem System, das ihn besitzt, und ein Spatial Join aller privaten Datensätze ist bereits eine Offenlegung, selbst wenn die Antwort einige Zeilen verbirgt (Kaleidr, 2026). Inventarisieren Sie den Join, nicht nur die Tabelle, die wie die Quelle aussah.
Kann ein Team einen Standort von der Quelle bis zu Analytics nachverfolgen?
Ein governter Datensatz sollte vom Eingang bis zur Karte und zum Aggregat nachvollziehbar sein. Der Pfad beginnt mit einer vertrauenswürdigen Quelle, etwa einer eingegebenen Adresse, einer Gerätekoordinate oder einem Unternehmensstammdatensatz. Die Normalisierung löst diese Eingaben in eine kanonische Orts- oder Asset-ID auf und entfernt Duplikate. Eine räumliche Transformation erzeugt danach die Darstellung, die die Aufgabe benötigt, etwa einen Geocode, eine Route oder eine Region. Erst nach diesem Schritt sollte ein minimierter Kontext mit abgeleiteten Feldern statt des rohen Ausgangspunkts ein Modell erreichen. Kartenergebnis und Analytics-Extrakt kommen zuletzt, und der Analytics-Extrakt sollte die gröbere Geografie tragen, die das Diagramm tatsächlich benötigt.
Der Pfad führt von einer eingegebenen Adresse, einer Gerätekoordinate oder einem Unternehmensstamm in eine kanonische Orts- oder Asset-ID. Räumliche Transformationen erzeugen danach einen Geocode, eine Route oder eine Region, bevor ein minimierter Kontext Karte und Analytics erreicht. Beispiel-IDs, Koordinaten und das Genauigkeitslabel in der Abbildung sind Illustrationen. Ein Produktionsdatensatz sollte Quelle, Beobachtungszeit, Transformationsversion, Genauigkeit und eine Lineage-ID behalten.
Führen Sie die Metadaten mit dem Datensatz: eine Quell-ID, eine Beobachtungszeit, eine Transformationsversion, die verwendete Genauigkeit und eine Lineage-ID. Eine spätere Korrektur kann dann jede abgeleitete Kopie finden, die noch von der alten Koordinate abhängt. Unbekannt ist ein anderer Zustand als falsch. Eine fehlende Beobachtungszeit beweist nicht, dass der Ort aktuell ist. Reproduzierbare Transformationen und versionierte Anreicherung machen eine Erklärung möglich. Eine Koordinate, die in Analytics ohne Quellenzeile erscheint, ist ein Datensatz, den das Team nicht mehr verteidigen kann.
Warum muss Zugriffskontrolle vor dem AI-Kontext stattfinden?
Lösen Sie Nutzer, Tenant, Rolle, Objekte und Felder auf, bevor ein privater räumlicher Datensatz eine Berechnung oder ein Modell erreicht. Der gute Pfad filtert zuerst die erlaubten Standorte und führt räumliche Arbeit nur auf diesem Satz aus. Der blockierte Pfad sendet einen gesamten privaten Datensatz und versucht erst zu verbergen, was der Nutzer nicht sehen darf, nachdem das Modell ihn bereits erhalten hat. Verbergen ist keine Autorisierung. Die Private-Location-Empfehlungen für AI-Karten schreiben dieselbe Reihenfolge fest: authentifizieren, autorisieren, dann einen minimierten Ausschnitt abrufen und keine uneingeschränkte interne Datenbank hochladen (Kaleidr, 2026).
Der gute Pfad prüft Nutzer, Tenant, Rolle, Objekte und Felder, bevor ein privater Standort eine Berechnung oder ein Modell erreicht. Der blockierte Pfad sendet einen gesamten privaten Datensatz und versucht, Zeilen erst danach zu verbergen. Diese Reihenfolge ist der Fehlerzustand. Autorisierung gehört vor den Abruf, nicht nachdem ein Modell die Zeilen bereits gesehen hat.
Ein Plattform-Credential identifiziert die Integration. Eine Endnutzerberechtigung bestimmt, welchen Tenant, welches Objekt und welches Feld diese Person nutzen darf. Das sind unterschiedliche Prüfungen, und ein gültiger Organisationsschlüssel gibt Kunde A nicht das Recht, Filialen, Assets oder Ausgangspunkte von Kunde B zu lesen. Caches und Retrieval-Stores brauchen dieselbe Tenant-Grenze wie die Primärabfrage. Testen Sie den Cross-Tenant-Fehler absichtlich. Eine Karte, die für einen angemeldeten Nutzer korrekt aussieht, kann über einen gemeinsam genutzten Cache-Key dennoch Datensätze des Nachbarn leaken.
Wie lange sollte jede Standortkopie bestehen bleiben?
Aufbewahrung folgt dem Zweck. Eine globale Anzahl von Tagen passt nicht zugleich zu einem nur für eine Anfrage benötigten Ausgangspunkt, einem auf einem Konto gespeicherten Ort, einer Fahrzeug- oder Vorfallhistorie und einem Analytics-Extrakt auf Marktebene. Eine nur für die Anfrage benötigte Koordinate kann mit dem Ende der Anfrage enden. Ein kontoverknüpfter Ort kann bestehen bleiben, solange das Feature oder das Konto aktiv ist. Betriebszustand kann einen aktuellen Wert plus eine kontrollierte Historie nach Abschluss des Ereignisses behalten, etwa für Sicherheit, Support oder einen vertraglichen Nachweis. Analytics kann eine reduzierte Genauigkeit, aggregiert oder gemäß Analytics-Richtlinie de-identifiziert, länger als die Live-Koordinate aufbewahren.
Aufbewahrung folgt der Aufgabe, nicht einer globalen Zahl. Ein nur für die Anfrage benötigter Ausgangspunkt kann verfallen, wenn die Anfrage endet. Ein kontoverknüpfter Ort kann mit dem Feature bestehen bleiben, und Betriebszustand kann nach Abschluss des Ereignisses eine kontrollierte Historie behalten. Analytics kann eine gröbere Geografie länger aufbewahren, während exakte Zeiträume organisationsspezifisch bleiben.
Trennen Sie den Standort, den das Produkt im Moment benötigt, von dem Standort, den Analytics behält. Eine Live-Übergabe kann eine Adresse benötigen. Ein Dashboard für Reichweite, Sessions und Orts-Engagement benötigt häufig einen Markt, eine Stadt oder ein Einzugsgebiet. Schreiben Sie diese Trennung fest, damit ein Diagramm nicht stillschweigend den exakten Dachstandort speichert, den das Produkt einmal verwendet hat. Exakte Zeiträume sind organisations- und kontextspezifisch. Die Abbildung zeigt die Form von vier Lebenszyklen, keinen Aufbewahrungsplan, den ein Team in eine Richtlinie kopieren kann.
Was muss sich bewegen, wenn ein Standortdatensatz gelöscht wird?
Löschung ist ein Weitergabe-Workflow. Eine Anfrage zum Löschen oder Widerrufen eines Datensatzes muss Primärspeicher, In-Memory- und Edge-Caches, Suchindizes und Vektorspeicher erreichen, die Embeddings halten. Analytics-Tabellen, Exporte und Provider-Systeme brauchen eine eigene Behandlung; das kann Löschung, ein kontrolliertes Ablaufdatum oder eine dokumentierte Trennung vom Identifikator sein. Observability-Stores brauchen dieselbe Prüfung. Bevorzugen Sie IDs, Versionen, Zählwerte und Reason Codes in der Telemetrie, und halten Sie Secrets, rohe private Datensätze und nicht benötigte präzise Koordinaten aus diesem Speicher heraus (Kaleidr, 2026).
Eine Löschung oder ein Widerruf muss Primärspeicher, Caches, Suchindizes und Vektorspeicher erreichen. Analytics, Observability, Exporte und Provider-Systeme brauchen ihre eigene Behandlung; das kann Löschung, Ablauf oder eine dokumentierte Trennung sein. Backups folgen ihrer Aufbewahrungsrichtlinie und entfernen einen einzelnen Datensatz möglicherweise nicht sofort. Das Diagramm ist eine Propagationskarte, kein einzelner Delete-Befehl.
Backups, Snapshots und Archive folgen dem Backup-Lebenszyklus. Behaupten Sie nicht, dass jedes Backup einen einzelnen Datensatz auf Abruf löschen kann. Sagen Sie, was die Backup-Richtlinie tatsächlich tut, einschließlich wie lange ein gelöschter Datensatz in einem Snapshot verbleiben kann. Provider-Verträge gehören in dieselbe Karte: Ein Modell- oder Enrichment-Provider, der Prompts aufbewahrt, kann nach dem Löschen der Primärzeile weiterhin eine Standortkopie halten. Zugriffs-Widerruf ist verwandt, aber nicht identisch. Ein Nutzer, der eine Rolle verliert, sollte sofort keine neuen Datensätze mehr erhalten, auch wenn ein älteres Aggregat noch innerhalb seines Analytics-Zeitfensters liegt.
Wo sollte Governance von Standortdaten neben Kaleidr sitzen?
Halten Sie Identität, Tenant-Autorisierung, private Geschäftsdaten, CRM, Bestand, Buchung, Aufbewahrungsrichtlinie, rechtliche und Datenschutzentscheidungen sowie Transaktionen innerhalb der Host-Organisation. Wenden Sie Zweck, Genauigkeit, Autorisierung, Minimierung und Datenherkunft an, bevor ein autorisierter Datensatz eine Kaleidr-Oberfläche erreicht. Kaleidr Enterprise ist Location-Intelligence-Infrastruktur mit Inference APIs, Ranking-Systemen und Analytics für moderne räumliche Produkte (Kaleidr, 2026). Die Entwicklerdokumentation beschreibt Chat als Spatial AI in der Host-Karte, Viewer als Veröffentlichung einer Karte, Tile als gestaltete Basemaps und Editor als Zeichnen und Bearbeiten (Kaleidr, 2026). Viewer bindet eine veröffentlichte Karte über ihre share id ein und benötigt für dieses Embed keinen publishable key (Kaleidr, 2026).
Die linke Spalte bleibt beim Host: Identität, Tenant-Autorisierung, private Geschäftsdaten, CRM, Bestand, Buchung, Aufbewahrungsrichtlinie, rechtliche und Datenschutzentscheidungen sowie Transaktionen. Die Mitte listet Kontrollen, die der Host anwendet, bevor ein Datensatz die Grenze überschreitet: Zweck, Genauigkeit, Autorisierung, Minimierung und Datenherkunft. Die rechte Spalte nennt dokumentierte Kaleidr-Oberflächen: Enterprise, Chat, Editor, Tile, Viewer und Analytics. Kaleidr ersetzt die Host-Systeme in der linken Spalte nicht.
Die Dokumentation unterscheidet ein Server-Credential, das vom Backend verwendet wird, von einem publishable Browser-Credential, das das SDK gegen eine kurzlebige Session austauscht und nicht als rohen Bearer sendet (Kaleidr, 2026). Keine der beiden Formen ist eine Endnutzerberechtigung, und ein Server-Credential gehört nicht in Browser-Code. Kaleidr Analytics dokumentiert Reichweite, Views und Engagement, Standort und Aktivität der Zielgruppe über Karten hinweg sowie Sessions, Views und Interaktionen pro Karte plus räumliche Muster wie Cluster, Lücken und Routen (Kaleidr, 2026). Entscheiden Sie, welche dieser Signale feine Standortdaten tragen dürfen und welche im Host-Warehouse grob bleiben sollten. Bestätigen Sie vertragliche Aufbewahrung und Verarbeitung für das Deployment, statt sie aus diesem Artikel abzuleiten.
Kaleidr Enterprise erkunden, um Spatial Intelligence neben den Systemen hinzuzufügen, die Nutzer und Datensätze bereits besitzen. Kaleidr Analytics erkunden für dokumentiertes Karten- und Orts-Engagement innerhalb der Genauigkeit, die die Governance-Prüfung zulässt. Lesen Sie beide Seiten gegen das Inventar und halten Sie feinere Standortdaten im Host-System, wenn das Diagramm sie nicht benötigt.
Hinweis: Kaleidr nutzt AI-gestützte Tools für Bilderstellung, Inhaltsverbesserung und Recherche in seinen kreativen und Entwicklungs-Workflows.
FAQs
Autorisiert eine Browser-Standortberechtigung jede spätere Nutzung?
Nein. Die Abfrage entscheidet, ob eine Origin den Gerätestandort erhalten darf. Aufbewahrung, Weitergabe, Modellnutzung, CRM-Verknüpfung, Analytics, Training und Löschung bleiben separate organisatorische Entscheidungen.
Sollte Analytics dieselbe Genauigkeit wie das Live-Produkt behalten?
Nicht standardmäßig. Eine Live-Aufgabe kann einen Ort oder eine Adresse benötigen. Ein Markt-Diagramm kann häufig eine Stadt, ein Einzugsgebiet oder eine andere grobe Geografie unter einer eigenen Aufbewahrungsregel behalten.
Ersetzt Kaleidr das Standortdaten-Governance-Programm eines Unternehmens?
Nein. Kaleidr stellt dokumentierte Spatial-AI-, Karten-, SDK-, API- und Analytics-Funktionen bereit. Die Host-Organisation bleibt für Nutzerberechtigungen, private Geschäftssysteme, Klassifizierung, Aufbewahrung sowie rechtliche oder Datenschutzentscheidungen verantwortlich, sofern ein konkreter Vertrag nichts anderes festlegt.
Welche Systeme sollte eine Löschanfrage erreichen?
Den Primärspeicher, Caches, Suchindizes, Vektorspeicher, Analytics-Extrakte, Exporte, Telemetrie und Provider-Systeme, die eine Kopie halten. Backups folgen ihrem eigenen Lebenszyklus und können einen einzelnen Datensatz möglicherweise nicht sofort löschen.
References
- National Institute of Standards and Technology. AI Risk Management Framework. Intended for voluntary use, to improve trustworthiness considerations in the design, development, use, and evaluation of AI products, services, and systems. Released January 26, 2023. Accessed October 5, 2026. https://www.nist.gov/itl/ai-risk-management-framework
- World Wide Web Consortium. Geolocation. W3C Recommendation, March 24, 2026. Express permission before a web application receives device location, with guidance on necessity, purpose, disposal, protection, update, deletion, retransmission, and disclosure. Accessed October 5, 2026. https://www.w3.org/TR/2026/REC-geolocation-20260324/
- Federal Trade Commission. FTC to Ban Kochava and Subsidiary from Selling Sensitive Location Data. May 4, 2026. Accessed October 5, 2026. https://www.ftc.gov/news-events/news/press-releases/2026/05/ftc-ban-kochava-subsidiary-selling-sensitive-location-data-settle-charges-they-sold-location-data
- Kaleidr. Spatial AI Data Integration. Each operational fact stays with the system that owns it, and a spatial join of private records is already a disclosure. https://kaleidr.com/blog/spatial-ai-data-integration
- Kaleidr. Private Location Data for AI Map Workflows. Authorize before retrieval, and do not upload an unrestricted internal database to a map or a language model. https://kaleidr.com/blog/private-location-data-for-ai-map-workflows
- Kaleidr. Spatial AI Observability. Prefer identifiers, versions, counts, and reason codes, and keep unneeded precise location out of telemetry. https://kaleidr.com/blog/spatial-ai-observability
- Kaleidr. Location Intelligence APIs and Map SDK. Inference APIs, ranking systems, and analytics for spatial products. Accessed October 5, 2026. https://kaleidr.com/enterprise
- Kaleidr Developer Docs. Products. Chat is Spatial AI in the host map, Editor is draw and edit, Tile is designed basemaps, and Viewer publishes a map. Accessed October 5, 2026. https://docs.kaleidr.com/
- Kaleidr Developer Docs. Viewer. Embeds a published map by its share id, and that embed does not require a publishable key. Accessed October 5, 2026. https://docs.kaleidr.com/viewer
- Kaleidr Developer Docs. Auth & Scopes. Distinguishes a backend server credential from a publishable browser credential with a different runtime. Accessed October 5, 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
- Kaleidr. Map Engagement and Location Analytics. Reach, views, engagement, audience location and activity, sessions, and spatial patterns. Accessed October 5, 2026. https://kaleidr.com/analytics
@misc{nist_ai_rmf_2023,
title = {AI Risk Management Framework},
author = {{National Institute of Standards and Technology}},
year = {2023},
url = {https://www.nist.gov/itl/ai-risk-management-framework}
}
@misc{w3c_geolocation_2026,
title = {Geolocation},
author = {{World Wide Web Consortium}},
year = {2026},
url = {https://www.w3.org/TR/2026/REC-geolocation-20260324/}
}
@misc{ftc_kochava_2026,
title = {FTC to Ban Kochava and Subsidiary from Selling Sensitive Location Data},
author = {{Federal Trade Commission}},
year = {2026},
url = {https://www.ftc.gov/news-events/news/press-releases/2026/05/ftc-ban-kochava-subsidiary-selling-sensitive-location-data-settle-charges-they-sold-location-data}
}
@misc{kaleidr_data_integration_2026,
title = {Spatial AI Data Integration},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/spatial-ai-data-integration}
}
@misc{kaleidr_private_location_2026,
title = {Private Location Data for AI Map Workflows},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/private-location-data-for-ai-map-workflows}
}
@misc{kaleidr_observability_2026,
title = {Spatial AI Observability},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/spatial-ai-observability}
}
@misc{kaleidr_enterprise_governance_2026,
title = {Location Intelligence APIs and Map SDK},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/enterprise}
}
@misc{kaleidr_docs_home_governance_2026,
title = {Kaleidr Developer Docs},
author = {{Kaleidr}},
year = {2026},
url = {https://docs.kaleidr.com/}
}
@misc{kaleidr_docs_viewer_2026,
title = {Viewer},
author = {{Kaleidr}},
year = {2026},
url = {https://docs.kaleidr.com/viewer}
}
@misc{kaleidr_auth_scopes_2026,
title = {Auth and Scopes},
author = {{Kaleidr}},
year = {2026},
url = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}
@misc{kaleidr_analytics_governance_2026,
title = {Map Engagement and Location Analytics},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/analytics}
}