随着生成式人工智能（AI）的兴起，我们与金融客户探讨了将其融入受监管软件领域的可能性。受监管环境下的约束，如安全性、质量和网络限制，以及 DevOps 和平台工程师的需求，促使我们定义了受监管软件领域中采用生成式 AI 的真实场景需求和解决方案。
不久以前...
我们与一位金融客户合作已有一段时间了，在闲暇之余，我们开始讨论生成式人工智能。因此，我们沉浸在兴奋之中，就像置身于一个积极的回溯系统中一样，开始勾勒出如何将其整合并应用于我们所处的现实场景中的想法。
将DevOps工程师的 LLM/AI 技能和知识与平台工程师的愿景相结合，我们开始定义受监管软件领域的真实场景的需求、约束和负载，然后定义可能的流程和解决方案。
但在哪种情况下呢？
在受监管的软件领域，尤其是在我们工作的银行环境中，存在安全性、质量和网络限制等制约因素。除此之外，还有数量可能非常多的 CI/CD 负载、已经超负荷的开发人员和成本管理。以下是初始要求的列表：
- 本地系统或托管虚拟机或私有云，可能存在隔离
- CI 和 CD 管道的性能没有下降
- 获得开发人员批准的零信任模型
- 选择受影响的组件
- 生成对象的限制
最后两点并非是强有力的约束，而是为了更好地解决问题而采取的常识性做法。
详细来说...
在受监管的软件领域以及网络可达性限制（处理可能的商业机密）方面，您不希望您的数据和代码在未受保护或未经验证的系统上被发送到外部。因此，系统应托管在隔离良好的网络中的私人机器上。生成式 AI 流程对资源消耗有很大影响，并且可能需要很长的处理时间。因此，为了限制时间和性能影响，它们不能被引入 CI/CD 周期：我们假设一个异步且独立的“连续生成循环”。
作为一个需要认证和验证的系统，并且必须尝试限制不当引入，因此必须采用零信任模型，其中“连续生成循环”会提出拉取请求（以下也称为 PR），经理必须验证和批准这些请求。基于这些假设，记住平台工程背后的原则之一是“从开发开始”，并且想要限制处理成本和时间，因此不可能在所有应用程序中生成数千行代码。生成部分应该：
仅选择并优先处理那些需要采取行动的应用程序
例如，如果有 3 个申请
- 覆盖率约为 85% 且存在一些代码异味，
- 覆盖率约为 80%，存在许多代码异味和一些小错误
- 覆盖率达 60%，且存在严重漏洞
系统应该优先考虑最后一个应用程序，并对其进行处理，以平衡应用程序池的总体水平。
限制生成的对象
如果我们要求经理或开发人员验证拉取请求，以防它包含大量可交付成果，那么最糟糕的情况是 PR 要么被完全拒绝，要么被草草地检查，并且有引入错误的风险。
为了确保生成活动与开发人员的日常工作协同，必须通过选择和确定活动的优先级来采取行动，寻找少数（希望如此！）影响最大的错误/漏洞，或通过测试覆盖影响最大、未覆盖的类别。
选择和优先排序方法可以实现更快的处理、更低的成本，并且只对真正需要外部帮助的应用程序采取行动，但最重要的是不会影响开发人员的工作。
接下来是什么？
接下来的步骤是：
- 定义应用程序优先级和选择算法
- 定义质量/漏洞解决方案和代码覆盖率的选择和优先级算法
- 根据创新管理和平台工程的原则，确定早期采用者和先驱者，在熟练的开发人员的帮助下，以可用的方式在现实环境中实施解决方案，以便为最终用户进行最佳开发
综上所述
可以在受监管的环境中将生成性 AI 引入IDP，同时尊重环境的所有约束和要求，同时不忽视最终用户及其对系统的用户体验。
