Codeliance Blog

Compliance Doesn't Start With a Checklist. It Starts With a Question

2026-07-30T00:00:00Z

The wrong question

Most compliance conversations start the same way: "Are we DSA compliant?"

It's the wrong question, and not because it's too hard to answer. It's because it assumes every platform is answering the same exam. They're not. The DSA doesn't hand every online service one list of obligations. It hands different services different lists, and which list you get depends on what kind of service you are and how big you've grown.

The question that actually needs answering first is narrower: which obligations even apply to us? Everything downstream, policies, engineering work, evidence, reporting, depends on getting that answer right before you start ticking boxes.

How the DSA does it

The DSA builds its obligations on a ladder. Mere conduits (pure network access) sit at the bottom. Hosting services sit above them. Online platforms sit above that. Very Large Online Platforms and Search Engines, VLOPs and VLOSEs, sit at the top, triggered once a service crosses 45 million average monthly users in the EU.

Each rung adds obligations on top of the one below it. Nothing is replaced, it's additive. A handful of obligations apply regardless of tier, most notably the exemption for micro and small enterprises. That exemption drops away the moment a small platform is designated a VLOP. Size doesn't buy you out of the rules that scale with reach.

We pulled the real numbers from our live obligation set rather than quoting a fixed figure. The honest answer changes as the regulation gets interpreted and as new enforcement guidance lands. Right now, a basic intermediary service faces a fraction of the obligations a full online platform does. A designated VLOP with advertising, a recommender system, and a marketplace faces close to the full set. Add the recommender system alone and the obligation count jumps again. Article 27's transparency requirements only switch on for services that actually rank and recommend content. Same platform, one feature flag, a materially different compliance surface.

That's the part people miss when they picture the DSA as one checklist. It's four or five checklists, and which one lands on your desk depends on answers you may not have formally worked out yet.

How the OSA does it, differently

The UK's Online Safety Act draws its lines in a different place, with different thresholds, but the same underlying logic. Ofcom's categorisation register sorts services into three tiers. Category 1 covers large user-to-user services with a recommender system: over 34 million UK users on their own, or over 7 million UK users if the service also lets users share content onward. Category 2A covers search services with more than 7 million UK users. Category 2B covers other qualifying user-to-user services that fall below the Category 1 bar.

Ofcom's own working estimate, going in, was that somewhere between 12 and 16 services would land in Category 1. The register that actually published on 10 July 2026 named 11, alongside a separate "emerging services" list for platforms close enough to the line that Ofcom is watching them without formally categorising them yet.

Different statute, different regulator, different thresholds entirely, but the same shape: size and functionality decide which obligations apply, and the line isn't always where the first estimate said it would be.

The pattern

Strip away the article numbers and the acronyms, and the DSA and the OSA are doing structurally the same thing. Neither is a flat list you compare yourself against. Both are decision logic: is this platform hosting, or an online platform, or something bigger? Does it recommend content? Does it let users share what they see? How many people actually use it, and where?

Answer those questions and the applicable obligation set falls out the other end. Get one of those inputs wrong, an outdated user count, a feature you shipped last quarter that nobody flagged, and the list you're working from is wrong too. You end up either missing obligations you're now exposed on, or carrying obligations that never applied to you in the first place.

This is what we mean by categorisation-aware compliance: treating classification as a live input to the compliance process, not a one-time form filled in at onboarding and never revisited.

Categorisation isn't a life sentence

Worth remembering: crossing a threshold isn't permanent, and it isn't always final in the direction you'd expect. Wikipedia spent over a year in the UK courts arguing it shouldn't be swept into the most demanding tier. Its case rested on a simple point: Wikipedia looks nothing like the platforms the rule was written for. It lost that specific argument, and ended up off the list anyway, watched but not categorised.

That's worth remembering next time a threshold looks like a wall instead of a door. Categorisation gets contested, and it gets revisited. A platform that grows into VLOP territory this year isn't stuck there forever if its user numbers move. A platform that adds a recommender system doesn't need to wait for its next annual review to find out what that switched on.

