In the enterprises I have worked with, the thing that stalled AI compliance was almost never the rules. It was that a single AI system turned out to be four different teams' problem at once, and no team owned the whole of it. People assume the EU AI Act is hard because it is complicated to read. In practice it is hard because of where it lands inside an organisation.
The Act is written as though an organisation is one actor with one set of obligations. Enterprises are not built that way. They are built out of functions that each own a slice of a system and none of the seam between them,and the AI Act lands squarely on the seams.
One AI system, four owners
Take an ordinary case: an AI tool that helps screen job applicants. Under the Act, that one system generates obligations that fall to at least four different parts of the business.
Someone has to decide whether it is high-risk, a legal and regulatory judgement about the use case.
Someone has to make sure the system itself has the required properties; logging, human oversight built in, robustness - which is engineering's problem, not legal's.
Someone has to establish what the vendor contract covers, and whether using the tool a certain way makes the firm a provider rather than a deployer - procurement's. And someone has to reconcile it with GDPR, because the same tool is almost certainly processing personal data - the DPO's.
Four functions. One system. Each of them can do their slice correctly and the organisation can still be non-compliant, because compliance lives in how the slices fit together, and fitting them together is nobody's job description.
Why the organisation chart is the real obstacle
This is the part that does not show up when you read the Act. The Act describes obligations; it says nothing about who inside a company holds them. And the honest answer, in most enterprises, is that they are held by people who do not routinely work together and do not share a language.
Legal thinks in obligations and risk. Engineering thinks in systems and tickets. Procurement thinks in contracts and renewals. The DPO thinks in lawful bases and data subjects. Each is a coherent world, largely sealed off from the others.
The AI Act asks a question that only makes sense across all four - is this specific AI system, in this specific use, compliant as a whole - and there is usually no one whose job is to hold that question.
I have watched capable teams each discharge their part and assume the rest was handled elsewhere.
The legal team classified the system and moved on. Engineering built what it was told to build. Procurement signed a contract that was silent on the Act. Nobody was wrong in their lane. The compliance failure lived in the space between the lanes, which is exactly where no one was looking.
The Act keeps landing on the seams
It is not a coincidence that the AI Act is hard in this particular way. The requirements themselves are cross-functional by nature.
Human oversight is a design property engineering builds and an operational duty the business exercises, one obligation split across two functions that have to agree on what "meaningful oversight" means. Provider-versus-deployer status is a legal question whose answer depends on facts only engineering and procurement hold. Technical documentation is engineering's output but legal's evidence.
The overlap with GDPR means the DPO and the AI Act owner, if there even is one - are describing the same processing from two directions. Almost every substantive requirement in the Act is a handoff between functions, and handoffs are where enterprises leak.
Smaller organisations sometimes have an easier time here, which sounds backwards until you see why: in a small company one person can hold the whole picture in their head. The enterprise's advantage - specialised functions, deep expertise - becomes its disadvantage the moment the obligation refuses to stay inside one specialism.
Why "just assign an owner" is harder than it sounds
The obvious answer is to appoint someone to own AI Act compliance end to end. It is the right instinct, and it is harder than it looks.
An end-to-end owner needs enough legal understanding to read the classification, enough technical understanding to know whether the system was built to requirement, enough commercial understanding to interrogate a vendor contract, and enough data-protection fluency to see the GDPR overlap.
That is a rare combination, and the person who has it is usually senior enough that AI Act coordination is not their day job. So the role gets split, or bolted onto someone already full, or left implicit, and the seams reopen.
The organisations that handle this well are not the ones with the cleverest legal reading. They are the ones that treat AI Act compliance as a coordination discipline first: a shared, current view of every AI system and which function owns which part of its compliance, kept in one place all four can see.
This is the part of the problem Montro exists to make tractable - not to replace the legal, engineering, procurement or data-protection work, but to give the four functions one picture to work from instead of four partial ones. That is a disclosed bias; the underlying point stands without us. The hard part of the AI Act, for an enterprise, is organisational before it is legal.
What this changes about getting started
If the difficulty is coordination, the first move is not to read the Act more closely. It is to make the cross-functional structure explicit before it is tested.
That means naming, for each AI system that matters, who holds the classification, who owns the technical requirements, who reads the contract, and who reconciles the data-protection overlap - and naming who holds the whole. It is quiet, procedural work, and it is what decides whether the legal reading ever actually reaches the system it applies to.
I will be honest about the limit of this framing. Coordination is necessary, not sufficient; a perfectly coordinated organisation can still get a hard classification wrong, and the Act's genuine ambiguities do not dissolve because the right people are in the room.
But in my experience the substantive hard parts are the minority. Most AI Act failures I have seen were not failures of understanding the law. They were failures of getting the understanding to the place where the decision was made.
Frequently asked questions
Why is the EU AI Act so hard for large organisations to comply with?
The difficulty is organisational more than legal. A single AI system generates obligations that fall across legal (risk classification), engineering (building in oversight, logging, robustness), procurement (vendor contracts and provider/deployer status) and data protection (the GDPR overlap) at once.
Each function can do its part correctly and the organisation can still be non-compliant, because compliance lives in the coordination between them - which is usually no single team's responsibility.
Who should own EU AI Act compliance in a company?
Ideally a single accountable owner holds the end-to-end picture, but in practice the role is hard to fill: it needs legal, technical, commercial and data-protection fluency at once, a rare combination usually found in people too senior to make it their day job. The more realistic answer is a coordination structure, a named owner for each part of each AI system's compliance, plus someone who holds the whole - kept in a shared view all the functions can see, rather than one heroic individual.
Is the EU AI Act harder for enterprises than for small companies?
In this specific respect, often yes. A small company can hold the whole compliance picture of an AI system in one person's head; an enterprise's specialised functions each hold only a slice. The enterprise's strengths - depth and specialisation, become a weakness when an obligation refuses to stay inside one specialism, which is exactly what the AI Act's requirements do.
Does buying compliance software solve the EU AI Act problem?
Not on its own. Software can give the functions a shared, current view of the AI systems and who owns which part of their compliance, which is the coordination layer most enterprises lack. But it does not do the legal classification, the engineering, the contract review or the data-protection assessment, those remain human work. What good software removes is the failure mode where four capable teams each do their part and no one holds the whole.
