ISO/IEC 5338 vs EU AI Act Lifecycle Obligations: What Maps and What Does Not

A voluntary process standard and a binding regulation

ISO/IEC 5338:2023, "Information technology — Artificial intelligence — AI system life cycle processes", is catalogued by ISO/IEC JTC 1/SC 42. Adopting it is a choice. It describes how an organisation can structure the processes around an AI system, from design through operation, maintenance and disposal.

The AI Act is Regulation (EU) 2024/1689, adopted on 13 June 2024 and published in the Official Journal. Its recitals state that high-risk AI systems should only be placed on the Union market, put into service or used if they comply with certain mandatory requirements. Obligations attach to roles, chiefly providers and deployers, not to processes.

That difference shapes everything below. A process standard tells you how to organise work. A regulation tells you what you must be able to demonstrate, to whom, and in what role. ISO describes standards as a way to mitigate risk and help bridge gaps in regulation. It does not describe them as a substitute for legal obligations.

Harmonised standards are a separate matter. The Commission states that harmonised standards will offer legal certainty under the AI Act. This page treats ISO/IEC 5338 as a lifecycle process reference and does not treat it as a harmonised standard.

Obligations with no process-standard counterpart

Some Act obligations are legal acts, not lifecycle activities. Conformity assessment, CE marking, EU database registration and serious incident reporting are procedures a provider carries out toward authorities and the market. A process standard can organise the internal work that precedes them, but it does not perform or replace them.

Deployer duties are the other major gap. ISO/IEC 5338 describes processes for an AI system life cycle. The Act assigns separate obligations to deployers based on their role in using the system. An organisation that is both provider and deployer needs to track each set of duties separately.

These items belong with legal interpretation and with the mechanisms the Act itself provides, such as harmonised standards where they exist. Assign a named legal owner to each. Do not assign them to the team that maintains lifecycle procedures.

Timelines add a further dependency. The Act's rules on general-purpose AI became effective in August 2025. For high-risk systems, the Commission proposed the Digital Omnibus on AI on 19 November 2025. It would set fixed dates for delayed application: 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for systems embedded in products. As of November 2026, these remain proposed dates, so plans should be flagged for legal review.

Design-time documentation versus runtime evidence

The most useful split in any mapping is by evidence type. Policies, procedures, risk files and technical documentation are design-time artefacts. They show that a process exists. They do not show what a system did on a given day.

Record-keeping, human oversight and deployer log retention depend on runtime behaviour. A procedure stating that high-risk outputs are reviewed by a person does not show that a review occurred for a specific interaction. A retention policy does not show that the records exist. These obligations call for operational evidence generated as the system runs, retained under a defined policy.

This is where standards alignment most often creates false assurance. A team can follow every lifecycle process and still lack the event-level evidence a regulator or auditor would ask for. The reverse also holds. Strong runtime evidence does not replace risk management, documentation or conformity procedures.

In practice, label each obligation in your mapping as needing process documentation, runtime evidence or both. That label tells you which team owns it and which control must produce the proof.

Where runtime enforcement is relevant, and where it is not

Trussed addresses the runtime portion of this problem. It enforces policy in the execution path of individual interactions and tool calls across models, agents, tools, MCP servers, AI sites and coding assistants. Decisions are allow, redact, block, rate limit or escalate for human approval. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence mapped to the EU AI Act, among other frameworks.

That is relevant to the runtime-dependent rows above: operational records, and human approval steps that can be evidenced per interaction. Retention and data residency are configurable, and deployment is self-managed in the customer cloud.

It is out of scope for the rest. Trussed does not provide model provenance, model lineage or dataset provenance. It does not provide transaction-level governance or end-to-end tracing of agentic workflows. It does not perform risk management, data governance, technical documentation, conformity assessment, registration or incident reporting. Those remain with your lifecycle processes, other standards and legal owners.