Why this has to be a live system, not a form

This is the part of the product we spend significant engineering effort on, and it's the part that's easiest to underrate. We don't ask a platform to self-report its tier once and generate a static obligation list from that answer. Every obligation in our system carries its own applicability logic. It knows which service tiers it applies to, which features it requires, whether the SME exemption covers it, whether it only switches on above a VLOP threshold.

We built it this way because thresholds move, features ship, and regulators publish new registers on their own schedule, not yours. Compliance is not a rules and features exercise that happens once and is then filed away and forgotten. It's a continuously moving target (in the technical sense, not the cynical one). Treat categorisation as an input you check once, and you're not doing DSA or OSA compliance. You're doing compliance for the platform you used to be.

If you're working out where your own platform sits on either ladder, we're happy to walk through it.

The €550M AliExpress Fine: What the Decision Actually Tells Compliance Teams

2026-07-27T00:00:00Z

On 20 July 2026, the European Commission fined AliExpress €550 million for breaching the Digital Services Act. It's the largest DSA fine issued to date, ahead of Temu's €200 million (May 2026) and X's €120 million (December 2025).

Most coverage will stop at the number. We think the more useful story is in the findings behind it, and what they signal to every other platform operating under the DSA.

What happened

The case has been building for over two years.

The European Commission opened formal proceedings against AliExpress on 14 March 2024, examining several areas of potential non-compliance: risk management and mitigation, content moderation and internal complaint handling, advertising and recommender system transparency, trader traceability, and researcher data access.

On 18 June 2025, the Commission resolved part of the case. AliExpress offered a set of binding commitments covering several of the articles under investigation:

Article 20 — internal complaint-handling system
Article 26 — advertising transparency
Article 27 — recommender system transparency
Article 30 — traceability of traders
Article 40 — researcher data access obligations

The Commission accepted these commitments and made them legally binding, with an independent Monitoring Trustee overseeing implementation over a five-year period.

But two issues weren't resolved by commitment. The Commission issued a preliminary finding of non-compliance on AliExpress's obligation to assess and mitigate the risk of illegal products being sold on its platform.

Thirteen months later, that preliminary finding became final. The Commission's non-compliance decision, issued 20 July 2026, concluded that AliExpress breached:

Article 34 DSA (Risk assessment): AliExpress failed to properly identify and assess the risks of illegal, unsafe, and counterfeit products being distributed through its recommender and advertising systems, and did not adequately assess whether it had sufficient staff to review those risks.
Article 35 DSA (Mitigation of risks): The measures AliExpress had in place, including its "brand authorisation" system meant to catch counterfeit sellers, were found ineffective, understaffed, and easy to circumvent. The Commission also found AliExpress overestimated how effective its detection systems actually were, and relied on a single quantitative indicator to measure whether its mitigation efforts were working.

AliExpress has until 20 October 2026 to submit an action plan addressing the breach. The Commission has said it will continue engaging with the platform, and non-compliance with the decision itself could trigger periodic penalty payments on top of the fine already issued.

Three things worth reading between the lines

The findings above are the official record. But for compliance and Trust & Safety teams navigating the DSA, three details in this decision matter more than the headline number.

1. Duration is now part of the compliance story, not just the substance.

The Commission didn't just say AliExpress had a risk. It said AliExpress knew about the risk for over a year and didn't fix it. That's a different kind of finding. It suggests regulators are watching trajectory, not just a snapshot. A platform that can show continuous, documented progress against a known risk is in a fundamentally different position than one that waits for the next audit cycle to demonstrate it did something. Compliance can't be a once-a-year event anymore. It has to be visible and ongoing.

2. The staffing question hasn't gone away, even in an AI-heavy compliance era.

The Commission's finding that AliExpress "did not properly evaluate whether it had enough people to review the risks" and "overestimated the effectiveness of its system" is notable. Across the industry, Trust & Safety headcount has been under pressure for several years, often justified by automation picking up the slack. This decision is a reminder that regulators expect platforms to know, and be able to show, that their human review capacity actually matches their risk exposure. Automation is part of the answer. It isn't the whole answer, and regulators are starting to say so directly.

