Regulation: EU AI Act: Art. 13, 14 and 15 mappings (deployer_instructions.md, forgelm approve staging gate as 'Article 14', model_integrity.json) (aging) (TECH-T10-012) #461

Wave 1 · theme D1-9: Compliance mappings and marketing language · highest severity High · 14 finding(s) · effort not estimated

Summary

The pre-release approval gate is a provider release control. It can support the Annex IV 2(e) human-oversight assessment, but it is not Art. 14 in-use oversight, so 'Article 14 ... gate' overreaches. The Art. 13 and Art. 15 mappings are reasonable as supporting evidence, but they predate the Art. 42(3) CRA presumption.

Primary finding

TECH-T10-012 — Regulation: EU AI Act: Art. 13, 14 and 15 mappings (deployer_instructions.md, forgelm approve staging gate as 'Article 14', model_integrity.json) (aging)

severity Watch

Item. Art. 13, 14 and 15 mappings (deployer_instructions.md, forgelm approve staging gate as 'Article 14', model_integrity.json) · verdict: aging · urgency: Watch

State in ForgeLM. README.md:117 lists an 'Article 14 human-oversight staging gate (forgelm approve, exit 4)'. The compliance guides map deployer_instructions.md to Art. 13 and model_integrity.json to Art. 15. Nothing mentions the new CRA route to an Art. 15 presumption.

State of the ecosystem on 2026-10-01. The text of Arts 13, 14 and 15 is unamended. Art. 14(1) requires that high-risk systems 'can be effectively overseen by natural persons during the period in which they are in use'. The Commission AI Act page (retrieved 2026-10-01) states that once a system is on the market 'deployers ensure human oversight and monitoring'. Reg. 2026/1744 Art. 1(18) adds Art. 42(3): high-risk systems within the scope of the Cyber Resilience Act (Reg. (EU) 2024/2847) that meet its Art. 12(1) conditions 'shall be deemed to comply with the cybersecurity requirements set out in Article 15'.

Impact. The pre-release approval gate is a provider release control. It can support the Annex IV 2(e) human-oversight assessment, but it is not Art. 14 in-use oversight, so 'Article 14 ... gate' overreaches. The Art. 13 and Art. 15 mappings are reasonable as supporting evidence, but they predate the Art. 42(3) CRA presumption.

Recommendation. Describe the gate as 'human release approval (supports Art. 14 design evidence / Annex IV 2(e))'. Note that Art. 14 oversight in use belongs to the deployer. In the Art. 15 docs, mention that cybersecurity conformity can be presumed through CRA conformity (Art. 42(3)).

Sources.

• Regulation (EU) 2024/1689, Arts 13-15 (2024-07-12)
• Regulation (EU) 2026/1744, Art. 1(18) (new Art. 42(3)) (2026-07-24)
• European Commission: AI Act page ('deployers ensure human oversight and monitoring') (2026-08-03)

Other findings with the same root cause

These close with the same fix; update them in the same pull request.

