再保险的巨灾模型每个季度都要跑一次：百慕大的算力该按峰值还是常态准备

负载形状是季度脉冲：最吃算力的活儿不在 7×24 的在线服务上

在百慕大，最消耗算力的那批机器不服务于 7×24 的在线交易或门户。真正把 CPU 打满的，是一批每个季度集中跑一次的巨灾模型。百慕大金融管理局（Bermuda Monetary Authority，BMA）在《Catastrophe Risk Modelling Report》里给出的数字很直接：2022 年与 2023 年，各有约 54.2% 的保险人按季度运行模型；2023 年另有 42.1% 的集团按季度积累数据。这个比例在连续两个年度的同一口径上重复出现，说明它不是某一年临时调整出来的安排，而是行业默认节奏。

百慕大是英国海外领土，拥有自己的金融监管机构 BMA。BMA 于 1969 年依法设立，职能涵盖监管银行、信托公司、投资业务、投资基金、基金管理人、货币服务业务、公司服务提供商、保险公司、数字资产发行与数字资产业务，并监管百慕大证券交易所，同时发行货币、管理外汇交易。它的办公地在 BMA House, 43 Victoria Street, Hamilton——汉密尔顿既是百慕大的首都，也是这个国际金融中心的商业中枢。这个司法辖区以保险为主，专精巨灾再保险，是全球最大的再保险市场之一。市场结构决定了负载形状：这里的保险人不是靠高频交易吃饭，而是靠对低频高损事件的建模能力吃饭。

把这件事翻译成资源语言：一条月度利用率曲线上，大部分时间负载低而平稳，每季度出现一次陡峭的脉冲，脉冲期间 CPU、内存带宽与存储 IO 同时接近上限。按月度平均值去买容量，会在脉冲期直接撞墙；按脉冲峰值去买，闲置期又明显浪费。所以这类业务的容量问题不是"要多少"，而是"为哪种形状的负载付钱"。季度的计算压力是集中释放的，这是本文要处理的第一条资源判断，后面所有关于并行、存储与供应商的推演都从这条曲线形状出发。

还有一个容易被忽略的前提：这条脉冲曲线的时间点是可预测的。它不像零售大促或突发新闻带来的流量尖峰那样需要临时应对，季度批量窗口可以提前排期、提前储备、提前做演练。可预测性本身就是最有价值的规划资源，它让"按峰值准备"从一种浪费变成一种可以精确计算的选择。

巨灾模型在算什么：AAL、PML、EP 与 TVaR 为什么必须整批重算

巨灾模型不是跑一次回归。它的输出是一组风险度量，常用的几个量包括：AAL（年平均损失，Average Annual Loss），把多年模拟事件的损失按年频率加总后得到的长期平均值；PML（可能最大损失，Probable Maximum Loss），在给定超越概率下的损失金额；EP（超越概率，Exceedance Probability）曲线，即损失金额与"损失超过该金额的概率"之间的完整对应关系；TVaR（尾部在险价值，Tail Value at Risk），超过某个分位点之后的平均损失。与之并列的还有 RDS（现实灾害情景，Realistic Disaster Scenarios），用历史上真实发生过的灾害参数构造的确定性情景，常用于结果的可解释性检验。

为什么这几个量必须整批重算，而不能做增量更新？EP 曲线是对完整事件集按损失从大到小排序后，与各自的年发生频率配对得到的；尾部（TVaR 对应的那一段）由排在最前面的少数极端事件决定。敞口明细一旦变动，每个事件的损失都要重算，排序结果会整体变化，尾部的那几个点可能来自完全不同的事件。AAL 同理，它是全部事件的年频率与损失的加权和，任何一个位置的敞口变化都会传导到总和。改一条保单，不能只重算一条保单，因为它在组合中的位置变了，它对尾部的贡献方式也变了。

