还常常忽略了对数据质量和模型完成的监测和恢复，而模型本可探测并防止此类事件的发生，而对其负面影响则往往要等到重大事故或入侵事件发生，但由于上游数据丢失或延迟，公共计算平台的排队时间太长，白名单模型错误，模型代码OOM等原因，导致最终结果无效。一些安全团队和企业不把监测和修复视为核心任务，并且常常没有对资源和优先选择事宜做好充足的资金投入，这正好是“千里之堤溃于蚁穴”的典型例子。

理想化地说，在理想情况下，数据科学团队能够无限制地存取所需要的数据，而在监管环境和企业利益的博弈中，数据所有者与团队之间的不可能完全融合，这种数据壁垒也是工程脆弱性的重要原因。

大多数安全运营团队缺乏相应的机制来处理模型预测结果，这无形中推高了每个案例的操作成本，这是运营脆弱的主要原因，网络安全领域知识的门槛也让数据科学团队很难协助。这主要包括两个方面，一是算法模型支持业务需要的信息，二是运营是否了解模型预测的结果。

资料学家们常常认为模型的任务局限于提供预测结果，如果是正确的，错的话，很大程度上降低了损失的回收率转换精度。但是正确的结果也需要操作，就好像模型检测到某段包含恐怖内容一样，而运营团队需要一帧一帧来寻找这个多小时的视频，就如同模型检测出新的APTC&C一样，就像模型检测出新的APTC&C一样，让运营团队需要一帧一帧去寻找这个多小时的视频。就像坊间谣传说亚马逊负责包裹分发算法的团队要跟一辆快递车送上一个月的快件，而对运营团队的工作置身事外的数据科学团队做不出有效的数据模型。相关的操作团队机制，工具框架和培训都与数据科学时代是同步的。大多数操作团队并没有分级，而是完全使用人力处理检测结果，这导致了无论一个案例的复杂性如何被随机地分配到团队中，安全研究员的经验水平不同。与此同时，事件调查和后续操作所需的上下文信息也分散到了数据系统的各个角落，需要使用多种工具做好随需查询。安全性研究者理解和使用算法的预测结果也会受到一些阻碍，包括结果的归因分析、预测结果应用于诸如防火墙等产品，以及合理处理不确定因素带来的影响等。由这些障碍所引起的运营焦虑进一步妨碍了安全研究者对数据模型的使用，而数据科学与安全运营团队之间的对话往往以“你明确告诉我是否可以阻止它”结束。