研究者提出 AI 评估沙盒配置器，支持欧盟 AI 法案下的技术评估

AIRS中的结构化技术测试缺少能让多方协作、并使证据可比、可追溯的专用基础设施。

• 场景： 作者称，AI Act要求各成员国在2027年8月前至少建立一个AI Regulatory Sandbox（AIRS）；参与自愿，初创企业和中小企业可免费使用核心活动。主管机关（Competent Authority, CA）提供监管指导。Article 58(2)(i)让AI Office汇总沙盒发现，因而预设各次参与的结果具有一定结构和可比性。
• 数字沙盒： EUSAIR把以法律和程序监督为中心的参与，与额外按CA要求做结构化技术测试并产出证据的参与区分开，后者称为digital sandbox。作者称这不是正式法律类别，也不规定测试如何实现。作者把承载该组件的基建称为AI Assessment Sandbox。
• 碎片化： 作者称没有单个现有工具是按这些条件设计的：多方角色和访问权不同；CA需要能用于Exit Report及后续监管的证据；隐私敏感行业要求评估完全在提供者环境内运行；没有单个工具覆盖AI Act的全部可信性维度。异构工具的输出难以比较、追溯和复用。
• 做法： 作者从Article 57与58的程序条件、与CA及Testing and Experimentation Facilities、AI Factories、European Digital Innovation Hubs的磋商，以及自身作为技术测试方的试点经验，导出11项架构与治理要求，并提出开源框架AI Assessment Sandbox Configurator。作者称R1、R3、R6分别排除固定评测协议、无差别的单一界面，以及不能完全部署在提供者环境内的基建。

论文没有以性能指标对比实验基线。Section 2按公开文档能否对照R1–R11来讨论工具；作者称这不是合规工具市场的穷尽地图，并排除内部机制未公开的专有产品。

碎片化与审计

• 伦理工具与审计标准： Portegies et al.（2025）分析伦理AI工具；作者转述其原则覆盖不平衡，且强烈依赖自我评估。Mökander（2023）讨论AI审计；作者称该领域仍缺共享术语，以及何谓审计、结果如何支持问责的稳定标准。
• 实验跟踪： MLflow（Zaharia et al. 2018）在单个机器学习项目的开发流水线内做元数据日志和谱系跟踪。作者称它具备模块化、谱系和部署可移植性，但不是为异构外部工具集成或多方监管场景设计的。
• 模型文档： Model cards（Mitchell et al. 2019）和datasheets for datasets（Gebru et al. 2021）用人工撰写的模板披露性能特征和数据来源，面向人读而非下游集成。作者称它们是多受众披露的概念前身，但不处理基础设施级要求。

综合评测与国家工具

• HELM： Liang et al.（2023）在单一集成框架中，按标准化条件评估语言模型的accuracy、robustness、fairness、bias、toxicity。作者称其在自有框架内有深度和扩展点，但不能容纳AIRS所需的异构、分行业测试。
• AI Verify： IMDA（2023）提供治理框架和测试工具包，把自动化测试与治理过程检查合在一起。作者称其目的最接近，具备结构化评估、可配置测试选择和自动报告；因工具包与框架紧耦合、没有协调任意外部工具输出的已记录机制，且不是为Article 58(2)(i)的跨参与汇总而设计，Table 2将R2标为❍。

参考架构与法规基准

• PARMA： Pintz, Becker, and Mock（2024）规定多方、可复现的AI可信性评估结构，不指定评估工具、数据格式或部署基建。作者称这保留了灵活性，但把具体集成、协调和部署留给采用方。
• COMPL-AI： Guldimann et al.（2024）把AI Act义务映射为技术要求和可执行测试，含18项要求、27个LLM基准。作者称它是监管锚定上最接近的工作，但规定的是面向语言模型的固定基准集，而不是AIRS所需的异构工具和多方流程；社区贡献走代码库，而不是稳定的第三方API。作者对Table 2中R2为❍的理由与HELM同类，即深度限于自有套件；R11为❍，是因为它评测被测模型的网络安全，而不是评估基建自身的安全控制。

