AspisAI: A Canonical, Machine-Interpretable Governance Framework for Automated Multi-Standard Compliance Monitoring Tsafac Nkombong Regine Cyrille CyberMACS, Applied Cybersecurity [email protected]
Hasan Dag
arXiv:2609.10881v1 [cs.CR] 9 Sep 2026
Kadir Has University Istanbul, Türkiye
Reiner Creutzburg SRH University of Applied Sciences Heidelberg Campus Berlin, Germany
Knut Haufe SRH University of Applied Sciences Heidelberg Campus Berlin, Germany
Abstract—Organisations operating in regulated and criticalinfrastructure sectors must satisfy multiple, heterogeneous cybersecurity and privacy instruments simultaneously, including but not limited to ISO/IEC 27001, the NIST Cybersecurity Framework 2.0, Cyber Essentials, and the GDPR. In practice these obligations are managed through manual mappings, spreadsheetbased tracking, and periodic audits that are costly to maintain, inconsistent across standards, and weak in traceability. This paper presents AspisAI, a bounded, standard-agnostic governance framework that translates selected requirements from several frameworks into a canonical, machine-interpretable control model, and evaluates submitted evidence against condition-based decision rules to produce explainable, traceable compliance determinations. Within a bounded scope of 26 representative requirements, the framework is evaluated in a controlled simulation against five governance-oriented criteria and, critically, against two external reference points that mitigate the circularity of single-author evaluation: its cross-standard mappings are validated against NIST’s own published informative references, with 57 % exact agreement and divergences confined to same-family controls, and the framework is applied to real third-party evidence from the OpenSSF Scorecard, surfacing genuine governance gaps in a live open-source project. The controlled results, comprising full requirement encoding, 88.5 % mapping coverage, complete traceability, and correct detection of all introduced gaps, establish functional correctness, while the external validation provides evidence of applicability beyond the simulation. The contribution is therefore a demonstration that a canonical, provenance-preserving governance model can render multi-standard compliance both automatable and auditable. Index Terms—Compliance automation, cybersecurity governance, machine-interpretable policy, ISO/IEC 27001, NIST CSF, GDPR, critical infrastructure, design science research, traceability.
regulated sectors. Instruments such as ISO/IEC 27001, the NIST Cybersecurity Framework 2.0, Cyber Essentials, and the GDPR overlap substantially in intent yet differ in structure, vocabulary, and evidentiary expectations [1], [2]. Managing them together typically relies on static, manually maintained mappings that drift out of alignment with the underlying standards, duplicate evidence-collection effort, and provide weak traceability from a compliance outcome back to the evidence that supports it. Emerging approaches such as compliance automation, policyas-code, and machine-readable governance artefacts suggest that compliance logic can be formalised [3], [4], [5]. However, much of this work is implementation-heavy or specific to particular technical environments such as cloud platforms or DevSecOps pipelines, and gives comparatively little attention to the governance-design problem itself: how selected requirements from heterogeneous frameworks can first be translated into a bounded, traceable, machine-interpretable governance structure. This paper addresses that gap with AspisAI, a governance framework that translates selected cybersecurity, privacy, and resilience requirements into structured, machine-interpretable governance logic suitable for automated and continuous compliance monitoring. The contributions are: (i) a standard-agnostic canonical control model with accompanying JSON schemas that preserves the provenance of each requirement; (ii) a lightweight rule-evaluation engine that produces explainable, traceable compliance determinations; and (iii) an evaluation on a simulated critical-infrastructure case study against five governance-oriented criteria.
I. I NTRODUCTION
II. R ELATED W ORK
Compliance with multiple cybersecurity and privacy frameworks has become a routine obligation for organisations in
Three streams of prior work are relevant. The first compares cybersecurity and regulatory frameworks and documents their
overlap and the difficulty of aligning them consistently in practice [1], [2]. The second concerns compliance automation: Bar-Haim et al. assess organisational cybersecurity posture in cloud settings using structured representations [3]; Haverinen et al. automate compliance in DevSecOps through an open information model for security-as-code [4]; and Angermeir et al. examine continuous security compliance [5]. The third addresses privacy- and GDPR-oriented compliance [6], [7], [8], [9] and the heightened need for traceable governance in critical-infrastructure contexts [10], [11]. A fourth, emerging stream treats compliance as executable artefacts. Policy-as-code expresses governance constraints directly as machine-checkable code [4], and recent work pairs large language models with deterministic validators so that machine-generated mappings or policies are checked before being trusted [12], [13], [14]. This stream is methodologically closest to the present work, which adopts the same “proposethen-validate” discipline but anchors it in a canonical crossstandard model rather than a single policy language. Across these streams, prior work tends to satisfy one or two of the properties required for integrated governance, namely multi-standard scope, machine-interpretability, and end-to-end traceability, but rarely all three within a single artefact. Frameworks that automate checking within a single environment, for example cloud posture or a CI/CD pipeline, typically lack a standard-agnostic canonical layer, while cross-framework comparison studies establish where standards overlap but stop short of an executable, traceable artefact. AspisAI is positioned to address this combination explicitly, with emphasis on a canonical model that preserves provenance while supporting cross-standard mapping and interpretable evaluation. This is best characterised as a technical gap: existing approaches are individually capable but are not composed into a single traceable, multi-standard governance layer. III. M ETHODOLOGY The study follows a design science research (DSR) methodology [15], [16], organised around the design and evaluation of an artefact. The artefact comprises five tightly related components: a bounded set of selected requirements, a canonical control structure, cross-standard mappings, machine-interpretable governance rules, and traceability-preserving compliance outputs. Figure 1 shows how these components compose into three layers: normalisation, governance logic, and evaluation output. A. Canonical Schema and Requirement Selection
Fig. 1. The three-layer AspisAI architecture. Layer 1 normalises requirements from four standards into a single canonical schema; Layer 2 applies crossstandard mapping and the rule engine to submitted evidence; Layer 3 produces traceable compliance decisions and gap reports. TABLE I P RIMARY R EQUIREMENT S OURCES IN THE C ANONICAL M ODEL Source
Role in the model
ISO/IEC 27001:2022 ISMS governance requirements NIST CSF 2.0 High-level cybersecurity outcomes Cyber Essentials Prescriptive technical baseline GDPR (Arts. 5, 25, 32, 33, 35) Privacy and data-protection duties NIS2 Directive Critical-infrastructure context
B. Governance Logic and Rule Engine A governance logic layer operates on the normalised representation through two components: a cross-standard mapping that records equivalence, overlap, and complementarity between requirements; and a rule engine that evaluates submitted evidence. A rule R is a finite set of conditions CR = {c1 , . . . , cn }, where each condition ci = (fi , op i , vi ) names an evidence field, a comparison operator, and an expected value. Submitted evidence E is treated as a partial map from field names to observed values, formed by merging the property sets of every artefact in the submission. A condition is satisfied only if the field was actually supplied and the comparison holds: ( 1 if fi ∈ dom(E) and op i (E(fi ), vi ) σi = (1) 0 otherwise Pn Writing k = i=1 σi for the number of satisfied conditions, the determination is if k = n COMPLIANT D(R, E) = PARTIAL (2) if 0 < k < n NON - COMPLIANT if k = 0
A bounded set of 26 representative requirements was selected from ISO/IEC 27001, NIST CSF 2.0, Cyber Essentials, and the GDPR. Each requirement is encoded in a canonical JSON schema with mandatory fields including a unique identifier, source standard, clause reference, control objective, governance domain, and expected evidence. This common representation establishes the shared vocabulary needed for cross-standard with compliance score s = k/n and gap set G(R, E) = {fi | mapping and preserves the provenance of every requirement. σi = 0}. The gap set is what makes an output actionable: it Table I summarises the four primary sources and the contextual names the specific fields that failed rather than returning a instrument. verdict alone. Because σi requires fi ∈ dom(E), a field that
was never supplied is treated as unsatisfied rather than silently skipped, which is the mechanism by which missing evidence becomes a detectable gap. The engine deliberately uses straightforward Boolean logic rather than weighted or probabilistic scoring to preserve interpretability, and binds every rule to one or more canonical requirements so that each determination is traceable to its source clause. Because the rule engine is purely Boolean and contains no stochastic element, the governance evaluation is fully deterministic: re-executing it on identical inputs yields byte-identical decisions, which makes the reported results reproducible from the accompanying artefact. Non-determinism is confined to the optional AI-assisted mapping component (Section III-E), and is deliberately contained by routing every model proposal through the deterministic validator before it can affect any decision. C. Simulated Case Study The framework is demonstrated on NorthGrid Energy Distribution Ltd, a simulated regional energy utility with hybrid IT/OT infrastructure. Four synthetic evidence domains (access control, incident response, data protection, and risk assessment) were defined, with a number of intentional gaps introduced to test detection. Synthetic evidence avoids reliance on sensitive organisational data while preserving realism. D. Evaluation Criteria The artefact is evaluated against five governance-oriented criteria: coverage (proportion of selected requirements encoded), mapping quality (cross-standard correspondence), rule decision accuracy (agreement with a predefined ground truth), traceability completeness (unbroken requirement-to-evidence chains), and gap detection (correct identification of missing evidence). E. AI-Assisted Mapping with Deterministic Validation To explore how the canonical model could scale beyond manually curated mappings, an optional component allows a large language model to propose cross-standard relationships, which the framework then validates deterministically. A proposal is accepted only if both requirement identifiers exist in the canonical model, the proposed relationship type is permitted, and the relationship is consistent with NIST’s published informative references; otherwise it is flagged as a probable hallucination. The language model is therefore never trusted directly: it acts as a generator of candidate mappings, while authority rests with the deterministic validator. Because the language model is itself non-deterministic, the component supports repeated execution so that the run-to-run stability of accepted mappings can be measured; the validator itself is deterministic and produces identical verdicts on identical proposals. IV. R ESULTS A. Coverage and Mapping Quality All 26 selected requirements were successfully encoded and validated against the canonical schema. The overall crossstandard mapping coverage rate, the proportion of requirements
appearing in at least one mapping group, was 88.5 % (23 of 26). Coverage was not uniform across frameworks; the three unmapped requirements were source-specific controls without natural cross-standard counterparts, reflecting realistic correspondence rather than forced linkage. B. Decision Accuracy and Gap Detection Eleven case-study evaluations were performed. Eight returned compliant (72.7 %) and three returned partially compliant (27.3 %), consistent with the intentional evidence design. Against a predefined ground truth, the engine matched the expected status in all 11 cases (100 % ground-truth accuracy). All three intentionally introduced gaps were correctly identified (100 % gap detection), with each output record naming the specific missing evidence property. C. Traceability Every compliance determination retained an unbroken chain from the source clause, through the canonical requirement and the bound rule, to the specific evidence property evaluated (Figure 2). The chain is walkable in both directions, which is what distinguishes an output usable in an audit from a bare verdict: instead of reporting non-compliance, the system names the property that fell short and the clause requiring it. This supports audit and accountability functions that statistical security-monitoring systems do not provide. D. A Worked Determination One evaluation makes the mechanism concrete. Rule RULE-AC-01 is bound to three requirements drawn from three different standards: ISO/IEC 27001 Annex A 8.5 (secure authentication), NIST CSF 2.0 PR.AA-01, and Cyber Essentials CE-AC-01. Its condition set is CR = {(policy_approved, = , TRUE), (mfa_enabled, =, TRUE), (mfa_coverage_percent, ≥ , 90)}. The submitted evidence EV-AC-001 bundles three artefacts, an approved access control policy, an MFA configuration report, and an access log sample. Merging their properties yields policy_approved = TRUE, mfa_enabled = TRUE, and mfa_coverage_percent = 95. All three conditions hold, so k = n = 3, and by (2) the determination is COMPLIANT with s = 1.0 and G = ∅ (Table II). The significant point is what happened once: a single evidence submission was evaluated a single time, and it discharged obligations under three separate standards. The engine records this as three determinations, one per bound requirement, each carrying its own clause reference so that an ISO auditor and a Cyber Essentials assessor can each be answered from the same underlying evaluation. Removing that duplication is the practical case for a canonical layer. The contrasting case shows how a gap surfaces. Rule RULE-DP-02, bound to GDPR Article 32, requires encryption at rest, encryption in transit, and coverage of at least 95 %. The evidence reports the first two as true but coverage at 85 %, one database having been left pending an upgrade. Here k = 2, n = 3, so the determination is PARTIAL with s = 0.667 and
Fig. 2. The traceability chain retained by every determination, from the source clause through the canonical requirement and the applied rule to the evidence property evaluated and any gap named. Each link is stored, so a determination can be reconstructed after the fact by a party who was not present when it ran.
TABLE II A W ORKED D ETERMINATION FOR RULE RULE-AC-01 Element
Value
Bound requirements ISO/IEC 27001 A.8.5; NIST CSF PR.AA-01; CE-AC-01 Conditions CR policy_approved = true; mfa_enabled = true; mfa_coverage_percent ≥ 90 Evidence EV-AC-001 (3 artefacts) Observed values true; true; 95 Satisfied k/n 3/3 Determination COMPLIANT, s = 1.0 Gap set G ∅
TABLE III M APPING VALIDATION AGAINST NIST I NFORMATIVE R EFERENCES
F. Baseline Comparison To isolate the contribution of the canonical model, the framework was compared against two simpler baselines. A keyword-matching mapper, which links requirements by lexical overlap alone, recovered the curated cross-standard mappings poorly (F1 ≈ 0.30), confirming that naive text similarity cannot substitute for a curated canonical structure. A rule-only configuration, which evaluates evidence without the canonical mapping layer, achieved zero cross-standard traceability and produced no cross-standard mapping groups, against complete traceability and eight mapping groups for the full framework. These comparisons attribute the framework’s traceability and cross-standard capabilities specifically to the canonical model rather than to the rule engine alone. Table IV summarises the comparison. G. Adversarial Robustness
Outcome Exact agreement with NIST references Same-family divergence (not an error) Genuine mismatch
Count 4/7 (57.1 %) 3/7 0/7
G = {encryption_coverage_percent}. The output names the field, the observed value, and the threshold it missed, which is the difference between a finding an engineer can act on and a score. E. External Validation Two checks address the circularity inherent in evaluating a single-author artefact against its own ground truth. First, the framework’s CSF and ISO mappings were compared against NIST’s official informative references: 4 of 7 asserted mappings (57.1 %) matched exactly, with the three divergences resolving to controls within the same ISO family rather than to genuine errors (Table III). Second, the framework was applied to real, externally generated evidence from the OpenSSF Scorecard for the Prometheus project, where it correctly identified 8 of 10 controls as compliant and surfaced two genuine governance gaps: unresolved dependency vulnerabilities and unsigned releases. Neither reference was authored by the researcher, so agreement in the first case and gap discovery in the second provide evidence of validity that the controlled case study alone cannot.
A set of adversarial probes was applied to test the evaluation logic beyond its intended inputs. Two genuine limitations were surfaced: the engine does not currently distinguish absent evidence from failing evidence in numeric comparisons, and it accepts evidence that is declared but not substantiated. These findings bound the framework’s claims to declared compliance and motivate evidence authentication as future work; importantly, they were discovered through the evaluation rather than assumed away. Table V collects the results of all five criteria together with the two external checks. V. D ISCUSSION The results support a specific claim: that the governancedesign problem, translating heterogeneous requirements into a bounded, traceable, machine-interpretable model, can be solved in a way that is both automatable and externally checkable. This is distinct from, and prior to, the engineering problem of building a compliance scanner; the canonical model is the contribution, and the rule engine merely demonstrates that it is executable. Within the bounded scope, the lightweight canonical layer consolidated multi-standard requirements into a single interpretable model, automated repetitive checks, and surfaced cross-standard gaps while preserving traceability. The principal limitations are the bounded requirement set (26 items), the use of a simulated case study rather than production data, and a condition-based rule language that trades expressiveness for interpretability. These constrain external validity but are appropriate for establishing feasibility and design soundness.
TABLE IV F RAMEWORK VERSUS S IMPLER BASELINES Approach Keyword matching Rule-only (no canonical model) AspisAI (full)
Mapping F1
Traceability
Mapping groups
0.30 n/a curated
n/a 0.0 1.0
n/a 0 8
TABLE V S UMMARY OF E VALUATION R ESULTS (S IMULATION S COPE ) Criterion
Result
Requirement coverage (encoded) 26/26 (100 %) Cross-standard mapping coverage 23/26 (88.5 %) Rule decision accuracy (ground truth) 11/11 (100 %) Traceability completeness Complete Gap detection 3/3 (100 %) Mapping validity (vs. NIST refs) 4/7 (57.1 %) Real-evidence case (OpenSSF) 8/10, 2 gaps found
The single-author construction of the case study, in which rules, evidence, and ground truth share one author, means the controlled results should be read as evidence of functional correctness and internal consistency rather than of generalisation. This is precisely why the external checks of Section IV, mapping validation against NIST references and application to real OpenSSF evidence, carry the weight of the validity argument: they are the components an independent party did not author. A. Threats to Validity Four categories of threat apply, and each is stated with the mitigation actually taken rather than the one that would have been ideal. Construct validity. The five evaluation criteria were defined by the same author who designed the artefact, so they measure what the framework was built to do. This risks a benchmark that cannot fail. The mitigation is the pair of external reference points in Section IV: NIST’s published informative references and the OpenSSF Scorecard output, neither of which was authored here and neither of which was adjusted after the results were seen. Internal validity. Rules, evidence, and ground truth share one author, so agreement between the engine and the ground truth partly reflects shared assumptions rather than independent confirmation. The adversarial probes were introduced specifically to attack the engine from outside those assumptions, and they found two defects that the criteria had not surfaced. That the probes succeeded is itself evidence that the main evaluation was not adversarial enough on its own. External validity. The scope is 26 requirements from four standards, one simulated organisation, one sector. Nothing here supports a claim about full standard coverage, about production evidence at scale, or about sectors with different evidentiary
conventions. The synthetic case study also contains gaps that were placed deliberately, so gap detection demonstrates that the mechanism works and not that it would find gaps nobody had thought to introduce. Conclusion validity. Eleven determinations is far too few for statistical inference. The paper therefore reports counts and proportions, makes no significance claims, and attaches no confidence intervals to figures such as 88.5 % or 57.1 %; these describe the sample and nothing beyond it. Reliability is the one area where the design is strong: the rule engine is deterministic, so the reported results reproduce exactly from the accompanying artefact. The AI-assisted mapping component is not deterministic and its behaviour is reported separately for that reason. B. Future Work Four directions follow directly from the limitations. First, evaluation on real, multi-organisation data with independent annotators would establish ecological validity and inter-rater agreement. Second, the requirement set and standards coverage can be widened, including AI-specific obligations such as the EU AI Act [17]. Third, evidence authentication would close the declared-versus-substantiated gap identified by the adversarial probes. Fourth, the AI-assisted mapping component can be benchmarked at scale once provider access is stable, reporting accepted-mapping stability across repeated runs. VI. C ONCLUSION This paper presented AspisAI, a canonical, machineinterpretable governance framework for automated multistandard compliance monitoring. Evaluated on a simulated critical-infrastructure case study, the prototype demonstrated high coverage, accurate and traceable compliance decisions, and reliable gap detection within its scope. Future work includes evaluation on real organisational evidence, expansion of the requirement set and additional frameworks (e.g. NIS2, the NCSC CAF, IEC 62443), richer rule formalisms, and integration into CI/CD toolchains. ACKNOWLEDGMENT This work was supported partially by the European Union in the framework of ERASMUS MUNDUS, Project CyberMACS (Project #101082683) (https://cybermacs.eu). The first author thanks Franziska Schwarz for her guidance and support during this research.
R EFERENCES [1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
W. Wang, S. M. Sadjadi, and N. Rishe, “A survey of major cybersecurity compliance frameworks,” in 2024 IEEE 10th Conference on Big Data Security on Cloud (BigDataSecurity), IEEE, 2024, pp. 23–34. DOI: 10 . 1109/BigDataSecurity62737.2024.00013 M. Mubarkoot, J. Altmann, M. Rasti-Barzoki, B. Egger, and H. Lee, “Software compliance requirements, factors, and policies: A systematic literature review,” Computers and Security, vol. 124, p. 102 985, 2023. DOI: 10.1016/ j.cose.2022.102985 R. Bar-Haim et al., “Towards automated assessment of organizational cybersecurity posture in cloud,” in Proceedings of the 6th Joint International Conference on Data Science & Management of Data (10th ACM IKDD CODS and 28th COMAD), ser. CODS-COMAD ’23, Mumbai, India: Association for Computing Machinery, 2023, pp. 167–175, ISBN: 9781450397971. DOI: 10 . 1145/3570991.3571008 [Online]. Available: https://doi. org/10.1145/3570991.3571008 H. Haverinen, T. Janhunen, T. Päivärinta, S. Lempinen, S. Kaartinen, and S. Merilä, “Automating cybersecurity compliance in devsecops with open information model for security as code,” in Proceedings of the 4th Eclipse Security, AI, Architecture and Modelling Conference on Data Space, ser. eSAAM ’24, Mainz, Germany: Association for Computing Machinery, 2024, pp. 93–102, ISBN: 9798400709845. DOI : 10.1145/3685651.3686700 [Online]. Available: https://doi.org/10.1145/3685651. 3686700 F. Angermeir, J. Fischbach, F. Moyón, and D. Mendez, Towards automated continuous security compliance, 2024. arXiv: 2407.21494 [cs.SE]. [Online]. Available: https://arxiv.org/abs/2407.21494 A.-J. Aberkane, G. Poels, and S. V. Broucke, “Exploring automated gdpr-compliance in requirements engineering: A systematic mapping study,” IEEE Access, vol. 9, pp. 66 542–66 559, 2021. DOI: 10.1109/ACCESS.2021. 3076921 K. R. Boeckl and N. B. Lefkovitz, “NIST Privacy Framework: A tool for improving privacy through enterprise risk management, version 1.0,” National Institute of Standards and Technology, Gaithersburg, MD, Tech. Rep., 2020. DOI: 10.6028/NIST.CSWP.01162020 O. Klymenko, O. Kosenkov, S. Meisenbacher, P. Elahidoost, D. Mendez, and F. Matthes, “Understanding the implementation of technical measures in the process of data privacy compliance: A qualitative study,” in Proceedings of the 16th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement, ser. ESEM ’22, Helsinki, Finland: Association for Computing Machinery, 2022, pp. 261–271, ISBN: 9781450394277. DOI : 10.1145/3544902.3546234 [Online]. Available: https://doi.org/10.1145/3544902. 3546234
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
O. A. Cejas, M. I. Azeem, S. Abualhaija, and L. C. Briand, “Nlp-based automated compliance checking of data processing agreements against gdpr,” IEEE Transactions on Software Engineering, vol. 49, no. 9, pp. 4282–4303, 2023. DOI: 10.1109/TSE.2023.3288901 European Parliament and Council of the European Union, Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the union (NIS2 directive), Official Journal of the European Union, L 333, pp. 80–152, 2022. [Online]. Available: https://eurlex.europa.eu/eli/dir/2022/2555/oj/eng J. Ruohonen, A systematic literature review on the nis2 directive, 2026. arXiv: 2412.08084 [cs.CR]. [Online]. Available: https://arxiv.org/abs/2412.08084 F. Romeo, L. Arena, F. Blefari, F. A. Pironti, M. Lupinacci, and A. Furfaro, “Arpaccino: An agenticrag for policy as code compliance,” in New Trends in Database and Information Systems. Springer Nature Switzerland, Sep. 2025, pp. 467–481, ISBN: 9783032057273. DOI: 10.1007/978-3-032-05727-3_39 [Online]. Available: http://dx.doi.org/10.1007/978-3032-05727-3_39 J. Schöning and N. Kruse, Compliance of ai systems, 2026. arXiv: 2503.05571 [cs.CY]. [Online]. Available: https://arxiv.org/abs/2503.05571 B. Marino et al., Compliance cards: Automated eu ai act compliance analyses amidst a complex ai supply chain, 2024. arXiv: 2406.14758 [cs.AI]. [Online]. Available: https://arxiv.org/abs/2406.14758 K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A design science research methodology for information systems research,” Journal of Management Information Systems, vol. 24, no. 3, pp. 45–77, 2007. DOI: 10.2753/MIS0742-1222240302 [Online]. Available: https://doi.org/10.2753/MIS0742-1222240302 A. R. Hevner, S. T. March, J. Park, and S. Ram, “Design science in information systems research,” MIS Quarterly, vol. 28, no. 1, pp. 75–105, 2004. DOI: 10.2307/25148625 European Parliament and Council of the European Union, Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (artificial intelligence act), Official Journal of the European Union, 2024. [Online]. Available: https://eur-lex.europa.eu/eli/reg/2024/1689/oj