EU AI Act: Deep Dive — What Software Teams Need to Operationalize

The EU AI Act has moved from legislative text to operational reality, and software teams are now the ones expected to produce proof that controls work. For systems that are in scope, the obligations call for technical documentation, testing records, logs, and change-control history that only engineering teams can produce as part of normal delivery work. Engineering leaders, security and compliance owners, and the developers shipping AI-touching features all share accountability for showing that the right controls operated at the right time.

This page walks through what EU AI Act compliance requires, when each obligation applies, how to figure out whether a given system is in scope, and what evidence teams should be ready to produce. It also covers where tools like automated code analysis can genuinely help, and where they can't. 

What is EU AI Act compliance?

EU AI Act compliance is the practice of identifying an organization's role under Regulation (EU) 2024/1689, then producing the technical and organizational evidence that demonstrates its AI systems satisfy the obligations attached to that role. The obligations differ sharply depending on whether a system is prohibited, high-risk, subject to transparency duties, or a general-purpose AI (GPAI) model.

In practice, compliance is less a single certification and more a continuous evidencing exercise. An organization determines how it participates in the AI value chain, maps each participation to a set of duties, and then keeps a defensible record that those duties were met throughout the system's lifecycle. The record matters as much as the control itself, because supervisory authorities and downstream partners will ask to see it.

Compliance here means one thing above all: you can show your work. When a regulator, customer, or auditor asks how a given AI system meets its obligations, you can point to concrete artifacts rather than assertions.

Why does EU AI Act compliance matter now?

Because parts of it are already in force, not pending. Prohibited-practice rules and the AI-literacy duty have applied since February 2025, and obligations for GPAI-model providers since August 2025: organizations that treat the Act as a future deadline may already be missing live obligations.

The stakes for getting it wrong are real: penalties scale with severity, with the most serious breaches, such as deploying a prohibited AI practice, at the top of the enforcement range. Beyond fines, non-compliance may also contribute to liability exposure under separate legal regimes, alongside contract disputes with customers who require regulatory assurances and reputational damage.

The practical reason to start early is that evidence takes time to build. A defensible record of testing, oversight, and controls accumulates over months of normal delivery work, it can't be meaningfully assembled the week before an audit.

When do EU AI Act obligations apply?

The Act's obligations roll out in stages rather than all at once. Here's the current schedule, including a 2026 update from EU lawmakers that pushed some dates back:

• Regulation (EU) 2024/1689 entered into force on 1 August 2024. 
• Chapters I and II (the prohibited-practice rules and Article 4's AI-literacy duty) became applicable on 2 February 2025. 
• Governance provisions and obligations for providers of general-purpose AI (GPAI) models followed on 2 August 2025; GPAI models already placed on the market before that date get a separate transition deadline of 2 August 2027. 
• Most of the remaining provisions, including Article 50's transparency rules and enforcement of whatever was applicable at the time, became applicable on 2 August 2026.

The 2026 AI Omnibus, in force since 27 July 2026, revised this timetable and some substantive provisions. It added new prohibitions on systems that generate specified non-consensual intimate material or child sexual abuse material, applicable from 2 December 2026, and gave providers of synthetic-content systems already on the market before 2 August 2026 until 2 December 2026 to meet Article 50(2)'s machine-readable marking requirement. It also revised Article 4, effective from the Omnibus's own entry into force, to clarify that providers and deployers must support AI literacy among relevant staff without guaranteeing any individual reaches a specific level.

High-risk requirements carry the longest runway, and the biggest gap between "applicable" and "ready to produce evidence." Chapter III, Sections 1–3, the substantive high-risk obligations,  apply to systems classified as high-risk under Article 6(2) and Annex III from 2 December 2027, and to systems classified as high-risk under Article 6(1) and Annex I from 2 August 2028 (Article 6(5) is excepted from that deferral).

Confirm dates against the European Commission's current implementation timeline and the amended regulation text rather than older summaries — this page's legal status was last checked against both on 28 September 2026. The practical takeaway for planning: the requirements demanding the most engineering work arrive last, but the evidence they require takes the longest to assemble, so teams that wait for the high-risk deadline to start building records will not have the historical trail those obligations expect.

What is the difference between a provider and a deployer under the EU AI Act?

The Act assigns obligations by role, not by company, and defines more roles than software teams typically encounter: importers, distributors, authorised representatives, and product manufacturers among them. The three below are the ones that come up most often for teams building or using AI systems. A single organization can hold more than one across different systems, and the duties attached to each are distinct. Getting the role classification right is the hinge on which the rest of compliance turns.

Provider

A provider develops an AI system or GPAI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. Providers of high-risk systems carry the heaviest obligations, including risk management, data governance, technical documentation, record-keeping, transparency, human oversight, and accuracy and robustness requirements.

Deployer

A deployer uses an AI system under its own authority in a professional context. Deployer obligations are lighter than a high-risk provider's but real, and they center on using the system according to instructions, maintaining human oversight, monitoring operation, and keeping logs. Under Article 25's conditions, a deployer of a high-risk AI system can become its provider instead — specifically if it puts its own name or trademark on the system, substantially modifies a high-risk system, or changes the intended purpose of a previously non-high-risk system so that it becomes high-risk.

GPAI provider

A provider of a general-purpose AI model carries a distinct obligation set focused on technical documentation, information for downstream providers, a copyright policy, and a summary of training content. Models presenting systemic risk face additional duties. Most software teams building on top of these models are downstream providers or deployers rather than GPAI providers themselves.

Key distinction

Role is determined by what you do with a system, not what you are as a company. The same organization can be a high-risk provider for one product, a deployer for a purchased tool, and have minimal obligations for a genuinely low-risk internal utility. But "internal-only" is not automatically "out of scope": deploying a high-risk AI system internally still carries deployer obligations, and building one in-house for your own use can still make you its provider. Classify each activity on its own facts before assigning any obligation.

Does using an AI coding assistant make my software subject to the EU AI Act?

Not every use of AI in software development triggers a high-risk compliance program, and treating it that way wastes effort that belongs elsewhere. The productive first step is triage: separate activities that plausibly fall inside scope from those that do not, then concentrate review where the obligations actually attach.

Activities that deserve closer review

• Building or substantially modifying an AI system that is placed on the market or put into service, which can make your organization a provider.
• Deploying an AI system in a context the Act treats as high-risk, which brings deployer duties around oversight, monitoring, and logging.
• Shipping AI features subject to transparency obligations, such as systems that interact with people or generate synthetic content, which require disclosure.
• Integrating a general-purpose AI model in a way that alters its intended purpose or rebrands it, which can shift your role toward provider.

Activities that should not automatically trigger a high-risk program

• Using AI coding assistants to help write ordinary application code, where the AI supports development rather than being the product placed on the market.
• Internal-only tools with no market placement and no high-risk use, which sit outside the heaviest obligation sets.
• Standard use of a third-party AI system strictly according to its instructions, without modification or rebranding.

The distinction that matters is between AI as a feature of the product you place on the market and AI as a tool that helps you build it. The former can pull you into provider or deployer obligations; the latter generally does not, though the code it produces still needs the same verification as any other code. Confirm every classification against the current legal text and qualified counsel rather than these heuristics alone.

What evidence do I need to show EU AI Act compliance?

Compliance is proven through artifacts, and the artifacts differ by role. The goal is a defensible record that a control operated continuously, not a document assembled the week before an audit. Four evidence sets cover most software teams.

Baseline record

Every team benefits from a baseline record regardless of role: an inventory of AI systems and models in use, each activity's role classification and the reasoning behind it, and the controls applied to each. This record is the foundation an auditor or regulator starts from, and it is the first thing to build.

High-risk provider evidence

A high-risk provider must be able to produce risk management documentation, data governance records, technical documentation, logs and record-keeping, evidence of human oversight design, and results demonstrating accuracy, robustness, and security. Much of this is engineering evidence, generated as code is developed, tested, and reviewed rather than written retrospectively.

Deployer evidence

A deployer should retain evidence that it used the system according to the provider's instructions, maintained human oversight, monitored operation, and kept the logs the system generates. The burden is lighter than a provider's but still demands a traceable record over time.

GPAI provider evidence

A GPAI provider needs technical documentation for the model, information enabling downstream providers to comply, a copyright policy, and a sufficiently detailed summary of training content. Systemic-risk models require additional evidence of evaluation and risk mitigation.

How do you embed proportionate controls into the SDLC?

Governance fails when it lives in a document nobody reads and controls that nobody enforces. The connection that holds is between the obligation and the engineering activity that produces its evidence, so the proof falls out of normal work rather than a separate compliance sprint.

Proportionality is the guiding principle: match the weight of the control to the role and risk of the activity. 

• A high-risk provider warrants rigorous, documented controls across the software development lifecycle. 
• An internal tool built with AI assistance warrants the same code quality and security standards you apply to all code, without a high-risk documentation program layered on top.

A three-tier operating model keeps this proportionate. The first tier applies baseline code verification to all code regardless of origin, catching quality and security issues before they merge. The second tier adds governance for AI-touching features that carry transparency or deployer duties, ensuring disclosure and oversight controls are present and evidenced. The third tier applies the full high-risk regime, with risk management, data governance, and technical documentation, only to the systems that genuinely require it. A pragmatic starting point is a focused action plan over a first quarter: inventory and classify activities, stand up baseline verification across all code, then build the role-specific evidence sets the classification demands.

Where does code verification fit into this evidence?

Code-level tooling covers a narrow, specific slice of the evidence described above — not the compliance program as a whole.

SonarQube analyzes code changes and can be used as part of the evidence a high-risk provider needs for the security and quality management elements of Article 15 (accuracy, robustness, and cybersecurity) and Article 17 (quality management system): analysis history, quality gate results, and remediation tracking that show when configured code-analysis controls ran and what results they produced. SonarQube Advanced Security adds software composition analysis and SBOM generation, which can help document an AI system's third-party and open-source dependencies — useful background for a provider's technical documentation and data governance records, even though the Act doesn't define a separate "supply-chain" evidence category of its own.

That is the extent of it. Code analysis does not assess training-data suitability, fundamental-rights impact, human-oversight effectiveness, transparency notices, model performance, or the legal classification of a system — the evidence sets that make up most of a high-risk provider's or deployer's obligations, and that depend on legal, risk-management, and governance work rather than code scanning. Treat code verification as one input among several, not a substitute for that broader work.

Next steps

• A developer's guide to SDLC compliance — a practical model for dividing compliance responsibilities between code and environment across the software development lifecycle.
• Compliance and reporting solution — how SonarQube operationalizes standards enforcement and generates audit evidence inside development workflows.
• SonarQube Advanced Security — dependency risk analysis, SCA, and SBOM generation for software supply chain evidence.