对照方式与本文定位

• 符号对照： Table 2用●、◗、❍评估MLflow、model cards/datasheets、HELM、AI Verify、PARMA、COMPL-AI和Configurator是否实质覆盖、部分覆盖或不在设计范围内。论文未报告与这些工具的查询次数、耗时或成功率对比。
• 定位： 作者把Configurator写成这些要求的可部署实现，并称不主张这是唯一可行的架构回应。与COMPL-AI的固定基准集、PARMA的未实例化参考架构相对，本文把可替换组件收束到两个稳定接口上。

AI Assessment Sandbox Configurator先在配置期描述系统、选择测试并规定可视化和报告，再实例化运行期沙盒。Figure 1将配置期画在上方，运行期画在下方。除Catalogue插件API和Testing Database中的共享数据模型外，组件可替换；作者称不变的是各组件都通过这两个接口通信，接口内部模式可在版本化治理下演化。框架以Apache 2.0发布，用Docker Compose做容器化部署。

十一项要求与配置式回应

• 导出： 要求分三阶段形成：Article 57、58的digital sandboxing程序条件；与CA及TEF、AI Factory、EDIH磋商中的操作预期；作者在Section 5试点中作为技术测试方的经验。Table 1用A、C、P标记来源。11项都与高风险系统提供者义务Articles 9至15中的一条或多条直接相关。
• 条目： R1可定制与模块化；R2外部评估目录兼容；R3可视化流水线与分角色仪表板；R4开源核心；R5插件架构；R6部署可移植；R7基于角色的访问控制；R8自动报告；R9不可变审计轨迹；R10共享数据模型与持久存储；R11网络安全与威胁缓解。
• 架构选择： 作者称R1、R3、R6合在一起，使一个固定沙盒难以同时覆盖不同行业、不同组织的角色结构和现场部署，因此每个沙盒由该次参与、相关方结构和报告需求配置出来。作者称这不是唯一可行回应，但是他们采用的方案。
• 覆盖口径： 正文称R2、R3、R8为架构上已承诺且在试点中部分运行；R1、R4、R5、R6、R7为架构上已承诺但试点未运行；R9、R10、R11的持久保证还依赖托管环境，而不只依赖框架。

资格认定与Catalogue

• AI System Card： 问卷记录风险类别、受影响的终端用户和第三方、部署行业、待评估的可信性维度。当前版本用一次LLM调用和结构化提示词推断卡片；论文未说明该LLM是哪一个。用户可在下游使用前手工修改。卡片可作PDF或JSON下载，用于选择插件，并作为机器可读画像。作者称若被广泛采用，可支持国家和欧洲层面的AI Office监督。该术语沿Golpayegani et al.（2024），与面向终端用户的另一种industry AI card无关。
• 生成器边界： 作者写明，非确定性调用位于可能进入监管产物的流程起点。内部开发使用而非系统评测中，出现过行业误分类、受影响群体欠指定、相近输入详略不一致。论文未定量描述逐次方差，也不给出测得错误率。后续版本计划改为对照卡片模式做形式校验的智能体推断；各版本仍保留手工修改。
• 集成契约： 插件须同时实现接口钩子、到共享数据模型的输出映射、插件专用报告逻辑和模板，以及标准化元数据文档。写作时已集成10个插件，分属LLM safety and robustness与classical ML performance；括号中的主题包括bias detection、multilingual performance、jailbreak resistance、RAG evaluation、agentic safety，以及classification、regression、anomaly detection、data drift、model explainability。作者对每个插件核对了无损失写入、经Testing Database API检索汇总、下游展示不另写插件逻辑。作者称这只说明数据模型对当前集合够用。
• 分层与分类： Table 3分Core、Verified、Community。写作时只有Core在运行，插件在主仓库并由项目组维护；后两层属更长期路线图。分类把AI HLEG的七个可信性维度落到可测子维度，生成式系统再辅以OWASP Top 10 for LLM Applications。控制项覆盖accountability、quality management、risk management。目标系统标注参考Hugging Face方案，行业来自OECD工具目录。可下载的本地Catalogue实例在计划中。

