Who owns EU AI Act compliance? A guide for engineering leaders

Ask five people at a software company who owns EU AI Act compliance and you'll often get five different answers, or worse, five versions of "not me." Legal assumes engineering handles the technical requirements. Engineering assumes legal reads the regulation and tells them what to do. The data science team thinks of it as a product question. Product thinks it's a governance question. Meanwhile the August 2, 2026 deadline for high-risk systems keeps getting closer, and the documented, auditable process the Act expects doesn't build itself.

This is a coordination problem more than a technical one. The Act doesn't map cleanly onto any single existing function, which is exactly why it falls through the cracks. This piece lays out who actually needs to do what, where the seams are, and how engineering leaders, QA, and compliance can split the work without dropping the parts in between.

If you haven't yet worked out which of your features are even in scope, start with our guide to classifying AI systems under the Act. The ownership question only matters for the features that land in the high-risk tier, so classify first, then assign.

Why this falls between functions

Most regulations a software company deals with have a natural home. GDPR has a Data Protection Officer. SOC 2 has security. Financial controls have finance. The EU AI Act is awkward because its obligations span the whole product lifecycle and pull in skills no single team owns.

Look at what the Act actually demands for a high-risk system. A risk management system that runs across the lifecycle. Data governance covering training, validation, and test datasets. Technical documentation detailed enough to reconstruct decisions. Automatic logging. Human oversight that provably works. Accuracy, robustness, and cybersecurity testing. A conformity assessment before launch. Post-market monitoring after it. That list touches legal, data science, ML engineering, QA, security, and product. No wonder it stalls.

The teams that handle this well do one thing early: they name a single accountable owner, then distribute the work underneath that owner with clear handoffs. The owner doesn't do everything. They make sure nothing is nobody's job.

The accountable owner: usually a compliance or product lead

Someone has to own the answer to "are we compliant, and can we prove it?" In most organizations that's a compliance lead, a head of product, or in larger companies a dedicated AI governance role. The European Commission's own framing of the Act treats compliance as an organizational obligation, not a developer task, which is a useful hint about where accountability should sit.

What the accountable owner actually does: maintains the inventory of AI systems and their risk classifications, decides which features get built or held based on compliance readiness, owns the relationship with any notified body or regulator, and signs off that the technical file is complete before launch. They don't write the tests or the data documentation. They make sure those things exist and connect.

The mistake here is handing accountability to someone with no authority to stop a launch. If the owner can't say "this isn't ready to ship into the EU yet" and have that stick, the role is decorative. Compliance ownership needs a real gate in the release process.

Engineering leaders: you own the parts that have to be built in

If you run engineering or data science, here's the uncomfortable truth: several of the Act's requirements can't be bolted on at the end. They have to be designed into the system, which makes them yours.

Logging and traceability. The Act requires high-risk systems to automatically record events over their lifetime so behavior can be traced. That's an architecture decision. If your system wasn't built to log the inputs, model versions, and decisions that matter, you can't retrofit it cleanly under deadline pressure.

Human oversight mechanisms. The Act requires that a human can understand, override, and where needed stop a high-risk system. The override and kill-switch aren't features you add for a demo. They're compliance infrastructure, and they have to actually work, which means they have to be tested as first-class functionality.

Data governance. The requirement that training, validation, and test data be relevant, representative, and as error-free as possible lands on whoever owns the data pipeline. Documenting data lineage after the fact is painful. Capturing it as you go is cheap.

The engineering leader's real job is sequencing: making sure these built-in requirements show up in the design phase for any feature heading toward the high-risk tier, rather than surfacing in a panic during the conformity assessment. This is the same lesson teams learned with GDPR. Privacy by design was cheaper than privacy retrofitted. Compliance by design will be too.

QA: the function that quietly inherited the proof burden

Here's the shift a lot of organizations haven't fully absorbed. The Act doesn't just require that AI systems work correctly. It requires that you can prove they work correctly, with records. Proving a system behaves as specified, under defined metrics, with an auditable trail, is QA's core competency. The Act effectively drafts QA into the compliance function.

