When Logging and Recordkeeping Applies and What to Do Next

AI logging and recordkeeping requirements do not apply to every SaaS feature in the same way. Under the EU AI Act, the specific duties in Articles 12, 19, and 26 attach to high-risk AI systems and vary according to whether an organisation is a provider or deployer and whether the relevant logs are under its control. Other systems may still need records for security, privacy, contracts, quality management, incident response, or sector rules, but those reasons should not be confused with the high-risk AI requirements.

The practical starting point is therefore scope, not a logging platform. Identify the AI system, intended purpose, affected workflow, operator role, classification, and evidence questions. Then record only the events and decisions needed to support traceability, monitoring, oversight, and investigation. Protect those records, set justified retention periods, and test whether an authorised reviewer can reconstruct a material event.

What logging means under the AI Act

Article 12 requires high-risk AI systems to technically allow automatic event recording over the system's lifetime. The capability must support traceability appropriate to the system's intended purpose. In particular, it must help identify situations involving risk or substantial modification, facilitate post-market monitoring, and support the deployer's operational monitoring duties.

That is a system-design requirement for providers. Article 19 then requires providers to keep automatically generated logs under their control. Article 26 places a corresponding retention duty on deployers for logs under their control. In both cases, the default minimum is six months, unless applicable Union or national law provides otherwise, and the period must remain appropriate to the intended purpose.

Recordkeeping is broader than runtime logs. A provider of a high-risk system must also retain specified technical, quality-management, notified-body, and conformity documentation for ten years after the system is placed on the market or put into service. Operational teams should distinguish these documentation records from automatically generated logs because their purpose, owner, and retention rules differ.

The duties are also risk based. Article 12 specifies minimum logging details for certain remote biometric identification systems, but it does not prescribe one universal event schema for every high-risk system. Most SaaS teams must translate the required outcomes into a proportionate design that fits the intended purpose, architecture, and actual risks.

For the wider role and classification analysis, begin with the EU AI Act guide for SaaS providers.

When the specific requirements apply

Start by asking four questions.

First, is the feature an AI system within the Act's definition? Conventional rules, reporting queries, and ordinary software automation should not be labelled AI merely because they process data. Document the reasoning and the facts on which it depends.

Second, is the system high-risk? This can arise because the AI is a safety component of, or itself is, a regulated product listed through Annex I, or because its intended use falls within an Annex III area such as certain biometric, critical-infrastructure, education, employment, essential-service, law-enforcement, migration, or justice contexts. Exceptions and classification details matter, so a product label such as “AI-powered” is not enough.

Third, what is the organisation's role? A SaaS company that develops a system and markets it under its own name may be a provider. A business using another party's system under its authority may be a deployer. A company can occupy different roles across different products or workflows, and changes such as rebranding, substantial modification, or a changed intended purpose can alter the analysis.

Fourth, which logs does the organisation control? A provider may control system-generated model, application, or monitoring records while a customer controls user-side decisions and downstream actions. A deployer cannot retain records it never receives, and a provider should not assume it possesses the context needed to demonstrate the deployer's human oversight. The evidence map should reflect those boundaries.

The 2026 amendment changed the application dates for the high-risk provisions. The relevant rules apply from 2 December 2027 for systems classified under Article 6(2) and Annex III and from 2 August 2028 for systems classified under Article 6(1) and Annex I. These dates provide preparation time; they do not create historical evidence after the fact. Systems expected to remain in service should be designed and tested early enough to meet the applicable date.

When other recordkeeping still matters

A system outside the high-risk category may still require useful records. Security monitoring may need authentication, configuration, and incident events. Privacy compliance may require consent, request, deletion, or access evidence. Contracts may require service, change, and support histories. A regulated customer may need records to satisfy its own obligations. Quality and product teams may need version, evaluation, approval, and rollback evidence.

Keep the purpose explicit. “The AI Act requires this” is not an adequate justification if the high-risk provisions do not apply. Conversely, “not high-risk” does not mean “retain nothing.” For each record class, name the actual legal, contractual, security, or operational purpose, and apply the controls appropriate to that purpose.

This distinction also prevents overcollection. Storing every prompt, document, output, and identity field “for compliance” can increase privacy, confidentiality, security, and deletion exposure. A stable identifier, protected reference, hash, structured outcome, or sampled snapshot may answer a review question without retaining full content. Make that decision field by field.

A practical scoping workflow

1. Define the system boundary

Document the intended purpose, users, affected people, business decision, inputs, outputs, environments, integrations, upstream models, retrieval sources, and downstream actions. Include human review and customer-controlled components. A model API call is rarely the complete operational system.

2. Record role and classification

State whether the organisation acts as provider, deployer, importer, distributor, or another operator for the particular workflow. Record the classification conclusion, supporting facts, reviewer, approval date, and uncertainties. Define reassessment triggers such as a new use case, new market, material model change, changed automation level, rebranding, or substantial modification.

