安全与合规

理解 iKho Embedded 的安全设计:全链路境内处理、端上加密与绑定模型、四类凭证的职责边界、数据保留与删除,以及接入方需要自行承担的用户隐私义务。

把用户的真实对话交给一套基础设施处理,信任是前提。这一页把 iKho Embedded 在安全上做了什么、没做什么、哪些责任在 iKho、哪些责任在接入方,一次说清楚。

先给出三句概括:

• 数据处理全链路走境内节点,音频与文本不出境。
• 录音先加密落在设备本地;一台 S1 只绑定一个合作方应用,设备丢失或被盗,他人无法直接读取其中数据。
• iKho 提供技术能力与安全基线,但不替代接入方自身的合规义务,尤其是录音告知与用户授权。

数据主权与境内处理

这是 iKho Embedded 与多数同类服务最直接的差异:从设备采集到转写出稿,数据处理的每一个环节都在中国大陆境内完成。音频文件与转写文本不经过任何境外节点,不落在任何境外存储。

「境内处理」是逐环节成立的承诺。把一段录音从设备变成逐字稿,数据会经过下面这些环节:

换句话说,链路上只有两段:一段是设备与手机之间的本地链路,数据根本不上公网;一段是应用与 iKho 云服务之间的境内链路,数据不出境。不存在第三段。

为什么这件事重要

Embedded 的典型接入方,处理的往往不是普通数据:

• 医疗随访平台:医患对话涉及健康信息,对数据出境的监管要求明确而严格。
• 政企与大型机构服务商:会议与访谈内容常被客户的采购与安全评审直接问到「数据在哪里处理」。
• 销售与客服辅导产品:客户对话可能包含个人信息与商业信息,数据边界是签约前的常见尽调项。

对这些场景,「数据在境内」不是加分项,而是入场券。用 iKho Embedded,你在回答客户与监管的这个问题时,答案是确定的。

边界与诚实说明

为避免误读,把边界也写清楚:

• 境内处理承诺覆盖的是 iKho 侧的链路:设备、同步、上传、转写、存储、回传。音频同步到你的应用之后,你自己的后端把数据存到哪里、传给谁,由你的架构决定,不在这一承诺范围内。
• 内测期服务区域只有中国大陆;海外区域处于规划中。海外区域上线后的数据边界与区域隔离方式,以届时发布的文档为准,不会以默认方式改变大陆区域「不出境」的口径。
• 用户没有选择同步的录音,始终留在设备本地,不会进入云端链路。

端上加密与绑定模型

iKho 的安全设计从设备端开始,而不是从云端开始。录音在写入设备存储时即完成加密,明文音频不落盘。设备的加密存储与录制过程都不依赖网络,离线环境下同样成立。

一台 S1 只绑定一个合作方应用

绑定是 Embedded 安全模型的核心概念:把用户的设备与你的应用建立关联。之所以叫「绑定」而不是「连接」,是因为一台 S1 同一时间只能绑定到一个合作方应用。绑定完成后:

• 该设备上的数据只与你的应用同步,不会流向其他 Embedded 应用,也不会流向 iKho 自己的用户端产品。
• 加密、解密与同步握手使用你的合作方凭证与该用户的用户令牌完成,数据的解读能力被限定在「这个用户 + 你的应用」这一组合内。
• 不存在「一台设备同时给两个应用供数」的旁路,数据归属在设备层面就是清晰的。

绑定与加密如何参与完整数据流,见工作原理。

设备丢失或被盗时

端上加密与绑定模型合在一起,回答了硬件设备最常被问到的问题:设备丢了怎么办。

• 设备本地存储的是加密数据,拿到设备本身,无法直接读出录音内容。
• 解密依赖绑定关系中的凭证链条,脱离绑定的应用与用户令牌,数据无法被还原。
• 捡到或偷到设备的人,既不能读取既有录音,也不能把设备静默接入另一个应用继续获取数据——重新绑定不会继承旧数据的访问能力。

解绑与换绑

用户更换手机、更换应用或设备转手时,涉及解绑与重新绑定。解绑后原绑定关系的凭证即失效,后续对该设备数据的同步与解密不再可行。解绑、换绑的具体操作路径与既有数据的处置口径,内测期以联调时的说明为准。

传输与存储加密

