更新：根据评论，这个答案并没有完全解释这种行为。

我不是专家，但我最近遇到了类似的事情。

首先，请注意“暂停”BitLocker 和“关闭”BitLocker 之间存在差异：

从您的屏幕截图中可以看出，您的 BitLocker 已暂停，而不是关闭。

根据微软：

Suspend-BitLocker cmdlet 暂停 Bitlocker 加密，允许用户访问使用 BitLocker 驱动器加密的卷上的加密数据。此 cmdlet 以明文形式提供加密密钥。

...

挂起时，BitLocker 不会在启动时验证系统完整性。您可能会暂停 BitLocker 保护以进行固件升级或系统更新。

Windows Update 有一个机制，它现在安装一些更新，其余的在下次重新启动时安装。我假设这是通过启动一些仅用于安装新文件的轻量级操作系统来完成的，然后在完成后调用 Windows 引导加载程序。看起来微软已经决定他们不想将所有 TPM 驱动程序捆绑到这个轻量级安装程序中，所以他们暂时禁用了 BitLocker。

暂停的 BitLocker 应在下次重新启动时恢复完全保护，因此答案似乎是当 Windows 更新要求您重新启动时，您应该立即执行。我知道这很烦人，但不幸的是，这就是 Windows 的工作方式。

对于它的价值，防止在 Windows 中覆盖组策略规则的“标准”方法是转到关联的注册表项，编辑它的权限，然后删除/拒绝 SYSTEM 用户（或所有用户）的写入访问权限。这对用于将配置更改推送到加入域的计算机的组策略引擎有效。我以前从未听说过 Windows 更新更改组策略规则，所以我不确定它是否会在那里工作，但如果有任何事情会阻止系统（或所有用户）写入可能仍然会这样做（另一方面手，不能保证 Windows 更新引擎会尊重 ACL；管理员级别的进程可以随意忽略它们，如果他们愿意的话）。

相关的注册表项似乎是

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE (and subkeys)

也许还有

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\Bitlocker (subkeys specifically)

第二个位置中的值引用第一个，所以第一个可能是权威位置，但据我所知，它并没有真正记录在案。无论如何，拒绝 SYSTEM 对两个键及其子键的写访问是我能想到的防止这种情况再次发生的最佳方法（但不能保证）。如果您想更加确定，您可以尝试拒绝所有用户的写入（例如，某些更新内容作为特殊的 TrustedInstaller 帐户运行）。