We covered the testing techniques in depth in our guide to testing non-deterministic AI: metamorphic testing, statistical acceptance bands, adversarial robustness, drift monitoring, and bias slicing. The point for this discussion is who owns them. QA does, with data science supplying the metrics and thresholds. The ownership split that works:

• Data science defines what "good enough" means: the accuracy bands, the fairness thresholds, the acceptable error rates. The Act requires these to be defined before testing (Article 9 says "prior defined"), so this can't be QA guessing after the fact.
• QA owns the execution and the evidence: running the tests, recording results, maintaining the link from each requirement to its tests to their outcomes, and keeping that chain auditable over time.
• Together they own the regression story: bias and robustness checks that run continuously, not as a one-time pre-launch audit.

When the auditor asks how you validated that your hiring model doesn't discriminate, the answer isn't a slide. It's a test plan, the execution records, and the trend line over months. That's a QA artifact, and producing it on demand is much easier when your test management carries requirements traceability and immutable history rather than living in spreadsheets and CI logs that roll off after thirty days. It's one of the reasons we built qtrl with that chain intact on every plan.

Legal and security: the bookends

Legal owns interpretation. The classification edges, the contractual allocation of provider versus deployer obligations, the regulator relationship, and the read on where genuine ambiguity sits all belong to counsel who knows the Act. Engineering should not be guessing at whether a feature qualifies for the Article 6(3) exemption. Legal should rule on it, with engineering supplying the technical facts.

Security owns the cybersecurity slice of Article 15. The Act explicitly requires high-risk systems to be resilient against attempts to alter their use or behavior, which pulls in adversarial robustness, prompt injection defenses for LLM-based features, and protection against data poisoning. That work overlaps with QA's adversarial testing, so the two functions need to agree on who runs what rather than both assuming the other has it.

A division of labor that actually holds

Pulling it together, here's the assignment that works for a typical software company shipping high-risk AI features:

• Accountable owner (compliance or product lead): AI inventory, risk classification sign-off, the launch gate, regulator relationship, final ownership of the technical file.
• Engineering leadership: logging and traceability architecture, human-oversight mechanisms, data governance and lineage, sequencing compliance work into the design phase.
• Data science: defining accuracy and fairness metrics and thresholds before testing, owning model evaluation methodology.
• QA: test execution and evidence, requirements-to-results traceability, continuous bias and robustness regression, the audit-ready record.
• Legal: classification rulings, provider/deployer allocation, regulator interpretation, ambiguity calls.
• Security: cybersecurity resilience, adversarial and poisoning defenses, coordinated with QA's robustness tests.

The seams between these are where things break, so name them explicitly. Who decides a classification when legal and engineering disagree? Who owns the threshold when data science proposes a number QA thinks is untestable? Who signs that the technical file is complete? Write those handoffs down. The Act rewards organizations that can show a deliberate, documented process, and punishes the ones improvising.

The first three things to do this quarter

If your organization hasn't assigned this yet, three moves matter more than the rest.

First, name the accountable owner and give them a real launch gate. Until one person can stop a non-compliant feature from shipping into the EU, the rest is theater.

Second, get QA, data science, legal, and security in one room and walk the division of labor above against your actual high-risk features. You're not after a perfect RACI chart, just confirmation that every obligation has exactly one owner and that the handoffs are explicit.

Third, pick where the evidence lives, and pick it now. The single biggest determinant of whether a conformity assessment goes smoothly is whether your classification decisions, test results, threshold rationales, and oversight verifications sit in one traceable place or scattered across a dozen tools. Gartner has reported that 68% of software engineering functions build AI-powered features, while only 3% have documented processes with full adherence. That gap, between "we test" and "we can prove we tested," is an evidence-management problem, and it's solvable before August if you start now.

That last point is where structured test management earns its keep. qtrl keeps the chain from requirement to test to recorded result intact, with immutable history on every plan, so the proof an auditor wants is already assembled rather than reconstructed. If your team is dividing up EU AI Act work and needs a place for the evidence to live, try qtrl free and see how it fits the way you've split the responsibilities.

This is part of our EU AI Act series. See also: is your AI feature high-risk, what the Act means for QA, and how to test non-deterministic AI.