隐私政策
我们实际存储哪些数据、保留多久、谁能访问，以及你的请求内容被转发到哪里去。
- 生效日期
- 2026-07-22
- 最近更新
- 2026-07-22
- 文本修订
- 1.0
1.本政策的范围
1.1
本政策说明 AK Router（下称「我们」）在提供 akrouter 服务过程中如何处理与你有关的数据。它是服务条款的组成部分。
1.2
我们对所有人执行同一套口径，不按法域给你分类。本政策没有"GDPR 用户请看这一节、CCPA 用户请看那一节"的分支：第 9 章的权利（访问、导出、更正、删除、限制处理）对每一个用户开放，不论你身处何地、不论哪部法律适用于你， 你不需要先证明自己受某部法律保护才能行使它们。若某部适用于你的法律赋予你更多权利，以该法律为准，本政策不减损它。
但这一条不等于「我们已经合规」
数据保护法规里有不少义务不是"把权利给用户"就能履行的。 就我们目前的状态，如实说明如下 —— 这几项也分别写在相应章节里，没有藏起来：
- 我们没有与子处理方签署标准合同条款（SCC）或等效的跨境传输安排（第 11.4 条）
- 我们没有指定数据保护负责人（DPO），也没有设立欧盟 / 英国代表（第 13.3 条）
- 我们没有可供企业客户签署的数据处理协议（DPA）
如果你所在的组织把上述任何一项作为采购前提，本服务目前不能满足你 —— 请在采购前联系 [email protected] 确认，而不是在合规审查阶段才发现。
1.3
本政策覆盖两类人：使用我们 API 的买方（开发者）， 以及在我们市场上架渠道的卖方（商户）。 涉及商户特有的处理，本文本会明确标出。
2.我们实际存储哪些数据
下表按数据库中的实际表逐一列出。这不是概括性描述 —— 每一行都对应代码里的一张表，你可以要求我们就任意一行做出解释。
2.1
账户与身份
| 数据 | 内容 | 来源 |
|---|---|---|
| 账户 | 邮箱、显示名、邮箱是否已验证、是否管理员、是否被暂停、创建与更新时间 | 你提供 |
| 登录凭据 | 口令的 scrypt 哈希（不是明文，也不是 md5/sha1）；若接入第三方登录，则为对方返回的 token | 你提供 |
| 会话 | 会话 token、所属账户、过期时间，以及登录时的 IP 与 User-Agent（仅用于异地登录排查，不参与鉴权判定） | 自动记录 |
| 一次性令牌 | 密码重置与邮箱验证用的短期令牌 | 自动生成 |
| 管理操作审计 | 管理员对账户、商户、渠道、订单与平台设置的写操作：操作人、动作、对象、改动前后的关键字段、理由 | 自动记录 |
| API Key | Key 的 SHA-256 摘要与前 12 位前缀、名称、允许的模型、速率与并发上限、价格上限、路由策略、来源 IP 白名单（如你设置了）、最后使用时间 | 你创建 |
我们没有你的 API Key 明文
库里只有 SHA-256 摘要。明文只在创建时向你显示一次，之后我们自己也拿不到 —— 所以我们既无法帮你找回，也无法用它替你发起调用。
2.2
调用记录（请求日志）
每一次 API 调用会写一条结构化的调用记录。内容包括：
- 时间、请求 id、账户 id、API Key id
- 请求的模型、客户端协议、上游协议、是否走了翻译路径、识别出的客户端类型（如 claude-code / codex / sdk）
- 最终选中的渠道与账号、结算归因到的商户，以及全部尝试的清单（每次尝试的渠道、状态码、首字节耗时、错误分类、错误消息、排队时长）
- 输入 / 输出 / 缓存读写的 token 数量与计量来源
- 上游成本与向你收取的金额
- 首字节耗时、总耗时、排队耗时、HTTP 状态、错误分类、结束原因
- 是否流式、你是否主动断开、是否发生过中断续写
- 你的 IP 地址与 User-Agent
★ 我们不存储请求正文与响应正文
你的 prompt、消息内容、模型输出、工具调用参数与结果，都不会被写入我们的数据库。上面那张表里没有任何一个字段用于存放它们。
唯一的例外需要如实说明：当上游返回错误时，我们会把上游错误响应体中的错误消息截断后随调用记录一并留存，用于排障。 个别上游会在错误消息中回显部分请求内容（例如"第 3 条消息格式不正确：…"）， 这种情况下该片段会一并留存。我们不主动提取，也无法逐个上游控制其措辞。
2.3
用量汇总
我们把调用记录按分钟聚合成汇总表（按账户维度、按渠道维度）， 用于控制台的曲线与市场页的成功率展示。汇总表只含计数、token 数、金额与延迟分位数， 不含 IP，也不含任何可回溯到单次请求内容的东西。
2.4
账务
- 账本流水：每一笔充值、消费、退款、赠送与人工调整，含金额、 余额快照、幂等键、关联的请求或订单 id、备注
- 充值订单：支付方、支付方的订单 id、状态、实付金额与币种、入账额度， 以及支付方 webhook 的原始报文
关于原始支付报文
我们保存支付服务商回调的完整报文，因为出现账务分歧时它是唯一能复盘的证据。 该报文由支付服务商生成，可能包含我们并未主动索取的信息（如付款人姓名、账单国家、卡号后四位）。我们不接触也不存储完整卡号或加密货币私钥。
2.5
路由偏好：你在账户级与 Key 级设置的成本护栏、渠道范围、 是否只用已认证商户等策略。
2.6
商户数据（仅适用于卖方）
| 数据 | 内容 |
|---|---|
| 商户资料 | 商户名、联系方式（微信 / Telegram / 邮箱）、简介、状态、认证时间、抽成比例 |
| 入驻与渠道申请 | 提交时的完整表单快照（含加密后的上游凭据）、自动探测报告、审核人、审核意见与时间 |
| 渠道与账号 | 上游地址、模型映射、协议、报价、能力矩阵、并发上限，以及加密后的上游凭据 |
| 探测记录 | 每次探测的类型、结论、耗时、消耗的 token 与成本、详情 |
| 结算 | 商户侧账本：应结、抽成、打款流水；加密后的结算信息 |
2.7
我们不做的事：不使用第三方广告追踪，不构建跨站行为画像， 不向数据经纪商出售或出租任何数据。
3.★ 你的请求内容去了哪里
如果本政策你只读一章，读这一章。聚合网关的工作方式决定了你的请求内容必须离开我们的服务器，这件事无法回避， 能回避的只是把它说清楚还是说含糊。
3.1
你的请求内容（prompt、对话历史、系统提示、工具定义与结果、附带的图片等） 会通过我们的服务器转发给被路由选中的上游。上游可能是：
- 模型厂商的官方 API
- 转售商
- 第三方商户在我们市场上架的渠道 —— 商户可能自己也是从别处获得上游能力的，因此你的内容可能沿着这条链路继续往下走
3.2
我们在转发链路上留存什么：不留存正文。请求体经我们的进程转发到上游，响应体以流式回传给你， 两者都不落盘、不写入数据库、不进日志。我们留下的只有第 2 章列出的结构化元数据。
3.3
上游可能留存什么：我们无法控制，也不替它们作出承诺。每个上游有各自的日志、留存与训练政策。 对于商户渠道，商户还可能受制于其自身上游（例如它所转售的账号提供方）的政策。把一次请求发出去，就等于把内容交给了那一条链路上的所有环节。
3.4
容灾会让内容被发送给多个上游。当一条渠道失败时我们会改换渠道重试，这意味着同一份请求内容可能先后 被发送给两家或更多不同的上游。你可以在路由元数据中看到实际发生了哪些尝试。
3.5
你可以限制内容的去向。在账户级或 Key 级路由策略中，你可以：
- 白名单：只使用你指定的渠道
- 黑名单：排除你指定的渠道
- 只使用已认证商户的渠道
- 只使用原生支持你所用协议的渠道（即禁止跨协议翻译路径）
限制越严，可用渠道越少，请求失败的概率越高。这个取舍由你决定。
3.6
敏感数据的建议
如果你要处理的是个人敏感信息、受监管的数据（医疗、金融、身份证件）， 或受保密义务约束的商业信息，请不要在未配置渠道限制的情况下使用本服务。 我们的默认路由会为了可用性与成本在多家第三方之间调度。 企业客户如需数据处理协议（DPA）与限定的渠道范围，请联系 [email protected]。
3.7
我们不使用你的请求内容训练模型。我们不训练模型， 也不会把内容用于我们自己的模型改进。上游各自的政策独立适用。
3.8
探测流量不使用你的内容。我们为检测渠道质量而发出的探针请求 （包括模型一致性检测）使用我们自建的提示词，与用户请求完全独立。
3.9
唯一一处从请求内容派生的存储：会话粘性的短哈希。为了让同一段对话尽量落到同一个上游账号（否则上游的 prompt cache 全部落空， 你的成本与首字延迟都会变差），我们会在路由层的缓存（Valkey）里放一条「会话摘要 → 渠道 + 账号」的绑定。
- 摘要是系统提示与首条消息各取前 2KB 的 SHA-256 截断，两段合计 64 位；原文不出计算函数，不进缓存、不进日志、不进数据库
- 它无法反推出原文，也不用于除路由排序以外的任何目的
- 绑定的有效期是 5 分钟，过期自动消失；命中时续期
说明它的存在，是因为"我们不碰请求内容"这句话如果有例外， 例外必须由我们自己写出来，而不是等别人发现。
4.我们如何使用这些数据
4.1
提供服务：鉴权、路由决策、并发调度、计费与扣费、 向你展示用量与账单、向商户结算。
4.2
保障可靠性：故障排查、容量规划、渠道健康度计算、 识别并降权表现不佳的渠道。
4.3
安全与反滥用：识别凭据泄漏、异常调用模式、支付欺诈与规避封禁的行为。 IP 与 User-Agent 主要用于这一目的。
4.4
履行法律义务：财务记录的保存、税务、以及依法响应有权机关的要求。
4.5
与你沟通：密码重置、邮箱验证、账户与条款变更的通知。 我们目前不发送营销邮件。
4.6
我们不做对你有法律或类似重大影响的完全自动化决策。 自动化的风控（限流、暂停）都可以通过 [email protected] 申诉并获得人工复核。
5.数据的共享与披露
5.1
上游与商户：如第 3 章所述，请求内容会被转发给被选中的上游。我们不会把你的账户身份（邮箱、账户 id）随请求发给商户， 也不会把你的 API Key 转发出去 —— 转发前下游认证头会被剥离并替换为该渠道自己的凭据。
5.2
我们向商户提供什么：聚合结算数据。商户在其后台能看到自己渠道的调用量、token 数、应结金额、成功率与延迟，看不到是哪个用户发起的，也看不到请求内容（请求内容是由上游而非商户后台接收的 —— 商户作为上游服务的运营者， 在其自己的服务端仍可能接触到内容，见第 3.3 条）。
5.3
子处理方：我们使用第三方服务运行本平台（托管、支付、错误追踪、 指标、拨测、邮件）。清单与各自接触到的数据见子处理方清单。
5.4
法律要求：当法律、法院命令或有权机关的合法要求要求我们披露时， 我们会披露必要的数据。在法律允许且不妨碍调查的前提下， 我们会事先通知受影响的用户。执法请求请发送至 [email protected]。
5.5
业务转让：如发生合并、收购或资产转让，相关数据可能作为资产的一部分转移。 我们会提前通知你，受让方须继续受本政策约束或提供不低于本政策的保护。
5.6
我们不出售个人数据，也不以任何对价交换个人数据；不为第三方的广告目的共享数据； 不进行跨情境的行为定向广告。这三句是无条件的，不取决于哪部法律适用于你 —— 我们的收入全部来自 API 用量的平台费。
6.保留期限
下表写的是系统当前实际执行的清理策略，不是理想策略。
6.1
| 数据 | 保留期限 | 如何执行 |
|---|---|---|
| 请求日志 | 约 6 个月 | 按月分区存储，定时任务删除超过保留月数的整个分区（当前配置保留 6 个月） |
| 分钟级汇总（渠道维度） | 30 天 | 定时任务分批删除超期行 |
| 分钟级汇总（账户维度） | 30 天 | 同一个定时任务，与渠道维度的汇总一并分批删除 |
| 账本与订单 | 按财务与税务要求保留 | 不随账户注销删除，见本章第 2 条 |
| 账户资料 | 账户存续期间 | 注销后按第 9 章处理 |
| 会话 | 到期即失效 | 定时任务清理过期会话 |
| 会话粘性绑定（Valkey 缓存） | 5 分钟 | 到期自动失效，不写入数据库 |
| 管理操作审计 | 不删除 | 它的价值就在于事后可查；删除等于取消这项保障 |
| 一次性令牌（重置 / 验证） | 短期有效，过期即清理 | 定时任务 |
| 商户资料、申请快照、探测记录 | 商户关系存续期间及之后的合理期间 | 争议与审计需要 |
6.2
账本流水不可删除。它是仅追加的，任何一条流水都不会被修改或删除 —— 这既是我们能与你对账的前提，也是财务合规的要求。 账户注销时账本会与身份信息解除关联，但流水本身保留。
6.3
备份中的数据会随备份的轮转周期滞后删除。 我们不会为了删除单条数据而回滚备份。
7.谁能访问这些数据
7.1
你自己：控制台可以查看你的账户资料、API Key（仅前缀）、 调用记录、用量汇总、账本与订单。
7.2
我们的管理员：拥有管理员标记的账户可以在管理后台查看全部用户的账户资料、调用记录元数据、账本与订单， 以及商户资料与审核材料。管理员看到的调用记录同样不含请求与响应正文。 管理员权限只授予运维本服务所必需的人员。
7.3
商户：只能看到自己渠道的聚合数据，见第 5.2 条。
7.4
子处理方：按各自职能接触必要的最小数据，见子处理方清单。
7.5
管理员的写操作有审计日志。商户状态变更、渠道上下架、健康度人工覆写、结算与订单操作、平台设置变更 都会写一条审计记录，内容包括操作人、动作、被操作对象、改动前后的关键字段与操作理由。 它的用途是纠纷举证 —— 商户来问"我的渠道为什么被下了"时，我们必须拿得出谁在什么时候做了什么。审计记录不含请求体全文（可能含凭据），也不删除。
7.6
这项保障的边界，如实写在这里：审计覆盖的是写操作； 管理员对数据的查看行为目前不单独留痕。 这一点与你有关，所以我们写出来：我们对管理员访问的约束主要来自授权范围（权限只授予运维本服务所必需的人员）而不是事后追溯。 我们在扩充审计覆盖面，进展不在本页逐条播报。
8.安全措施
我们只写已经实现的措施。我们没有 SOC 2、ISO 27001 或任何第三方安全认证。
8.1
传输：对外全链路 HTTPS，证书自动续期。
8.2
凭据：
- 用户口令以 scrypt 哈希存储
- API Key 只存 SHA-256 摘要，明文不可还原
- 商户的上游凭据以 AES-256-GCM 加密落库，密钥来自环境变量而非代码库，永不回显明文、永不进日志、永不进错误追踪
8.3
会话：登录状态由 HttpOnly、签名的会话 Cookie 承载， 仅经 HTTPS 传输，浏览器端的脚本读不到它。会话有过期时间， 过期与注销后即失效，你也可以随时修改口令使既有会话作废。存放会话记录的数据表及其备份，在运维上按凭据级别对待。
8.4
出站安全：商户提交的上游地址必须通过 SSRF 校验 （拒绝私有网段与环回地址，每一跳重定向重新校验）， 防止有人借我们的出口 IP 攻击内网。
8.5
数据备份：数据库定期备份至对象存储。
8.6
安全事件通知：发生可能危及你数据的安全事件时，我们会在知悉后 72 小时内通知受影响的用户， 并在法律要求时同时通知相应监管机构。 我们取 72 小时是因为它是各辖区里最严的一档 —— 按最严写不会写错，而通知是人发的，不依赖任何尚未建成的系统。
8.7
没有任何系统是绝对安全的。请为你的账户使用独立的强口令， 并定期轮换 API Key。
9.你的权利
9.1
访问与导出：账户资料、调用记录、用量与账本都可以在控制台查看。 如需机器可读的完整导出，请联系 [email protected]。
9.2
更正：账户资料可以在设置中自行修改。
9.3
删除与注销：你可以申请注销账户。注销后我们会删除或匿名化账户资料与会话， 吊销全部 API Key。账本流水、订单与财务相关记录按第 6 章保留， 因为删除它们会使我们无法履行财务与税务义务。
9.4
反对与限制处理：你可以通过限制路由范围来限制内容的转发对象（第 3.5 条）。 对风控处置的申诉见 服务条款 第 12 章。
9.5
上述权利我们不按法域区分。无论 GDPR 的访问权、可携权、更正权、删除权、限制处理权与反对权， 还是 CCPA/CPRA 的知情权、删除权与退出权，其实质内容都已包含在本章第 1 至 4 条中，并对所有用户开放。 你不需要先证明自己适用哪部法律才能行使它们。
9.6
我们会在收到请求后的合理时间内答复。为防止他人冒用你的身份行使权利， 我们可能要求你通过账户绑定的邮箱发起请求。
10.Cookie 与本地存储
10.1
登录会话 Cookie（必要）：用于保持登录状态，HttpOnly 且签名。 没有它无法使用控制台。
10.2
浏览器本地存储：主题偏好（浅色 / 深色）、部分列表的筛选与排序偏好。 这些只留在你的浏览器里，不上传。
10.3
我们不使用广告 Cookie、第三方追踪像素或跨站行为分析。我们用到的 Cookie 只有登录会话这一项，属于提供你主动请求的服务所严格必需的类别， 多数辖区对这一类不要求事前同意 —— 因此本站没有 Cookie 同意横幅。 我们如果日后引入任何非必需的 Cookie，会在引入前加上同意机制，而不是加完再说。
10.4
API 调用本身不使用 Cookie，只用 API Key 认证。
11.数据存储地与跨境传输
11.1
我们的服务器与数据库位于美国。 无论你身处何地，使用本服务都意味着你的数据会被传输至美国并在当地存储与处理。这一点没有关闭选项 —— 继续使用本服务即表示你知悉并同意该传输。
11.2
接收方的类别（不是具体公司名单，具体名单见 子处理方清单）：
- 我们自己：位于美国的服务器与数据库，接触第 2 章列出的全部数据
- 子处理方：托管与网络、支付服务商、错误追踪、指标与拨测、邮件发送； 各自只接触其职能所必需的部分
- 上游模型服务商与商户：接收你的请求内容，见第 3 章。它们可能位于任何国家，商户申报的地理位置信息（如有）仅供参考， 我们不对其真实性作独立核实
11.3
你可以就跨境传输行使权利。对数据的访问、更正、导出、删除，以及对特定处理的反对与限制（包括通过路由策略 限制内容的转发对象），都可以通过 [email protected] 提出，处理方式见第 9 章。
11.4
我们尚未与子处理方签署标准合同条款（SCC）或等效的跨境传输安排。我们如实写出这一点，而不是含糊地说"我们采取了适当的保障措施"。 如果你所在的组织要求数据只在特定法域内处理，或要求签署带 SCC 的数据处理协议，本服务目前不能满足你 —— 请在采购前联系 [email protected] 确认， 而不是在合规审查时才发现。
12.未成年人
12.1
本服务面向开发者，不面向未成年人。使用本服务须年满 18 周岁（见 服务条款 第 4.2 条）。我们不针对未成年人提供服务，也不有意收集其数据。
12.2
如果我们发现在不知情的情况下收集了低于最低年龄者的数据， 会删除相关账户与数据。你可以通过 [email protected] 向我们举报此类情况。
13.政策变更与联系方式
13.1
本政策变更时，我们会更新页面顶部的修订号与更新日期。 涉及数据用途扩大或新增共享对象的实质性变更， 我们会通过邮件或控制台内提前通知。
13.2
第 2 章与第 6 章描述的是数据库里实际存在的表与实际执行的清理策略。我们改动存储结构时会同步更新这两章 —— 如果你发现某一行与你能观察到的行为不符， 请告诉我们，那是需要修正的错误，不是可以含糊过去的表述。
13.3
隐私相关事务、数据主体权利行使与执法请求都请联系 [email protected]（请在主题里写明事由）。我们目前没有指定数据保护负责人（DPO），也没有设立欧盟 / 英国代表 —— 我们的规模还没到那一步，写一个虚职比空着更糟。 隐私事务由处理 support 邮箱的同一批人负责。 你也有权向你所在地的数据保护监管机构投诉。