A governança de dados de localização decide quais fatos geográficos um produto de Spatial AI pode coletar, com que precisão e para qual finalidade, quem pode vê-los, quanto tempo cada cópia permanece e qual caminho de analytics ou de modelo pode recebê-los. Uma solicitação do navegador responde apenas se uma origem pode ler a localização do dispositivo. O desenho operacional cobre todas as cópias que surgem depois.
As seções abaixo classificam os fatos de localização, definem um nível mínimo de precisão para cada trabalho e separam uma solicitação do navegador do uso posterior. Inventário, linhagem e controle de acesso vêm antes de qualquer modelo ver um registro privado. Retenção, exclusão e analytics recebem então suas próprias regras. Kaleidr fica ao lado dos sistemas do host que já possuem identidade, políticas e transações.
Fundamentos da governança de dados de localização
- Comece pelo trabalho: Defina por que um campo de localização existe antes de escolher uma coordenada, um lugar ou uma região.
- Classifique antes de copiar: Lugares públicos, registros empresariais privados, posição do dispositivo, movimento e inferências não seguem a mesma regra.
- Mantenha a menor precisão que funcione: Analytics pode permanecer em granularidade mais ampla quando operações em tempo real precisam de um lugar ou endereço.
- Autorize antes da recuperação: Uma credencial de plataforma não é uma permissão de usuário final, e esconder linhas depois que um modelo já as viu é tarde demais.
- Trate a exclusão como propagação: Caches, índices, exportações, telemetria e provedores precisam de um caminho, enquanto backups seguem sua própria retenção.
O que é governança de dados de localização?
Governança de dados de localização é o conjunto de controles que decide por que um fato geográfico foi coletado, quão preciso ele precisa ser, quem pode usá-lo, qual sistema pode receber uma cópia e quando essa cópia termina. O fato pode ser uma loja selecionada, um endereço digitado, uma coordenada do dispositivo, uma rota, uma área de serviço ou uma inferência como um provável mercado residencial. A governança opera sobre o campo e a finalidade, não sobre o mapa como um único bloco. Um marcador de mapa base e a origem privada de um cliente podem compartilhar a mesma tela e, ainda assim, seguir regras diferentes.
O diagrama de capa organiza esses controles em torno de um fluxo de trabalho de mapa: finalidade, classificação, precisão, permissão, autorização, linhagem, um limite de AI, retenção, analytics, exclusão, resposta a incidentes e revisão. Trate o destaque desse diagrama como ilustração. O identificador de lugar de exemplo, a linha de precisão de 50 metros e a redução do tempo de viagem são rótulos de exemplo, não um resultado medido da Kaleidr. Um programa útil consegue explicar por que a localização foi autorizada a estar ali, não apenas o que o mapa respondeu.
Como privacidade, segurança e governança de AI permanecem distintas?
Privacidade, segurança, gestão de dados e governança de AI se encontram no registro de localização, e nenhuma substitui as outras. Privacidade pergunta sobre o risco para as pessoas e sobre uso apropriado. Segurança pergunta quem pode acessar o registro e se ele permanece íntegro. Gestão de dados pergunta por identidade, qualidade, linhagem e ciclo de vida. Governança de AI pergunta quais modelos, ferramentas e provedores podem ver um contexto minimizado e como esse uso é avaliado. Um banco de dados bloqueado ainda pode ter a precisão errada para o trabalho, e um aviso de privacidade ainda pode deixar um provedor de modelos com uma cópia que ninguém inventariou.
O diagrama posiciona os registros de localização entre privacidade, segurança, gestão de dados e governança de AI. Privacidade cobre risco para as pessoas e uso apropriado. Segurança cobre acesso não autorizado e integridade. Gestão de dados cobre identidade, qualidade, linhagem e ciclo de vida, enquanto governança de AI cobre modelos, ferramentas, provedores e avaliação.
O NIST descreve o AI Risk Management Framework como destinado ao uso voluntário, para melhorar a capacidade de incorporar considerações de confiabilidade ao projeto, desenvolvimento, uso e avaliação de produtos, serviços e sistemas de AI. A mesma página informa que o framework foi lançado em 26 de janeiro de 2023 (NIST, 2023). Esse framework não é uma lei de dados de localização e não escolhe uma precisão nem uma janela de retenção para um produto de mapas. Use-o como lembrete de que uso de modelos, provedores e avaliação pertencem à mesma revisão que a coleta. As regras geográficas ainda precisam ser escritas para o produto.
Quais fatos de localização precisam de uma classe?
Classifique a localização antes de decidir quem pode vê-la. Um lugar público como uma loja, aeroporto ou parque não é o mesmo registro que uma instalação empresarial privada, um depósito ou uma unidade restrita. Um lugar fornecido pelo usuário, digitado ou selecionado, não é o mesmo registro que uma coordenada do dispositivo vinda do navegador ou do telefone. Movimento, como uma rota ou uma origem repetida, pode revelar um padrão mesmo quando cada ponto parece comum. Uma localização inferida, como um provável mercado residencial, é uma afirmação derivada. Estado operacional, como um veículo, incidente ou estoque por lugar, é um fato de negócio ligado à geografia.
As sete classes são lugar público, negócio privado, lugar fornecido pelo usuário, localização do dispositivo, movimento, localização inferida e estado operacional. Um parque e um depósito não carregam os mesmos controles. Um endereço digitado e uma coordenada do dispositivo também não. O contexto muda o requisito, e o endereço de exemplo na figura é apenas ilustrativo.
Um mapa pode conter várias classes ao mesmo tempo. Um localizador de lojas pode mostrar na mesma resposta uma filial pública, a origem selecionada pelo usuário e um indicador privado de estoque. A governança deve nomear cada campo, em vez de aplicar um único rótulo a toda a tela. Combinações aumentam a sensibilidade: uma coordenada precisa mais um horário mais uma conta podem descrever uma visita que nenhum desses campos descreve sozinho. Não atribua um rótulo jurídico universal, como pessoal ou não pessoal, apenas pelo nome da classe. Jurisdição, contrato e finalidade ainda decidem essa questão, e este guia é um framework operacional, não uma opinião jurídica.
Qual deve ser a precisão de cada trabalho?
Use a representação menos precisa que ainda conclui o trabalho declarado. Uma região, cidade ou área postal pode sustentar uma visão de mercado. Um bairro ou uma área de serviço pode sustentar seleção de lojas e comparação de rotas. Um identificador de lugar, endereço ou coordenada exata pertence a operações em tempo real, fulfillment ou uma experiência no local que falha sem esse detalhe. Clima, uma campanha em nível de cidade ou um gráfico regional de demanda raramente precisam de um ponto exato no telhado. Despacho de emergência e entrega na calçada talvez precisem. Precisão é um controle, não um troféu por usar o sensor mais exato disponível.
A escada vai de região e cidade em direção a lugar, endereço e coordenada exata. Analytics muitas vezes pode permanecer em granularidade mais ampla. A seleção de lojas pode usar um bairro ou uma área de serviço. Operações em tempo real podem precisar de um identificador de lugar, um endereço ou uma coordenada, e a latitude de exemplo na figura não é um resultado da Kaleidr.
Um endereço digitado, uma loja selecionada ou uma propriedade ativa podem concluir muitos trabalhos sem ler o dispositivo. Mantenha um identificador canônico de lugar ou ativo ao lado de qualquer coordenada para que uma correção posterior não dependa da correspondência de latitude e longitude brutas. Os níveis da escada não são categorias universais de sensibilidade. Uma cidade pode ser sensível em um contexto, e uma coordenada precisa pode ser apropriada em outro, quando finalidade, público e retenção são explícitos. Reduza a precisão que adiciona risco sem mudar a decisão.
Uma solicitação do navegador governa todos os usos posteriores?
Uma solicitação de geolocalização do navegador responde a uma pergunta restrita: esta origem pode receber a localização do dispositivo? A Recomendação de Geolocalização do W3C de 24 de março de 2026 chama a geolocalização de recurso poderoso que exige permissão expressa antes que qualquer dado de localização seja compartilhado com uma aplicação web (W3C, 2026). A recomendação também diz que os destinatários deveriam solicitar informações de posição apenas quando necessário e usá-las somente para a tarefa para a qual foram fornecidas. Os destinatários deveriam descartá-las quando a tarefa terminar, a menos que o usuário permita expressamente a retenção, e precisam proteger informações de localização armazenadas contra acesso não autorizado. Se a informação for armazenada, os usuários precisam poder atualizá-la e excluí-la, e os destinatários precisam se abster de retransmiti-la sem permissão expressa do usuário.
O lado esquerdo mostra uma solicitação do navegador que permite a uma origem receber a localização do dispositivo. O lado direito lista escolhas posteriores sobre retenção, compartilhamento, uso de modelo, junções com CRM, analytics, treinamento e exclusão. A permissão do navegador não responde a essas escolhas. A linha de fonte cita a Recomendação de Geolocalização do W3C de 24 de março de 2026.
Esses sinais da plataforma não decidem se a organização pode manter a coordenada por um ano, juntá-la a um registro de CRM, enviá-la a um provedor de modelos, usá-la para publicidade, permitir que outro funcionário a abra ou treinar um modelo com ela. Cada uma dessas escolhas precisa de uma finalidade de produto, um contrato e as regras aplicáveis à implantação. Trate a solicitação como um gate técnico. O inventário, o cronograma de retenção e a lista de provedores ainda precisam nomear as cópias existentes depois que o usuário toca em Permitir.
Quando uma localização precisa exige cautela extra?
A localização precisa se torna mais sensível quando revela movimento ou visitas ligados à atividade pessoal. Em 4 de maio de 2026, a Federal Trade Commission afirmou que proibirá o data broker Kochava e sua subsidiária de vender, compartilhar ou divulgar dados sensíveis de localização sem o consentimento afirmativo expresso dos consumidores, para resolver alegações de que as empresas venderam dados de localização de centenas de milhões de dispositivos móveis que poderiam ser usados para rastrear os movimentos de indivíduos (FTC, 2026). Essa ação é um caso de data broker. Não a interprete como uma regra universal para todo produto first-party que centraliza o mapa em uma loja escolhida pelo cliente.
A cautela ainda pertence à revisão de design. Pergunte se o fluxo precisa de uma coordenada, de um identificador de lugar ou apenas de um tempo de viagem que o host já calculou. Pergunte se um terceiro pode reter a transferência, usá-la para outra finalidade ou recusar uma exclusão posterior. Um valor derivado, como minutos de viagem ou desvio de rota, pode sustentar uma explicação sem enviar a origem exata do cliente. Substituição é um controle. Uma frase de política que diga “tenha cuidado” não é um controle até que o payload mude.
O que um inventário de localização deve registrar?
Um inventário nomeia cada campo de localização que o produto realmente mantém, não os campos que uma apresentação esperava coletar. Para cada campo, registre a classe, a finalidade, o sistema de origem, o identificador canônico, a precisão necessária, as cópias existentes e o responsável que pode alterar a regra. As cópias incluem o armazenamento primário, um cache, um índice de busca, uma exportação, um prompt, um embedding, uma tabela de analytics e um log do provedor. Um campo sem finalidade é candidato à remoção. Um campo com duas finalidades precisa ter ambas escritas, porque uma verificação de fraude e um agregado de marketing não são a mesma decisão.
Revise o inventário quando o produto mudar, não apenas quando um documento de política for republicado. Uma nova ferramenta de modelo, um novo gráfico de analytics ou um novo conector pode criar uma cópia que a revisão anterior nunca viu. Prompts e embeddings são cópias do contexto de localização mesmo quando ninguém os chama de banco de dados. O limite de integração também importa aqui. O guia de integração de dados mantém cada fato operacional com o sistema que o possui, e uma junção espacial de todos os registros privados já é uma divulgação mesmo quando a resposta esconde algumas linhas (Kaleidr, 2026). Inventarie a junção, não apenas a tabela que parecia a fonte.
Uma equipe pode rastrear uma localização da origem até analytics?
Um registro governado deve ser rastreável da entrada até o mapa e o agregado. O caminho começa com uma fonte confiável, como um endereço digitado, uma coordenada de dispositivo ou um cadastro mestre empresarial. A normalização resolve essas entradas para um identificador canônico de lugar ou ativo e remove duplicatas. Uma transformação espacial produz então a representação que o trabalho precisa, como um geocódigo, uma rota ou uma região. Somente depois dessa etapa um contexto minimizado, com campos derivados em vez da origem bruta, deve chegar a um modelo. O resultado no mapa e o extrato de analytics vêm por último, e o extrato de analytics deve carregar a geografia mais ampla de que o gráfico realmente precisa.
O caminho vai de um endereço digitado, uma coordenada de dispositivo ou um cadastro mestre empresarial até um identificador canônico de lugar ou ativo. Transformações espaciais produzem então um geocódigo, uma rota ou uma região antes que um contexto minimizado chegue ao mapa e a analytics. Identificadores, coordenadas e o rótulo de precisão de exemplo da figura são ilustrações. Um registro de produção deve manter a fonte, o horário de observação, a versão da transformação, a precisão e um identificador de linhagem.
Mantenha os metadados com o registro: um identificador da fonte, um horário de observação, uma versão da transformação, a precisão usada e um identificador de linhagem. Uma correção posterior pode então localizar todas as cópias derivadas que ainda dependem da coordenada antiga. Desconhecido é um estado diferente de falso. A ausência de horário de observação não prova que o lugar está atualizado. Transformações reproduzíveis e enriquecimento versionado tornam uma explicação possível. Uma coordenada que aparece em analytics sem uma linha de origem é um registro que a equipe já não consegue defender.
Por que o controle de acesso deve acontecer antes do contexto de AI?
Resolva o usuário, o tenant, o papel, os objetos e os campos antes que qualquer registro espacial privado chegue a um cálculo ou a um modelo. O bom caminho filtra primeiro as localizações permitidas e executa o trabalho espacial apenas nesse conjunto. O caminho bloqueado envia um conjunto de dados privado inteiro e tenta esconder o que o usuário não deveria ver depois que o modelo já o recebeu. Esconder não é autorizar. A orientação sobre localização privada para mapas com AI coloca a mesma ordem por escrito: autenticar, autorizar, depois recuperar uma fatia minimizada, e não carregar um banco de dados interno sem restrições (Kaleidr, 2026).
O bom caminho verifica usuário, tenant, papel, objetos e campos antes que qualquer localização privada chegue a um cálculo ou modelo. O caminho bloqueado envia um conjunto de dados privado inteiro e tenta esconder linhas depois. Essa ordem é o modo de falha. A autorização vem antes da recuperação, não depois que um modelo já viu as linhas.
Uma credencial de plataforma identifica a integração. Uma permissão de usuário final identifica qual tenant, objeto e campo essa pessoa pode usar. São verificações diferentes, e uma chave válida da organização não dá ao cliente A o direito de ler lojas, ativos ou origens do cliente B. Caches e stores de retrieval precisam do mesmo limite de tenant da consulta primária. Teste de propósito a falha entre tenants. Um mapa que parece correto para um usuário autenticado ainda pode estar vazando registros do vizinho por uma chave de cache compartilhada.
Quanto tempo cada cópia de localização deve durar?
A retenção segue a finalidade. Um único número global de dias não atende ao mesmo tempo uma origem usada apenas durante uma solicitação, um lugar salvo em uma conta, um histórico de veículo ou incidente e um extrato de analytics em nível de mercado. Uma coordenada usada apenas para a solicitação pode terminar quando a solicitação termina. Um lugar vinculado à conta pode durar enquanto o recurso ou a conta estiver ativo. O estado operacional pode manter um valor atual mais um histórico governado depois que o evento se encerra, por segurança, suporte ou registro contratual. Analytics pode manter uma precisão reduzida, agregada ou desidentificada conforme a política de analytics, por mais tempo do que a coordenada em tempo real.
A retenção segue o trabalho, não um número global. Uma origem usada apenas para a solicitação pode expirar quando a solicitação termina. Um lugar vinculado à conta pode durar com o recurso, e o estado operacional pode manter um histórico governado depois do encerramento do evento. Analytics pode conservar uma geografia mais ampla por mais tempo, enquanto as durações exatas continuam específicas da organização.
Separe a localização de que o produto precisa naquele momento da localização que analytics mantém. Uma entrega em tempo real pode precisar de um endereço. Um dashboard de alcance, sessões e engajamento com lugares muitas vezes precisa de um mercado, uma cidade ou uma área de influência. Documente essa separação para que um gráfico não armazene silenciosamente o ponto exato no telhado que o produto usou uma única vez. As durações exatas são específicas da organização e do contexto. A figura mostra a forma de quatro ciclos de vida, não um cronograma de retenção que uma equipe possa copiar para uma política.
O que precisa se mover quando um registro de localização é excluído?
A exclusão é um fluxo de propagação. Uma solicitação para excluir ou revogar um registro precisa alcançar o armazenamento primário, caches em memória e de edge, índices de busca e vector stores que mantêm embeddings. Tabelas de analytics, exportações e sistemas de provedores precisam de tratamento próprio, que pode ser exclusão, expiração governada ou desvinculação documentada do identificador. Stores de observabilidade precisam da mesma revisão. Prefira identificadores, versões, contagens e códigos de motivo na telemetria, e mantenha segredos, registros privados brutos e coordenadas precisas desnecessárias fora desse store (Kaleidr, 2026).
Uma exclusão ou revogação precisa alcançar o armazenamento primário, caches, índices de busca e vector stores. Analytics, observabilidade, exportações e sistemas de provedores precisam de tratamento próprio, que pode ser exclusão, expiração ou desvinculação documentada. Backups seguem sua política de retenção e talvez não removam um registro individual imediatamente. O diagrama é um mapa de propagação, não um único comando de exclusão.
Backups, snapshots e arquivos seguem o ciclo de vida de backup. Não afirme que todo backup consegue apagar um registro individual sob demanda. Diga o que a política de backup realmente faz, incluindo quanto tempo um registro excluído pode permanecer em um snapshot. Contratos de provedores pertencem ao mesmo mapa: um provedor de modelo ou enriquecimento que retém prompts pode manter uma cópia da localização depois que a linha primária desaparece. A revogação de acesso é relacionada, mas não idêntica. Um usuário que perde uma função deve parar de receber novos registros imediatamente, mesmo quando um agregado antigo ainda está dentro da janela de analytics.
Onde a governança de dados de localização deve ficar ao lado da Kaleidr?
Mantenha identidade, autorização de tenant, dados empresariais privados, CRM, estoque, reservas, política de retenção, decisões jurídicas e de privacidade e transações dentro da organização host. Aplique finalidade, precisão, autorização, minimização e linhagem antes que qualquer registro autorizado alcance uma superfície da Kaleidr. Kaleidr Enterprise é infraestrutura de location intelligence com inference APIs, sistemas de ranking e analytics criados para produtos espaciais modernos (Kaleidr, 2026). A documentação para desenvolvedores descreve Chat como Spatial AI no mapa do host, Viewer como publicação de um mapa, Tile como mapas-base projetados e Editor como desenho e edição (Kaleidr, 2026). Viewer incorpora um mapa publicado por seu share id e não exige uma publishable key para essa incorporação (Kaleidr, 2026).
A coluna da esquerda permanece com o host: identidade, autorização de tenant, dados empresariais privados, CRM, estoque, reservas, política de retenção, decisões jurídicas e de privacidade e transações. O centro lista os controles que o host aplica antes que qualquer registro atravesse o limite: finalidade, precisão, autorização, minimização e linhagem. A coluna da direita nomeia superfícies documentadas da Kaleidr: Enterprise, Chat, Editor, Tile, Viewer e Analytics. Kaleidr não substitui os sistemas do host da coluna esquerda.
A documentação distingue uma credencial de servidor, usada no backend, de uma credencial publicável do navegador que o SDK troca por uma sessão de curta duração e não envia como bearer bruto (Kaleidr, 2026). Nenhuma das duas formas é uma permissão de usuário final, e uma credencial de servidor não pertence ao código do navegador. Kaleidr Analytics documenta alcance, visualizações e engajamento, localização e atividade da audiência entre mapas, e sessões, visualizações e interações por mapa, além de padrões espaciais como clusters, lacunas e rotas (Kaleidr, 2026). Decida quais desses sinais podem carregar localização detalhada e quais devem permanecer em granularidade mais ampla no data warehouse do host. Confirme retenção e processamento contratuais para a implantação em vez de inferi-los deste artigo.
Explorar Kaleidr Enterprise para adicionar spatial intelligence ao lado dos sistemas que já possuem usuários e registros. Explorar Kaleidr Analytics para engajamento documentado com mapas e lugares dentro da precisão permitida pela revisão de governança. Leia ambas as páginas à luz do inventário e mantenha qualquer localização mais detalhada no sistema host quando o gráfico não precisar dela.
Observação: Kaleidr usa ferramentas assistidas por AI para criação de imagens, refinamento de conteúdo e pesquisa em seus fluxos criativos e de desenvolvimento.
FAQs
Uma permissão de localização do navegador autoriza todos os usos posteriores?
Não. A solicitação decide se uma origem pode receber a localização do dispositivo. Retenção, compartilhamento, uso de modelo, junções com CRM, analytics, treinamento e exclusão continuam sendo decisões organizacionais separadas.
Analytics deve manter a mesma precisão do produto em tempo real?
Não por padrão. Uma tarefa em tempo real pode precisar de um lugar ou endereço. Um gráfico de mercado muitas vezes pode manter uma cidade, uma área de influência ou outra geografia de menor precisão sob sua própria regra de retenção.
Kaleidr substitui o programa de governança de dados de localização de uma empresa?
Não. Kaleidr fornece recursos documentados de Spatial AI, mapas, SDK, API e analytics. A organização host continua responsável por permissões de usuários, sistemas empresariais privados, classificação, retenção e decisões jurídicas ou de privacidade, salvo quando um contrato específico disser o contrário.
O que uma solicitação de exclusão deve alcançar?
O armazenamento primário, caches, índices de busca, vector stores, extratos de analytics, exportações, telemetria e sistemas de provedores que mantêm uma cópia. Backups seguem seu próprio ciclo de vida e podem não apagar um registro individual imediatamente.
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}
}