企业级 Spatial AI 架构

企业级 Spatial AI 架构会把语言模型、地图、业务数据、空间计算、权限、工具和操作分开，让每项工作都留在真正能够执行其规则的层中。回答再流畅，也可能把用户引导到错误的门店。宿主系统保留身份与交易。空间服务负责地理计算。语言模型负责理解请求，并解释已经由这些系统完成事实落地的结果。

下文将介绍所有权、授权、凭证、工具、请求路径以及三种部署模式。相关内容包括 Spatial AI Accuracy Evaluation 和 An Enterprise Spatial AI Pilot。相比没有任何系统记录支持、但听起来合理的推荐，正确拒绝有时反而是更好的结果。

企业级 Spatial AI 架构要点

• 分离职责： 语言模型负责解释与说明。库存、权限、路线和交易不应由模型拥有。
• 先授权，再检索： 在私有上下文进入模型之前，先解析用户、租户、对象和字段。
• 事实保持类型化： 稳定 ID 和运营字段保持结构化。不要用自然语言替代它们。
• 限制每个工具： 读取、地图、草稿和写入操作应采用不同的审批规则。
• 衡量工作流： 关注位置决策和宿主系统结果，而不仅仅是 token 和延迟。

什么是企业级 Spatial AI 架构？

客户可能会问：哪一个服务中心今天可以处理某项工作、位于合同覆盖范围内，并且相对当前路线增加的出行时间最少。这样一个问题需要意图层、客户与合同记录、设施数据、服务区域规则、路线计算和地图工作流。生产系统还需要身份、租户隔离、工具边界、操作检查、日志，以及让人工审批高影响步骤的位置。把所有这些职责都塞进一个 prompt，会让产品既难以保护，也难以修改。模型可以指出下一步应该做什么，但规则执行应留在模型之外。

左侧让一个模型直接连接数据库、路由和交易。右侧则把身份、数据、空间工具、排序和已验证操作放在独立层中。这里展示的是一种架构模式，而不是 Kaleidr benchmark。

更实用的路径，不是让用户直接与一个能够访问一切的模型交流，而是建立一条宿主系统可检查的处理链。应用持有用户信息和当前地图状态。身份与授权在检索前完成。之后，意图理解只请求已批准的数据和空间计算。资格检查会在排序前移除无效选项。通过验证的操作更新地图或工作流，分析层记录任务是否成功。这样一来，团队可以更换模型、地图供应商或排序规则，而不必围绕一个不透明依赖重建整个产品。

每一类事实应该由哪个系统拥有？

架构讨论应在选择模型之前，先明确每一项关键事实的所有者。宿主身份提供方拥有用户身份。宿主应用拥有租户成员关系、产品权限、工作流和业务结果。业务系统拥有设施身份、库存、可用性、价格、预订状态和政策。经批准的位置数据源拥有坐标。空间计算层拥有距离、出行时间和 point-in-polygon。客户端应用拥有 viewport 和当前选中的地点。AI 层拥有意图解释，以及基于已落地证据生成的说明。宿主工作流拥有最终交易。

每一列只有一个主要所有者。AI 层负责协调意图与说明。宿主和业务系统仍然是 system of record，这张图是一个框架，而不是产品清单。

如果团队说不清某项关键事实到底归谁所有，助手通常只会把这个缺口掩盖起来。Kaleidr 关于 grounded Spatial AI 的指南使用同样的分工：模型负责理解复合意图，而库存、政策、权限和路由仍留在专门保存这些事实的系统中（Kaleidr, 2026）。retrieval 负责找到上下文。authority 决定哪个来源可以回答事实问题。被检索出来的文档不会自动成为 system of record。

为什么必须先授权，再检索？

一种常见错误是先检索私有数据、发送给模型，然后再让模型判断用户可以看哪些行。顺序应该反过来。先验证用户身份，解析租户，解析角色与权限，授权对象，最小化字段，检索已经批准的记录，最后才把必要上下文继续传递。权限边界应当是确定性的，并且可审计。语言模型不应该决定区域经理能否查看某设施、一个客户能否读取另一个客户的位置历史，或员工能否检索受限的工作场所数据。

