Module 5 — Logging, Instructions and Oversight by Design (Art. 12-14)

Module 5 of the AI Act Provider certification: automatic record-keeping under Art. 12, the instructions for use required by Art. 13, and designing a system a human can actually oversee under Art. 14.

These three articles are where the provider's obligations meet the deployer's. Everything a deployer owes under Art. 26 depends on what you built and what you told them. A deployer who cannot keep logs because the system does not produce them, or cannot oversee because the interface exposes nothing, has a problem that originates in your product.

Art. 12 — automatic record-keeping

High-risk systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.

The logging capability must provide for the recording of events relevant for:

• identifying situations that may result in the system presenting a risk within the meaning of Art. 79(1), or in a substantial modification;
• facilitating the post-market monitoring referred to in Art. 72;
• monitoring the operation of high-risk systems by deployers as referred to in Art. 26(5).

Three design consequences.

Logging is a product requirement, not an operations concern. It is in Chapter III Section 2 alongside accuracy and cybersecurity. A system that cannot produce these records is non-conforming, and the defect is not curable by the deployer's infrastructure.

"Over the lifetime of the system" means the capability persists, not that you retain forever. Retention is the deployer's Art. 26(6) duty — at least six months, to the extent the logs are under their control. If you host, control is yours in fact, which makes an export capability a contractual and practical necessity.

Substantial modification is a logged event class. Design the records so that a change affecting Chapter III compliance is visible in them, because that is what Art. 12 asks the logs to help identify.

For Annex III point 1 systems, Art. 12(3) sets a minimum: the period of each use (start and end date and time); the reference database against which input data has been checked; the input data for which the search led to a match; and the identification of the natural persons involved in the verification of the results under Art. 14(5).

Art. 13 — transparency to deployers, and the instructions for use

High-risk systems shall be designed and developed so their operation is sufficiently transparent to enable deployers to interpret the output and use it appropriately, and shall be accompanied by instructions for use.

The instructions must contain, among other things:

• the identity and contact details of the provider and its authorised representative;
• the characteristics, capabilities and limitations of performance, including its intended purpose; the level of accuracy, including its metrics, robustness and cybersecurity against which it has been tested and validated; any known or foreseeable circumstance which may impact those; where appropriate, its performance regarding specific persons or groups on which it is intended to be used; and, where appropriate, specifications for the input data or other relevant information in terms of the training, validation and testing datasets used;
• when appropriate, information to enable deployers to interpret the output and use it appropriately;
• any changes to the system and its performance predetermined by the provider at the moment of the initial conformity assessment;
• the human oversight measures referred to in Art. 14, including the technical measures put in place to facilitate the interpretation of outputs by deployers;
• the computational and hardware resources needed, expected lifetime and necessary maintenance and care measures, including their frequency;
• where relevant, a description of the mechanisms allowing deployers to properly collect, store and interpret the logs.

That last bullet is the one that determines whether your customers can meet Art. 26(6).

Three practical points.

Write it as a control. Art. 9(5) makes information to deployers the third tier of risk management. Every residual risk you decided to manage by telling the deployer should be traceable to a passage here.

Declared performance is a commitment. Whatever accuracy figure appears in the instructions is the figure your deployers will monitor against under Art. 26(4), and the figure a market surveillance authority will test against. State the conditions.

Predetermined changes must be declared up front. A system designed to continue learning after deployment must have that behaviour and its bounds described at the initial conformity assessment — otherwise a later change looks like an undeclared substantial modification.

Art. 14 — oversight has to be designed in

High-risk systems shall be designed and developed, including with appropriate human-machine interface tools, such that they can be effectively overseen by natural persons during the period in which they are in use.

The measures shall be commensurate with the risks, level of autonomy and context of use, and are ensured through either or both of: measures identified and built into the system by the provider before it is placed on the market; and measures identified by the provider before placing on the market and which are appropriate to be implemented by the deployer.

Art. 14(4) then sets what oversight persons must be enabled to do — the checklist Module 3 of the Deployer track examines from the other side:

• understand the relevant capacities and limitations of the system and duly monitor its operation, including to detect and address anomalies, dysfunctions and unexpected performance;
• remain aware of automation bias, in particular for systems providing information or recommendations for decisions to be taken by natural persons;
• correctly interpret the output, taking into account the interpretation tools and methods available;
• decide not to use the system, or otherwise disregard, override or reverse the output;
• intervene in the operation or interrupt the system through a stop button or similar procedure allowing it to halt in a safe state.

For Annex III point 1 systems, Art. 14(5) adds that no action or decision may be taken on the basis of the identification unless separately verified and confirmed by at least two natural persons with the necessary competence, training and authority — with narrow carve-outs for certain law enforcement, migration, border control and asylum contexts.

Designing against automation bias

The Regulation names automation bias as something oversight persons must remain aware of. As a provider you are the party who can design for or against it, and the design choices are not subtle:

• Surface uncertainty. A bare verdict invites deference; a calibrated confidence changes behaviour.
• Make dissent cheap. If accepting is one click and overriding is a form, your override rate goes to zero and your deployer fails Art. 26(2) using your product as intended.
• Expose the basis. Element 3 of Annex IV and Art. 13 both ask about interpretation tools; they are the same capability seen from two articles.
• Instrument the override. A system that reports its own override rate hands the deployer the single best evidence that oversight is live. It costs little and it differentiates the product.

Check yourself

1. Our customer's SIEM captures everything; do we need Art. 12 logging? — Yes. Art. 12 is a product requirement in Chapter III Section 2; the deployer's telemetry is not a substitute and cannot make a non-conforming system conform.
2. Our instructions are a sales datasheet plus an API reference. — Art. 13 requires the accuracy metrics, limitations, oversight measures and log-handling mechanisms. Without them your deployers cannot satisfy Art. 26.
3. Our system continuously learns after deployment. — Declare that behaviour and its bounds at the initial conformity assessment, per Art. 13, or later change will read as an undeclared substantial modification.
4. Oversight is the deployer's problem. — Art. 14 is a design duty on the provider. If the interface exposes no override and no stop, the defect is yours.

Previous: Module 4 — Technical documentation (Art. 11 and Annex IV) Next: Module 6 — Accuracy, robustness, cybersecurity, and the QMS →