EU AI Act Compliance Engineering: Technical Documentation, Logging, Oversight and Data Governance

Most of what has been written about the EU AI Act is about scope: which risk tier you land in, whether you are a provider or a deployer, whether your system is caught by Annex III. Your legal advisers answer that.

What almost nobody addresses is what happens after the answer. If your system is high-risk, the regulation asks for a risk management system that runs across the lifecycle, data governance you can evidence, automatic logging with defined retention, technical documentation in a prescribed structure, human oversight that is designed rather than asserted, and post-market monitoring that actually collects something. Those are engineering deliverables. That is the part we build.

Where the deadlines now stand

The AI Act (Regulation (EU) 2024/1689) entered into force in August 2024 and applies in stages. The staging changed in 2026, and it is worth being precise, because the change moved money and attention.

• 2 February 2025: prohibited practices and AI literacy obligations applied.
• 2 August 2025: obligations for general-purpose AI models applied.
• 2 August 2026: transparency obligations under Article 50 applied: disclosure that a user is interacting with an AI system, marking of synthetic content, disclosure of emotion recognition and biometric categorisation, and labelling of deep fakes.
• 2 December 2027: high-risk obligations for stand-alone systems, following the Digital Omnibus. The Council and Parliament agreed the deferral in May 2026 and it received final sign-off in June 2026.
• 2 August 2028: high-risk obligations for AI systems embedded in regulated products.

If you are a provider of a high-risk system, the deferral bought roughly sixteen months. It did not reduce the work, and it did not move the two obligations already in force: transparency under Article 50, and AI literacy for staff who operate these systems.

What we build

Technical documentation, as a generated artefact

Annex IV specifies what the technical documentation must contain: system description, design choices, architecture, data requirements, training methodology where applicable, validation and testing procedures, metrics, risk management measures, and the changes made across the lifecycle.

Written by hand, this document is out of date the week after it is signed. We build it as something your pipeline produces: model cards and data sheets generated from the training and evaluation runs, architecture and data-flow descriptions maintained alongside the code, evaluation results attached to the version they describe, and a change history that comes from your version control rather than from someone's memory. The document becomes a build output.

Automatic logging that satisfies Article 12

High-risk systems must log automatically over their lifetime, to a standard that permits traceability of functioning and post-market monitoring, with retention appropriate to the purpose, and in some cases at least six months.

In practice this means deciding what an "event" is for your system, capturing inputs, outputs, model version, decision path and the identity of the human involved, storing it in a form that is queryable years later, and doing that without accumulating personal data you have no basis to keep. That tension (log enough for the AI Act, keep little enough for the GDPR) is the actual design problem, and it is one we work through explicitly with your data protection people.

Data governance under Article 10

Training, validation and testing data sets have to be relevant, sufficiently representative, and to the extent possible free of errors and complete, with examination for bias. Meeting that means data lineage you can show, documented provenance, a bias assessment methodology with results, and the ability to reproduce which data produced which model version.

We build the pipeline that makes those statements checkable rather than aspirational: versioned data sets, reproducible splits, automated data quality checks, and bias evaluation on the protected characteristics relevant to your use case.

Human oversight, built rather than declared

Article 14 requires that high-risk systems be designed so a human can understand the output, remain aware of automation bias, interpret the result correctly, decide not to use it, and intervene or stop the system.

That is a user interface specification. We build oversight into the product: confidence and uncertainty surfaced honestly, the factors behind an output made visible, an override that is as easy to use as acceptance, a stop control that works, and logging of every override so the post-market monitoring has something to learn from.

Post-market monitoring and incident reporting

A monitoring plan is required, as is reporting of serious incidents to the relevant authority. We build the telemetry that feeds it: performance tracked against the metrics in your documentation, drift detection on inputs and outputs, a channel for user-reported problems that reaches engineering, and an incident workflow with the timing obligations built in rather than discovered during one.

Transparency obligations under Article 50

Already in force. Disclosure that a user is dealing with an AI system, machine-readable marking of synthetic audio, image, video and text, deep fake labelling, and disclosure for emotion recognition. We implement the disclosure surfaces and the content provenance marking (C2PA content credentials where that is the right mechanism), and make them survive the export and re-encoding paths that usually strip them.

Registration and conformity support