私有记录只有在完成租户、角色、对象和字段检查后才能跨越边界。下方那条让模型基于完整数据库推断权限的路径保持阻断。平台凭证与最终用户授权仍是两项不同检查。

平台凭证可以证明应用被允许使用某项能力，但它不能决定哪个最终用户能读取哪些行。CORS、凭证认证、API capability scope 和应用级用户授权解决的是不同问题；混在一起会形成错误的失败模式（Kaleidr, 2026）。因此，私有数据路径应是一组层叠检查，而不是一个“代表一切”的 token。

浏览器凭证和服务器凭证应该如何分离？

浏览器可以被检查，因此发到浏览器中的任何内容都应该视为对运行它的人可见。长期秘密信息、私有业务数据访问、政策执行和 server-to-server 调用应放在 backend。浏览器可以持有一个可公开、对客户端安全、且只面向有限地图能力的凭证。经过身份验证的产品请求发送到宿主 backend，backend 应用用户上下文、访问私有数据，并使用 server credential 调用空间或 AI 操作。两个运行环境不应共享同一个秘密。

浏览器端按“可能暴露”来设计，只保留有限范围的客户端能力。服务器端保留 server credential、私有记录和用户授权。图中的勾选只是边界示意，并不是安全认证。

Kaleidr 当前的 key 文档定义了用于浏览器的 publishable key，以及用于 backend 集成的 server key。publishable key 绑定 origin，SDK 会在运行时把它交换为短期会话，而不是把这个字符串长期当作 server bearer 使用。server key 保留在可信服务器上（Kaleidr, 2026）。同一组文档也把 Chat、Editor、Tile 和 Viewer 描述为不同 surface，它们分别通过 attach、embed 和 tile 等入口接入，并不采用完全相同的 mount 方式（Kaleidr, 2026）。应遵循每个 surface 当前的 contract，而不是假设一个凭证和一种 mount 方式就能覆盖整个技术栈。

业务事实和地理信息应该放在哪里？

Enterprise Spatial AI 的价值，在于它能够基于公开模型不知道的事实进行推理，例如当前库存、合作伙伴资格、设施能力、合同覆盖、临时关闭和实时可用性。这些事实属于 system of record。不要让模型记住一个今天下午就可能发生变化的值。不要把可以通过查询返回的运营字段拿来做模型 fine-tune。不要把大范围内部数据库粘贴到 system prompt 中。正确流程是：理解请求，判断需要哪些已授权记录，只检索最小集合，保留稳定 ID 和类型化字段，执行硬性过滤器，计算地理关系，然后再解释已经完成 grounding 的结果。

{
  "branch_id": "b_1042",
  "open_now": true,
  "inventory_status": "in_stock",
  "service_eligible": true,
  "lat": 38.91,
  "lng": -77.22
}

类型化记录可以被过滤、记录日志、检查权限，并传递给后续操作。一个写着某家门店“看起来开着”且“可能”有货的句子做不到这些。自然语言仍然适合用于解释，但它不应取代应用可以直接保存的字段。

空间计算也应该因为同样的原因拥有独立层。point-in-polygon、路线距离、驾车时间、步行时间、服务区域成员关系、路线偏离程度，以及是否能在指定时间内到达等分析，如果产品能够计算，就应由地理服务提供。AI 层可以判断“需要进行计算”，但真正的计算应由空间服务执行。之后，解释层再说明这类关系为什么对当前请求重要。更换语言模型不应该迫使团队重新定义应用如何计算出行时间或包含关系。

硬性约束和软性偏好应该保持分离。一个诊所查询可能要求接受某保险计划、18:00 以后营业、地点处于启用状态，并且用户有权访问该记录。只有通过这些规则的候选项，才应该根据驾车时间、路线偏离或指定偏好进行排序。正确顺序是 retrieval、授权、资格检查、空间计算、排序、解释。先排序，再希望模型记住所有约束，会让无效选项藏在一份看似流畅的 shortlist 中。零售、房地产、预订、工作场所以及多地点网络都可以使用同样的顺序，因为这里的约束关乎有效性，而不是行业术语。