选择、配置与实例化

• 手工选择： 写作时没有自动助手。用户按可信性维度、目标系统类型、行业、验证类型筛选。作者称目标参与中由技术测试方与提供者磋商选择，CA可强制最低测试和控制集合；配置沿用同一分工。两步相互独立，不必按此顺序。
• 省略风险： 作者指出，若提供者驱动或影响选择，被评估方会部分决定产出哪些证据，评估可能因省略而非误报而显得有利。设计上的缓解是把选择记入审计轨迹并写入报告，使CA能看到未测项。选择权最终归谁，作者称框架只把问题显出来，并不裁定。
• 分角色配置： 按插件指定可视化，以及business process owners、regulators、technical AI experts、legal and compliance specialists、ethical experts中哪些角色可访问。报告可有多套模板，例如内部机密版、公开摘要和监管卷宗，共用同一证据库。
• 实例化内容： 配置完成后供应Test Execution Engine、Collaborative Assessment Dashboard、Report Generator，初始化Testing Database模式，绑定角色视图和报告模板，并以RBAC向参与方开放。

共享数据模型与运行时产物

• 模式： 采用OMG的Structured Metrics Metamodel（SMM, 2018），并扩展AI系统元数据、数据集、评估配置和法律要求。作者称因此不同工具的自动结果和人工控制可以放在同一表示中比较和共同报告，这也是未来欧洲层面汇总的技术前提。参考实现为PostgreSQL；跨关系库移植是设计意图，尚未测试。
• 执行与审计： 引擎连接目标端点，保存分插件的版本化运行配置，并实施RBAC、凭证与端点隔离、组件间认证通道。审计使用ImmuDB：追加式库，对内容维护Merkle哈希树，持有已发布根哈希的一方可检测事后篡改。作者称选择它是因为事务API接近常规数据库。当前只覆盖执行引擎和协作仪表板。
• 仪表板与报告： 仪表板汇集自动测试和人工控制，支持按数据集、配置、指标或运行过滤，以及结构化评论。Web应用由低代码框架BESSER从声明式规格生成。Report Generator把结果注入插件专用Jinja 2 HTML模板，经Weasyprint生成PDF；强制段落保证各组最低透明度，可选段落调节技术粒度。
• 三类产物： AI System Card；可导出为CSV和JSON的防篡改日志；Tailored Assessment Report。作者称该报告意图送入或附于CA出具的官方Exit Report，而不是取代它。

实验设置

• 被测系统： 试点对象是一家意大利初创公司的LLM-backed conversational assistant，以英语、法语、意大利语的结构化对话生成GDPR数据保护影响评估。论文未给出基础模型名称，也未说明DPIA插件所称cross-model对照了哪些模型。
• 场合与角色： EUSAIR运行该AIRS试点，LIST作为外部技术测试方。EUSAIR联合体承担CA-equivalent。相关方包括提供者的产品经理和开发者、LIST技术测试方、EUSAIR法律专家。
• 运行范围： 作者称试点运行共享数据模型、Collaborative Assessment Dashboard和Report Generator。Test Execution Engine、Qualification流程和端到端不可变审计轨迹未运行。
• 插件与导入： 使用Catalogue中的StrongReject（Souly et al. 2024a,b），即prompt-injection鲁棒性基准，按发布版本复用；另有为本次实现的跨模型、跨语言DPIA completion插件。二者在引擎外运行，经共享数据模型API导入，如同已集成插件的产物。
• 对照与判定： 论文没有把Section 2的工具当作性能基线，也没有定义ASR、阈值、评审模型、样本量或重复次数。Table 2是对R1–R11的符号覆盖评估。卡片生成器不在该试点内；Section 4.1的失败模式来自内部开发使用。

主结果

组件	试点记载	出处
共享数据模型	未做schema扩展即使用	Section 5
Collaborative Assessment Dashboard	未改仪表板代码即使用	Section 5
Report Generator	除契约要求的插件报告模板外，未为本次另写模板逻辑；产物作为官方Exit Report附录	Section 5
Test Execution Engine	未运行，结果走导入路径	Section 5
Qualification流程	未运行	Section 5
不可变审计日志	试点未产生	Section 5；Section 6.3

