The AI Act belongs with IT: four tasks for engineering and data teams

Who is responsible for the AI Act in an organisation? The regulation does not assign its obligations to a department. It assigns them to the organisation in its role: provider, deployer, importer or distributor. Legal determines which obligations apply. The evidence that you meet them lives in the AI inventory, the logs, the model versions and the screens on which staff can override an output. That is the work of IT, data and MLOps.

Publication note: an earlier, shorter Dutch version of this piece appeared in AG Connect (print issue 4 - 2026, section Tech & Toekomst, pp. 52-54) and online on 8 October 2026: De EU AI Act hoort niet thuis bij Legal, maar bij IT. This English version on Praxikon expands each task, connects it to the GDPR and reflects the law as it stands after the Digital Omnibus.

The moment the file changes hands

In many organisations the pattern is the same. The AI Act arrives as legislation, so it goes to Legal or Compliance. An AI policy is drafted, someone is made accountable and the topic gets a place on the risk register. That work matters. It only becomes a problem when everyone assumes the job is done.

That assumption breaks the moment someone asks a concrete question. An internal auditor, a customer in a tender or a supervisory authority asks which AI systems you use, which of them are high-risk and how you can show that a human can genuinely stop an output. The policy document has no answer. The answer sits in an incomplete CMDB, in the settings of a SaaS tool a team switched on by itself, and in logs whose retention period nobody knows.

The AI Act is legal in form and technical in substance. Teams that realise this late end up reconstructing after the fact what could have been recorded up front.

Role first, department second

Before any team starts, one question needs an answer: what role does your organisation play for each system? A provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name. A deployer uses a system under its own authority. Most organisations are mainly deployers, with the occasional in-house build for which they are the provider. The difference decides which obligations apply; the provider versus deployer comparison sets them side by side.

The role is not fixed. Under Article 25, anyone who substantially modifies a high-risk system already on the market, puts their own name on it, or repurposes a general system for a high-risk use becomes its provider. For IT teams this is not theory: a fine-tune, your own retrieval layer or a new purpose for an existing tool can be exactly that shift. The mechanics are explained in when you become a provider under Article 25.

This is where the natural division of labour lies. Legal determines the role and risk class per system and translates them into requirements. IT, data and MLOps build the facilities that produce the evidence. The business owns the use and the decisions that follow from an output. As long as these three only meet during the audit, things go wrong.

Task 1: an AI inventory that moves with your deployments

Everything starts with knowing what you run. The AI Act never literally requires an internal AI inventory, but without one you cannot classify a system, keep documentation current or show that you know where your obligations lie. That argument is set out in what the AI Act really requires of your AI inventory.

An inventory that survives an audit records, for each system, at least: the business owner, the technical owner, your role, the intended purpose, the risk class with the reasoning behind it, the underlying models and datasets, the vendor, and whether it is built or bought. For classification, use the Annex III classifier or the risk classification decision tree, and record the outcome and the date, because a classification is a snapshot.

The biggest blind spot is rarely the model your data team built. It is the AI that arrived through an update: the summary feature in the ticketing system, the assistant in the CRM, the copilot a department enabled on its own. That is why the inventory belongs at the source, not at the end. Three connections make the difference:

• Procurement: no contract for software with AI features without an inventory entry. The questions to put to a vendor are in the AI vendor due diligence guide.
• Deployment: a new model or model version in the registry automatically creates a draft inventory entry that its owner must confirm.
• Network and SaaS management: traffic to known AI APIs and newly enabled AI features in existing tools are regularly checked against the inventory. That is the practical side of shadow AI.

An inventory that is not wired into a process is out of date within a quarter. Start small and working: ten systems that are genuinely accurate beat two hundred rows nobody trusts. Providers of Annex III systems will also need to register in the EU database under Article 49, but that registration is only as good as your own inventory.

Task 2: logging and traceability as a design requirement

