“We Need Article 12 Logs Before Review.” Which Evidence Belongs to the Provider—and Which to the Deployer?
Separate EU AI Act Article 12 automatic-recording design from deployer log control and retention before scoping an AI logging evidence request.
Signals to watch
- A named AI system is approaching conformity, procurement or deployment review and the team says only that Article 12 logs are missing
- Provider-side event design and deployer-side retention have been assigned to one vendor without confirming who controls each record
- The request names a review date but leaves high-risk classification, intended purpose and the exact logged events unresolved
An Article 12 logging request has two different evidence owners. The provider must show how a high-risk AI system technically records events automatically and why those events support traceability for the intended purpose. The deployer must show which automatically generated logs are under its control and how it keeps them. A request that says only “we need the Article 12 logs” has not yet defined the work.
That is the first answer an AI governance or observability provider’s business-development lead needs when reading authorised model-provider, enterprise-AI and regulated-industry Telegram groups. The message becomes commercially relevant when it names a system, a review event and a concrete gap in recording, export, integrity, access or retention. After the conformity or procurement team selects an architecture, the logging owner may no longer be able to change the evidence path before review.
Definition: Article 12 is a high-risk-system design requirement
Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, does not impose Article 12 on every piece of software marketed as AI. Article 12 sits in the requirements for high-risk AI systems. Classification depends on the system and intended purpose under Article 6 and the Act’s relevant annexes and rules.
Article 12 requires high-risk AI systems to technically allow the automatic recording of events—called logs—over the system’s lifetime. The logging capability must make it possible to record events relevant to identifying situations that may create a risk or substantial modification, facilitate post-market monitoring, and monitor operation of specified high-risk systems. The degree of traceability must be appropriate to the intended purpose.
Why this matters: a generic infrastructure log can be operationally useful without proving that the high-risk system records the events needed for its legal and safety context. Conversely, Article 12 does not say every internal event must be retained forever.
First owner: the provider designs the automatic record
The provider controls the system definition, intended purpose and design evidence. Its Article 12 record should connect four layers.
System boundary. Which released system and version is being assessed? A model endpoint, a workflow that combines several components and a human-decision tool may have different event boundaries. “Our platform” is not precise enough.
Event catalogue. Which events are recorded automatically? Useful entries might include version, input route, output or decision identifier, human-oversight intervention, error state and material configuration change. The correct catalogue depends on the intended purpose; this list is an example, not a legal minimum.
Traceability purpose. For each event, state which investigation, monitoring or risk question it helps answer. A long list of fields without a traceability purpose is inventory, not a reasoned logging design.
Integrity and access. Show how events receive timestamps and identifiers, how changes are controlled, how authorised people retrieve them and which limitations remain. A screenshot of a dashboard may demonstrate visibility but not export completeness or integrity.
Certain remote biometric identification systems have additional Article 12(3) content requirements, including recording the period of use, reference database, input data that led to a match and the people involved in verification. That specialised paragraph should not be copied into an unrelated high-risk credit or employment system.
Second owner: the deployer controls use and retention
Article 19 gives the deployer a different duty. Deployers of high-risk AI systems must keep logs automatically generated by the system to the extent those logs are under their control. The period must be appropriate to the intended purpose and at least six months, unless applicable Union or national law—particularly personal-data law—provides otherwise.
The phrase “under their control” prevents a consultant from assuming the deployer can retrieve every provider-side event. The handoff must show:
- which log streams reach the deployer’s environment;
- which remain controlled by the provider or another processor;
- who can access and export each stream;
- when the retention clock begins;
- which retention setting is active, rather than merely available;
- which legal or operational reason changes the period; and
- how the deployer connects a log to an actual use event.
The provider may also have its own documentation and record-keeping duties elsewhere in the Act. Do not replace role analysis with the slogan “six months for everyone.”
The two-owner evidence map
The original contribution here is a small map with one row per proof question:
| Proof question | Provider evidence | Deployer evidence | Still unknown |
|---|---|---|---|
| What system is in scope? | Intended purpose, version and boundary | Deployed configuration and use context | Whether the use changes classification |
| What is recorded? | Automatic event catalogue and implementation | Streams actually received | Gaps between designed and available events |
| Why is it recorded? | Traceability and monitoring rationale | Operational investigation need | Whether each event is sufficient |
| Who controls it? | Access and export design | Roles, permissions and processor route | Contractual and technical control gaps |
| How long is it kept? | Product capability and limits | Active retention policy and evidence | Other applicable legal requirements |
This map prevents the observability provider from accepting a legal conclusion it cannot make. It also produces a practical scope: event instrumentation, export mapping, timestamp integrity, access-control review or retention configuration.
Example: one Friday review, two missing owners
Consider this illustrative composite thread; it is not a customer conversation:
“Risk wants Article 12 logs before Friday. Vendor says logging is enabled.”
“We can see decisions in the admin screen. Raw events maybe sit with their cloud team.”
“Retention is default. Nobody here knows the number.”
The fragments reveal a named review and three possible gaps: provider evidence is being reduced to an enabled feature, deployer control over raw events is unclear, and retention is unverified. They do not prove the system is high-risk, that Article 12 applies, that the visible “decision” is the required event, or that six months is the correct final period.
The first commercial question is not “How many gigabytes per day?” It is: Who has classified the system and intended purpose, and which log proof is missing from the provider column versus the deployer column? If neither owner can supply the system boundary, the honest scope begins with evidence discovery.
An AI literacy record concerns the people operating around the system, not its event history; see the Article 4 literacy evidence handoff. The Article 50 transparency readiness request addresses notices and synthetic-output disclosures, not Article 12 logs. Pricing and access describe the discovery product.
TOP Prospect can filter, merge, deduplicate and rank relevant fragments from Telegram groups a user deliberately connects and is authorised to access. It can retain original messages, sources, times, summaries and ranking reasons for a person to examine. It cannot classify the AI system, inspect private logging infrastructure, decide retention law, certify conformity or contact the poster.
Key facts
- Article 12 applies to high-risk AI systems, not every AI system.
- The system must technically allow automatic recording of events over its lifetime.
- Logging must support traceability appropriate to the intended purpose and the monitoring and investigation functions described in Article 12.
- Provider evidence explains system boundary, event design, purpose, integrity and access.
- Article 19 requires deployers to keep automatically generated logs under their control for an appropriate period of at least six months, unless other applicable law provides otherwise.
- A visible dashboard and an enabled setting do not by themselves prove event completeness, control or retention.
FAQ
Does Article 12 apply to every AI system?
No. Article 12 is a requirement for high-risk AI systems. The system and intended purpose must first be assessed under the AI Act classification rules.
What does Article 12 require from the provider-side system design?
High-risk AI systems must technically allow automatic recording of events over their lifetime. The logging capability must support traceability appropriate to the intended purpose and enable monitoring and investigation of specified risks and substantial modification.
Who keeps logs for at least six months?
Article 19 requires deployers of high-risk AI systems to keep automatically generated logs under their control for a period appropriate to the intended purpose of at least six months, unless another applicable Union or national law provides otherwise.
Can an observability vendor certify Article 12 compliance from a Telegram request?
No. The vendor can scope event design, export, integrity or retention work, but legal classification, role allocation, conformity evidence and compliance conclusions require authorised human review.
The request is ready for a technical scoping call when the high-risk classification source, provider log owner, deployer log owner and missing proof can all be named in one record.
Frequently asked questions
Does Article 12 apply to every AI system?
No. Article 12 is a requirement for high-risk AI systems. The system and intended purpose must first be assessed under the AI Act classification rules.
What does Article 12 require from the provider-side system design?
High-risk AI systems must technically allow automatic recording of events over their lifetime. The logging capability must support traceability appropriate to the intended purpose and enable monitoring and investigation of specified risks and substantial modification.
Who keeps logs for at least six months?
Article 19 requires deployers of high-risk AI systems to keep automatically generated logs under their control for a period appropriate to the intended purpose of at least six months, unless another applicable Union or national law provides otherwise.
Can an observability vendor certify Article 12 compliance from a Telegram request?
No. The vendor can scope event design, export, integrity or retention work, but legal classification, role allocation, conformity evidence and compliance conclusions require authorised human review.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