• 范围： 作者把试点写成所覆盖层次的可行性证据，而不是对整体架构的确认。
• 绑定方式： 作者称，仪表板和报告层对外部产生的结果无需改动即可工作，说明把组件绑在一起的是共享数据模型，而不是执行路径。仅为本次构建的是DPIA插件及其映射。
• 复跑： 作者报告，初次StrongReject运行显示该助手对基准中并非微不足道的一部分prompt-injection攻击存在脆弱性。产品经理和开发者在迭代之间加入安全护栏；后续运行中，作者称越狱抵抗有可见改善，并把这描述为参与期间、而非上市后达成的compliance-by-design结果。迭代过程和法律专家对残余风险的解释写入Testing Database并进入报告。论文未报告该比例、改善幅度、迭代次数或残余风险的具体内容。

同一结果的多方解读

• 测了什么： Section 6.1回看这次试点中同一批结果如何被不同角色使用，不是另一次定量实验。
• 结果： 作者称同一结果被技术、法律和领域专家作出不同解释。论文未给出分歧条目或人数。
• 作者的解读： 作者称Configurator可以形式化流程、标准化报告并提供可复用模块，但不能决定适当的评估焦点，也不能权衡发现；表述和解释仍是人的责任。

需求覆盖自评

• Configurator： 正文称R2、R3、R8已在试点部分运行并在Table 2标为●；R1、R4、R5、R6、R7架构上已承诺但试点未运行，仍标●；R9、R10、R11为◗。R10为◗并不表示数据模型未使用：正文称模型已针对当前插件集使用和校验，但持久保证还依赖存储后端和保留策略。R9还依赖时钟同步和已发布根哈希的保管；R11还依赖网络隔离、身份源、密钥、补丁和监控。表注称，架构上已承诺但尚未大规模运行之处，自评故意取得保守。
• 正文点名的其他格子： AI Verify与COMPL-AI的R2为❍；COMPL-AI的R11为❍。正文称因PARMA是参考架构而非可部署系统，将R6标为不适用；Table 2中PARMA的R6为●。其余符号见Table 2。
• 未做的性能对照： 论文未报告Configurator与MLflow、HELM、AI Verify、PARMA或COMPL-AI在同一系统上的测试结果差异。

其他消融与分析

• 卡片生成器：无系统评测、无测得错误率；内部使用中的三类失败模式见Section 4.1，手工修改被用于纠正这些模式。
• 数据模型：针对10个插件、两个领域做了三项校验；作者称尚未证明对专门领域或新系统类型的可推广性（Section 4.2、6.3）。
• 存储：PostgreSQL为参考实现；其他关系库移植未测试（Section 4.6、6.3）。
• 审计：ImmuDB只覆盖执行引擎和仪表板；试点无审计日志（Section 4.7、6.3）。
• 选择：写作时无自动推荐；顾问式向导在路线图上，选择决定仍留给用户（Section 4.3、6.3）。
• Catalogue：仅Core层在运行；Verified与Community属于更长期路线图（Table 3、Section 6.2）。

作者指出的局限与后续方向