3. A single metric doesn't make a risk assessment.

Perhaps the most interesting detail: the Commission found AliExpress relied on one quantitative indicator to measure the effectiveness of its risk mitigation. This points to a challenge the T&S field has wrestled with for years: what does "safe" actually look like in numbers? A removal count tells you volume. It doesn't tell you whether the products that got through caused harm, or whether your mitigation is actually reducing risk over time. Regulators are now signaling that a defensible risk assessment needs metrics that reflect effort and outcome, not just activity.

Why this matters beyond AliExpress

This decision reinforces something we've built Codeliance around: DSA compliance isn't a document you file once a year. It's an operational, ongoing obligation that has to be demonstrable at any point in time, across staffing, systems, and metrics.

Platforms that can show continuous evidence of risk assessment and mitigation, not just a report from twelve months ago, are in a stronger position with regulators. That's the gap Codeliance exists to close: turning DSA obligations into structured, testable requirements your team can validate on an ongoing basis, not just when the Commission asks.

If your team is thinking through how your compliance posture would hold up to this kind of scrutiny, we'd be glad to talk.

Compliance in the Age of AI: What Actually Changes, and What Doesn't

2026-07-22T00:00:00Z

Every few months, someone asks me if AI is going to replace compliance teams. I understand why they ask. It's a fair question when a technology this capable shows up in a field this manual.

My answer hasn't changed: AI changes how compliance work gets done. It doesn't change who should be doing it.

Here's what I mean by that.

The problem hasn't gotten simpler

Five years ago, online safety regulation meant a handful of laws. Today it's closer to 40 worldwide: the DSA, the OSA, Brazil's ECA, California's AADC, Malaysia's Online Safety Act 2025, India's IT Rules, and more arriving every year.

Each one comes with its own definitions, its own thresholds, its own enforcement style. And none of them stay still. Amendments get published. Commission guidelines get updated. Courts issue rulings that reinterpret what a law actually requires in practice.

Keeping up with that pace, manually, across every jurisdiction you operate in, is not a staffing problem you can solve by hiring one more person. It's a structural one.

Where the real difficulty lives

Ask any Trust & Safety or legal team where compliance actually breaks down, and it's rarely the reading of the law itself. It's what comes after.

Breaking a regulation into obligations. A single article can contain several distinct, separately enforceable duties. Turning 100+ pages of legal text into a clean list of "here is what we are actually required to do" takes real regulatory judgment, not just careful reading.

Translating obligations into product requirements. This is the step I've spent the most years of my career on. "Provide a user-friendly reporting mechanism" is not a specification an engineer can build from. Someone has to turn it into: where does the report button live, what fields does the form need, what happens after submission, how is receipt confirmed. That translation usually means legal and product sitting in a room together, often for longer than either side expected.

Monitoring progress once you've started. Compliance isn't a document you file once. It's an ongoing state. What's actually been implemented versus what's still open. Where the gaps are. Whether a fix from six months ago is still holding. Most teams I've spoken with are tracking this across spreadsheets, which works until it doesn't.

Fragmented regulation, hard translation, unclear progress. Those are the three places compliance work actually gets stuck.

Where AI genuinely helps

I want to be specific here, because "AI helps with compliance" is a claim I'd want to interrogate too if I were reading it.

Monitoring the regulatory landscape. AI is well suited to watching for new regulations, amendments, litigation, and court decisions as they land, and flagging when one of them changes how an existing obligation should be interpreted. This is pattern recognition and continuous tracking at a scale that doesn't fatigue. It's the closest thing to a genuine unlock in this list.

Breaking a regulation into obligations, article by article. AI can do a first, fast pass at decomposing legal text into structured, individual obligations. This is where a human has to stay in the loop. The output needs a person who understands regulatory intent to review and correct it, not just approve it.

