机构发布一项负责任的人工智能使用政策，然后假设行为会遵循该政策，这是不够的。开发者在交付压力下工作，并面对不明确的问题，因此当正式渠道显得缓慢或脱离工程工作的具体细节时，他们可能会转而使用未经批准的工具。因此，发表于Stack Overflow Blog的文章提出了一个核心观点：限制“隐形人工智能”应从设计工作流开始，而不是向学习门户再添加一份文件。
文章依据 Stack Overflow 关于人工智能采用和开发者信任度的调查结果：84%的受访者表示他们正在使用或计划使用人工智能工具，而不信任这些工具准确性的开发者人数多于信任者。看似基本正确、但随后需要额外修正的输出，是最主要的挫败来源之一。
未经授权的使用是工作流存在缺陷的信号
文章建议，管理层不应将每一次未经授权的使用都视为构成完整合规违规的行为。当工程师将敏感材料复制到公共模型中，或安装未经批准的编程助手时，这可能表明获批准的路径没有提供完成任务所需的数据、上下文、集成或权限。
实际应对措施应从提出诊断性问题开始：哪些任务促使开发者使用外部工具？什么阻力妨碍了采用获批准的替代方案？能否通过获批准的平台和记录使用情况的监控网关来提供试验空间，而不是试图通过全面封禁加以阻止？按照这一视角，非正式使用会成为帮助机构改进系统的证据，而不是自动迫使员工隐藏试验的理由。
将政策转化为工程界面
好的政策规定目标，但良好的运营会将其转化为开发者能够在日常工作中作出的决策。文章提到 NIST 人工智能风险管理框架的职能：治理、识别、测量和管理。实际上，规则应说明如何对使用场景进行分类，哪些模型和数据来源获准使用，如何测试结果，由哪个部门负责批准，以及哪些证据必须保存在开发记录中。
政策应直接回答的问题包括：每种工具可以输入哪些数据？工具可以访问哪些代码仓库或系统？对生成代码需要进行何种级别的审查？何时需要人类决策者介入？开发者如何报告有害、不安全或不可靠的输出？试验何时转变为生产系统？文章指出，安全和隐私是开发者拒绝相关技术的主要原因之一，因此，明确的规则能够减少不确定性，并在降低模糊性的同时支持采用。
将控制措施放在工作发生的地方
保存在培训门户中的政策很难与集成开发环境中内置的助手竞争。因此，文章建议将控制措施放入代码仓库、合并请求、构建流水线、访问系统和部署工作流中。例如，将获批准的模型配置保存在版本控制系统中，按角色限制访问，检查提示词和输出中的机密信息，在风险较高的使用场景中保留日志，并在合并生成的更改前强制执行测试。
“审查人工智能输出”也应转化为可重复的步骤，例如功能检查、上下文适用性验证、依赖项审查，以及必要时的集体审查。并非所有使用场景都适合同一套批准级别；用于解释代码的工具，其风险不同于拥有生产系统写入权限的代理。文章提到 OWASP 生成式人工智能应用清单中的风险，包括提示词注入、敏感信息泄露、供应链弱点、对输出处理不当以及权限过度。
问责、培训与衡量
每个使用场景都应指定明确的人类负责人，该负责人应理解所需结果，并拥有停止或调整流程的权限。按照文章提出的划分，产品负责人承担商业决策，工程负责人承担实施质量，安全和隐私专家确定适当的控制措施；开发者对其提交的代码负责，审查者负责批准决定，运营人员负责监控和事件响应。
文章还呼吁开展与开发者实际决策相关的培训，而不是进行一场泛泛的宣导会议。培训内容包括获批准的工具、允许使用的数据、故障模式、审查要求、升级路径以及来自机构环境的示例。培训还应产出能够在工作流中直接使用的要素，例如代码仓库说明、审查清单、测试套件、获批准的提示词模式和有记录的示例；证书能够证明参加过培训，但真正影响行为的是这些要素。
至于成功衡量，不应局限于许可证数量、提示词数量或活跃用户数量。文章建议比较引入工具前后的工作流，采用周期时间、流入生产环境的缺陷、回滚操作、安全检查结果、审查负担、文档质量、事件、开发者满意度以及用于修正输出的时间等指标。由于 DORA 2024 年结果将更高的采用率与文档和代码质量提升以及更快的审查速度联系起来，但同时也发现其可能对软件交付绩效产生负面影响，因此这一点尤其值得关注。Stack Overflow 的调查还指出，代理可能带来个人层面的收益，但未必带来相应的团队协作收益。
certi.news 的编辑解读
文章提出的实际变化不在于制定一项新政策，而在于将责任从文件层面转移到工具和流程层面。当安全路径能够提供获批准的工具、有用的上下文、明确的边界、快速的升级机制，以及与数据敏感度、自主程度和影响可逆性相匹配的控制措施时，它才会变得可用。
这不是要取消人类判断，而是试图让人类判断成为开发周期中清晰可见的一部分。建议的有效性仍取决于每个机构界定使用场景并衡量实际结果的能力；此外，文章中的数字汇总了多项研究和调查的结果，单凭这些数字无法证明每个开发环境都会取得相同结果。