工具和操作应该如何设限？

Agentic Spatial AI 会让工具目录本身成为重要边界之一。任意 SQL 字符串、shell command 或自由格式内部 URL 这样的开放工具，本质上是执行环境，而不是业务能力。更适合的是输入和输出都明确的窄工具，例如：搜索合格地点、计算出行时间、读取门店可用性、展示地点、请求路线，或创建预订草稿。每个工具都可以拥有自己的权限检查、验证、rate limit、日志记录和失败模式。

当调用者已经完成授权时，读取和地图工具可以运行。草稿会创建一个可供审查的对象。确认预订、分派任务或修改记录的写入操作，则需要等待明确的政策 gate。这里的层级是架构指导，并不是固定的 Kaleidr 权限列表。

读取记录和改变业务状态属于不同风险类别。生产环境中的工具目录可以把能力分成 read、map、draft 和 write。通过授权后，读取和低影响地图操作可以自动执行。draft 可以准备一份预订或服务请求供人工审查。确认预订、调度车辆或发布变更的 write，则可能需要用户确认、第二次政策检查，有时还需要人工审批。confidence score 不是权限系统。

OWASP 2025 年关于 excessive agency 的指南，将过度功能、过度权限和过度自主性视为不同原因。它建议把 agent 能够调用的 extension 限制在最低必要范围，优先使用细粒度函数而不是开放式能力，对高影响操作要求审批，并在 downstream system 中真正执行授权，而不是依赖模型决定是否允许调用（OWASP, 2025）。即使如此，应用仍然应该验证每一个提议的调用。对于地图操作，应检查该操作是否允许、place ID 是否属于已授权结果集、用户是否有权访问这些地点，以及参数是否格式正确。对于 write，应采用更严格检查。prompt、被检索文档或格式错误的工具结果，都不能变成授权绕过路径。

OWASP 关于 system prompt 的指南从另一侧强调了相同边界。system prompt 不是秘密，也不是安全控制。权限分离和授权检查不能通过 prompt 或其他方式委托给模型（OWASP, 2025）。地图操作应使用语义化词汇，例如展示地点、调整视图以容纳地点、选择地点、绘制路线、清除路线，然后由确定性 adapter 把这些操作转换成 Mapbox、MapLibre、Google Maps 或其他 renderer 的具体行为。模型不应在每一轮都输出 renderer code。

地图状态应该如何进入请求？

地图状态会改变用户所说的“这些”“这里以北”或“第二个选项”到底指什么。一个有用的 snapshot 可以包括 viewport bounds、已选择地点的 ID、当前可见 result ID、active filter、当前 route ID，以及按照任务所需精度获准使用的位置。应明确哪些字段始终可用、哪些可选、哪些是私有的、哪些已由用户批准、哪些可能过时、哪些是权威数据、哪些是推断结果。不要仅仅因为地图能够读取精确 device location，就在每个请求中发送它。对于“这些地点里哪个营业更晚”这种问题，最强的引用不是截图，而是当前结果集合中的稳定 ID。Kaleidr 关于 map-aware assistant 的指南也明确了这一边界：共享 viewport、selection、filter 和 result ID，不要让模型从像素中推断应用状态（Kaleidr, 2026）。

编排层可以决定某个请求是否需要业务数据 retrieval、路由、地图操作、澄清问题，或者证据摘要。它可以由模型驱动、规则驱动，也可以二者结合。但它不应该是唯一的安全边界。编排层可以判断是否需要查询可用性。授权层则回答：这个调用者是否有权为这些记录检索可用性。编排层可以判断是否要开始预订。交易层则回答：用户是否已经确认，以及该操作是否有效。这种分离即使在模型出错时也能成立。

租户隔离也属于同一条路径。在查询前解析经过认证的身份、租户、角色和允许对象，并把查询 scope 限制到该租户。不要依赖一个 prompt 去告诉模型“不要提到其他租户”。除非应用具有明确的跨租户目的和政策，否则模型绝不应该接收到另一个租户的数据。tenant-scoped query、对象检查、字段最小化以及经过脱敏的日志，才是实际控制措施。prompt 中的一句话不是。

