企业人工智能噩梦悄然上演企业人工智能的噩梦并非是杀人机器人而是对自身环境中运行内容的洞察和掌控能力逐渐丧失。如今关于企业人工智能即将融入生产系统的讨论不断这一现实或许早已悄然上演。一切常始于一个“试点项目”“原型”或者“副业项目”有人借助智能代理搭建内部仪表盘很快试验项目变成正式生产应用。在此过程中没人问诸如从 npm、PyPI 或 Docker Hub 上拉取了哪些内容、认证如何配置、是否关注针对智能代理所选工具和库的供应链攻击等问题。而且人工智能让企业能更快生成更多代码、推出更多产品和项目等到安全团队介入时业务已依赖这些无法回头噩梦开始。有哪三大问题让噩梦成现实未明确选择的组件人工智能代理构建应用隐患大当让人工智能代理构建应用时它会围绕问题构建一整个生态系统引入 Web 框架、抓取库、搭建数据库等。从提高生产力角度看很棒但从安全角度令人担忧。自己用这种方式构建应用若不回头让代理解释很难说清用了哪些组件。在 npm 或 PyPI 上任何人都能发布内容攻击者会将恶意软件包混入或破坏广泛使用的软件包。近期一些事件中安全和运维工具拉取受感染依赖项在 CI/CD 流程中运行窃取机密信息或篡改构建过程。几个月前就有人亲身经历攻击需更新 GitHub 上的所有凭证。人工智能代理默认选择最易发现和集成的内容像“从互联网上随意下载一个库”问题现在是自动大规模且高速进行。要解决此问题需让代理具备对风险承受能力的内在认知给其批准的组件列表、日志记录要求等通过规范文件和“章程”实现即“约束工程”。技能从编码向架构转移开发者能力面临新挑战很多人担心人工智能包办初级开发者编码工作他们能否学会编码但有人认为让代理输出代码没问题关键是代理不擅长识别和避免代码中的问题。例如在一个项目中代理提议在无认证情况下将内存服务器暴露在公共互联网上乍看正常能运行但思考后发现无认证和密码。所以问题不在于是否失去编码能力而在于能否提出问题、做出判断在事情不对劲时察觉。企业需要有人能识别危险软件模式、宽松认证流程、数据存储边界、架构技术债务等问题明白“能用”不等同于“安全”或“正确”能与代理据理力争。要教导使用人工智能辅助编码的人员基本安全原则和架构模式他们不断提问人工智能会教会更高级知识。缺乏约束的代理企业治理模式缺失企业在开发工作流程中引入强大代理却未将其视为需治理的一等角色。许多企业将人工智能助手接入代码仓库或 IDE搭建项目和流水线安装安全扫描器就宣称“实现了人工智能赋能”这并非治理模式。一个能广泛访问代码仓库、CI/CD 流水线和工件注册表的代码生成代理像效率高但未经良好训练的初级开发者对组织政策无概念引入新工具、依赖项和模式的速度超审查流程承受范围。有人在个人项目中将此视为“约束工程”问题尝试引入其他代理制衡如专注安全、架构、性能和可靠性的代理结合为代理提供基本原则的章程进行大规模约束工程。但很多企业未采取这些措施代理像自由职业者凭感觉编码不受限于可信注册表或加固基础镜像无需安全可审计记录决策实现决策从人类转移到无人监管系统。新问题如何解决企业人工智能的噩梦是开发速度增长时对运行内容洞察和掌控能力丧失危险在于放弃控制权推出不安全应用。此刻企业中可能有人用人工智能构建应用拉取不明内容添加到基础设施。好消息是这些问题可识别和解决但需不同思维方式。要从统计角度思考制定包含基本原则的章程标准化可信技术栈和注册表围绕架构安全对人员再培训将代理约束视为值得设计审查和修改的系统。但在企业承认噩梦降临前这一切无法实现。