| Requirement | Description | Relevant AI Act Articles | Origin |
|---|
| R1: Customisability and Modularity | Each engagement involves a distinct system, sector, and risk profile, with metrics, thresholds, and testing methods that cannot be prescribed in advance. The sandbox must support “à la carte” configuration of tests, metrics, and pipelines, tailoring every engagement to its context rather than forcing it into a generic protocol. | Art. 9 (Risk Mgmt), Art. 15 (Accuracy) | A, P |
| R2: Compatibility with External Assessment Catalogue | No single tool covers the full range of trustworthiness dimensions a CA may require evidence on. The sandbox must integrate heterogeneous external tools, benchmarks, and datasets, enabling unified execution and result harmonisation regardless of original format, so the evidence base reflects the full scope of the engagement. | Art. 10 (Data Governance), Art. 13 (Transparency), Art. 15 (Accuracy) | A, C |
| R3: Visual Pipelines and Tailored Dashboards | A CA official, a technical tester, a legal expert, and a product manager cannot all be served by the same view of assessment results. The sandbox must provide role-specific, real-time dashboards through which each group interprets harmonised evidence in the terms of its regulatory, technical, or governance responsibility, alongside low-code interfaces for composing and monitoring pipelines. | Art. 11 (Documentation), Art. 13 (Transparency), Art. 14 (Human Oversight) | C, P |
| R4: Open-Source Core | For CA oversight to be meaningful, the assessment infrastructure itself must be inspectable; a proprietary black-box sandbox undermines the transparency that supervised regulatory testing requires. The core codebase must be released under a permissive licence, enabling community scrutiny, co-development by regulators and industry, and alignment with European digital sovereignty objectives. | Art. 11 (Documentation), Art. 13 (Transparency) | C |
| R5: Plug-in Architecture | The AI Act spans sectors and system types with domain-specific testing needs that no single team can anticipate. The sandbox must expose stable APIs enabling third parties to add sector-specific tests, visualisers, and data connectors without modifying the core, so the assessment ecosystem grows alongside regulatory needs. | Art. 15 (sector-specific accuracy and robustness) | A, C |
| R6: Deployment Portability | Providers in privacy-sensitive sectors such as healthcare or finance cannot allow assessment data to leave their control. The sandbox must be deployable on-premises or in sovereign clouds, producing identical artefacts in any deployment context, so portability constraints do not compromise cross-engagement comparability. | Art. 15 (Robustness) | C |