• DOC-BLEGAL-031 (docs, High) — docs/usermanuals/en/getting-started/first-run.md: wrong detail — README.md ← Article 13 model card
  severity High
  Where. docs/usermanuals/en/getting-started/first-run.md:171 (Turkish mirror: docs/usermanuals/tr/getting-started/first-run.md:171) · type: wrong detail
  The document says. README.md ← Article 13 model card
  What the code does. Art. 13(2)-(3) requires instructions for use with provider identity and contact; characteristics, capabilities and limitations, including intended purpose, accuracy metrics and foreseeable risks; pre-determined changes; human-oversight measures; compute resources and maintenance; and log collection. The HF README model card lacks most of these and is not an Art. 13 artefact. ForgeLM's Art. 13 art…
  Proposed correction. Label README.md as 'HF model card' and add the deployer-instructions file with '← Article 13 instructions for use (deployer_instructions.md)'. TR: 'README.md ← HF model card' and 'deployer_instructions.md ← Madde 13 kullanım talimatları'.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-032 (docs, High) — docs/usermanuals/en/reference/configuration.md: misleading — require_human_approval: false # Article 14: pause the pipeline for human review (exit 4)
  severity High
  Where. docs/usermanuals/en/reference/configuration.md:138 (Turkish mirror: docs/usermanuals/tr/reference/configuration.md:139) · type: misleading
  The document says. require_human_approval: false # Article 14: pause the pipeline for human review (exit 4)
  What the code does. Art. 14(1) requires high-risk systems to be designed so that natural persons can oversee them effectively 'during the period in which they are in use'. Art. 14(4) lists the in-use capabilities the overseer must have: understand, monitor, interpret, override and stop. A one-time, pre-release sign-off on a training checkpoint is a provider-side release control (QMS Art. 17(1)(b)-(d)), not Art. 14 o…
  Proposed correction. '# Pre-release human sign-off (QMS release control; supports, but does not implement, Art. 14 in-use oversight)'. TR: '# Yayın öncesi insan onayı (KYS yayın kontrolü; Madde 14 kullanım-anı gözetimini desteklemez/yerine getirmez)'.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-035 (docs, High) — docs/usermanuals/en/reference/yaml-templates.md: misleading — require_human_approval: true # Article 14 oversight gate
  severity High
  Where. docs/usermanuals/en/reference/yaml-templates.md:103 (Turkish mirror: docs/usermanuals/tr/reference/yaml-templates.md:104) · type: misleading
  The document says. require_human_approval: true # Article 14 oversight gate
  What the code does. Art. 14 concerns oversight of a high-risk system by natural persons while it is in use, with the capabilities in Art. 14(4) and deployer assignment under Art. 26(2). ForgeLM's pre-release approval of a fine-tuned checkpoint is a provider release and design-verification control, not an Art. 14 oversight measure.
  Proposed correction. '# pre-release human sign-off gate (not Art. 14 in-use oversight)'. TR: '# yayın öncesi insan onay kapısı (Madde 14 kullanım-anı gözetimi değildir)'.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-036 (docs, High) — docs/usermanuals/en/training/dpo.md: misleading — require_human_approval: true # Article 14 oversight gate
  severity High
  Where. docs/usermanuals/en/training/dpo.md:186 (Turkish mirror: docs/usermanuals/tr/training/dpo.md:172) · type: misleading
  The document says. require_human_approval: true # Article 14 oversight gate
  What the code does. A provider's pre-release approval of a training checkpoint matches none of the Art. 14(4)(a)-(e) overseer capabilities, which apply 'during the period in which they are in use'. It is a QMS design-verification and release control (Art. 17(1)(b)-(d)) and supports Annex IV documentation.
  Proposed correction. '# pre-release human sign-off (QMS release control, not Art. 14 in-use oversight)'. TR: '# yayın öncesi insan onayı (KYS yayın kontrolü; Madde 14 gözetimi değildir)'.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-043 (docs, High) — site/features.html: misleading — Article 14 staging gate — forgelm approve / forgelm reject + forgelm approvals implement the human-oversight staging directory with audit-stamped sign-off.
  severity High
  Where. site/features.html:412-413 (Turkish mirror: site/js/translations.js:1138-1139) · type: misleading
  The document says. Article 14 staging gate — forgelm approve / forgelm reject + forgelm approvals implement the human-oversight staging directory with audit-stamped sign-off.
  What the code does. Art. 14(1) requires oversight by natural persons 'during the period in which they are in use', with the Art. 14(4) capabilities, and Art. 26(2) requires deployers to assign competent overseers. A one-time pre-release approval of a fine-tuned checkpoint is a provider release and design-verification control, not Art. 14 human oversight.
  Proposed correction. Title 'Pre-release approval gate'. Body '… implement a pre-release human sign-off staging directory with audit-stamped decisions (supports QMS release control; Art. 14 in-use oversight remains a system/deployer design duty).' Fix translations.js:1033-1034 (EN), 1138-1139 (TR), 4474-4475 (DE), 4520-4521 (FR), 4566-4567 (ES) and 4612-4613 (ZH) too.