对资源的含义很明确：单次计算是一个不可切分的整体作业。输入是全量敞口明细加全量事件集，输出是全量事件损失表（Event Loss Table）以及由它导出的 EP 曲线。作业规模由事件数与敞口记录数共同决定，而不是由并发用户数决定。这是巨灾模型与在线业务的根本差别：在线业务的负载可以拆成大量小请求横向分摊，巨灾模型的单次运行则是一个必须完整执行的大作业，中间结果无法只更新一部分。

这些量的落点有两处。一是承保端的定价支持：一份新合同进来之后，它对整个组合尾部贡献了多少资本，要重新算一遍才能定价。二是资本端的 BSCR（百慕大偿付能力资本要求）测算，巨灾模型输出直接进入资本要求的计算链条。百慕大的监管框架里还有 SPI（特殊目的保险人）这类载体用于巨灾风险证券化，相关 Cat Return（巨灾债券或行业担保安排的收益口径）的定价也依赖同一套模型输出。模型输出的每一次变动，都会同时传导到资本与定价两个方向，这也解释了为什么运行时机如此刚性。

季度节奏从哪来：监管申报周期与敞口数据更新周期叠在一起

季度不是随便选的，它由两条周期叠在一起形成：一条是监管申报与内部资本测算的周期，一条是承保敞口数据的更新周期。

先说数据这一条。巨灾模型的输入是承保组合的敞口明细。一个季度里，续转、新单、退保、限额调整会持续改变组合结构，这些数据必须先做地理编码清洗（把地址解析到模型使用的风险网格）、风险特征补齐与一致性校验，才能进入模型。数据没清洗完，模型跑出来的结果就没有意义。所以"什么时候能跑"取决于"数据什么时候齐"，而业务上敞口数据按季度归集是最常见的做法，这直接把计算窗口推到了季度边界上。

再说监管这一条。百慕大的受监管保险人需要按固定周期向 BMA 提交与资本、偿付能力相关的监管申报，BSCR 是这套计算里的核心口径，巨灾模型输出直接进入资本要求的计算。申报有截止期，倒排下来就得到一个长度固定的准备窗口。叠加内部还要做资本充足测算与承保决策支持，季度节奏就被固定住了。这也解释了为什么 BMA 报告里"按季度"的比例会稳定在 54.2% 这个水平上：它不是偏好，是周期约束的结果。

对容量规划的直接结论是：峰值时间点是已知的，窗口长度是固定的，唯一需要估的是窗口内部要塞下多少工作量。这种可预测性决定了几件事——容量可以提前锁定而不必按常态冗余配置；外部弹性容量可以按日历预约而不必常驻；演练可以安排在真实窗口之前的空档期做。反过来说，一旦把这种业务当成"平时够用就行"来规划，撞墙的时刻会精准出现在申报前那几天。

loading factor 从 9.3% 到 12.30%：模型外那部分加成也在涨

BMA 报告里有一个指标值得单独拿出来看，那就是 loading factor，即模型外的加成或安全边际。已公布的数据是：2022 年法人实体平均 10.57%，2021 年为 9.3%；集团层面 2022 年 9.10%，2021 年 8.8%。2023 年法人实体平均升至 12.30%，这是连续第五年上升，集团为 10.68%。2024 年法人实体平均缓冲 11.9%，集团 9.22%。

这个数字的含义是：模型算出来的损失并不是最终被使用的那个数，实体还要在模型输出之上再叠一层人工缓冲。缓冲从 9.3% 一路走到 12.30%，说明模型本身被业界判断为系统性偏低，需要人为补足。BMA 在 2024 年的报告里直接指出，若供应商模型低估潜在损失，整个行业的资本水平可能随之受影响。上升原因包括社会性通胀与气候变化影响可能尚未完全反映在模型中。这个判断落到技术侧并不轻松：模型输出被系统性打折，说明模型的可解释性与可复核性要求只会更高，不会更低。