A high-risk system must be built so that events over its lifetime are recorded automatically. That is Article 12, and its purpose is traceability: spotting situations in which the system may present a risk or undergo a substantial modification, enabling post-market monitoring and allowing the deployer to monitor operation. The provider keeps the logs under its control for at least six months (Article 19); the deployer does the same for the logs under its control (Article 26(6)).

What that means in practice becomes clear with one question. A customer was refused a loan in March and in September a supervisory authority asks why. Can you show which model was running, which version, with which input, what score came out, which threshold applied and who reviewed the outcome? If the answer comes out of your model registry and your logging platform, you have evidence. If it lives in scattered emails and stale notebooks, you have a reconstruction.

A workable log design records, per decision, at least: a timestamp, the system and model version, a reference to the input, the output and the threshold used, whether a human intervened and what that intervention changed. These are architecture decisions, not audit decisions.

This is where the AI Act meets the GDPR head on. Logs about decisions on people contain personal data, and six months is a floor, not a licence. The AI Act's retention rules apply expressly without prejudice to data protection law, so data minimisation and storage limitation still apply: log a reference to the input rather than the full input where you can, pseudonymise, restrict access to those who need it, and record the retention period you chose and why. Designing logging together with your privacy officer saves rebuilding it later. Where the two regimes overlap more broadly is covered on the page on the GDPR alongside the AI Act.

Task 3: documentation and data that come out of the pipeline

The provider of a high-risk system draws up technical documentation before the system is placed on the market and keeps it up to date (Article 11). What it must contain is set out in Annex IV: a description of the system and its intended purpose, its design and architecture, the data used, the validation and testing procedures and results, the human oversight measures and the changes planned in advance. SMEs and start-ups could already provide those elements in simplified form; since the Digital Omnibus that also applies to small mid-caps, using a Commission form.

Almost everything Annex IV asks for already exists in some form in a mature MLOps setup: model cards, experiment tracking, evaluation reports, data lineage and release notes. The work is in connecting them. Treat documentation as code: generate most of it per release from the registry and the evaluation pipeline, version it alongside the model, and let a human add only the judgement. A document updated by hand once a year describes, within a month, a system that no longer exists.

Data governance belongs in the same pipeline. Article 10 requires providers to ensure that training, validation and test datasets meet quality criteria: provenance, relevance, representativeness, bias detection and documented choices. The detail is in data governance under Article 10. One Omnibus change matters for data teams: since 27 July 2026, the legal basis for using special categories of personal data to detect and correct bias sits in a new Article 4a, with the same conditions as the former Article 10(5) and a wider circle of organisations that can rely on it. It does not switch off the GDPR: the safeguards and the record-keeping remain, and a DPIA is the obvious step for such processing.

If you are a deployer rather than a provider, the work shifts but does not disappear. You use the system in line with the provider's instructions for use, ensure input data are relevant and sufficiently representative to the extent you control them, and use the provider's information for your DPIA (Article 26(1), (4) and (9)). Your documentation is then mainly evidence of correct use: which version, which configuration, which instructions, and what you did when the system misbehaved. The full overview is in the deployer obligations guide.

Task 4: human oversight built into the screen, not the procedure

In the AI Act, human oversight is a design requirement, not a work instruction. Article 14 requires a high-risk system to be built, with appropriate human-machine interface tools, so that natural persons can oversee it effectively. Those people must understand its capabilities and limitations, stay alert to the tendency to over-rely on outputs, be able to disregard, override or reverse an output, and be able to stop the system.

Take a model that ranks job applications. "A recruiter still looks at it" is not oversight. Oversight is a screen that shows what a score is based on and how confident the model is, a control that lets the recruiter override the ranking, a mandatory note when they deviate, and a log that shows how often that happens. If nobody ever overrides anything, that is not proof the model is good. It is a sign that oversight has become a tick box. This rubber-stamping pattern is discussed in human oversight under Article 14.