一个生产请求如何穿过整套技术栈？

一个完整请求可以分成十二个阶段，但并不是每个请求都要经过全部阶段。先获取经过认证的用户、租户、地图状态和工作流状态。理解任务、地理约束、业务约束以及预期操作。在进行任何私有检索之前，解析允许使用的数据源、记录、字段、工具和操作。

检索已授权事实和 canonical place ID，然后计算距离、出行时间、包含关系或服务区域成员关系。移除未授权、不可用、已关闭或超出区域的候选项，再对剩余候选进行排序。解释已经 grounding 的结果，提出语义化地图或工作流操作，并在模型之外验证该操作。执行操作，然后记录决策和结果。

这些阶段从地图状态和意图开始，经过授权、grounding、地理计算、资格检查和排序，然后进入解释、拟议操作、验证、执行和衡量。简单的“显示这个地点”请求可以跳过 retrieval 和排序。服务推荐则可能使用几乎整条路径。

失败行为也是同一路径的一部分。如果业务数据不可用，不要编造可用性。应明确说明当前无法验证可用性。如果路由服务不可用，就不要声称做了基于出行时间的排序；如果使用直线距离替代，应明确标注为 fallback。如果没有任何候选项通过硬规则，应返回 no result，而不是默默放宽关键约束。如果授权失败，不要让模型解释它从未接收到的私有信息。如果模型不可用，确定性搜索与过滤器仍然可以继续支撑地图功能。如果工具结果格式错误，则在验证阶段拒绝它。当产品没有明确 degraded mode 时，语言模型很容易无意中变成“缺失基础设施”的 fallback。

人工审批应根据影响程度决定，而不是所有按钮都使用同一条规则。展示三个公开地点属于低影响。确认预约、调度车辆、修改设施记录或提交付费预订则不是。可以把搜索、retrieval 和路线预览归为低影响；保存偏好或草稿归为中等影响；购买、调度、运营写入或权限修改归为高影响。然后分别匹配自动执行、用户确认或独立审批。NIST 的 AI Risk Management Framework 是自愿采用的框架，旨在把可信性纳入 AI 产品的设计、开发、使用和评估。NIST 同一页面还说明 AI RMF 1.0 正在修订（NIST, 2023）。该框架为产品自己的风险判断提供背景，并不是 Kaleidr 的控制清单。

控制平面位于哪里？

请求路径负责实时工作：用户、授权、retrieval、空间工具、模型、操作和响应。控制平面决定这条路径允许以什么方式运行。凭证、scope、模型选择、prompt、工具策略、数据源配置、rate limit、环境、评估套件、feature flag 和审计设置都放在这里。把两者分离后，团队可以不重写每个对话流就修改政策。禁用一个 write tool 不应该要求设计一套新界面。控制平面是用于管理这些设置的一种架构模式，图中并没有声称某个产品一定提供所有方框。

上排是配置：凭证、scope、模型、prompt、工具策略、数据源、限制、评估、flag 和审计设置。下排是实时请求。政策箭头指向它所控制的阶段，因此团队可以修改规则，而不必重写整个路径。

可观测性应追踪决策，而不只是 token 账单。值得记录的事件包括：意图解析完成、授权通过或拒绝、retrieval 完成、因资格检查移除候选、空间计算完成、排序完成、no-result 响应、工具被提议、工具被拒绝、地图操作已执行、地点已选择，以及工作流完成。这些名称是需要设计的一种模式，并不是平台自动输出的固定列表。它们回答的是很实际的问题：错误来自地点解析还是排序？用户是否在拒绝一份本来有效的 shortlist？某个市场是不是产生更多空结果？工具调用是因为权限失败，还是因为参数格式错误？用户选择地点后，是否完成了宿主任务？NIST AI RMF core 指出，应记录 test、evaluation、verification 和 validation 中使用的测试集、指标以及工具细节（NIST, 2023）。对于 Spatial AI，文档化测试应该覆盖地理和业务决策，而不只是生成的句子。