另一组相关数字是：2023 年约 70% 的法人实体与集团采用大西洋多年代振荡（AMO）近期视角。AMO 是调节北大西洋飓风活动的重要气候信号，选近期视角还是长期视角，会直接改变飓风频率假设。视角选择不是一个可以默认掉的参数，它需要单独记录、单独复核，而且不同视角下的结果要能被拿出来对比。

从资源角度看，loading factor 上升带来三件具体的事。第一，敏感性测试变多：既然要证明加成幅度是合理的，就要跑更多组假设（不同气候视角、不同脆弱性曲线、不同相关性假设），每一组都是一次完整批量。第二，复核链条变长：加成部分需要可追溯的证据，模型输入快照、参数版本、运行时间戳都要留痕，这些留痕本身就是存储与 IO 开销。第三，输出变多：不同情景下的结果要并存对比，存储容量与版本管理压力上升。这三件事全部挤在同一个季度窗口里，会直接推高上一节说的"窗口内工作量"。

AIR 与 RMS 并用、内部自建模型占 41.7%：多模型并行是常态配置

百慕大的巨灾建模不是单一供应商的天下。BMA 报告显示，AIR Worldwide（AIR）与 Risk Management Solutions（RMS）是最常使用的建模软件工具，可以并用也可以单独使用，其中 AIR 在法人实体与集团中均居首位。内部自建模型的比例不低而且在上升：2022 年 37.5% 的法人实体、28.6% 的集团使用内部自建模型；2023 年升到 41.7% 的法人实体与 31.6% 的集团。

累积计算中使用一个以上模型的比例是：2022 年 16.7% 的法人实体与 21.1% 的集团；2023 年 12.8% 的法人实体与 5.9% 的集团。注意 2023 年集团口径降到 5.9%，说明多模型并行在集团层面并不普遍，但在法人实体层面维持在一成以上。两组数字合起来看，内部自建的比例在走高，而多模型并行的比例在走低，这是两种不同的节约路径：有人选择自己造，有人选择只信一家。

对一个具体的容量规划来说，这些比例要换算成"同一窗口内同时有几套完整计算在跑"。三套（AIR 加 RMS 加内部自建）是罕见配置，两套（一个供应商模型加内部自建）是常见配置，单套也有。三档配置之间的资源需求不是线性关系而是倍数关系：两套并行意味着窗口内要同时容纳两套全量事件集的计算与中间文件，内存占用与 IO 吞吐同时翻倍，而且两套的峰值往往重叠，因为它们通常被刻意安排在同一个窗口内以便结果可比。可比性要求本身就是并行度的来源。

这里还有一个经常被估错的点：内部自建模型的并行效率通常不如商业软件。商业巨灾模型一般内置了经过优化的事件分片与内存布局，内部自建实现要靠自己解决，同样规模的事件集可能需要更多核心才能达到同等运行时间。所以在统计"并行模型数"这个变量时，内部自建那一套的权重不应该按 1 来算，而应该按实测效率折算成一个更大的等效值。忽略这个折算，窗口排期就是偏乐观的。

峰值怎么估：批量窗口、并行模型数、单次运行时长三者的关系

公开资料没有提供百慕大这些机构的具体算力规模、CPU 或 GPU 数量、机房容量数字，本文也不做任何推测。这一节只讲估算方法，给出变量之间的关系，具体数值要用自己环境下的实测去填。

峰值容量由三个变量决定：批量窗口 W、并行模型套数 N、单次运行时长 T。

• W（可用批量窗口）：从数据齐备到申报截止之间的时间，但要扣除流程占用——数据清洗时间、结果复核时间、人工审批节点的时间、返工预留。真正可用于计算的时间远小于日历时间，这一步扣减最容易被漏掉。
• N（并行模型套数）：见上一节，分 1、2、3 三档，且内部自建那一套要按实测效率折算成等效套数。
• T（单次运行时长）：单套模型跑完一次完整累积计算所需时间，要在自己的敞口规模与事件集规模下实测。不同版本、不同事件集规模下差异很大，应以实际版本文档与实测结果为准，不要套用别人的数。