High-risk systems in Annex III areas must be registered in the EU database before being placed on the market, and providers must run a conformity assessment. We prepare the technical inputs (the documentation, the evidence pack, the quality management system artefacts on the engineering side), and work alongside your notified body or internal assessment process.

What this is not

We do not provide legal advice, and we do not tell you which risk tier your system occupies. That determination is a legal one with real consequences, and it belongs to counsel or a qualified compliance adviser.

We also do not sell an AI governance platform. There is a large field of those, and if your need is a register of AI systems and a policy workflow, one of them will serve you better than we would. What we do is the engineering inside the systems themselves.

Who this is for

Providers of high-risk AI systems under Annex III (recruitment and worker management, credit scoring, insurance pricing, education assessment, essential services eligibility, biometric systems), who now have until December 2027 and a lot to build.

Manufacturers embedding AI in regulated products (medical devices, machinery, vehicles), where the AI Act sits on top of an existing conformity regime and the two documentation sets have to agree.

Companies deploying high-risk systems bought from someone else, who carry their own obligations: human oversight, input data relevance, monitoring, and log retention.

Anyone shipping generative features to EU users, where Article 50 transparency already applies today regardless of risk tier.

How engagements run

Technical gap assessment, two to four weeks. We take the classification your legal team has arrived at and assess your systems against the engineering obligations that follow. The deliverable is a gap register (obligation, current state, what has to be built, effort), that your compliance and engineering leads can both work from.

Build, phased, usually starting with logging and documentation generation, because everything else produces evidence that has to land somewhere.

Readiness review ahead of conformity assessment, with the evidence pack assembled and the gaps that remain named honestly.

Standards and frameworks

Regulation (EU) 2024/1689 and its Annexes III and IV; the harmonised standards emerging from CEN/CENELEC JTC 21; ISO/IEC 42001 for AI management systems and ISO/IEC 23894 for AI risk management; the NIST AI Risk Management Framework where a US parent needs alignment; and the GDPR, which does not go away and which constrains most of the logging decisions.

Frequently asked questions

Has the AI Act been delayed?

Partly. The Digital Omnibus deferred high-risk obligations to 2 December 2027 for stand-alone systems and 2 August 2028 for AI embedded in regulated products. Prohibited practices, AI literacy, general-purpose AI model obligations and the Article 50 transparency rules were not deferred and are in force now.

We only use AI systems built by someone else. Do we have obligations?

Yes, as a deployer. Those include operating the system according to its instructions, assigning human oversight to people with the competence and authority to exercise it, ensuring input data is relevant to the intended purpose, monitoring operation, and retaining logs. Lighter than a provider's obligations, but real, and note that modifying a system substantially or putting your own name on it can make you a provider.

Our system is not high-risk. Is there anything to do?

Probably two things. Article 50 transparency applies to certain systems regardless of risk tier, including chatbots and synthetic content generation. And AI literacy under Article 4 applies to providers and deployers generally. Beyond that, being able to evidence the classification decision is worth having if a regulator ever asks.

Can the technical documentation really be generated?

Most of it, yes. Architecture, data set descriptions, evaluation results, metrics, model versions and change history all exist in your systems already; the work is capturing them in a stable structure at build time. The genuinely narrative sections (intended purpose, risk analysis, design rationale) are written by people, and then kept in the same repository so they version with everything else.

How does the AI Act interact with the GDPR?

They overlap and occasionally pull in opposite directions, particularly on logging. The AI Act wants traceability; the GDPR wants minimisation and deletion. The resolution is usually pseudonymisation, careful scoping of what is logged, and defined retention tied to a documented purpose. It is a design decision, taken once, deliberately.

Does using a third-party model make us a provider of that model?

No, but building an AI system on top of one can make you the provider of that system, with the obligations attaching to it. Where the line falls depends on what you build and how you present it, which is a legal question, but the engineering consequence is that you should assume you will need documentation of your own system regardless.

Get started

Tell us what your systems do and where your legal advisers have landed on classification. We will assess what the obligations mean in code and give you a gap register with effort against each line.

Contact us to book an AI Act technical gap assessment.

Related services

• AI Agent Development & MCP Integration: building the systems this regime governs
• EU Market Entry Development: the wider EU digital compliance stack
• Web Accessibility Remediation: the other EU obligation that turns out to be an engineering project