空间分析和宿主结果回答的是不同问题，架构应该使用稳定 ID 把两者连接起来。Kaleidr Analytics 目前描述了有关 reach、view、engagement、受众位置和活动、每张地图的 session、view、interaction 以及空间模式的 dashboard（Kaleidr, 2026）。预订、购买、qualified lead、调度以及已完成服务，仍然保留在真正拥有这些数据的宿主系统中。recommendation ID 可以指向 selected place ID，然后指向 host workflow ID，最后连接到结果。公开的 Analytics 材料并没有声称所有业务 conversion 都会自动捕获。

三种部署模式是什么？

三种模式可以覆盖大多数企业部署，但没有一种模式永远最好。公开地图助手适合旅游、发现、编辑型地图和活动探索。浏览器地图使用可公开的 client capability、map-aware AI、公开或经批准的地点数据以及空间工具，最后返回地图操作。因为工作流大多处理公开信息，所以数据边界更简单。经过认证的业务助手适合客户门户、考虑库存的门店选择、房地产、合作伙伴网络和私有设施。浏览器连接宿主登录和宿主 backend，backend 先应用 tenant 和 object 授权，然后私有数据、空间工具和解释才返回地图。带业务操作的 spatial agent 适合预订、调度和运营工作流。该路径会增加类型化 tool proposal、确定性 validation、在高影响场景需要的 confirmation、transaction system，以及结果 audit。第三种模式会改变业务状态，因此需要最严格的 governance。

公开模式只处理已批准的公开地点。认证模式把私有记录保留在宿主之后。操作模式在交易前增加 validation 与 confirmation。图中的示例 place card 仅用于说明，并不是 Kaleidr 的测量结果。

Kaleidr 在这套架构中位于哪里？

Kaleidr 当前把 Enterprise 描述为面向产品团队的 location-intelligence infrastructure，包含 inference API、ranking、Analytics 以及宿主可添加的 SDK surface（Kaleidr, 2026）。开发者文档在一个 SDK 中列出四种 surface。Chat 把 AI interaction 接到宿主已经运行的地图上。Editor 在产品内部 mount 地图编辑。Tile 提供设计过的 basemap。Viewer 发布地图用于 embed。当前 Chat 文档列出 Mapbox、MapLibre 和 Google Maps 作为宿主自有地图的集成路径（Kaleidr, 2026）。宿主继续保留最终用户、身份验证、tenant 授权、私有业务系统、工作流规则、交易和业务结果。Kaleidr 添加所选空间 surface，但不取代宿主技术栈中仍然具有权威性的系统。

宿主这一行保留用户、tenant 授权、工作流、私有系统、交易和结果。Chat、Editor、Tile、Viewer 与 platform API、Analytics 并列。凭证标签遵循公开浏览器与服务器的分离方式，图中没有展示真实秘密信息。

哪些错误往往直到生产环境才暴露？

把模型直接连接到所有系统会造成过度权限，也更难定位到底哪一层失败。把 prompt 当作授权层同样会失败：prompt 可以影响措辞，却无法确定性地允许或拒绝某一条记录。把整个内部数据库发送进 context 违反最小化原则。把硬性过滤与排序混在一起，会让不合格地点继续留在平均结果中。让模型估算本应由空间服务计算的距离，是用语言流畅性替代真正计算。一个没有限制的工具，或者继承了 read tool 政策的 write tool，会让一条推荐获得交易级权限。把地图当成图片会丢失下一轮需要的稳定 ID。只监控延迟和 token 成本，会漏掉地点解析、资格检查、路由、排序、工具失败以及宿主结果。单独一个模型 benchmark，无法证明组装好的工作流已经适合生产。

NIST 的 TEVV-Athlon framework——NIST AI 200-2——initial public draft 于 2026 年 8 月 7 日宣布，并开放意见到 2026 年 10 月 6 日。它把评估描述为证明系统达到个人或组织目标的证据，测量应根据应用及其真实世界影响进行调整，包括 agentic system（NIST, 2026）。该文件是正在征求意见的草案，并不是 Kaleidr 的控制清单。对于这套架构，评估上下文应是位置依赖决策本身：意图、授权、grounding、地理、资格、排序、工具、操作、失败处理以及宿主结果。

