您的多云AI策略没有弹性，这是一个“弗兰肯堆”等待崩溃：Srinivasa Atta

多年来，多云的福音一直在每个CTO的讲坛上宣讲。承诺很明确：避免销售商锁定，优化成本并建立真正的运营弹性。现在，当我们急于在这些复杂庄园中部署生成AI时，我们发现了这种策略中的致命缺陷。我们还没有建立一个弹性，相互联系的系统。我们建立了一个怪物 – 缝合的安全工具的“ Franken-stack”，以及脱节的治理政策，这是朝着合规灾难造成的。

问题的核心是，我们的安全和治理方法在每个云环境中仍然保持孤立。我们使用Defender for Cloud，GuardDuty和GCP以及其安全命令中心管理Azure。然后，我们尝试使用一个位置的SageMaker模型卡来控制我们的AI模型，而Azure Machine Learning的模型注册表则在另一个地方进行管理。结果是我们风险姿势的混乱，分散的视野。

这不仅效率低下；对于金融机构来说，这是危险的。当您的AI模型在三种不同的治理工具上分开时，您如何证明您的AI模型没有偏见？当云之间移动时，如何将一致的安全策略应用于容器化的应用程序，每个应用程序都具有自己独特的安全配置和词汇？诚实的答案是，您不能 – 不信心。我们寻求的“弹性”创造了一场安全噩梦，在该噩梦中，攻击面不仅仅是更大，它在我们云基础架构的接缝处充满了盲点。

是时候停止使用更多的胶带了。该解决方案不是另一个仪表板，该仪表板汇总了我们不同系统的警报。解决方案是思维的战略转变。我们必须朝着一个
统一控制平面– 一个坐着的单一的抽象图层 多于 单个云。

这不仅仅是一个新工具；这是一个新的建筑范式。统一的控制平面将外部化并集中最关键的功能：

• 安全策略作为代码： 定义一组通用的安全规则，这些规则在AWS，Azure和GCP上始终执行，无论其本机工具如何。

• AI治理和血统： 为每个AI模型创建一个真实的来源。从数据摄入和培训到部署和实时监控，整个生命周期都可以整体跟踪，从而使监管审核变得微不足道。

• 身份与访问管理： 从一个中心点管理访问和权限，以确保开发人员的权限是相同且适当的，无论他们访问哪个云环境。

构建这个统一的层并不是一件小事，但是替代方案要差得多。继续缝制本机工具的当前路径是资源的无穷无尽的水槽，只会产生更复杂和脆弱性。我们正在建造纸牌屋。

与AI在整个云中进行创新的竞赛不仅仅是速度。这是关于控制的。金融机构必须停止投资修补他们的弗兰肯 – 堆栈，并开始建立真正的统一控制。因为当监管机构敲门时，带有一个连贯的治理故事的机构将是一个左翼。