Teams reviewing third-party components can use the questions to ask before adopting internal AI tools to capture vendor and control boundaries.

3. Define the questions the evidence must answer

List concrete review questions before choosing fields. Which system and version produced a material output? What data or reference source was used? Which controls ran? Was a threshold exceeded? Did a required human review occur? What downstream action followed? Was an incident opened and resolved? Which party controlled each stage?

4. Map questions to minimum records

For each question, identify the event, decision record, or documentation item that provides the answer. A useful schema may include a transaction identifier, reliable timestamp, system and component version, operational context, input and output reference, control result, human action, downstream outcome, incident link, and integrity information. Not every system needs every field.

5. Assign end-to-end ownership

Engineering may own instrumentation and correlation; product may own intended-purpose and workflow facts; security may own access, integrity, and incident preservation; privacy may advise on necessity and personal-data handling; and compliance may maintain the requirements map and review cadence. Name one accountable owner for the complete workflow and explicit owners for access approvals, evidence requests, retention exceptions, legal holds, deletion tests, and remediation.

6. Set protection and retention rules

Define access groups, authentication, encryption, export restrictions, monitoring, clock standards, integrity controls, environment separation, and emergency access. Then set retention by record class. For high-risk automatically generated logs controlled by providers or deployers, apply the appropriate-purpose test and the statutory six-month floor unless other applicable law says otherwise. Do not automatically copy that period to all documentation or operational data.

7. Test reconstruction and deletion

Select a material event and ask a reviewer who did not design the system to reconstruct the version, context, controls, human action, downstream result, and follow-up. Separately test whether expired records disappear from production stores, analytics copies, exports, archives, and the applicable backup process. Record gaps, owners, deadlines, and verification evidence.

Common decision errors

The first error is treating all telemetry as an audit trail. Availability and latency logs may be valuable but still fail to connect an outcome to its configuration, control results, and human actions.

The second is assuming one party owns the whole record. Providers, deployers, customers, and vendors frequently control different events. Contracts, technical documentation, and deployed configurations should agree about what is produced, accessible, retained, and exportable.

The third is using a six-month default for everything. Automatically generated high-risk logs, technical documentation, security events, support exports, and personal data may have different rules. Retention needs a record-specific rationale.

The fourth is designing only for an audit deadline. Logging should support post-market monitoring, incidents, corrective action, complaints, change control, and operational oversight. A workflow that works only for a prepared demonstration is not reliable evidence.

The final error is never revisiting scope. Intended use and architecture change. Add reassessment to release, vendor, risk, and incident workflows rather than relying on a one-time legal memo. For a deeper corrective list, see common logging and recordkeeping mistakes SaaS teams make.

What to do next

Choose one AI workflow that affects a meaningful decision, customer commitment, or launch. Create a one-page system record covering its boundary, intended purpose, role, classification, controlled log sources, evidence questions, owners, and reassessment triggers. Do not begin by enabling every event.

Then map five to ten review questions to the minimum records needed to answer them. Confirm with security and privacy that the fields, access, integrity, retention, and deletion approach are proportionate. Ask vendors and customers to confirm control boundaries where the evidence chain crosses organisations.

Finally, run one reconstruction test before the next release. The result will show whether the evidence is connected, understandable, and trustworthy. It also gives the team a finite remediation backlog rather than an abstract instruction to “improve AI logging.” This evidence-led approach aligns with how AI governance is changing SaaS compliance expectations and the controls enterprise buyers increasingly request.

FAQ

Does AI Act logging apply to every SaaS AI feature?

No. The specific Articles 12, 19, and 26 duties discussed here concern high-risk AI systems. Other legal, contractual, security, privacy, or operational reasons may still justify records for other features.

What is the practical purpose of logging and recordkeeping?

The purpose is to make material system behaviour and compliance decisions traceable. Records should help authorised reviewers monitor operation, investigate risk or incidents, verify oversight, and understand what changed.

Must providers and deployers store the same logs?

Not necessarily. Each must retain the relevant automatically generated logs under its control. Their systems, roles, and operational context may differ, so the evidence chain should state who produces and controls each record.

Is six months always the correct retention period?

No. It is the default minimum for the relevant high-risk automatically generated logs unless other applicable Union or national law provides otherwise. The period must also be appropriate to the intended purpose. Other record classes can have different requirements.

What should a SaaS team document first?

Start with the system boundary, intended purpose, operator role, classification rationale, controlled log sources, review questions, accountable owner, and reassessment triggers. Only then define fields and tooling.

Sources

• Regulation (EU) 2024/1689, especially Articles 12, 18, 19, and 26.
• Regulation (EU) 2026/1744, including the amended application dates for high-risk requirements.
• European Commission, “AI Act,” for the current implementation timeline and overview.