What EU AI Act Article 12 record-keeping requires
If your high-risk system is due to meet the rules in 2027 or 2028 and nothing in its design records what it does, you have a gap that cannot be closed quickly. Article 12(1) of the AI Act requires high-risk AI systems to technically allow automatic recording of events, or logs, over the entire lifetime of the system. The word that matters is technically: the system itself must produce the records, so logging cannot be a manual process or a policy that staff are expected to follow. Under Article 12(2), those logs must make three things traceable: situations where the system may present a risk or undergo a substantial modification, the post-market monitoring required by Article 72, and the deployer's monitoring of operation under Article 26(5). Each purpose sets a different bar for what gets captured, so a log built only for debugging will usually fall short.
Logs are hard to retrofit because the events that matter most, such as a model version change, a threshold update or an unusual pattern of inputs, are often not recorded anywhere if the system was not built to record them. Adding logging to a running system later means reconstructing history from partial sources, and the gap in the record is the gap an assessor will look at. Time synchronization is part of the design too. A chrony-based clock source with a documented NTP hierarchy helps make event times comparable across components. For a system that uses a self-hosted platform, the decision to make now is which components emit events, where those events are stored, and who is responsible for retention, which Article 19 and Article 26(6) set at no less than six months unless other law requires longer.
Article 12(3) adds a stricter minimum for remote biometric identification in Annex III point 1(a). Those logs must capture at least the start and end date and time of each use, the reference database checked, the input data that led to a match, and the identity of the people who verified the results. Ask your team whether the verification step is recorded as a separate event tied to a named person, since that is where many designs fall short. The 2026 amendment moved the high-risk rules in Chapter III Sections 1 to 3 to 2 December 2027 for Annex III systems and to 2 August 2028 for Annex I product systems, but the design of logging still has to exist before market placement. Confirm the exact obligations with your legal team and the EUR-Lex consolidated text.
Which systems and log sources fall under Article 12
Article 12 applies to every high-risk AI system, but the logging duty lands differently depending on whether the system is an Annex III system or an Annex I product, who built it, and who runs it. The cards below cover the dates, the provider and deployer split, and the scoping decisions that determine which logs your organization must keep and for how long.
Annex III systems and their dates
Annex III high-risk systems, such as those used in employment, credit scoring or biometric identification, fall under the logging duty once the high-risk rules apply. Under the 2026 amendment, Chapter III Sections 1 to 3 apply to Annex III systems from 2 December 2027. Check each system against Annex III before you assume the logging duty is not yet live, because the date driving your plan is the one that matches the system's category.
Annex I product systems and their dates
AI systems that are safety components of products covered by Annex I, such as machinery or medical devices, follow a later date. As amended in 2026, the high-risk rules apply to these product systems from 2 August 2028. Confirm with your product certification team whether the AI function sits inside a regulated product, since that changes both the date and the conformity route that will carry your logging evidence.
Provider and deployer log ownership
Providers must design the system so it can record events automatically, while deployers must keep the logs generated under their control. The same log stream can serve both roles, so write down which party stores which records, who can read them, and how a deployer obtains logs held by a provider. Ambiguity here is the most common reason a logging gap goes unnoticed until an incident.
Third-party components and models
A high-risk system often combines an inference service, a vector store, an identity provider and a model from another vendor. Each component may emit its own events, and only some will be under your control. Map every component that touches inputs, outputs or decisions, record whether it writes logs you can export, and confirm the vendor's retention period before you rely on it.
Cloud services and hosted logs
Managed cloud logging, SaaS audit trails and hosted model APIs often keep records for a fixed period and let you export them on request. Where logs sit with a cloud provider, check whether you can retain them for the period Article 19 and Article 26(6) require, whether you control deletion, and whether the export format is usable for post-market monitoring under Article 72.
Control of logs and retention duty
Articles 19 and 26(6) require logs under the provider's or deployer's control to be kept for a period appropriate to the intended purpose, and for at least six months unless other Union or national law says otherwise. Logs held only by a vendor that you cannot access may not count as logs under your control. Confirm contractually who holds them, how long they persist, and what triggers their release to you.
How to design logging that meets Article 12
This sequence turns Article 12's design requirement into a logging system you can explain to an assessor: it starts from the decisions the system makes, produces a defined event schema, and ends with logs that are protected, time-accurate, documented for deployers and proven retrievable.
Map decisions and risk-relevant event points
The provider's engineering and risk owners list every decision, output and state change the system produces, then mark the points where a situation could present a risk, where a substantial modification could occur, and where post-market monitoring or deployer oversight needs visibility. Article 12(2) ties logging to these three purposes, so the map should name each one. Output: a written event inventory, reviewed by the risk management owner, that links each event type to a purpose under Article 12(2). Confirm the mapping against your Article 9 risk management file before moving on.
Define the event schema
Engineering turns the event inventory into a schema that fixes, for each event type, the mandatory fields, their formats, the system version, the model or configuration identifier, the operator or service account, and the outcome. Records should be structured (for example JSON lines) so they can be queried later. Output: a versioned schema document and sample records for each event type, checked by a second engineer who was not involved in writing it. Include a field that identifies the deployer context where the system is deployed by more than one customer.
Set time synchronization across all sources
Every host, container and service that writes an event must share a trusted clock, or the sequence of events cannot be reconstructed. Configure an NTP client such as chrony against authorized time sources on each system, and record the source and offset in your evidence. chrony can also serve time to other machines on the internal network. Output: a configuration baseline for each host class and a report showing that clock offsets are monitored and alerted on. Ask your infrastructure team to confirm which time sources are permitted in your environment, especially for air-gapped deployments.
Configure append-only storage and access controls
Logs must be protected from alteration and kept for the period Articles 19 and 26(6) require for logs under your control, which is at least six months unless other Union or national law sets a longer period. Write logs to a store that supports append-only or write-once behavior, restrict deletion to a documented role, forward copies to a separate system, and log every access to the log store itself. Where the system uses a secrets or identity service, enable its audit device so requests and responses are recorded with sensitive values hashed. Output: a retention schedule, an access matrix and a test showing that a standard user cannot modify or delete records.
Add remote biometric identification fields
Where the system performs remote biometric identification under Annex III point 1(a), Article 12(3) adds specific minimum content. For each use, capture the start and end date and time, the reference database checked, the input data that led to a match, and the identity of the people who verified the results. Build these as required fields so a record cannot be closed without them, and tie the verifier identity to the two-person verification workflow described under Article 14. Output: a biometric event profile in the schema and a test that rejects an incomplete record. Confirm with your legal team whether any national rule adds further requirements.
Document collection and interpretation for deployers
Article 13(3)(f) asks the provider's instructions for use to describe, where relevant, the mechanisms that let deployers collect, store and interpret logs. Write a procedure that explains which logs exist, where they are stored, how a deployer exports them, what retention applies on their side, and how each field should be read. Include a worked example labeled as illustrative. Output: a log interpretation section in the instructions for use, reviewed by the team that answers deployer support questions and checked against the schema version in force.
Test retrieval and reconstruction end to end
Run a scripted scenario that produces known events, then retrieve them through the export path a deployer would use and reconstruct the sequence for a chosen incident. Check that every mandatory field is present, timestamps order correctly across hosts, and the records answer the three Article 12(2) purposes. Keep the test output, the scripts and the defects found. Output: a signed test report with a pass or fail result for each event type, and a retest after each schema or infrastructure change. Independent assessors will ask to see this evidence, so keep it under version control.
How an assessor tests Article 12 logging
This table sets out each test step an assessor is likely to run on Article 12 logging, the evidence requested for it, and where providers and deployers most often fall short. Read it as a pre-assessment checklist: if you cannot produce the evidence in the right-hand column for a row, that row is where a finding is likely.
| Test area | What the assessor checks | Common finding |
|---|---|---|
| Design review of logging capability | Whether the system is technically built to record events automatically across its lifetime, covering the system's design documents and logging architecture | Logging is switched on only in some components, or is a manual feature that operators must remember to enable |
| Sampling against Article 12(2) purposes | Whether sampled log entries can show situations that present a risk, substantial modifications, post-market monitoring inputs and deployer monitoring under Article 26(5) | Logs exist but cannot show a risk event, because they record access and errors without the decision context needed to reconstruct it |
| Biometric field verification | For remote biometric identification under Annex III point 1(a), whether each use records start and end date and time, the reference database checked, the matching input data and the identity of the people who verified results | Timestamps are present but the reference database, the input data or the second verifier's identity is not captured |
| Clock and time integrity | Whether event timestamps come from a synchronized, documented time source so that sequences across components can be ordered and relied on | Components log in different time zones or drift from one another, making event sequences unreliable |
| Retention checks | Whether logs under the provider's or deployer's control are kept for a period appropriate to the intended purpose and for at least six months, unless other law requires longer | Rotation or deletion policies remove logs after days or weeks, or retention settings differ between environments |
| Instructions for use review | Whether the instructions for use under Article 13(3)(f) explain how deployers collect, store and interpret the logs | Instructions say logs exist but do not describe how to access, export or read them |
| Log integrity and access | Whether logs are protected from unauthorized change and whether access to them is itself recorded and limited to authorized roles | Administrators can edit or purge logs without a trace, or sensitive values are stored in clear text |
| Evidence requested | Logging design specification, sample log extracts for each purpose, retention configuration, time source configuration, and the relevant section of the instructions for use | Evidence is assembled only at audit time, so records cannot be shown to cover the period under review |
How the logging layers fit together
Article 12 is satisfied by a record that can be reconstructed end to end, not by any single log file. Three layers have to line up: application events that describe what the high-risk system did with an input, identity and API audit trails that show who or what touched the system and its secrets, and a trusted clock that puts every entry on the same timeline. Each layer answers a different question during an investigation. Application events show the decision path, audit trails show the actor and the access, and the clock lets an assessor or incident team order events across systems. If any layer is missing, the others can still be intact yet fail to explain a specific output.
The clock is the layer teams most often leave to default settings. chrony (GPL-2.0-only) keeps the host clock synchronized with NTP servers or reference clocks and can serve time to other machines on the network. Confirm in your own environment that every component producing logs, including the model serving host, the audit store and any retrieval service, draws time from the same internal source, and that drift is monitored and alerted. Without this, a sequence reconstructed from two systems may be out of order by an amount that changes the conclusion.
Correlation is the step that turns separate logs into one record. Application events, OpenBao audit entries and Nextcloud audit entries should carry a shared identifier or at least timestamps in one consistent format and time zone, so a reviewer can follow a single request across the stack. Tools produce these outputs in different shapes, and their exact fields and behavior should be confirmed in your environment before you rely on them. Those tool behaviors are examined in the next section, where you can check them against your own deployment.
Evidence that passes an Article 12 review
An assessor testing Article 12 looks for a documented logging design, proof that logs are produced and protected, and sample records that match the purposes the Article names. The cards below cover the artifacts that connect design intent to what the system actually recorded, and each one needs an owner who refreshes it on a schedule rather than only before an audit.
Logging design specification
This document states which events the system records, why each event type exists, and how each maps to the purposes in Article 12(2): identifying risk or substantial modification, post-market monitoring under Article 72, and deployer monitoring under Article 26(5). Check that every event class has a named purpose and that the specification is versioned alongside the system release it describes. An assessor will compare it against the running configuration, so mismatches between the document and the deployed settings are a common finding.
Event schema with field definitions
The event schema lists each log field, its data type, its meaning and whether it is mandatory. For remote biometric identification under Article 12(3), the schema must carry the start and end date and time of each use, the reference database checked, the input data that led to a match, and the identity of the people who verified the results. Confirm that the schema is machine-readable so that sample extracts can be validated against it automatically.
Retention policy and legal drivers
The retention policy sets how long logs under your control are kept, with the six-month minimum from Article 19 for providers and Article 26(6) for deployers as the floor. Record any longer period that another Union or national law requires, such as sector record-keeping rules, and state which law drives it. Document who may extend or delete a retention period, and how deletion is logged, so the policy can be tested rather than simply asserted.
Log integrity and access records
Assessors expect evidence that logs cannot be altered without detection and that access to them is restricted and recorded. Keep configuration exports showing where logs are written, the permissions on those locations, and access records for administrators who read or change log storage. For audit trails on secrets and API activity, OpenBao audit devices write a detailed JSON record of each request and response, with most sensitive values hashed, which gives a reviewer a verifiable trail to sample.
Time synchronization records
Logs are only useful for reconstructing an incident if their timestamps agree across systems. Keep the time source configuration for every system that writes logs, along with periodic offset reports showing that clocks stay aligned with the NTP servers or reference clocks in use. chrony can act as both the client and the NTP server for a network, and its tracking output gives a dated record of synchronization quality that an assessor can sample.
Sample log extracts by purpose
Sample extracts show that the design works in practice. Prepare one extract per Article 12(2) purpose: a risk or substantial modification event, a post-market monitoring record and a deployer monitoring record, each with a short note explaining what it shows. For systems that use language models, garak writes a JSONL report of every probe attempt plus a hit log of attempts that found a vulnerability, which can serve as a dated test record. Refresh extracts after each release so they reflect the current schema.
Extra fields for remote biometric identification
Article 12(3) applies to remote biometric identification systems listed in Annex III point 1(a), and it sets a fixed minimum of event details beyond the general logging duty in Article 12(1) and 12(2). Compliance leads should treat each use of the system as a documented event with four required elements, and confirm that the logging design produces them for every use, not just in aggregate. The record must be retrievable by an assessor who did not build the system.
- Start and end date and time: Confirm that each use has both timestamps, recorded in a consistent time reference that matches the synchronized system clock.
- Reference database checked: Name the specific database or reference set queried for each use, with its version or identifier, so an auditor can trace which population was compared.
- Input data that led to a match: Document which input produced the match result, and how that input is linked to the stored record under your data governance rules.
- Identity of the people who verified the results: Record who checked the result, so the verification step can be traced to named individuals.
Ask your provider or implementation partner to show a sample record for one simulated use, and check that all four elements appear in it.
Engineers turn the Article 12(3) minimum into fields, storage rules and retention controls. The main design risk is that a log built to prove traceability also becomes a second copy of biometric or other sensitive data. The design should capture the fields the regulation names and use references, hashes or pseudonymous identifiers wherever a raw value is not needed to prove what happened. The choice of which values to store in clear should be documented and reviewed.
- Timestamps: Record start and end times with a time source that is synchronized, for example through
chronyagainst NTP servers or reference clocks, and store them in UTC with a fixed format. - Reference database identifier: Log the database name, version and a content hash, not a copy of the reference entries.
- Input data handling: Store a keyed reference or hash of the input that led to a match, and keep raw biometric material out of the log. Confirm which fields the audit tooling writes in clear, because some platforms hash sensitive values by default.
- Verifier identity: Store a pseudonymous operator ID that maps to the directory under access control, so the identity can be proven without spreading personal data across logs.
- Access and retention: Restrict read access to the log store, separate it from the biometric data store, and apply the retention period your legal review sets, which must be at least the minimum in Article 19 or 26(6) unless other law requires longer.
Confirm with your data protection officer how each field is classified before release.
Operators are the people who carry out the verification step, and their actions are part of the record. Article 12(3) requires the identity of the people who verified the results, so the system must make the second check visible and attributable. Operators should work from a defined procedure that tells them what to do, when to record it and what to do when they disagree with the match.
- Two-person verification: Record each verifier separately, with the time of their decision and their result, so the log shows that two people checked the match where that rule applies.
- Disagreement handling: Log conflicting verdicts and the escalation step taken, since a disputed match is a common point of questions from assessors.
- Operator sign-in: Tie each verification to an individual session, not a shared account, so the identity recorded is the actual person.
- Review of records: Set a routine where a supervisor samples verification records against the procedure, and keep evidence of that review.
- Training and role assignment: Keep records showing who is authorized to verify and that they were trained on the procedure.
Check that the operator interface writes these records by default and that they cannot be edited after the event.
What Article 12 logging costs to meet
This table lists the cost components of meeting Article 12 logging, who is paid for each one, whether it is one-time or recurring, and what drives it up or down. Read it as a checklist for building a quote: no figures are given because none were supplied, so ask each provider to price every row against your own log volume and retention period. The main takeaway is that retention length and log volume drive most recurring cost, while open-source components can remove some license spend but not the engineering and evidence work.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it |
|---|---|---|---|
| Event design and instrumentation | Internal engineers or an implementation partner mapping events to Article 12(2) purposes | One-time, with updates after each substantial modification | Number of system components, integrations and event types the logs must capture |
| Log storage and retention | Cloud or data center provider for storage; internal team for capacity planning | Recurring for the whole retention period | Log volume per day, retention length (at least six months under Articles 19 and 26(6) unless other law applies), and replication |
| Time synchronization | Infrastructure team; time sources such as NTP servers or reference clocks | One-time setup, small recurring monitoring effort | Number of hosts that write logs and the accuracy the organization sets for event timestamps |
| Access control and integrity protection | Security engineering for restricted access, tamper resistance and audit of log access | One-time design, recurring review | Number of people with log access, separation of duties and integrity mechanisms chosen |
| Remote biometric identification fields | Engineering for the Article 12(3) minimum fields and verifier identity capture | One-time for systems in Annex III point 1(a), recurring for operation | Volume of identification events and the workflow for two-person verification |
| Evidence upkeep | Compliance lead or consultant maintaining the log record of design, retention and reviews | Recurring | Frequency of system changes, number of log sources and the depth of documentation expected |
| External review and readiness checks | Independent consultant or auditor; the organization owns the outcome | Periodic, often tied to the conformity assessment | Scope of the system, number of log sources and whether a notified body is involved |
| Auditor sampling and testing | Independent assessor who samples logs and tests completeness | Recurring per assessment cycle | How easily logs can be retrieved, filtered and shown to be complete for the period sampled |
| Open-source license spend | Reduced where logging components are open source; support contracts may still apply | Recurring if support is bought | Choice of platform components and whether vendor support or retainers are required |
Open-source tools that produce logging evidence
Article 12 asks for automatic event logs over a high-risk system's lifetime, and those logs must support risk identification, post-market monitoring and deployer oversight. The four tools below each produce a different kind of record, so they can cover different parts of the logging picture. None of them sets Article 12 coverage on its own, and the organization must decide which events its system needs to record.
Nextcloud admin_audit logs
The admin_audit app writes additional event information to a file named audit.log in the data directory, or to a path set with logfile_audit. This is useful evidence for administrative actions on a file-sharing or collaboration platform that hosts AI system documentation or data. Confirm that the events it captures include every action your risk and monitoring processes depend on, and that the log is shipped off the server so it cannot be altered by the same administrators it records.
OpenBao audit devices
OpenBao audit devices keep a detailed JSON record of every API request and response, including errors, so they show who accessed secrets and keys and when. Most sensitive values are hashed with HMAC-SHA256, which keeps secret material out of the log while still allowing matching of repeated values. Confirm the audit device is enabled before any workload touches the system, that log storage and retention meet your policy, and that hashed fields still let investigators answer the questions Article 12 requires.
chrony time synchronization
Logs are only useful as evidence if their timestamps agree across systems. chrony synchronizes the system clock with NTP servers or reference clocks such as GPS receivers, and it can act as an NTPv4 server for other machines on your network. Accuracy is typically within milliseconds over the Internet and tens of microseconds on a LAN. Confirm which time sources you trust, that every system producing AI event logs points to the same source, and that drift is itself monitored and recorded.
garak test reports
garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. These records support testing evidence for risk management and accuracy and robustness, but they are test logs, not operational logs of a deployed system. Confirm that you archive the reports with the model version and configuration tested, and that production logging is captured separately.
Who owns Article 12 work and what to outsource
Your organization owns the Article 12 outcome. Article 12(1) places the duty on the high-risk system itself to technically allow automatic event logging over its lifetime, and the provider carries the design obligation for that capability. Deployers carry their own duties for logs under their control under Article 26(6). The decisions that define the logging design belong inside the organization, because they tie directly to the system's intended purpose, its risks and the monitoring it must support. In practice, your team should own the following:
- Log design decisions: which events are recorded, at what granularity, and which situations the logs must make traceable under Article 12(2).
- Retention decisions: the period for each log set, set against the minimum of six months in Articles 19 and 26(6) and any longer obligation in other Union or national law.
- Access and review controls: who may read, export or alter logs, and how review of logged events is assigned and recorded.
- Remote biometric identification scope: whether the system falls under Annex III point 1(a) and therefore needs the Article 12(3) fields.
- Instructions for use: the description of how deployers collect, store and interpret logs, required by Article 13(3)(f).
Confirm with your legal and compliance leads which other Union or national rules set longer retention periods for your sector before you finalize the retention schedule.
An implementation partner can prepare the systems that produce and hold the logs. This work is configuration and evidence engineering inside your own infrastructure, and it is usually where outside help adds the most. DeployOpen, for example, works this way on self-hosted open-source platforms, but the design choices above remain yours to approve. Typical work includes:
- Logging configuration: enabling and tuning audit output in platforms such as Nextcloud, where the admin_audit app writes to audit.log or a path set with logfile_audit.
- Log schema and pipelines: defining field names, formats and storage locations, and wiring audit streams into retained storage.
- Time synchronization: configuring chrony against trusted NTP sources so that timestamps across systems can be compared.
- Secrets and API audit trails: enabling audit devices in OpenBao, which record requests and responses with sensitive values hashed.
- Evidence packs: producing sample log extracts, configuration exports and retention settings that show the design works in operation.
Fixed-scope work of this kind is priced from a written scope. Ask any partner which platforms, retention targets and log sinks are included, and who keeps the configuration current after go-live.
An independent auditor, assessor or notified body tests the logging design and reports on it. Under Article 43, notified bodies are involved for some biometric systems and Annex I products, while most Annex III systems rely on internal control under Annex VI. Where a notified body is not required, your organization may still engage an independent assessor to test the logs before a customer or regulator asks. The independence line matters: the party that tests the logs cannot have designed them, configured them or written the evidence it examines.
- Testing: sampling log records, checking that required events appear and that timestamps and retention match your documented design.
- Reporting: issuing any report or certificate, which only the independent party may do.
- Scope limits: an auditor cannot write your logging schema or configure your audit devices and still test them.
- Assessor selection: confirm the assessor's accreditation status and conflict-of-interest statements before engagement.
- Timing: ask when the assessor needs access to logs, configurations and staff, and what sample period they will examine.
Confirm with the assessor in writing which evidence they will sample and how they will treat any work your implementation partner has already delivered.
Where Article 12 logging usually falls short
Article 12 asks for logs that make a high-risk system's behavior traceable over its lifetime, and the gaps that fail an assessment are rarely dramatic. They tend to be ordinary defaults, unsynchronized clocks, logs nobody can retrieve and documentation that never mentions logs at all. Each card below names one gap and the check that closes it.
Errors logged, risk events missing
Application and API logs often capture failures and stack traces but not the events Article 12(2) cares about: situations where the system may present a risk, substantial modifications, and events needed for post-market monitoring under Article 72. Map each risk scenario from your risk management file to a specific logged event, including model version changes, threshold overrides and human decisions. Check that every identified risk scenario has a log entry that would show it occurred.
Unsynchronized system clocks
Logs from several services are only useful for reconstructing an incident if their timestamps agree. Hosts that drift or use mixed time zones make event sequences unreliable, which weakens the traceability Article 12 requires. Confirm that every component that writes logs syncs to a common time source, and that the time source and its offset are themselves monitored. chrony is one open-source option for this, and its NTP service can serve a local network.
Retention left at defaults
Many logging tools rotate or delete logs on short default schedules that were set for operations, not for regulation. Article 19 for providers and Article 26(6) for deployers require logs under their control to be kept for a period appropriate to the intended purpose, and for at least six months unless other Union or national law says otherwise. Check the retention setting on every log store, and confirm that rotation does not delete logs before the six-month floor. Record who owns that setting.
Logs deployers cannot retrieve
Providers often keep detailed logs on their own infrastructure, but deployers need to collect, store and read the logs under their control to monitor operation. If the export path, access rights or log format is undocumented, the deployer cannot meet Article 26(5) and (6) in practice. Test the export as a deployer would: create a sample event, retrieve it through the documented route, and confirm a non-administrator can read it. Confirm the expected format with your assessor if you are unsure.
Instructions for use silent on logs
Article 13(3)(f) asks the instructions for use to describe, where relevant, the mechanisms that let deployers collect, store and interpret the logs. Documents that cover accuracy and oversight but omit the log location, format, retention and interpretation steps leave deployers unable to follow the logging design. Write a logging section that names each log source, its fields, where it is kept and how a deployer reads it. Keep it in step with the technical file under Article 11.
Biometric use without required fields
For remote biometric identification in Annex III point 1(a), Article 12(3) requires a log record of at least the start and end date and time of each use, the reference database checked, the input data that led to a match, and the identity of the people who verified the results. Generic access logs rarely contain all four. Build a log schema with these fields as mandatory, and test that a sample identification produces every one of them before go-live. Verify the two-person verification identity is captured, not just the user session.
How much effort and cost does Article 12 logging take?
What drives the cost of Article 12 logging for a high-risk AI system?
The main cost drivers are how many systems you run, how much event data each one produces, how long you must keep the logs, and how much of the logging stack already exists. Article 12 requires automatic event recording over the system's lifetime, so the work is less about writing a log line and more about designing what gets captured, where it goes, who can read it and how it stays intact. Systems that already write structured, centrally collected logs usually need less change than systems that log only to local files. No public price is set by the Act, so the cost depends on the scope agreed for your environment. Ask any partner to split the quote into design, build, testing and handover so you can see which parts depend on your current logging maturity.
Which Article 12 costs are one-time and which recur?
One-time work includes mapping the events each system must record, configuring audit sources, setting up central collection, documenting the logging design and testing that logs are complete. Recurring costs include storage, log platform licenses or hosting, access reviews, periodic checks that logs are still being written, and time spent reviewing logs for risk signals and post-market monitoring. Retention is the recurring driver most teams underestimate. Article 19 and Article 26(6) require logs under your control to be kept for at least six months unless other Union or national law requires longer, so storage grows with every system and every year of operation. Ask for the recurring part of any quote as a separate line item.
When must Article 12 logging be in place for high-risk systems?
The high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, following the 2026 amendment by Regulation (EU) 2026/1744. Logging is a design requirement, so it should exist before a system is placed on the market, not be added after an incident. Work backward from those dates: the logging design must be in the technical documentation, tested in pre-market conformity work, and running in the production environment before launch. Confirm the final dates for your category against the Official Journal text, since the timeline has already changed once.
What does the engineering team need to provide for Article 12?
The team needs a precise list of the events each high-risk system produces, including inputs, outputs, model or version changes, errors and human overrides, mapped to the three purposes in Article 12(2): identifying risk or substantial modification, post-market monitoring under Article 72, and deployer monitoring under Article 26(5). Engineers must also supply the time source, the storage location, the access model and the retention settings. For remote biometric identification, they must capture the fields in Article 12(3). Plan for named owners on the platform side, the AI product side and the compliance side. Without those owners, logging designs stall at the handover between teams.
Can we implement Article 12 logging in-house?
Yes, if your team already runs self-hosted logging, security monitoring and infrastructure as code, and has time to document the design for an assessor. The harder parts are usually the event inventory, the mapping to Article 12(2) purposes and the evidence trail, because they require both technical and regulatory judgment. Many organizations keep ownership of the event inventory and risk decisions in-house while bringing in an implementation partner for configuration, hardening and testing. DeployOpen plans, implements and documents self-hosted platforms inside your own environment under a written, fixed scope, but the organization still owns its controls and decides what counts as acceptable logging.
What should we ask a partner to include in an Article 12 quote?
Ask for a written scope that names each high-risk system, its logging sources and the Article 12 purposes it must support. Ask which deliverables you receive: an event inventory, logging architecture, configuration of audit and time sources, retention settings, access controls, test records and documentation for your technical file. Ask who tests log completeness and how, what is out of scope, and what you must provide, such as access, environments and staff time. Ask how ongoing support is priced if it is separate from the build. Confirm that the partner prepares evidence only and that an independent auditor or notified body makes any formal assessment.
Who issues the evidence that Article 12 logging is compliant?
The organization owns its logging controls and its technical documentation, so it is responsible for showing that logging works. Providers of high-risk systems must make the evidence part of their conformity work, which for most Annex III systems is an internal-control procedure under Annex VI. Notified bodies are involved for some biometric systems and Annex I products under Article 43. An implementation partner can prepare configurations, test records and documentation, but it does not issue reports or certificates. Only an independent auditor, assessor or certification body issues formal attestations.
How do Article 12 retention periods interact with GDPR storage limits?
The two rules pull in different directions and must be reconciled in your design. Article 12 and Articles 19 and 26(6) require logs to be kept for a period appropriate to the intended purpose, at least six months unless other Union or national law provides otherwise. GDPR requires personal data to be kept no longer than necessary for its purpose, and logs containing personal data are personal data. Record the legal basis for each log category, minimize personal fields, pseudonymize where possible and set separate retention periods for different event types. Confirm the position with your data protection officer and legal counsel, because this is a legal determination for your organization, not a technical default.
How DeployOpen approaches Article 12 for your systems
DeployOpen plans, implements and documents the self-hosted logging that supports Article 12 inside your own infrastructure, whether that sits in your cloud accounts, your data centers or an air-gapped network. The work typically covers which events each high-risk system must record, where the logs are written, how the clock is synchronized, how retention is enforced and how the records are protected from alteration. DeployOpen prepares the systems, configuration and evidence that an assessor will ask for. It does not issue audit reports, attestations or certifications. Conformity for Annex III systems is generally based on internal control under Annex VI, so the organization remains the accountable party for its logging design and for the declarations it makes, and any independent review is carried out by a body you select and engage directly.
Engagements are fixed-scope. Before work starts, you and DeployOpen agree in writing which systems are in scope, which logging sources are covered, which open-source platforms are configured, what the deliverables are (for example, configuration baselines, a log field catalogue, retention settings and an evidence pack mapped to the requirement) and how the work will be accepted. Ask for the written scope to name each system's intended purpose, whether any system falls under the remote biometric identification fields in Article 12(3), and who will hold the retention and access responsibilities after handover. Because the deliverables are defined up front, you can compare proposals on what each one includes rather than on general claims about logging maturity.
Logging is not a one-time build. Log sources change, platforms are upgraded and retention rules may be set by other Union or national law, so the work needs an owner after go-live. DeployOpen offers retainers for ongoing support, upgrades, configuration reviews and continuous testing of the logging pipeline, scoped and priced separately from the initial engagement. Before you sign either, confirm with DeployOpen the exact deliverables, the handover responsibilities between your team and DeployOpen, and how a log integrity or access issue will be reported to you. Confirm the status of your assessment route with your legal and compliance advisers, and confirm dates against the consolidated text of the Act.
