现场的AI和公司文书的AI在哪里分开。Cor.株式会社的设计判断

你好，我是Cor.株式会社的寺田。

现场的AI和公司文书的AI，要在哪里分开。谈本地AI时，这两者有时被说成一件事。

一个是在相机和传感器附近运行的AI。另一个是处理公司文书和业务数据的本地LLM。

两者都可以选择抑制向外部云发送的构成。仅凭这一点，并不等于可以放进同一个环境。Cor.株式会社分别看各自连着什么、处理什么、出了问题影响到哪里。

重视的条件

现场的AI看的是从收到输入到返回判断的时间，以及通信中断时的动作。带动机械的用途里，异常时能转到安全侧也不可少。不是只有「不能停」才是正确答案。

现场一起看的是不停（可用性）、不迟到（实时性）、危险时能安全停下。

处理公司文书的AI，谁可以参照哪份文书是大问题。负责人换了，权限能不能卸下。卸下的权限会不会反映到检索和回答。必要的操作能不能事后确认。

现场的AI也需要权限管理。公司内的LLM也需要响应时间和稳定运行。设计上特别留意的地方不同。

信任边界

在同一个集群上，并不能由此得出危险与否的结论。设备分开，也不是安全的证明。

即使在同一套基础上，也可以用网络分离、认证与授权、工作负载隔离来设计边界。NIST的零信任是不单凭物理位置或网络上的位置来信任的想法。

如果把现场设备无条件加入单一集群，边界就会模糊。共同的访问权、认证信息和管理路径在没有确认理由的情况下共享，影响范围就会变大。放在现场的设备也许会到达靠近公司文书的地方。

在构成图上只是细细的一条线。在运用上是很大的差别。

数字怎么合计

把台数和速度的数字加在一起，资料会好看。Cor.株式会社不把用于其他用途的设备加进一个系统的台数。条件不同的测定值也不合成一个。要能看出数字量的是什么。这是自己的合计规则。别人的意图不写在这里。

边界一模糊，下面这些就说明不了。这台边缘机停下时，公司内LLM的哪项使用会受影响。这台设备的账号停了，会停到哪里。

现在的方针

Cor.株式会社现在选择的是下面的分法。这是方针，不是说分开了就安全。

• 物理推理的边缘按边缘专用来设计
• 不放到公司内本地LLM的主线集群上
• 对外说明时，也不把边缘机混进主线的构成或性能
• 两者之间传递数据时，传递的内容和路径逐项决定

有人希望把边缘得出的结果用到业务侧。那时也不采用「因为在同一个集群里就可以自由读」。

说明用的例子

设想要把现场的检查结果用到公司业务里。这是为了说明的构成例。不是Cor.株式会社已经实现的功能，也不是客户事例。

如果只靠检查ID、时刻和判定结果业务就能进行，也许不必交出全部影像，也不必把现场终端的自由连接交出去。如果用途需要图像，就先确认必要性和处理范围。

不说「因为在同一家公司就可以读」。说「因为这个用途需要，所以只交这个内容」。停止使用之后连接是否被拒绝，一侧停止对另一侧有什么影响，是按每个构成来确认的项目。本文并没有写这项确认已经结束。

模拟里看到的

Cor.株式会社以劈西瓜这类使用身体的任务为题，做物理推理的验证。目前是模拟中的验证。这个验证环境也按方针与处理公司文书的环境分开。

即使是实验，信息的处理也不含糊。模拟里确认到的，不当作实机安全性或性能的证明。实机的安全性和性能需要另外确认。这里尚未确认。

性能和运用

速度很重要。如果不能在需要的时间内返回答案，业务就用不了。推理性能是Cor.株式会社在研究开发上用力的地方。速度会因环境和用途而大大不同。

只靠速度，决定不了能不能用于业务。即使答得快，如果出现不该看的文书、停不了使用、故障时的应对没有定，也会为难。

目标是满足性能要件，并且一起确认能够安全运用的构成。这不是在任何环境都能安全运用的保证。

能够说明谁、到哪里、可以用到什么时候。把边界、权限、失效和安全性一起设计。

放到本地并不会自动变安全。从现有设备出发，考虑本地处理的范围和适合业务的构成。

责任的范围

云也是共同责任模型。访问权限和数据管理本来就留在使用者一侧。分担的内容因服务形态而不同。这里引用的是AWS公开说明的一个例子。

改成本地之后，还要加上基础的物理管理和运用。自己要画的线会因此变多。把那些线一条一条说明清楚，是Cor.株式会社看重的地方。

审查的状态

Cor.株式会社在运用ISMS。2026年10月完成了ISO/IEC 27001第二阶段审查。认证注册预计在2026年12月前后。审查的状态和各个系统验证了什么，分开说明。

连接的范围

把现场的AI和公司文书的AI分开，不是为了放弃连接。是为了只把需要的地方，以有理由的形式连上。

谁、什么、可以用到什么时候。连接停了会怎样。出了问题影响到哪里。方针是把这个说明从构成图接到设置和确认结果。还没有确认结果的项目，不写成已经有了。

如果想用AI处理公司文书和现场数据，但连接范围还没定，请从业务对象和现在构成的概要来咨询。第一次咨询不必发送机密文书或认证信息。

参考资料

• NIST SP 800-207: Zero Trust Architecture - 不把网络上的位置当作默示信任的想法（2026年10月29日确认了概要）
• AWS: Shared Responsibility Model - 云的责任分担的一个例子。分担因服务形态而不同（2026年10月29日确认）
• Cor.株式会社: 安全 - 在运用ISMS，2026年10月完成ISO/IEC 27001第二阶段审查，认证注册预计在2026年12月前后