涉密数据不出厂，第一件被锁死的不是模型选型，而是部署形态。制程参数、机台数据、良率记录一旦被判定不能离开厂区内网，公有云 API 这条路就整体关闭，提示词、输出和训练数据都必须留在企业自有或自管的基础设施内，推理服务、向量库、工具调用链路全部落在本地。这个约束会反向筛选场景，而不是简单地给 AI 能力打折扣。
受影响最直接的是依赖外部上下文的任务。Agent 只能在单点网络内看到有限信息，一旦任务本身需要跨厂区、跨企业调用供应链上下游数据，本地化部署反而会放大信息孤岛。这类场景并非不能做，而是应当等本地数据治理和接口标准化完成后再进入。同理，要求 Agent 直接下发控制指令、驱动执行机构的场景，在试点阶段通常也应推迟——不是技术不可行，而是失败成本过高，需要更长的验证周期。
真正适合先做的，是数据敏感但流程边界清晰、结果可人工复核的任务：设备点检记录的语义检索与异常归集、工艺文档的问答式查询、质检报告的结构化摘要、排产约束条件的辅助核对。它们的共同点是输入确实涉密，但输出不直接触发生产动作，人可以做最后一道确认。
场景被筛过之后，算力结构的问题才会浮现。把本地 Agent 等同于“跑一个大模型”是常见误判。Agent 运行时是持续运行的，要接收消息、调用工具、读取文件、维护状态，算力因此被拆成三层：模型推理层以 GPU 显存和算力为主，是成本大头；编排与调度层负责任务分解、状态管理和路由，现代多核 CPU 通常可以胜任；工具与数据层负责预处理、文件读写和向量检索，瓶颈更多落在内存与高速存储上。对以 RAG 检索加多工具调用为主、而非长上下文推理的任务，先测清任务画像往往比盲目堆显卡更省钱。
部署形态上，中心与边缘是分层而非二选一。厂区机房或私有云部署较大参数量模型，承担知识库问答与复杂分析，同时作为模型仓库和统一管理节点；靠近产线的边缘侧部署量化后的小模型，承担低延迟、数据就地处理的判断类任务。量化与剪枝在私有部署下比在云端更关键，因为本地扩容不像云上那样随时可加。分层还带来一个现实好处：负载峰值时可以把非敏感、非实时的溢出任务放到公有云，涉密数据始终留在本地，容量规划不必按峰值设计。
立项前的筛选可以归结为几个问题：数据源是否已明确、可枚举、有稳定接口；输出是否允许人工复核后再进入流程；任务频次是否高到能摊平本地算力的固定投入；出错代价是人工返工还是产线停线；算力是否留有增量扩展余地。若内网与机房环境不稳定、核心数据尚未完成目录化与权限梳理、缺少能维护推理服务和边缘节点的技术人员，或只有 IT 部门在推动而业务侧没有流程负责人，更稳妥的选择是延后。这些是顺序问题，不是永久门槛。