# The AI Act from an engineer's desk: Articles 12-15

> Human oversight, accuracy, robustness, cybersecurity. What AI Act Articles 12, 13, 14, 15 actually require of a high-risk system, in engineering terms.

- URL: https://artcode.software/blog/2026-07-08-ai-act-articles-12-15-practical-guide
- Author: Artur Kluz, Founder, AI architect (https://www.linkedin.com/in/arturkluz/)
- Published: 2026-07-08
- Updated: 2026-10-16
- Language: en
- Tags: ai-act, compliance, regulated-industries, high-risk-ai
- Publisher: ArtCode Software (https://artcode.software)

The AI Act (Regulation 2024/1689) is a very long text. Most engineering teams I work with have read the executive summary and stopped. The result is architecture reviews where nobody can tell whether the system is high-risk and nobody knows which articles apply to the deployment pipeline. This post is a working reference for the four articles that bite hardest on day-to-day engineering: **Article 12** (logging), **Article 13** (transparency), **Article 14** (human oversight), **Article 15** (accuracy, robustness, cybersecurity).

**In short.** Four AI Act articles hit engineering hardest: Article 12 requires automatic event logging, Article 13 instructions for deployers, Article 14 effective human oversight, and Article 15 accuracy, robustness and cybersecurity. A small team can cover them with a Postgres log table, a `model-card.md`, a reviewer console and tests in CI.

## Who this applies to

These four articles sit in **Chapter III, Section 2** of the AI Act: "Requirements for high-risk AI systems." Before they apply, your system must be classified as high-risk under Article 6 and Annex III. Most AI used in regulated industries (credit scoring, insurance underwriting, clinical documentation, biometric identification, recruitment screening, safety components in critical infrastructure) ends up in Annex III. The four articles apply to **providers** placing a high-risk system on the EU market and to **deployers** using one. If you build AI into your own product and your customers deploy it, you are typically a provider. If you integrate a third-party model into your own business process (an insurer using a vendor's underwriting tool), you are typically a deployer. Both roles have different obligations on these articles.

## Article 12 - Automatic logging

Article 12 requires that high-risk AI systems "automatically record events (logs) over the duration of the system's lifecycle." Six categories must be captured for every operational event: the technical specification of the system at the time of the event (model version, weights checksum, prompt template version, tool schema, retrieval index version); the input data the system processed (prompt or a stable hash plus raw prompt under retention rules, retrieved documents, attached files); the output the system produced (full model response including refusal cases and intermediate tool calls); identification of natural persons involved (the user account that triggered inference, the operator who approved a high-risk decision, the reviewer who overrode a recommendation); date and timestamp with UTC sub-second precision; and reference to the database or data source consulted (retrieval hits, knowledge graph nodes, vector store chunk IDs). The minimum log retention is six months (Article 19(1), not Article 12), unless other law provides otherwise. Logs must be "made available on request to competent authorities." This is the article that breaks most cloud LLM wrappers: a chat API returning a response and an HTTP 200 does not give you logs that satisfy it. The receiving system has to capture and store them itself.

## Article 13 - Transparency and information to deployers

Article 13 requires that high-risk systems come with instructions for use containing "concise, complete, correct, and clear information" relevant, accessible, and comprehensible to deployers. Twelve items are listed in Article 13(3). Engineering teams most often miss: identity and contact details of the provider (single name, email, physical address); characteristics, capabilities, and limitations of the system (known failure modes, performance metrics disaggregated by the demographic or contextual variables that matter for the use case); the declared accuracy, robustness, and cybersecurity (which must match Article 11 technical documentation and Article 72 post-market monitoring); the foreseeable misuse risks (you must enumerate the misuse cases you considered, not only intended uses); and the level of human oversight required (Article 14 interlock; vague language fails an audit).

In a SPA this is a `/transparency` route, in a CLI a `tool model-info` command, in an API integration a JSON document linked from the deployer's contract documentation. For deployers, Article 13 maps to a confirmation step: the vendor gives you this document and you keep it on file. If they do not, that is a gap in your supplier risk assessment under NIS2 Article 21 and DORA Article 28.

## Article 14 - Human oversight

Article 14 requires that high-risk systems be "designed and developed... in such a way... that they can be effectively overseen by natural persons during the period in which they are in use." Five required properties are listed:

1. **Natural persons can understand the system's behaviour.** Not just see the output: trace the reasoning path, retrieved context, tool calls, prompt.
2. **Operators can decide when to use the system and when to override.** Override paths have to be in the UI, not the source code.
3. **Operators can intervene or interrupt.** A kill switch at the request level, not just a deployment rollback.
4. **Operators can refuse using the system in a particular situation.** A confidence score alone does not satisfy this; the operator has to be able to refuse the output explicitly.
5. **Awareness of automation bias.** The system design must enable operators to know they are interacting with AI and avoid over-relying on its output.

Engineering deliverables are concrete: a reviewer console with input, retrieved context, model response, and a required decision field; a confidence-or-equivalent metric on every output; an override taxonomy with stable codes (approve, modify, reject, escalate) and a log entry for each; and an automated bias warning in the UI at intervals defined by usage patterns. The five properties require operational design, not just a model card entry: this is what distinguishes deployers who are operationally compliant from those who only have documentation.

## Article 15 - Accuracy, robustness, cybersecurity

Article 15 bundles three distinct properties under one article. **Accuracy** (15(1)) requires "an appropriate level of accuracy" for the intended purpose; Article 15(4) requires it to be declared in the instructions for use. The required measurements at minimum are task-level accuracy on a held-out test set representative of the deployed distribution, calibration error, and segment accuracy on the dimensions that matter for the regulated decision; a single global F1 does not satisfy. **Robustness** (15(1) and 15(4)) requires resilience to errors, faults, and inconsistencies, plus "technical and organisational measures" against foreseeable misuse. Three engineering tracks feed this: red-teaming and adversarial testing of prompts, fault injection during inference (model dropout, retrieval backend unavailable, partial context), and behavioural tests against known model-failure modes. **Cybersecurity** (15(1) and (15(5))) requires protection against "unauthorised access, manipulation, and adversarial examples"; for general-purpose models integrated into a high-risk system, the model and the system satisfy these properties together. Practical controls: signed prompts and responses, input validation at the boundary, model artefact integrity verification on load, egress controls, and the standard NIS2-aligned controls at every integration point.

## What goes wrong in practice

Six patterns recur in the architectural reviews I do.

1. **Logging without the model version.** Logs are captured, but the weights checksum is not. The result is unverifiable under Article 12(1)(a).
2. **Accuracy claims on a training distribution, not a deployment distribution.** A test set built from the training data is not evidence under Article 15(4).
3. **Human oversight as a UI checkbox.** Reviewers can mark "approved" but cannot read the retrieved context. Article 14(1) requires understanding, not just acknowledgement.
4. **Transparency document maintained by legal, never updated by engineering.** The document drifts from the system; in a conformity assessment this is a finding.
5. **No override logging at the deployer side.** The override event happens in the UI but is not captured in the audit trail. Article 12 covers this implicitly; missing entries fail an audit.
6. **Robustness tested once, at launch.** Article 15 expects continued testing. Post-market monitoring under Article 72 makes this an ongoing obligation.

None of these are exotic edge cases. They are the modal failures of regulated SMEs preparing for their first AI audit.

## What good looks like for a small team

You do not need a dedicated platform team for Articles 12 to 15 if you start with the right components. A single Postgres table with a stable JSON schema covers Article 12 logging. A `model-card.md` in the repo, mirrored as a `/transparency` page and a PDF for procurement, covers Article 13. A small reviewer console with an explicit override taxonomy covers Article 14. A standardised test harness (Ragas, promptfoo, or pytest with held-out fixtures) wired into CI covers Article 15.

ArtCode Software ships this exact baseline to regulated Polish SMEs. The result survives a procurement cycle and is the technical-file basis for a conformity assessment under Article 43.

If you need a fixed-scope diagnostic of where you stand on these four articles, the [AI Readiness Audit](/#zalacznik-1) maps each article to the artefacts present or missing in your current system. If you want to design the architecture before writing a line of code, an AI architect embedded in your engineering process one day a week helps bring the implementation plan to a state that can be reviewed. The scope of such work is described in the [offer](/#oferta).