• 范围： Section 6.3称，论文给出的是经早期试点验证了协调与报告层的架构；Section 6.4的更广主张是前瞻性的，并取决于下列路线图。
• 卡片生成器： Section 6.3称其未经系统评测。手工修改可用，并已用于纠正Section 4.1的失败模式；若跳过修改，细微不一致可能不被发现。量化逐次一致性被列为近期优先项，并与改为智能体推断并列。
• Catalogue形态与选择： Section 6.3称当前是仅Web的公开实例，有保密约束的组织不能在此模式下集成专有插件；可下载的本地开源实例在计划中。测试选择仍是手工浏览，对不熟悉评估版图的用户构成负担；路线图上的向导只作顾问，选择决定留在用户。
• 数据模型与存储： Section 6.3称共享数据模型已针对10个插件、两个可信性领域验证，对专门领域或新系统类型的可推广性尚未得到展示；将随Verified和Community层接纳新插件继续验证。PostgreSQL以外的关系库移植仍是设计意图，尚未测试。
• 审计与符合性评估： Section 6.3称不可变审计轨迹只在执行引擎和协作仪表板上运行，试点未产生审计日志；把ImmuDB扩展到全部组件是近期优先项，并将在后续试点中运行。符合性评估支持仍停留在技术基础；与正式流程对齐有待相关实施法案和协调标准定稿（亦见Section 6.1）。
• 治理未裁定： Section 6.2称，Verified层在技术检查之外是否还应做法律实质认可、由哪些机关承担，以及Community层如何展示长尾贡献而又不暗示背书，作者都尚未确定。Section 6.4把成员国间比较分析写成前瞻而非已展示的结果。

实验覆盖范围

• 要求对照： 对照对象为MLflow、model cards/datasheets、HELM、AI Verify、PARMA、COMPL-AI（Section 2、Table 2）。作者称调查限于公开文档足以评估R1–R11的工具，排除内部机制未公开的专有产品。
• 插件校验： 写作时Core层有10个插件，分属两个可信性领域，并按四项集成契约做了三项数据校验（Section 4.2）。Table 3写明Verified与Community尚未运行。
• 试点对象： 一次由EUSAIR协调的AIRS参与：意大利初创公司的LLM-backed conversational assistant，以英、法、意对话生成GDPR DPIA。角色包括提供者的产品经理和开发者、LIST技术测试方、EUSAIR法律专家；EUSAIR承担CA-equivalent（Section 5）。
• 试点组件： 运行了共享数据模型、Collaborative Assessment Dashboard和Report Generator。两个插件为Catalogue中的StrongReject，以及为本次实现的DPIA completion插件；二者在Test Execution Engine之外运行并经API导入（Section 5）。
• 论文未报告的数量： 论文未报告StrongReject样本量、攻击成功比例、复跑次数、卡片生成所用LLM，以及评审与人工一致性。Qualification流程和端到端不可变审计轨迹在该试点未运行（Section 4.1、5、6.3）。

AI Assessment Sandbox Configurator是面向欧盟AIRS中结构化技术测试的开源配置框架，用来按一次参与组装评估环境。

• 问题： 成员国须在2027年8月前建立AIRS。含技术测试的参与要让不同角色在受监督环境中协作，并使CA能把证据用于Exit Report和后续监管；Article 58(2)(i)还预设跨参与汇总。作者认为现有工具输出难以比较、追溯和复用，没有单个工具按这些条件设计。
• 要求与结构： 11项要求来自Article 57与58、与CA及相关欧洲倡议的磋商，以及作者的测试经验。配置期生成AI System Card，从Catalogue选择插件，并规定角色视图和分受众报告；运行期再实例化执行、协作和报告组件。稳定接口是插件API和扩展自SMM的共享数据模型。写作时Core层有10个插件；Verified与Community层尚未运行。
• 试点： 在EUSAIR的一次参与中，对象是生成GDPR DPIA的多语言对话助手，论文未给出模型名。共享数据模型、仪表板和报告生成器被使用且基本未改；执行引擎、资格认定和端到端审计未运行。StrongReject与一个临时DPIA插件经API导入。作者称初次运行显示助手对基准中并非微不足道的一部分prompt-injection攻击存在脆弱性，加入护栏后的后续运行在越狱抵抗上有可见改善；论文未给比例。Tailored Assessment Report被用作官方Exit Report的附录。
• 作者的结论： 作者把该试点视为所覆盖层次的可行性证据，而不是整体架构确认，并称同一结果会被不同专业作出不同解释，解释责任仍在人。结论中的“被评估系统出现可见改善”，在Section 5被具体写为越狱抵抗上的可见改善。跨境比较、符合性评估对齐和欧洲开源评估生态，作者写成前瞻事项，取决于Section 6.3的路线图，以及Catalogue治理中尚未裁定的背书问题。