三者的关系可以直接写成：串行总时长 T_serial 等于 N 乘以 T；要在 W 内完成，所需的有效并行度约等于 T_serial 除以 W。这个比值就是采购时真正要买的"能同时跑多少份"。再往下拆一层：单套模型内部分能分多少片（事件能否分片、分片后内存是否放得下），决定了这个并行度是靠单机的多核实现，还是要靠多台机器分摊。如果单套模型最多只能分片到 P 份，那么所需机器数约等于 T_serial 除以 W 与 P 的乘积。

存储与 IO 要单独算，而且经常先于 CPU 成为瓶颈。估算式可以这样列：中间数据量约等于事件数乘以每个事件的损失记录条数再乘以单条记录大小；IO 吞吐需求约等于 N 乘以中间数据量再除以 W。这些变量都要实测填入。巨灾模型的 IO 形态是大文件顺序写与结果表随机读混在一起，与在线业务的随机小 IO 完全不同，按在线业务的 IOPS 指标去选存储，选出来的东西会跑不动批量作业。

还有一项是版本留存加成。既然监管要求可追溯，同一个季度的输入快照、参数版本、输出结果都要保留，而且不同假设视角（例如 AMO 近期视角与长期视角）会产生多套结果。存储容量约等于单季数据量乘以保留期数，再乘以并行模型套数，再乘以视角数。这个连乘里任何一项被忽略，容量都会估小，且短板会在季度末集中暴露。

还有一条容易被忽略：峰值利用率不是非要跑到 100% 才算合理。批量作业在并行度提升时会遇到串行段与 IO 竞争，并行效率随规模下降是常态。估算时预先留出这个衰减，比事后发现窗口排不下要省事得多。

放到云上不等于责任搬走：BMA 指引里那句「不转移也不减轻问责」

BMA 于 2026 年 8 月就一份适用于全部受监管金融服务的 AI 使用指引征求意见，公开征求意见截止 2026 年 10 月 30 日，写作本文时文件仍在征求意见期内。适用范围包括再保险公司与保险公司、银行、投资公司、数字资产业务、公司服务提供商。这份文件需要先用正确的定位去读：它是指引说明（guidance note），不是新的 AI 许可制度，不创设新的法定或监管义务，不指定单一合规方法，也不要求事先审批。

文件里最该被技术供应商与采购方逐字读的那句话是：使用第三方、集团提供或外部托管的 AI 系统，并不转移或减轻受监管实体对由此产生的受监管活动、决策、流程或结果的问责。这句话对容量规划与供应商选择的影响很大。把建模搬到云上、托管给第三方、或者使用集团统一提供的平台，责任完整保留在自己身上，搬走的只是机房。这意味着外包不等于免责，外包之后反而多了一份举证义务：你要能证明自己对该系统的输出尽到了控制责任。

因此选型时要同时准备两样东西。其一是证据链：供应商尽调记录、服务等级约定、日志与运行留痕、结果与参数的版本对应关系，以及发生争议时能拿出来的复核路径。其二是替代路径：当外部系统不可用、或者供应商模型被判断为低估时，自己还能用什么方式在窗口内完成任务。没有替代路径，责任保留就等于风险全部自留，而且是自留在最不能出错的那几天。

BMA 在文件里点名关注的 AI 用途包括承保、定价、理赔分诊、欺诈检测、敞口与巨灾建模、投资组合优化，以及文档抽取与合规工作。巨灾建模被明确列入其中，说明前面几节讨论的算力问题同时也落在 AI 治理的范围内。文件要求逐案评估，低风险内部工具可能只需要批准使用政策、培训与访问控制；而直接进入资本计算的巨灾建模，显然不落在低风险那一档，需要按较高影响的用途配置控制。

供应商集中度被单独点名：双牌照常见、三模型并用罕见的结构性原因