企业级 Spatial AI 架构如何成为发布门槛？

在 pilot 向生产推进之前，先确认所有者。工作流要求的地方必须完成用户认证，租户成员关系在模型之外解析。每一个关键字段都应有权威来源；私有 retrieval 在推理前执行；字段最小化；稳定 ID 在跨层传递时继续保留。地理服务执行产品声称能够提供的计算，评估中使用的 tolerance 应提前记录。工具必须保持窄范围，read 与 write 分离，参数经过验证，高影响操作可以被确认和审计。浏览器凭证与服务器凭证保持分离，scope 保持有限，环境保持隔离。团队能够看到整个决策链，并能把地点选择连接到宿主结果。不可用数据、空候选集合和 degraded mode 都应显式处理；关键操作应 fail closed，而不是编造事实。探索 Kaleidr Enterprise，可了解如何在产品现有技术栈旁增加 spatial intelligence API、ranking、Analytics 和 SDK surface。实施前请 阅读 Kaleidr 开发者文档，确认 Chat、Editor、Tile、Viewer、key 和 scope 的当前 contract。

常见问题

什么是企业级 Spatial AI 架构？

企业级 Spatial AI 架构是一种系统设计，用来连接语言模型、地图、地理服务、业务数据、权限、工具、操作和分析，并把每一项职责保留在真正能够执行相应规则的层中。

语言模型应该直接访问业务数据库吗？

通常不应该把它作为不受限制的接口。先授权当前用户，只检索任务需要的最少记录，保持字段结构化，并暴露范围明确的窄工具。开放式数据库访问会让模型变成权限引擎。

语言模型应该负责什么？

模型适合处理自然语言意图、已批准能力之间的编排，以及解释已经 grounding 的结果。授权、交易、业务事实和地理计算应留在专门为这些职责设计的系统中。

平台认证和用户授权有什么区别？

平台认证确认某个应用可以使用平台能力。用户授权决定哪个人或租户可以访问一条记录或执行某项业务操作。一种检查不能代替另一种。

Spatial AI 应该使用 retrieval-augmented generation 吗？

retrieval 可以提供相关文档或记录，但 retrieval 本身不能建立 authority。库存、可用性、价格、权限和服务区域成员关系，仍应绑定到各自的 system of record 和确定性规则。

Spatial AI 工具应该如何保护？

使用窄函数、最小权限、基于用户上下文的授权、参数验证、rate limit、监控，以及针对高影响操作的独立审批。不要把模型或 system prompt 当作授权机制。

Spatial AI 操作应该需要人工审批吗？

审批应根据影响决定。展示地点这类低风险地图操作可以自动执行。购买、预订、调度、管理写入和权限修改，则可能需要显式确认或独立审批。

地图助手应该如何使用当前地图？

传递结构化状态，例如 viewport bounds、选中的 place ID、active filter、可见 result ID、route ID，以及满足任务精度需求的位置。既然已有结构化状态，就不要要求模型从截图中推断应用状态。

Spatial AI 可以与现有地图配合使用吗？

可以。Spatial AI 层可以接入宿主已经运行的地图和应用。Kaleidr 当前的 Chat 文档说明了如何把 conversational Spatial AI 接入宿主运行的 Mapbox、MapLibre 或 Google Maps 实例。

团队在扩大规模之前应该如何评估这套架构？

应评估整个组装后的工作流：意图、授权、grounding、地理计算、资格、排序、解释、工具、操作、失败处理和业务结果。通用语言模型 benchmark 无法替代这项测试。

参考资料

