EU AI Act risk classification, audit logging & documentation

LMXAI turns EU AI Act requirements into an engineering workstream: a system inventory, a reasoned risk classification, audit logging, human oversight and the technical documentation behind them. This page explains what is delivered and how it relates to scholarship on the Act, which notes that the Regulation defines risk categories without a clear method for assessing risk in concrete situations.

Keywords EU AI Act · risk classification · audit logging · technical documentation · human oversight

LMXAI helps organisations turn EU AI Act requirements into an engineering workstream: system inventory, role and risk classification, technical evidence, audit logging, human-oversight controls and production documentation. The objective is to connect regulatory requirements to the way the AI system is actually designed, deployed and operated.

LMXAI is based in Leiden, the Netherlands, and works on production AI architecture, sovereign LLM infrastructure, agentic systems, RAG, evaluation and observability. This makes the compliance work technical by default rather than a policy document disconnected from the running system.

The primary source is the Regulation itself. It sets obligations by risk class and, for high-risk systems, requires risk management, data governance, technical documentation, automatic logging, transparency, human oversight, and accuracy, robustness and cybersecurity (Articles 9–15)^[1].

Scholarship on the Act explains why classification is engineering work and not a lookup. The Act defines four risk categories but, as one analysis notes, lacks a clear methodology for assessing risk in concrete situations; the authors propose scenario-based assessment with a proportionality test^[2]. Early commentary on the draft found the risk-tiered structure sensible while warning that some provisions could prove largely ineffective^[3]. The two enforcement mechanisms in the proposal, conformity assessment and post-market monitoring, have been read as establishing a Europe-wide ecosystem for AI auditing^[4]. Both analyses concern the proposal, so details should be checked against the adopted text.

For the evidence itself, the machine-learning community already has documentation formats that map onto a technical file: model cards state intended use and evaluation across relevant conditions^[5], datasheets record how a dataset was motivated, composed and collected^[6], and an end-to-end framework exists for internal algorithmic auditing^[7].

AI Act obligations depend on what the system does, how it is used, who places it on the market or puts it into service, and which role the organisation has in the AI value chain.

A practical assessment therefore starts with questions such as:

• What is the AI system's intended purpose?
• Who are the provider, deployer, importer or distributor, where relevant?
• Is the system prohibited, potentially high-risk, subject to transparency obligations, or otherwise lower risk?
• Does the solution integrate a general-purpose AI model?
• Which decisions or workflows can materially affect people?
• What data enters the system and where does it flow?
• What does the model generate, recommend or trigger?
• Where is human oversight required?
• Which evidence already exists in code, logs, evaluation results and operational processes?

The output is a system-specific classification record rather than a one-size-fits-all compliance label.

1. AI system inventory and role mapping

We document the actual AI components, models, data flows, integrations, intended purpose and organisational ownership. This creates the base layer for deciding which AI Act requirements apply.

2. Risk classification assessment

The system is mapped against the relevant AI Act categories and current European Commission guidance. Where a high-risk classification may be relevant, the assessment records the use case, reasoning, assumptions and evidence that should be reviewed and maintained.

3. Technical documentation package

LMXAI can structure the technical file around the system that exists in production, including:

• architecture and component inventory;
• model and provider information;
• intended purpose and system boundaries;
• data sources and retrieval design;
• evaluation methodology and results;
• known limitations and failure modes;
• human-oversight mechanisms;
• security and access controls;
• monitoring and incident-handling processes;
• change history and release evidence.

The goal is to make documentation maintainable as the system changes, not produce a static PDF that becomes obsolete after the next release.

4. Audit logging and traceability

For AI systems that need stronger traceability, LMXAI can design logging across the application and model workflow. Depending on the architecture, this can include:

• model and prompt version;
• request and response metadata;
• retrieval sources;
• tool calls and tool outputs;
• user or service identity;
• approvals and human intervention;
• policy decisions;
• latency, errors and retries;
• evaluation or confidence signals;
• deployment and release version.

Sensitive content does not need to be logged indiscriminately. Retention, redaction and access to logs should follow the organisation's privacy and security model.

5. Human oversight and approval controls

For systems that recommend or execute consequential actions, LMXAI can translate human-oversight requirements into concrete workflow controls: approval nodes, escalation paths, role-based permissions, review queues and explicit stop conditions.

6. Evaluation and production evidence

A compliance claim is stronger when the organisation can show how the system was tested. LMXAI can create repeatable evaluation sets and release gates for model quality, retrieval grounding, tool use, safety behavior, latency and regressions.

Modern enterprise AI is often more than one model call. A user request may trigger retrieval, multiple tools, an agent workflow and several model decisions.

For these systems, traceability should cover the whole execution path, not just the final answer.

LMXAI works with technologies such as LangGraph, FastAPI, OpenTelemetry and Phoenix to make workflow state, tool execution, retrieval and model calls observable. For sovereign deployments, the same control layer can be combined with self-hosted inference using vLLM and Kubernetes.

The AI Act uses a risk-based framework. The European Commission's current guidance distinguishes prohibited practices, high-risk systems, transparency-related obligations and systems presenting minimal or no risk. High-risk classification is tied to the system's intended use and the categories in Article 6 and the relevant annexes, while separate rules apply to general-purpose AI models and certain transparency scenarios.

Commission guidance also emphasises documentation, logging and traceability, human oversight, robustness, cybersecurity and risk management for relevant high-risk systems. Transparency obligations under Article 50 started applying on 2 August 2026.

Because guidance and implementation timelines continue to evolve, LMXAI keeps the engineering evidence modular: classification assumptions, controls and documentation can be updated without rebuilding the AI product.

Official references

• European Commission — AI Act regulatory framework
• European Commission — high-risk AI system classification guidance
• European Commission — transparency obligations under Article 50
• European Commission — GPAI provider obligations

A typical engagement can be structured as:

1. Discovery — inventory systems, use cases, roles, data and deployment context.
2. Classification — map each system to relevant AI Act categories and record the reasoning.
3. Gap assessment — compare required evidence and controls with what currently exists.
4. Implementation — add logging, evaluation, approvals, monitoring or architecture changes where required.
5. Documentation — produce the technical record and operational ownership model.
6. Release process — define how future model, prompt, retrieval and tool changes are reviewed and evidenced.

The exact package depends on the system, but may include:

• AI system inventory;
• role and risk classification matrix;
• architecture and data-flow map;
• gap analysis;
• logging and traceability specification;
• evaluation plan and test evidence;
• human-oversight design;
• technical documentation structure;
• operational monitoring and incident workflow;
• implementation backlog prioritised by risk.

Need more detail? Chat with Savion’s AI legal assistants for EU AI Act questions: obligations, risk tiers and documentation checklists. Open Savion →

• Practical EU AI Act guide
• What an EU AI Act compliance deliverable contains
• Fractional AI CTO
• Production-grade agentic systems

LMXAI combines AI architecture and implementation with AI Act-oriented technical evidence. That means the same partner can assess the system, identify missing controls and implement logging, evaluation, governance and production changes.

Discuss your AI Act engineering requirements with LMXAI