• DOC-BLEGAL-061 (docs, Medium) — config_template.yaml: misleading — require_human_approval: false # Article 14: pause + stage the model for human sign-off (exit code 4)
  severity Medium
  Where. config_template.yaml:181 · type: misleading
  The document says. require_human_approval: false # Article 14: pause + stage the model for human sign-off (exit code 4)
  What the code does. Art. 14 concerns in-use oversight by natural persons (14(1), 14(4)); a pre-release checkpoint sign-off is a QMS release control. RQ-059 judged this citation current, relying on Art. 14(3)(a) (measures built in by the provider before placing on the market). But a sign-off on a training checkpoint is not a measure built into the system, and RQ-073, RQ-283, RQ-654 and RQ-295 judge the same mapping i…
  Proposed correction. '# pre-release human sign-off (QMS release control; supports Art. 14 documentation, not in-use oversight) — exit code 4'.

• DOC-BLEGAL-075 (docs, Medium) — docs/guides/human_approval_gate.md: misleading — EU AI Act Article 14 requires high-risk AI systems to permit effective human oversight throughout their lifecycle. ForgeLM implements this as a co…
  severity Medium
  Where. docs/guides/human_approval_gate.md:3-7 (Turkish mirror: docs/guides/human_approval_gate-tr.md:3-7) · type: misleading
  The document says. EU AI Act Article 14 requires high-risk AI systems to permit effective human oversight throughout their lifecycle. ForgeLM implements this as a config-driven gate that pauses model promotion
  What the code does. Art. 14(1): high-risk AI systems shall be designed and developed so 'that they can be effectively overseen by natural persons during the period in which they are in use'. The scope is the period of use, not the lifecycle; 'lifecycle' is Art. 9(2)/Art. 72 language. Art. 14(3)-(4) concern operational oversight: understanding capacities, automation bias, interpreting output, overriding and stopping…
  Proposed correction. 'EU AI Act Article 14 requires high-risk AI systems to be designed so natural persons can effectively oversee them while they are in use. ForgeLM's config-driven gate adds a pre-deployment human sign-off recorded in the tamper-evident audit chain; it is supporting evidence, not the in-use oversight Art. 14 requires of the deployed system.' Mir…
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-086 (docs, Medium) — docs/product_strategy.md: misleading — "Art. 15 Accuracy & Robustness → model_integrity.json + safety evaluation results"
  severity Medium
  Where. docs/product_strategy.md:37 (Turkish mirror: docs/product_strategy-tr.md:37) · type: misleading
  The document says. "Art. 15 Accuracy & Robustness → model_integrity.json + safety evaluation results"
  What the code does. Art. 15(1)-(5) requires appropriate accuracy, robustness and cybersecurity: declared accuracy metrics (15(3)), resilience to errors and feedback loops (15(4)), and resilience to poisoning and adversarial attacks (15(5)). A SHA-256 checksum manifest is at most a supporting cybersecurity/integrity measure (Annex IV 2(h)). It is not accuracy or robustness evidence.
  Proposed correction. 'Art. 15 → benchmark/safety evaluation results (accuracy, robustness evidence); model_integrity.json supports artefact integrity (cybersecurity, Annex IV 2(h))'.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-091 (docs, Medium) — docs/qms/access_control.md: false claim — Article 14 staging requires the approving operator to be different from the training operator (segregation of duties — ISO A.5.3, SOC 2 CC1.5):
  severity Medium
  Where. docs/qms/access_control.md:179-181 (Turkish mirror: docs/qms/access_control-tr.md:182-183) · type: false claim
  The document says. Article 14 staging requires the approving operator to be different from the training operator (segregation of duties — ISO A.5.3, SOC 2 CC1.5):
  What the code does. Art. 14 (unamended) requires that high-risk systems can be effectively overseen by natural persons 'during the period in which they are in use'. It sets no rule that the approver differ from the trainer. Its only multi-person rule is Art. 14(5), for remote biometric identification at use time. SOC 2 CC1.5 is accountability; segregation sits in CC5.1, CC6.3 and CC8.1. The CC1.5 entry in the header…
  Proposed correction. ForgeLM's staging gate supports segregation of duties: deployers should require the approving operator to differ from the training operator (ISO A.5.3; SOC 2 CC5.1 / CC6.3 / CC8.1). This is an organisational control; EU AI Act Article 14 does not itself impose it.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-122 (docs, Medium) — docs/usermanuals/en/compliance/model-card.md: wrong detail — EU AI Act Article 13 requires transparency: deployed AI systems must be accompanied by clear documentation of capabilities, limitations, i…
  severity Medium
  Where. docs/usermanuals/en/compliance/model-card.md:8 (Turkish mirror: docs/usermanuals/tr/compliance/model-card.md:8) · type: wrong detail
  The document says. EU AI Act Article 13 requires transparency: deployed AI systems must be accompanied by clear documentation of capabilities, limitations, intended use, and training data.
  What the code does. Art. 13 applies only to high-risk AI systems, not to 'deployed AI systems' in general. It requires instructions for use for deployers, with the minimum content in 13(3). Training data appears only conditionally, at 13(3)(b)(vi) ('when appropriate, specifications for the input data ...').
  Proposed correction. EU AI Act Article 13 requires high-risk AI systems to be accompanied by instructions for use covering, among other things, the provider's identity, the system's intended purpose, capabilities and limitations, and (when appropriate) input-data specifications.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-124 (docs, Medium) — docs/usermanuals/en/compliance/overview.md: wrong detail — | 15 | Accuracy & robustness | Benchmark gates + safety eval + cybersecurity (PII / secrets at ingest). |
  severity Medium
  Where. docs/usermanuals/en/compliance/overview.md:77 (Turkish mirror: docs/usermanuals/tr/compliance/overview.md:77) · type: wrong detail
  The document says. | 15 | Accuracy & robustness | Benchmark gates + safety eval + cybersecurity (PII / secrets at ingest). |
  What the code does. Art. 15(5) cybersecurity means resilience against unauthorised third parties altering use, outputs or performance: data poisoning, model poisoning, adversarial examples, confidentiality attacks. PII/secret masking at ingest is a data-protection and data-governance measure: GDPR Art. 5(1)(c),(f), AI Act Art. 10(2)(c) and Art. 4a(1)(b).
  Proposed correction. | 15 | Accuracy & robustness | Benchmark gates + safety eval. (PII / secrets masking at ingest is a data-governance measure — Art. 10 / GDPR Art. 5 — not Art. 15 cybersecurity.) |
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-147 (docs, Medium) — docs/usermanuals/en/reference/json-output.md: misleading — a training run halted at the Article 14 human-approval gate ... / true iff the run halted at the Article 14 human-approval gate (exit 4)
  severity Medium
  Where. docs/usermanuals/en/reference/json-output.md:17,186 (Turkish mirror: docs/usermanuals/tr/reference/json-output.md:17,186) · type: misleading
  The document says. a training run halted at the Article 14 human-approval gate ... / true iff the run halted at the Article 14 human-approval gate (exit 4)
  What the code does. Art. 14 concerns oversight of the high-risk system while it is in use (14(4)(a)-(e)). A pre-promotion approval of a model artefact is a design and change-control measure under Art. 17(1)(a)/(b)/(d), which can be documented under Annex IV 2(e). It is not Art. 14 human oversight.
  Proposed correction. a training run halted at the human-approval (promotion) gate ...
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-159 (docs, Medium) — site/index.html: wrong detail — "require_human_approval: true # Article 14 oversight gate"
  severity Medium
  Where. site/index.html:580 · type: wrong detail
  The document says. "require_human_approval: true # Article 14 oversight gate"
  What the code does. AI Act Art. 14(1) requires that high-risk systems 'can be effectively overseen by natural persons during the period in which they are in use', and Art. 14(4)(a)-(e) lists in-use capabilities (monitor, interpret, override, stop). A pre-release approval step is a change/release-control measure that fits Art. 17(1)(a) (management of modifications). It is not the Art. 14 oversight measure. The Commis…
  Proposed correction. '# human release-approval gate (change control, Art. 17(1)(a); supports, does not replace, Art. 14 in-use oversight)'

Acceptance criteria

• Each statement is re-checked against the code at fix time.
• Documentation listed above is corrected in English and in its Turkish mirror in the same PR.
• Every finding in this issue is resolved or explicitly closed with a reason.

_{Found by the October 2026 ForgeLM code and documentation review against commit cab2947. Code links point at that commit; line numbers may have moved since. Finding IDs (CR-…, DOC-…, TECH-…) are stable references for this backlog.}