The Compliance Work Your Clients Cannot Do Themselves

On 2 December 2026 a deadline lands that most businesses have not heard of. AI systems that were already running before August must, from that date, label the content they generate in a machine-readable way. It is the tail end of a transparency obligation that came into force on 2 August, and it applies now.

That is eleven weeks away at the time of writing. Your clients will not find out from their accountant. They will ask you, because you are the person they ask about anything with a plug in it.

This is the third piece in a series on moving a managed service business into AI and automation work. The first covered the shift, the second covered pricing. This one covers the service line that almost nobody in the channel has packaged, which is the same reason it is worth packaging.

A caveat before any of it. This is not legal advice, and nothing here makes anyone compliant. Anything material should go past a practitioner before a client relies on it.

What moved and what did not

The EU AI Act is Regulation (EU) 2024/1689. In July 2026 an amending regulation, the Digital Omnibus on AI, was published in the Official Journal on the 24th and entered into force on the 27th. It changed the timetable, and the change is widely misread as a general delay. It was not.

The obligations on prohibited practices have applied since February 2025. The rules for general-purpose models and the requirement that staff have a working level of AI literacy have applied since August 2025.

Transparency stayed exactly where it was. Since 2 August 2026, a person must be told when they are interacting with an AI system unless it is obvious, and generated or manipulated content must be labelled. Systems deployed before that date got a short reprieve on the machine-readable labelling specifically, and that expires on 2 December 2026.

What did move was the heavy end. Standalone high-risk systems, the ones listed in Annex III, shifted from August 2026 to 2 December 2027. AI embedded in products already covered by EU product safety law moved to 2 August 2028.

So the summary for a client is short. The expensive obligations are a year further out than you thought. The disclosure obligations are already live, and you are probably not doing them.

The trap that should worry an MSP specifically

Here is the part that changes how you scope work, and it is the reason this article exists.

The Act distinguishes between the provider of an AI system and its deployer. A deployer uses the system. A provider puts it on the market, and carries a far heavier set of obligations: technical documentation, conformity assessment, registration, post-market monitoring.

Under Article 25, a deployer becomes a provider if it puts its own name or trademark on a high-risk system, substantially modifies one, or changes what it is used for.

Read that again with an MSP's business model in mind. You take a foundation model or a vendor's AI service. You fine-tune it on the client's data, you wire it into their workflow, you change what it is for, you strip out a human approval step because it was slowing things down, and you deliver the result under your own firm's name because your branding is on everything you produce.

Every one of those actions is a candidate for moving you across that line. And the line matters, because the obligations on the far side of it are not a checklist, they are a programme.

This is the single most valuable thing you can tell a client, and it is also the thing you most need to get right about your own business. Work out which role you are in for every system you touch, write it down, and make it a clause in the statement of work rather than an assumption.

The mistake that makes an over-cautious adviser look wrong

The most common error in this space is over-blocking, and it damages credibility as fast as under-blocking damages the client.

Article 5 prohibits inferring emotions in the workplace, and a lot of advisers stop reading there and tell clients that any sentiment analysis is illegal. It is not. The prohibition applies to inferring emotions from biometric data, meaning facial images, voice, physiological or behavioural signals.

Scoring the sentiment of written text, support tickets or survey responses is not caught by that prohibition. It is very likely high-risk under Annex III where it touches employment, worker monitoring or evaluation, which brings the December 2027 obligations, a data protection impact assessment and a duty to inform workers. Those are real requirements. They are not a ban.

An adviser who tells a client something is forbidden when it is merely regulated has cost them a project and taught them something false. When the client eventually finds out, everything else you told them is in question.

What you actually enforce

Governance sold as a service is not a policy document. It is a set of things that are true about a client's estate, and that you keep true.

Start with the register. Every AI system and automation in the business, with an owner by name, what it does, what data it touches, how much it decides on its own and what happens when it is wrong. A register nobody maintains is out of date by March, so the version that works fills itself as things get built.

Then the controls that follow from the risk. A named owner at every level. Human review and an audit log once a system acts on real data. A stop mechanism and a disclosure to the people on the receiving end once it is talking to anyone outside the company. For high-risk systems there is a specific retention duty: deployers must keep automatically generated logs for at least six months, and if you set a longer house standard, label it as yours rather than implying the law requires it.

Then discovery, because the register only covers what you know about. Pull ninety days of DNS and cloud audit logs and find the AI services staff are already using on their own. Every business has them. Sorting those into approved, restricted and prohibited, with a reason attached to each, is a deliverable clients understand immediately.

And the disclosures, which are live now. Any chatbot facing a customer, any generated content going out, any synthetic media. That is this quarter's work, not next year's.

Packaging it

The commercial shape is the same as the rest of the series. A fixed-fee assessment to start, in the low tens of thousands for a mid-market client, that produces the register, the discovery findings, the role determination for each system and a prioritised plan.

Then a monthly retainer, a few thousand a month, for the part that never ends: keeping the register current, watching for drift, updating the controls as systems change, and a quarterly review with someone senior enough to decide things.

Discrete engineering work sits on top as fixed-fee pieces of work rather than being folded into the retainer, so the recurring number stays honest.

The reason this sells is not fear. It is that the client cannot do it themselves and their existing suppliers are not offering it. Their lawyer can tell them what the law says but cannot see their tenant. Their AI vendor has an interest in the answer. You can see the estate, you already hold the access, and you are the only party in the relationship who can turn a legal obligation into a configuration change.

What you must not sell

Be careful about what you claim, because this is the one service line where overclaiming is itself the risk.

You cannot sell compliance. You can sell a structured self-assessment, a register that is current, controls that are evidenced, and a documented position on which role your client occupies for each system. A status of confirmed means the checks passed, not that every control is in place, and the gap between those two things should be visible on the report rather than smoothed over.

Do not put a certification claim on anything. Do not describe a screening as an audit. And when a question is genuinely legal, which most of the interesting ones are, say so and bring in someone qualified. An MSP that knows where its competence ends is considerably more sellable than one that does not.

There is also an honest argument against starting here at all. If your clients are UK-only, sell nothing into the EU and have no EU-based users, the Act may not reach them, and leading with it will make you look like you are selling by alarm. Lead with the register instead, which is useful to every business regardless of jurisdiction, and bring the regulation in only where it actually applies.

Where to start

Do your own estate first. You cannot sell a register to a client while your own automations run unowned, and the exercise will teach you what the client conversation feels like from the other side.

Then pick one account and run the assessment properly. You will need a map of how that business actually works before you can say which of its processes are high-risk, who owns them and what a system touching them is allowed to do.

abi. Clone for MSPs builds that map from interviews with the client's own team, and every automation built from it arrives on an AI register with an owner, a risk tier and the controls that tier calls for, scored from what the workflow actually does rather than from a form somebody filled in. It is a structured self-assessment, not legal advice, and it does not certify compliance.

Eleven weeks to the labelling deadline. The assessment is a three-week engagement.

Sources: Regulation (EU) 2024/1689; the Digital Omnibus on AI, published in the Official Journal 24 July 2026, in force 27 July 2026; Article 25 on provider and deployer roles; Article 26(6) on log retention; Article 50 on transparency; Article 99 on penalties.