EU AI Act Compliance
The EU AI Act imposes transparency and record-keeping obligations on any organisation using AI systems. Article 50 requires disclosure when an AI system interacts with a person and machine-readable marking of generated content. Articles 12, 19 and 26 require automatic logging and retention of activity for high-risk systems so you can demonstrate what the system did when regulators ask.
ASPEN is the system of record for the AST platform. It captures AI prompts, responses, and agent actions at the gateway, logs every event with tamper-evidence, and retains the complete timeline — providing the audit trail and evidence infrastructure that compliance depends on.
Record-keeping: Articles 12, 19 and 26
Articles 12, 19 and 26 require you to prove afterwards what an AI system actually did. They sit in Chapter III of the Regulation, which means they attach to high-risk AI systems — and therefore do not apply on 2 August 2026.
Do not read the deferral as a reason to wait. Two things here are architecture, not configuration, and both have to be right before the obligation bites.
| Requirement | Article | What it requires in practice |
|---|---|---|
| Automatic logging capability | Article 12(1) | The system must “technically allow for the automatic recording of events (logs) over the lifetime of the system”. System-generated: manual or operator-entered records do not satisfy it. |
| Events that must be traceable | Article 12(2) | Traceability “appropriate to the intended purpose”, covering events relevant to identifying a risk under Article 79(1) or a substantial modification, to post-market monitoring under Article 72, and to the deployer’s operational monitoring under Article 26(5). |
| Tamper-evidence | Not stated explicitly | The Regulation does not use the words “tamper-proof”. It is read into the Article 12(2) standard and recital 71 by regulators and most legal commentary, on the reasoning that a log which can be altered has no evidentiary value. Treat it as a settled expectation rather than a quoted requirement. |
| Minimum retention — provider | Article 19(1) | Logs under the provider’s control, kept for a period appropriate to the intended purpose and at least six months, unless other Union or national law provides otherwise, in particular data protection law. |
| Minimum retention — deployer | Article 26(6) | The same six-month floor for logs under the deployer’s control. The two duties are separate: being a deployer does not discharge the provider’s obligation, or the reverse. |
| Biometric-specific fields | Article 12(3) | For Annex III point 1(a) systems only. A fixed minimum with no discretion: the period of each use, with start and end date and time; the reference database the input data was checked against; the input data for which the search led to a match; and identification of the natural persons involved in verifying the results under Article 14(5). |
Why the deferral is a build window
Retention floors run backwards. Articles 19(1) and 26(6) require at least six months of logs, so a system that begins logging on the day the obligation applies has no compliant history behind it — the six months has to have already happened. And evidentiary weight depends on the record being trustworthy, which is a property of how the log store is built. Neither is something to retrofit onto records that were mutable for their first year.
Producing the logs, not just keeping them
Article 21(2) requires a provider, on a reasoned request from a competent authority, to give that authority access to the Article 12(1) logs, to the extent they are under the provider’s control; Article 22(3)(c) places the same duty on authorised representatives. The practical test is therefore not whether the logs exist, but whether a specific period can be scoped, exported, and read by someone outside the organisation on request.
What ASPEN contributes
ASPEN is the system of record for the AST platform. Telemetry arrives automatically from sensors and from any integrated log source, is enriched and indexed on ingest, and stays queryable across the full historical timeline, including retroactive correlation over events that predate the rule being applied. For AI systems specifically, prompts, model responses, and agent tool calls are captured inline at the gateway — the same capture path Article 12(2) describes for events relevant to risk identification and operational monitoring.
Retention is set per deployment, and Articles 19(1) and 26(6) put the floor at six months for logs under your control. Where a system falls under Annex III point 1(a), the Article 12(3) field set is fixed and has to be captured in full rather than sampled. Both are scoping questions for the deployment rather than defaults, and are settled during onboarding.
ASPEN produces the monitoring, logging, and evidence infrastructure that a compliance position depends on. It does not, by itself, make an organisation compliant, and AST is not a law firm — confirm with counsel which obligations apply to your systems and to your role as provider or deployer.
The evidence a regulator or an auditor will ask for
A compliance position is not established by a configuration screenshot. Each of the following is a question a supervisory authority, an auditor, or your own DPO can ask, with the record ASPEN produces to answer it.
Can you show that a user was told they were dealing with an AI system?
Article 50(1) requires the disclosure to be served at or before the start of the interaction. ASPEN’s transparency and disclosure assurance verifies continuously that it is actually served at session start — not merely enabled in a settings panel — and records each check with a timestamp. Coverage includes first-party chatbots and white-labelled third-party assistants embedded in your own properties, where the code is a vendor’s and the obligation is yours.
Can you show that AI-generated content was marked before it was published?
Article 50(2) requires machine-readable marking that makes output detectable as artificially generated. Article 50(4) requires disclosure on deepfakes and on AI-generated text published on matters of public interest, unless a human has taken editorial review and responsibility for it. ASPEN checks generated output for the marking before publication and raises a compliance event when it is absent, so the gap is caught while it is still cheap to fix rather than after distribution.
Can you show what left the organisation inside a prompt?
AI prompt and response DLP scans every outbound prompt and inbound response in real time, before it reaches an external model, for secrets, credentials, personal data, source code, and intellectual property. Policy decides per match — block, redact, or allow and alert — and every decision is recorded. Where personal data is involved, that record is what an Article 33 assessment is built on, and what the Article 30 record of processing has to reflect.
Can you show what an AI agent was allowed to do, and what it actually did?
AI agent action auditing checks every tool call and API invocation against the scope the agent was authorised for, surfacing privilege creep, unsanctioned plugin and connector use, and actions outside the approved boundary. The retained call sequence is the evidence that human oversight under Article 26 was real — that a person could see what the system did and had the means to intervene.
Can you show when an AI-linked incident started, and when you reported it?
AI incident detection correlates compromised model accounts, agent-driven data exfiltration, and scope violations into qualified incidents rather than leaving them as isolated alerts, and tracks each against NIS2’s 24-hour early warning and 72-hour report obligations from the moment it qualifies. Prompts, responses, and agent actions are reconstructable in full, for the investigation and for the report itself.
Can you show that an attack on your AI was detected and contained?
Prompt injection and jailbreak detection covers direct injection in user input and indirect injection carried in retrieved content — a poisoned document, a fetched web page, an email an agent was asked to summarise. Detections are mapped to MITRE ATLAS, so AI-specific activity is reported in the same frame as the rest of the estate rather than as a separate category nobody owns.
What the AI Act does not displace
Article 4: AI literacy
In force since 2 February 2025 and enforceable by national market surveillance authorities from 3 August 2026, Article 4 requires providers and deployers to ensure a sufficient level of AI literacy among staff, contractors, and anyone using AI systems on the organisation’s behalf. That includes employee use of consumer-grade tools the organisation never formally deployed — precisely the usage most organisations cannot currently describe. Prompt-level telemetry is what turns it into a documented picture.
GDPR
Personal data in a prompt is personal data. It brings Article 30 records of processing, DPIA screening where the processing warrants it, and the Article 33 72-hour breach notification clock if personal data is exposed through a prompt or a model output. The AI Act sits on top of these obligations; it does not replace them.
NIS2
Essential and important entities remain subject to the 24-hour early warning and 72-hour incident report obligations for significant incidents. An AI-linked incident — a compromised model account, an agent exfiltrating data — is a significant incident like any other.
Where to start
The capabilities described here are part of ASPEN, and are also bundled as the AI Risk & Compliance package with onboarding, policy configuration, and periodic evidence reporting. Full technical detail is on the ASPEN product page.
ASPEN produces the monitoring, logging, and evidence infrastructure that a compliance position depends on. It does not, by itself, make an organisation compliant, and AST is not a law firm — confirm with counsel which obligations apply to your systems and to your role as provider or deployer.