Building scenarios that let a machine test compliance. Once an obligation is defined, you can construct a scenario: a defined action, a defined expected system behaviour, and a way to check whether the product actually does it. This is where AI's contribution depends entirely on the human writing the scenario. You need someone who knows how the product actually behaves, not just what the law says it should do. That's Trust & Safety expertise, not legal expertise or engineering expertise on its own. It's the seam between the two.

Running that verification continuously. Once you have scenarios in place, there's no reason to only check them once. AI can re-run them on a schedule (daily, weekly, monthly) or trigger them off a real event: a new feature ships, a meaningful commit lands. Instead of finding out at the next audit that something drifted out of compliance three months ago, you get a live posture. This is the piece that actually answers the "monitoring progress" problem from earlier. Compliance stops being a snapshot you take once a quarter and becomes something you can check on any given day.

Why this is, honestly, the best version of compliance we could ask for

I don't think AI replaces judgment here. I think it's the first time judgment has had proper tools to work with.

We spent years managing compliance manually: gathering people in a room, mapping workflows by hand, translating regulatory text into product logic one article at a time. That work required understanding both the law and the product deeply. AI doesn't remove the need for that understanding. It removes the parts of the work that never needed a human in the first place: the monitoring, the first-pass structuring, the repetitive scenario-building.

What's left is the part that actually requires expertise. And that's exactly where Trust & Safety and compliance people should be spending their time.

This is why we built Codeliance the way we did. Not as a system that tells platforms what to do without them, but as one built by people who managed this exact problem themselves, with the product knowledge and the regulatory background to know where AI should assist and where a human still has to make the call.

If you're navigating this same translation problem on your own team, I'd genuinely like to hear how you're approaching it.

Welcome to Codeliance

2026-07-14T00:00:00Z

They say a good product starts with a pain.

Mine started in 2017.

I had the honour of leading parts of the implementation of the General Data Protection Regulation (GDPR) at Google for Search Trust & Safety.

I remember the uncertainty.

Going back to the law again and again, trying to understand what was actually required:

What data can we store?
For how long?
What are the exemptions?

Nothing felt clear.

At some point, I gathered around 40 people in one room.

We asked them to manually document their workflows - what they do, what data they touch, where it flows.

We tried to map reality to regulation.

It was… painful.

And this was Google.

With the resources, the expertise, and some of the best people in the world working on it.

We still struggled to translate legal requirements into something operational.

And back then - we didn’t even have AI.

What hasn’t changed

Eight years later, we’re no longer talking about one regulation.

We’re talking about dozens.

From the Digital Services Act to the Online Safety Act, and many more across the world.

And the same pattern keeps repeating:

The law is written in legal language
Teams try to interpret it
Product and engineering try to implement it
And somewhere in between, things get lost

Not because people aren’t capable.

Because the process itself doesn’t work.

The real problem

It took me 8 years and about 30 Trust & Safety regulations to realise:

This isn’t just a legal problem.

It’s a translation problem.

Between law and systems.

What we’re building

This is where Codeliance comes in.

We’re building a way to take regulatory requirements and turn them into something systems can actually work with.

In practice, that means:

Breaking down laws into concrete, structured obligations and connecting them to how systems actually behave.

Not just:

“You should have a reporting mechanism”

But:

What happens when a user clicks “report”?
What needs to be captured?
What needs to be shown?
What needs to be communicated back?

And importantly:

Can you actually verify that it works?

Today, too much of compliance is still manual - living in documents, interpretations, and assumptions.

We believe more of it can live closer to the system itself.

Where this is going

We’re still early.

We’re learning a lot from the teams we work with: what’s possible, what’s not, and where this approach actually helps.

But one thing is already clear:

Regulation is becoming system-level.

And compliance will need to be built the same way.

Try the DSA Quick Check

We built a simple self-assessment that helps you map a small part of your product - like reporting mechanisms - against DSA expectations.

It takes a few minutes, and gives you a clearer view of where things might break between regulation and product.

Welcome to Codeliance.