在端上加密之外,数据在传输与静态存储两个层面都有加密保护。本节只做定性说明,不在公开文档罗列算法与密钥细节。

传输加密

• 设备与移动应用之间:BLE 与 Wi-Fi 快传通道上的音频同步,基于绑定关系建立的加密会话完成,不是明文搬运。
• 应用与云服务之间:移动应用、你的后端服务与 platform.ikho.cn 之间的全部 API 调用与文件上传走加密传输,不提供明文通道。

静态加密

• 设备侧:录音写入设备存储时即加密,见上一节。
• 云侧:上传后的音频文件与转写产生的文本在境内节点加密存储。

凭证与权限模型

Embedded 接入会用到四类凭证。它们职责不同、生命周期不同、允许存在的位置也不同。把每一类凭证放在正确的位置,是接入方安全责任里最重要的一条。

模型背后的原则

• 应用级与用户级分离:client_secret、合作方令牌、API Key 是应用级凭证,代表「你的应用」;用户令牌是用户级凭证,只代表「你的某一个用户」。端侧只应持有用户级凭证,应用级凭证一旦进入端侧,等于把整个应用的权限交给了任意一台被逆向的手机。
• 长期机密换短期令牌:长期有效的机密(client_secret、API Key)只住在后端;真正在链路上流动的是短时效令牌,泄露的影响窗口有限。
• 最小作用域:用户令牌只能操作该用户的设备与数据,拿到一个用户令牌不构成对其他用户数据的访问能力。

凭证保管清单

接入联调前,建议对照检查:

• client_secret 与 API Key 存放在后端密钥管理设施中,不出现在任何客户端产物、仓库历史与日志里。
• 移动应用安装包内没有任何应用级凭证,反编译得不到。
• 用户令牌由后端按用户签发,时效设置为业务需要的最短值,不做「一个令牌全体用户共用」。
• 令牌续期与重签逻辑在后端闭环,端侧令牌过期后向你的后端要新令牌,而不是端侧自己持有续期凭证。
• 制定了凭证泄露预案:一旦怀疑泄露,立即通过对接工程师重置 client_secret 或 API Key,并重签受影响的令牌。

接入方的用户隐私义务

责任边界具体来说:

• iKho 负责:设备与云服务本身的安全设计,本页与安全白皮书所述的加密、绑定、境内处理与访问控制。
• 接入方负责:面向终端用户与对话参与者的告知、授权与同意管理;你的隐私政策对数据采集与使用的披露;你自己系统内数据的存储、使用与保护;你所在行业的额外监管要求。

建议实践

以下是面向对话采集类产品的通用建议,不构成法律意见:

• 在产品交互中明示录音状态,让用户清楚设备何时在录制,并利用好设备本身的物理指示。
• 在用户首次启用录音功能前,完成明确的授权流程,而不是把授权埋在冗长条款里。
• 区分场景:员工工作场景与面向消费者的场景,告知对象与同意方式往往不同;涉及对话另一方(客户、患者、访客)时,考虑对方的知情与同意如何达成。
• 在隐私政策中如实披露:采集什么、传到哪里、用于什么、保留多久、如何删除。
• 只采集业务必需的数据,不因为「设备能录」就默认多录。
• 如你的行业有专门监管(医疗、金融、教育等),在产品设计阶段即引入合规评估,而不是上线后补。

数据保留与删除

用户对自己的对话数据享有删除权,这一点在 Embedded 的三层数据结构中分别成立:

设计你的产品时,建议把「用户发起删除」作为一条完整链路来实现:用户在你的产品里删除一条记录时,你的系统应同步处理自己存储的副本,并向 iKho 侧发起对应的删除请求,而不是只删列表项。

合规资质

关于安全认证与合规评估,iKho 的口径是:相关认证与评估以正式开放时公布为准。内测阶段,我们不在公开文档中宣称任何未完成的认证、测评或备案,这与本页其余部分「只写做到的事」是同一条原则。

如果你的采购或安全评审流程需要:

• 安全白皮书与联调期安全说明,可在接入流程中向对接工程师获取。
• 安全问卷、尽调材料与数据处理条款,可在商务合同阶段提出,由对接团队按当时可提供的口径回应。
• 数据使用边界(包括是否用于服务改进等)在商务合同中明确约定,以合同条款为准。

常见问题