BMA 在 AI 指引征求意见稿中把供应商集中度（vendor concentration）列为需要关注的风险之一，与数据质量差或有偏见、生成式 AI 输出不准确、网络安全威胁、过度依赖自动化决策并列。这不是一条抽象提醒，百慕大市场的结构让它变得特别尖锐。

结构是这样的：最常使用的建模软件是 AIR 与 RMS 两家，AIR 在法人实体与集团中均居首位；同时有相当比例的实体使用内部自建模型。这构成一个典型的双供应商格局。双牌照，即同时持有两家供应商模型的使用授权，是常见配置；三模型并用（两家供应商加内部自建同时进入累积计算）则是罕见配置。2022 年 16.7% 的法人实体与 21.1% 的集团在累积计算中使用一个以上模型，2023 年这个比例在法人实体为 12.8%、集团只有 5.9%。换句话说，多数实体在任何一个时间点都只依赖一家的输出做累积。

集中度风险在季度批量场景下的表现形态是单点失效被时间窗口放大。供应商模型如果在窗口内不可用、需要重新授权、或者版本更新导致结果不可比，受影响的不是一项日常功能，而是本季度的全部资本结论与定价结论。而且窗口是固定的，无法靠"延后几天"解决，这也是它和普通 SaaS 故障的根本区别。

可操作的应对方式，是把集中度当成容量变量而不是采购偏好来处理，具体是三件事。第一，确认第二套路径是否真的跑通过：不只是有授权，而是实际运行过、有实测时长数据、有可与主路径对比的结果。第二，确认两套路径的输入数据格式与地理编码口径一致，否则替代跑出来的结果不可比，替代就失去意义。第三，把替代路径的运行时长纳入 W 的倒排计算，因为替代路径通常更慢或并行效率更低，它的 T 值要单独测。没有实测过的替代路径，等于没有替代路径。

影子 AI 与代理式 AI：审计记录、人工审批节点与回退安排的额外开销

BMA 这份指引征求意见稿点名的风险里，有两个与技术资源规划直接相关：员工未授权使用 AI（影子 AI，shadow AI），以及代理式 AI（agentic AI）的自主多步行动。这两条都不是纯粹的"政策问题"，它们会实打实地改变资源与流程设计。

对较高影响或更自主的用途，文件要求更强的控制：独立质疑（independent challenge）、更严格的系统能力限制、可靠的审计记录、人工审批节点，以及系统失效时的回退安排。逐条翻译成资源需求是这样的：

• 独立质疑：需要一套与主计算隔离但能访问同样输入的环境，供第二团队或第二方法独立复算。这意味着窗口内多一份计算，N 要相应加一，或者至少在时间上额外预留一段。
• 更严格的系统能力限制：意味着不能让系统自动扩展到任意规模，要有明确上限。上限会直接影响可用并行度，超大事件集需要分片跑，分片本身增加调度与 IO 开销。
• 可靠的审计记录：谁在什么时候用什么参数跑了什么，要能事后还原。这产生的是持续写入的日志量与长期留存量，存储容量与 IO 都要单列一项，不能并入业务存储。
• 人工审批节点：审批不是瞬间完成的，它占用日历时间。审批时长必须从 W 里先扣掉，否则倒排出来的窗口是虚的。
• 回退安排：系统失效时用什么继续，回退路径的资源需求要提前准备好，而不是临时找。

影子 AI 这一条容易被技术团队当成合规部门的事，但它对容量有直接影响。如果员工可以自行调用外部 AI 服务处理敞口数据或模型输出，这些调用既不在规划中的容量账上，也不在可观测范围内。边界外的使用不占你的资源、不受你的控制，但它产生的结论可能进入申报材料。文件给出的低风险管理方式是批准使用政策、培训与访问控制，落到技术侧就是三件事：明确哪些工具可用、可访问哪些数据、访问如何留痕。这三件事都需要有对应的技术与流程载体，而不是一纸通知。

