Most coverage of the EU AI Act asks what it means for new AI projects. That’s the easier half of the question.
The harder half (and the one that lands on engineering teams) is what it means for the systems you’re already running. The ERP with a scoring module someone added in 2022. The support platform with automated triage. The customer-facing assistant that shipped last year. These are in production today, and the AI Act reaches them.
This article covers what the AI Act is in general terms, what it changes for maintaining and developing existing systems, and how to approach it practically.
A note: this is practical guidance from an engineering perspective, not legal advice. For classification decisions and anything consequential, involve your legal counsel.
The AI Act in general terms
The EU AI Act is the first comprehensive horizontal regulation for artificial intelligence. It entered into force on 1 August 2024 and applies in staggered phases rather than all at once.
Two ideas do most of the work.
First, it’s risk-based. Obligations depend on what the AI system does, not what technology it uses:
- Prohibited practices: a small set of uses banned outright. These have been applicable since February 2025.
- High-risk systems: a defined list including AI used in recruitment, credit scoring, education, biometric categorisation, law enforcement, and AI embedded in regulated products like medical devices and machinery. These carry the heaviest obligations: risk management, data governance, technical documentation, logging, human oversight and conformity assessment.
- Limited-risk / transparency: systems that interact with people or generate synthetic content. The core requirement is disclosure: people should know they’re dealing with AI or seeing AI-generated content.
- Minimal risk: everything else, with no specific obligations.
Second, your role matters. The Act distinguishes providers (those who develop and place an AI system on the market) from deployers (those who use it under their own authority). Most mid-size companies are deployers, but the moment you commission a custom AI system, or substantially modify one, you can find yourself with provider-side obligations.
Where the timeline stands
The phasing has shifted since the Act was adopted, so it’s worth being precise:
- Prohibited practices and the AI literacy obligation: applicable since 2 February 2025.
- General-purpose AI model rules: applicable since 2 August 2025.
- Transparency obligations (Article 50): applicable from 2 August 2026. These are live now, and they affect a wide range of organisations using generative AI. For systems generating or manipulating synthetic content that were already on the market before that date, the machine-readable marking requirement was deferred to 2 December 2026.
- High-risk obligations: deferred by the 2026 Digital Omnibus. Standalone high-risk systems (Annex III: recruitment, credit scoring and similar) now apply from 2 December 2027; AI embedded in regulated products (Annex I) from 2 August 2028.
The deferral of the high-risk deadlines is real breathing room, but it’s worth reading correctly: it did not defer everything. Prohibitions, GPAI rules and transparency obligations stayed on their original dates. If your system talks to customers or generates content, the relevant date has already passed.
What this changes for maintaining existing systems
Here’s where it gets concrete for engineering teams. Six things change.
1. You can’t comply with what you haven’t inventoried
The first practical problem isn’t legal, it’s archaeological. Most companies don’t have a complete list of where AI already sits in their systems. A recommendation engine here, a classification model there, an OCR pipeline, a vendor module whose “smart” feature turned out to be a model. Some of it was added years ago by people who have left.
Before any classification question can be answered, someone has to map it: what AI is running, what it does, what data it touches, whose model it is, and which system it’s embedded in. For a company with legacy systems, this is genuinely a maintenance and documentation exercise, not a legal one.
2. Transparency obligations hit systems already in production
Article 50 is the one most likely to require code changes to software you already run. If a system interacts with people, they generally need to know they’re dealing with an AI. If it generates or manipulates content, that output generally needs to be marked as artificially generated.
For a chatbot or an assistant shipped two years ago, that isn’t a policy decision. It’s a change to the interface, the output pipeline, and possibly the data model. That’s maintenance work, on a live system, with a deadline attached.
3. “Substantial modification” can change your obligations
This is the point most relevant to maintenance, and the most easily missed.
The Act’s obligations are attached to systems as they’re placed on the market, but significant changes to an AI system’s intended purpose or design can bring it back into scope, or shift you from deployer to provider. In practice, this means a maintenance decision can have a regulatory consequence: extending a triage model to also rank job applicants isn’t just a feature; it may move that system into a high-risk category.
The practical implication for engineering: changes to AI functionality need a moment of classification review before they ship, not after. That’s a change to how a maintenance backlog is triaged.
4. Documentation and logging stop being optional hygiene
For high-risk systems, technical documentation, record-keeping and automatic logging are explicit requirements. But even below that threshold, the ability to answer “what does this model do, on what data, and what did it decide last March” becomes the difference between a manageable request and a fire drill.
Most legacy systems fail this test today, not because anyone was careless, but because nobody was asked before. Retrofitting logging and documentation into a running system is classic maintenance work, and it takes time that a deadline doesn’t grant retroactively.
5. Human oversight has to exist in the workflow, not the policy
Where obligations apply, human oversight must be effective: a person able to understand, monitor and override the system’s output. That’s an architectural property, not a paragraph in a handbook. If a system auto-approves, auto-rejects or auto-sends with no practical intervention point, adding one is a change to the workflow and often to the system itself.
6. The ground moves underneath you
The model your system calls gets deprecated. The vendor changes terms, or the processing region. A new model version behaves differently on the same inputs. Standards and guidance continue to be published, and the timelines themselves have already shifted once.
An AI-enabled system is not a “build it and forget it” asset. It requires the same ongoing attention as any critical system, plus a compliance dimension that didn’t exist before.
How Dink can help
This is, at its core, the work we already do, applied to a newer problem. Dink maintains and modernizes the systems mid-size companies depend on in Belgium and the Netherlands, and the AI Act turns several of our habits into requirements.
Finding what’s actually there. Our technology assessment is a structured review of an existing platform: what runs, on what, integrated with what. Extending it to inventory AI components and the data they touch is the natural first step toward any classification decision.
Making the changes safely. Adding transparency disclosure, retrofitting logging, building in an oversight step: these are changes to live systems that can’t go down. Staged rollouts, reversible changes and testing are how we work on critical software already.
Documenting what only lives in people’s heads. Technical documentation is a compliance artefact now. It’s also what we produce as a matter of course when we take over a system, because it’s what makes long-term maintenance possible.
Reviewing changes before they ship. Treating “does this change what the AI does?” as part of the maintenance workflow, so a routine improvement doesn’t quietly reclassify a system.
Keeping it working afterwards. Models get deprecated, vendors change terms, guidance evolves. Ongoing maintenance is what keeps an AI-enabled system both functional and defensible over time.
If you’re not sure what AI is running inside your systems, or what the AI Act means for the changes on your roadmap, that’s a good first conversation to have, and a good reason to start with an assessment rather than a rebuild.
Frequently asked questions
Does the EU AI Act apply to AI systems we already have in production? Yes. The Act reaches systems already in use, though obligations depend on the risk category and the applicable date. Transparency obligations under Article 50 have applied since 2 August 2026 and can require changes to systems already running, such as disclosing that a user is interacting with AI or marking AI-generated content.
Have the high-risk deadlines been delayed? Yes, but only the high-risk ones. Under the 2026 Digital Omnibus, standalone high-risk systems (Annex III) now apply from 2 December 2027 and AI embedded in regulated products (Annex I) from 2 August 2028. Prohibited practices, general-purpose AI rules and transparency obligations remain on their original dates.
Are most business systems high-risk under the AI Act? No. Most ordinary business uses (document extraction, internal knowledge search, summarization, routing) fall into lower-risk categories where transparency is the main requirement. High-risk categories cover defined uses such as recruitment, credit scoring, education, biometrics and AI embedded in regulated products. If your system touches those areas, treat it as high-risk until confirmed otherwise.
Can modifying an existing AI system create new obligations? It can. Significant changes to an AI system’s intended purpose or design can bring it into scope or change your role from deployer to provider. This is why classification review belongs in the maintenance process, before changes ship rather than after.
What’s the first practical step for a company with existing systems? Inventory. Map what AI is actually running across your systems, what it does, what data it touches and who provides it. You can’t classify or comply with what you haven’t catalogued, and for most companies with legacy systems, that mapping is an engineering exercise before it’s a legal one.