端到端指南
如何在受监管企业中构建软件
帮助人们用 AI 制作原型。授予真实数据或 API 访问前验证安全，再按企业要求交付和运行软件。
简要回答
为人们提供时间、工具选择、合成数据，以及从有用原型到持续维护服务的路径。授予真实 API 访问或机密信息前，验证应用、平台和数据流。通过内部平台或软件工厂，连接安全交付、合规证据和运维。在整个生命周期中，始终明确负责人应承担的责任。
帮助更多人将想法变成软件
CTO 可以邀请组织各处的人员用 AI 构建原型。财务团队了解审批问题，运营团队了解重复的人工任务。给他们时间和工具，展示更好的工作流。
允许使用不同工具探索，同时明确安装、账户和允许输入的规则。提供合成数据集、沙箱 API 和实际帮助。人们应有清晰路径，在不连接生产系统的情况下展示价值。
随后定义下一项决定：应用接收机密信息、真实 API 权限或生产流量前，必须验证什么？让原型创建者能够理解这条路径。
原型需要真实访问时，会发生什么变化？
正常工作的功能只是服务的一部分。组织还必须说明谁能使用、如何处理数据，以及如何恢复。发布后，这些职责仍然存在。
适用要求取决于服务、行业、司法管辖区、合同和数据。请负责法律、隐私和安全的专业人员识别这些要求。开发框架或供应商证书，不能证明具体服务合规。
以下步骤提供工程工作流，用于连接要求、决定和证据。NIST SSDF 提供安全开发实践，可以支持现有 SDLC，但不能替代识别适用义务的工作。
1. 将有用原型转化为服务说明
请创建者描述问题、演示工作流，并记录用户学到了什么。让创建者继续以领域专家身份参与。将技术评估和持续运维交给承担相应职责的团队。
写出用户任务、预期结果和失败后果。指定产品负责人、服务负责人、安全联系人，以及有权接受剩余风险的人。约定谁可以停止发布。
例如，导出客户数据不仅需要下载按钮。应定义谁可以导出哪些记录、出于什么目的，以及保留多久。确定谁调查未授权导出。这是虚构示例。
应保留的证据： 服务说明、职责图和已批准的验收标准。
2. 授予数据或 API 访问前，验证边界
识别机密信息、个人数据、凭据和其他受限材料。画出提示词、检索上下文、日志和生成输出的去向。检查所选服务关于保留、训练、访问和区域处理的条款。
探索想法时，使用合成数据或获准测试数据。成功原型不能证明其提供方可以处理生产数据。检查每个提供方及部署配置。
周二构建的虚构银行仪表板，可能在虚构交易上运行良好。账户只读访问仍可能暴露机密记录，支付权限还可能带来财务后果。启用连接前，验证实际范围、凭据处理、授权和故障行为。学习银行应用原型示例。
这项审查必须在首次敏感输入或真实连接前完成。把应用称为原型，不会减少它已经拥有的权限。
只给智能体任务所需的工具和权限。将代码仓库文件与检索文档视为不可信输入。不要将秘密信息放入提示词。
应保留的证据： 数据流图、提供方评估和权限策略。
3. 提供受支持的生产交付路径
让服务纳入组织的身份、网络、日志和部署控制。定义受支持环境，以及以代码管理的基础设施。容器和数据库不足以构成完整运行环境。
如果策略要求使用自己的基础设施，验证部署确实进入组织的云账户或网络。将运行时控制与开发、模型数据流分开检查。托管在自己的账户中，不能证明合规，也不能保证每个 AI 请求都留在该账户内。
受支持路径可以使用内部平台、软件工厂，或两者结合。定义各方为验证、部署、漏洞修复和运维提供什么。原型可能需要修改或替换部分代码，才能使用这条路径。
约定可接受的中断时长和数据丢失：RTO 与 RPO。根据目标选择可用性和恢复机制。Multi-AZ、多区域和备份解决不同故障场景。测试完整恢复流程，包括依赖和恢复后的数据。
应保留的证据： 架构决策记录、环境定义和实测恢复结果。
4. 用可验证要求构建小变更
向开发者或智能体提供明确任务与验收标准。将要求关联到实现、测试和审查。保持变更足够小，便于检查。
测试前定义安全要求。OWASP ASVS 提供应用安全验证要求。选择相关要求并记录范围。仅有扫描器结果，不能验证应用行为。
除了成功操作，也要测试被拒绝的操作。在导出示例中，验证未授权用户无法请求另一个客户的记录。
应保留的证据： 要求、变更 diff、测试结果和审查决定。
继续学习将测试用作证据和审查 AI 生成代码。
5. 让发布决定可重现
从已审查版本构建可识别制品。记录目标环境、配置、必需检查、剩余风险和发布决定。在需要回滚或恢复前，先测试相应方法。
决定何时需要人工授权。保留例外的负责人、原因、范围和到期日期。不要把获批例外当作策略的永久修改。
应保留的证据： 制品标识、发布记录、批准或策略决定，以及回滚说明。
6. 部署后持续维护软件
针对新披露漏洞，扫描依赖和已部署组件。即使没有新代码提交，服务也可能出现已知漏洞。为每项发现指定负责人，并作出修复决定。
验证修复、部署修复，并确认运行中的版本。记录接受的风险，在条件变化时重新审查。这项持续工作，是将原型当作成品时经常缺失的部分。
应保留的证据： 组件清单、扫描日期、分诊决定、修复变更和部署验证。
遵循持续漏洞管理工作流。
7. 运行、响应和改进
监控有用服务结果、故障和安全信号。约定事件角色、升级路径，以及 SOC 和 SIRT 的职责，并演练这些安排。
NIST 网络安全框架 将风险管理与治理、保护、检测、响应和恢复联系起来。定义运行模式时，采用这种生命周期视角。
将事件和重复问题转化为经过审查的变更。将自愈限制在获授权操作内，并设置验证和停止条件。自动重启不能证明原始缺陷已经修复。
应保留的证据： 服务指标、事件记录、恢复结果和已验证的改进变更。
8. 决定哪些职责自建，哪些采购
根据相同要求比较内部平台、编程助手和 AI 软件工厂。询问谁执行每项任务、有什么证据，以及哪些职责仍由你承担。计入维护、恢复、集成和退出成本。
人们可以继续使用偏好的探索工具，同时组织维护共同的生产路径。检查代码、规格说明和测试中的哪些内容能在工具间迁移。要求演示向所需基础设施部署，以及完整维护流程。
Taiga 发布了治理信息和共同责任说明。将它们作为一家供应商的材料，根据你的要求评估。Taiga 是本学习站点的发布者；这些链接不是独立推荐。
先进行职责比较。随后，Taiga 学习路径展示这些问题如何对应具体产品工作流。
常见问题
受监管企业可以使用 vibe coding 吗？
可以。提供合成数据、沙箱 API，以及明确组织边界内的工具选择。让人们测试想法，并将有用原型带入受支持交付路径。授予机密数据或真实权限前，必须验证控制措施，即使尚未正式投产也一样。参见 vibe coding：用途与限制。
AI 生成代码需要不同验收标准吗？
必要行为与风险控制仍然适用。AI 带来关于上下文、数据处理、权限和输出可靠性的额外问题。无论由谁或什么系统生成，都应审查实际变更及其证据。
首先应该准备什么？
准备使用合成数据的探索环境，并指定下一步的联系人。对于有用原型，记录目的、预期数据、负责人、要求和恢复目标。用软件生命周期练习识别缺失决定，再扩大访问。