什么情况下不该按峰值买，什么情况下必须按峰值买

先讲反例。按峰值准备容量不是普适答案，以下这些情况就不该这么做：核心负载本来就是常态在线型（交易、门户、接口），批量任务只是附属且没有硬截止时间，此时按在线峰值规划，批量任务排队执行即可；并行模型套数为 1，且单套模型分片并行度高，串行总时长远小于可用窗口，此时有效并行度需求小于 1，按峰值买就是浪费；可以通过外部弹性容量补充，且合同与合规两侧都允许（合同允许临时扩容、数据存放位置符合要求、供应商审计权落实），此时常态容量按均值，峰值差额靠临时扩容补；业务处于早期，敞口规模与事件集规模还在快速变化，此时 T 值尚未稳定，按当前峰值采购会在半年后失效。

反过来，下面这些条件只要命中两条以上，就必须按峰值规划：模型输出直接进入监管申报或资本计算，申报有硬截止期且窗口不可延展；并行模型套数大于等于 2，或者需要为独立质疑额外预留一份计算；供应商集中度无法分散，只有一个可用模型路径，或第二路径没有实测过；流程里有必须的人工审批节点，且审批时长占窗口比例不低；存储与 IO 已被识别为瓶颈，此时即使 CPU 有富余，整体时长也压不下来；审计留存要求导致数据量按版本数放大，存储增长速度快于预期。

还有一个混合判断值得单独说：按峰值买计算资源，按均值买常态服务资源。季度批量型业务往往同时存在在线部分（核保系统、文档系统、报表门户）与批量部分，这两部分的负载形状完全不同，放在同一份容量方案里谈，通常会顾此失彼。把两条负载曲线分开核算，是这类业务做容量规划的第一步。分开之后还要再做一次合流检查：两类业务是否共享存储、共享网络出口、共享备份窗口，共享的部分要按两者峰值的较大者配置，而不是各算各的。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

容量与合规的双清单：采购前把这两组条目逐条过一遍

下面这张表把常态在线型业务的默认假设与季度批量型业务的现实摆在一起对照，供规划时逐行核对。注意它的用途是列出需要确认的变量，不是配置清单。

容量侧的清单，逐条确认后再谈机型与数量：一、本季度窗口内要同时完成的完整批量任务数，含主路径、替代路径与独立质疑的额外一份。二、单套模型在自己的敞口规模下的实测时长，分别记录最优情况与含 IO 竞争的真实情况。三、单套模型可分片上限，分片后单分片内存占用峰值。四、事件集规模带来的中间文件量与 IO 吞吐需求。五、保留期数乘以视角数乘以模型套数得到的存储总量。六、审批、复核、返工预留占用的日历时间，从窗口中先行扣除。七、弹性容量能否按日历预约，以及从下单到可用的时间。

合规侧的清单，同样逐条确认：一、建模与敞口工作是否落入 BMA 指引关注的 AI 用途范围（文件点名了敞口与巨灾建模），据此判断属于低风险档还是较高影响档。二、较高影响用途的四项控制是否都有对应载体：独立质疑、系统能力限制、审计记录、人工审批节点。三、系统失效时的回退安排是否写清，回退路径是否有资源保障。四、外部托管或集团提供系统的情形，合同中是否有审计权与数据可移植条款。五、员工可用 AI 工具范围、可访问数据范围与留痕方式是否明确，对应影子 AI 那条风险。六、供应商集中度是否被登记为已知风险，第二路径是否实际演练过。七、loading factor 的取值理由是否有可追溯记录，含 AMO 视角选择的依据。

百慕大这类季度批量业务，采购前最该问清楚的几件事

第一件：并行模型套数到底算几套。不要按许可证数量回答，要按窗口内实际同时运行的完整计算数量回答，内部自建那套还要按实测效率折算。这个数字直接决定 N，也直接决定后面所有乘法的结果。