The deployer assigns oversight to people with the necessary competence, training, authority and support (Article 26(2)). That is where Article 4 comes in. Since 2 February 2025, providers and deployers have had to take AI literacy measures for their staff. Since the Omnibus (27 July 2026), the duty reads as taking measures that support the development of AI literacy, and the text states expressly that no particular level per individual must be guaranteed; the duty to take measures remains. For IT teams the link is concrete: a recruiter who does not know where the model fails cannot meaningfully override a score. Record per role which measures you took and why they suit the system and its context. What such a file looks like is shown on the page on evidence for Article 4.

The task that is often missing: changes and monitoring

AI systems change constantly: a new model version, a different threshold, extra training data, a new prompt. The AI Act has its own concept for this. A substantial modification is a change after placing on the market that the provider did not foresee in the initial conformity assessment and that affects compliance with the requirements or changes the intended purpose. A high-risk system that is substantially modified must go through conformity assessment again (Article 43(4)). Changes the provider determined in advance and recorded in the technical documentation, for example for a system that continues to learn, do not count as substantial.

For engineering, that translates into change management with an AI question built in. Every change to an inventoried system gets a short check: is this within what was described in advance, does the purpose change, does it affect accuracy, robustness or oversight? Define up front which changes fall within the margins, so that routine updates stay routine. And remember that a deployer who substantially modifies a high-risk system becomes its provider under Article 25.

Monitoring closes the loop. The provider sets up post-market monitoring (Article 72); the deployer monitors operation on the basis of the instructions for use and, where there is a risk, must inform the provider or distributor and the market surveillance authority without undue delay and suspend use (Article 26(5)). Suspending is not optional. So make sure a technical off switch exists and that someone knows when to use it. The logging from Task 2 is what makes this monitoring possible.

Where the GDPR has already done the groundwork

Organisations that took the GDPR seriously do not start from zero. The record of processing activities is a good starting point for the AI inventory, because most AI applications process personal data. DPIA practice provides the method for risk analysis, and for the deployers that must carry out a fundamental rights impact assessment, that FRIA may include or refer to relevant parts of a DPIA. The difference between the two is set out in the DPIA and FRIA comparison. The data protection officer's role and existing processor agreements also offer a structure the AI Act can plug into.

If you are also subject to NIS2 or DORA, you will see the same underlying processes return: logging, incidents, suppliers and change management. Build one control set with a view per law rather than three parallel tracks; see AI Act, NIS2 and DORA in one control set.

The timeline on 8 October 2026

The facts in the AG Connect article were checked as of early July 2026, when the high-risk postponement was politically agreed but not yet law. That has changed. The Digital Omnibus on AI was published as Regulation (EU) 2026/1744 on 24 July 2026 and has applied since 27 July 2026. Where things stand today:

For most IT teams this means two things. Article 50 is no longer something to prepare for but law in force: a chatbot that does not tell users they are talking to AI, or a generative system without machine-readable marking, is now a compliance question. The Article 50 decision tree shows which paragraph applies to which role. And the high-risk obligations now have a fixed date. That is runway, not a reason to wait: filling an inventory, classifying systems, rebuilding logging and getting documentation into the pipeline takes months. The full overview is in AI Act deadlines 2026, 2027 and 2028.

A division of labour that holds

In summary, a workable split looks like this:

Start with ten systems

The AI Act feels big as long as it is presented as one legal block. For an IT or data team it breaks down into four manageable tasks: know what you run, record what it does, document it as you build, and make sure a human can genuinely intervene. That is not a compliance project alongside the work. It is good engineering with an audit trail attached.

The worst thing you can do is wait for a policy document and assume you are done. The best thing you can do today is open your inventory and add the first ten systems. To see, for a single system, which obligations, actions and evidence apply, with the source for every step, build an implementation map.

This piece and Zahed Ashkara's other media publications are listed together on the press page.