1. Kaleidr. Grounded Spatial AI for Business Data. https://kaleidr.com/blog/grounded-spatial-ai-business-data
2. Kaleidr. Map API Authentication. https://kaleidr.com/blog/map-api-authentication
3. Kaleidr. Get an API Key. Publishable browser keys and server keys. Accessed September 30, 2026. https://docs.kaleidr.com/get-an-api-key
4. Kaleidr. Introduction. Chat, Editor, Tile, and Viewer in one SDK. Accessed September 30, 2026. https://docs.kaleidr.com/
5. OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
6. OWASP Gen AI Security Project. LLM07:2025 System Prompt Leakage. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/
7. Kaleidr. How to Build a Map-Aware AI Assistant. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
8. National Institute of Standards and Technology. AI Risk Management Framework. Voluntary framework for trustworthiness in design, development, use, and evaluation. Released January 26, 2023. Page states that AI RMF 1.0 is being revised. Accessed September 30, 2026. https://www.nist.gov/itl/ai-risk-management-framework
9. National Institute of Standards and Technology. AI RMF Core. Measure 2.1: test sets, metrics, and details about the tools used during TEVV are documented. Accessed September 30, 2026. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
10. Kaleidr. Map Engagement and Location Analytics. Accessed September 30, 2026. https://kaleidr.com/analytics
11. Kaleidr. Location Intelligence APIs and Map SDK. Accessed September 30, 2026. https://kaleidr.com/enterprise
12. Kaleidr. Chat. Attach AI to a host-run Mapbox, MapLibre, or Google Maps instance. Accessed September 30, 2026. https://docs.kaleidr.com/chat
13. National Institute of Standards and Technology. The TEVV-Athlon Framework for Evaluating AI Systems. NIST AI 200-2, initial public draft. Announced August 7, 2026; comments through October 6, 2026. https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
14. Kaleidr. Spatial AI Accuracy Evaluation. https://kaleidr.com/blog/spatial-ai-accuracy-evaluation
15. Kaleidr. An Enterprise Spatial AI Pilot Before Scaling. https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling

@misc{kaleidr_grounded_architecture_2026,
  title  = {Grounded Spatial AI for Business Data},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}

@misc{kaleidr_map_api_auth_2026,
  title  = {Map API Authentication},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/map-api-authentication}
}

@misc{kaleidr_get_api_key_2026,
  title  = {Get an API Key},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://docs.kaleidr.com/get-an-api-key}
}

@misc{kaleidr_docs_intro_2026,
  title  = {Introduction},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026. Chat, Editor, Tile, and Viewer},
  url    = {https://docs.kaleidr.com/}
}

@misc{owasp_llm06_2025,
  title  = {LLM06:2025 Excessive Agency},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {Accessed September 30, 2026},
  url    = {https://genai.owasp.org/llmrisk/llm062025-excessive-agency/}
}

@misc{owasp_llm07_2025,
  title  = {LLM07:2025 System Prompt Leakage},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {Accessed September 30, 2026},
  url    = {https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/}
}

@misc{kaleidr_map_aware_2026,
  title  = {How to Build a Map-Aware AI Assistant},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant}
}

@misc{nist_ai_rmf_2023,
  title  = {AI Risk Management Framework},
  author = {{National Institute of Standards and Technology}},
  year   = {2023},
  note   = {Released January 26, 2023. Accessed September 30, 2026. Page states AI RMF 1.0 is being revised},
  url    = {https://www.nist.gov/itl/ai-risk-management-framework}
}

@misc{nist_ai_rmf_core_2023,
  title  = {AI RMF Core},
  author = {{National Institute of Standards and Technology}},
  year   = {2023},
  note   = {Measure 2.1. Accessed September 30, 2026},
  url    = {https://airc.nist.gov/airmf-resources/airmf/5-sec-core/}
}

@misc{kaleidr_analytics_architecture_2026,
  title  = {Map Engagement and Location Analytics},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://kaleidr.com/analytics}
}

@misc{kaleidr_enterprise_architecture_2026,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_chat_docs_2026,
  title  = {Chat},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://docs.kaleidr.com/chat}
}

@techreport{nist_ai_200_2_2026,
  title       = {The TEVV-Athlon Framework for Evaluating AI Systems},
  author      = {{National Institute of Standards and Technology}},
  institution = {National Institute of Standards and Technology},
  number      = {NIST AI 200-2},
  year        = {2026},
  note        = {Initial public draft, announced August 7, 2026},
  url         = {https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems}
}