第二件：单次运行时长有没有实测值，是在什么敞口规模下测的。公开资料没有给出百慕大机构的算力规模数字，别人的数字也不能直接套用。没有实测 T 值，就不可能算出有效并行度，采购只能靠猜。

第三件：窗口扣掉流程之后还剩多少。数据清洗、复核、审批、返工预留都要先扣掉，剩下的才是真正能用来算的时间。很多排期失败不是因为算得慢，是因为窗口本来就没那么大。

第四件：第二路径能不能真的跑起来。只持有授权不算有替代路径，要有实测时长、可对比的结果、一致的地理编码口径。这件事同时是容量问题和合规问题，而且 BMA 已经把供应商集中度单独点名了。

第五件：外部托管之后，自己还留着什么控制手段。既然使用第三方、集团提供或外部托管的 AI 系统不转移也不减轻问责，那么合同里的审计权、数据可移植条款、退出条款就是责任能否落地的关键，缺一条就意味着责任自留而无控制手段。

第六件：IO 与存储是不是单独核算过。季度批量型业务的常见失败模式是 CPU 算得快、IO 跟不上，最后整体时长压不下来。这一项如果没有单独测，按峰值买的 CPU 会有一半时间在等 IO。

第七件：留痕与审批占多少资源与多少时间。审计记录是持续写入的存储与 IO 开销，审批节点是必须从窗口里扣掉的日历时间，两者都不该被视为零成本。

本文引用的监管报告与来源，以及哪些需要你自己复核

本文的监管与市场数据来自百慕大金融管理局（BMA）公开发布的《Catastrophe Risk Modelling Report》系列，涉及年份为 2022 年、2023 年、2024 年。其中引用的数字包括：loading factor 法人实体 10.57%（2021 年 9.3%）与 12.30%、11.9%，集团 9.10%（2021 年 8.8%）与 10.68%、9.22%；2023 年约 70% 的法人实体与集团采用 AMO 近期视角；内部自建模型比例法人实体 37.5% 与 41.7%、集团 28.6% 与 31.6%；累积计算中使用一个以上模型的比例，2022 年法人实体 16.7% 与集团 21.1%，2023 年法人实体 12.8% 与集团 5.9%；按季度运行模型的保险人比例 2022 年与 2023 年均为约 54.2%，2023 年按季度积累数据的集团为 42.1%。

关于 AI 治理的部分，来自 BMA 于 2026 年 8 月发布征求意见的 AI 使用指引，公开征求意见截止 2026 年 10 月 30 日，写作本文时文件尚未定稿。该文件的定位是指引说明而非新的 AI 许可制度，不创设新的法定或监管义务，不指定单一合规方法，也不要求事先审批，适用于再保险公司与保险公司、银行、投资公司、数字资产业务、公司服务提供商。由于文件仍在征求意见期内，最终文本与本文引用的表述可能存在差异，引用前请以 BMA 正式发布的最终版本为准。

以下这些内容需要你自己复核，本文没有给出也不需要给出：一是具体的算力规模，公开资料未提供百慕大机构的 CPU、GPU 数量或机房容量数字，本文不做推测；二是单次运行时长、中间文件量、IO 吞吐等变量，这些必须在自己的敞口规模与事件集规模下实测，不同版本差异很大，应以实际版本文档为准；三是具体的申报截止日期与申报频次，本文只说明存在固定周期与硬截止期，具体日期以 BMA 当期的正式要求为准；四是机型、带宽与报价，这些属于实时信息，需以官网实时信息或咨询确认为准。

还有一处需要说明口径：本文把"按季度运行"作为资源规划的主线，是因为 BMA 报告显示这是占比最高的节奏，但并不排除其他节奏（月度、半年、年度、事件驱动）的存在。如果某个实体的实际节奏不同，把本文的变量关系套进去仍然成立，只是把 W 从季度换成对应周期即可。方法是一致的，数字要换成自己的。