The AI Act for developers: provider duties and documentation

Short answer: If you build, train or fine-tune an AI system, you are probably a provider under the AI Act — the role with the most obligations. For high-risk AI this means risk management, data quality, technical documentation, logging, transparency and human oversight. The good news: nearly all of it is engineering you build in early in the design rather than bolt on afterwards.

When are you a provider?

You are a provider if you develop an AI system and place it on the market under your own name or brand. Note: a substantial modification or fine-tuning of an existing model can also make you a provider. That role determines which obligations rest on you — see also the AI Act for procurement for the difference with the deployer.

The core obligations for high-risk AI

• Risk management system. A continuous process that identifies, evaluates and mitigates risks across the entire lifecycle.
• Data and data governance. Training, validation and test data must be relevant, representative and as error-free as possible, with attention to bias.
• Technical documentation. Record how the system was designed, trained and tested — enough for supervisors to assess conformity.
• Logging. Automatic recording of events during operation, for traceability.
• Transparency. Instructions for use that enable the deployer to operate the system correctly.
• Human oversight and robustness. Designed in, not added later — for robustness and security, work with the CISO.

The full picture is in the high-risk obligations overview.

Documentation is not a side issue

Many teams underestimate the technical documentation. Under the AI Act it is the evidence: without watertight documentation you cannot demonstrate conformity, and a system cannot lawfully reach the market. Treat documentation as part of the definition of done, not as an afterthought.

Build compliance into your process

Weave AI Act requirements into your development process: a risk check in the design phase, data quality controls in the pipeline, logging as a standard component and documentation that grows with the code. Anchor this in the broader governance framework and coordinate with the DPO wherever personal data is involved.

What to do

• Determine your role (provider or not) early in the project.
• Set up a risk management process that covers the whole lifecycle.
• Ensure data governance: provenance, representativeness and bias control.
• Make technical documentation part of the definition of done.
• Build logging and human oversight by design.
• Invest in AI literacy within the team.

For the developer the AI Act is mainly a quality framework. The systems that meet it are also the systems you can later trust, explain and maintain.