EU DSA Recommender System Transparency 2026: SaaS Developer Compliance Guide
Post #1361 in the sota.io EU Compliance Series
If your SaaS product ranks, filters, or personalises content for users — a newsfeed, a search result, a product recommendation, a job match, a content queue — the EU Digital Services Act (DSA) has specific things to say about how you must disclose that logic to your users and, if you reach certain thresholds, to regulators. Algorithmic transparency is no longer optional in the EU. As of February 2024, the DSA is fully enforceable for all intermediary services, and Article 27 (plus Articles 38–40 for Very Large Online Platforms) creates legally binding recommender system disclosure obligations.
This guide explains what counts as a "recommender system" under the DSA, who is subject to the transparency rules, what you must disclose and how, the opt-out requirement, and what documentation your compliance programme needs.
1. What Is a Recommender System Under the DSA?
The DSA defines a recommender system in Article 3(s) as:
"a fully or partially automated system used by an online platform to suggest in its online interface specific information to recipients of the service, or prioritise that information, including as a result of a search initiated by the recipient of the service or otherwise determining the relative order or prominence of information displayed."
This definition is broad by design. It captures:
- Content feeds that rank posts, articles, or updates
- Search results that order listings by relevance, rating, or behavioural signals
- Product recommendation engines ("customers also viewed", "recommended for you")
- Job / freelancer / service marketplaces that surface listings based on matching algorithms
- Notification ranking that decides which alerts reach users first
- Email digest curation that selects which items appear in a summary
What it does NOT capture:
- Pure chronological ordering with no algorithmic prioritisation
- Manual editorial curation by humans (though hybrid systems still qualify if automation plays a role)
- Internal platform routing not visible to recipients (e.g., load-balancing)
The key test is whether automated logic influences what users see and in what order in a recipient-facing interface. If yes, you have a recommender system.
2. Who Is Subject to Which Rules?
The DSA creates a tiered obligation structure:
Tier 1: All Online Platforms (Article 27)
Scope: Any "online platform" — i.e., a hosting service that, at users' request, stores and disseminates information to the public. This includes B2C SaaS, marketplaces, community platforms, job boards, content-sharing tools. Micro-enterprises (fewer than 10 employees and annual turnover or balance sheet under €2M) are temporarily exempt from Article 27 until they grow beyond the threshold.
Obligation: You must publish at least one recommender system explanation in your Terms of Service or a dedicated policy. This explanation must cover the main parameters used in the system and the relative importance of those parameters to the user.
Tier 2: Large Online Platforms (LOPs — Article 38)
Scope: Platforms with more than 45 million monthly active EU users. Designated by the European Commission.
Additional obligations: Must offer recipients the ability to use at least one recommender system option that is not based on profiling (i.e., a non-personalised, non-tracking-based alternative).
Tier 3: Very Large Online Platforms and Very Large Online Search Engines (VLOPs/VLOSEs — Articles 38–40)
Scope: 19+ million monthly active EU users OR designated by the Commission. Currently includes Amazon, Apple, Facebook, Google, Instagram, LinkedIn, Microsoft Bing, Pinterest, Snap, TikTok, Twitter/X, Wikipedia, YouTube, Zalando, and others.
Additional obligations: Algorithmic audit rights, data access for vetted researchers, annual systemic risk assessments, and Code of Conduct participation.
For most SaaS developers, Tier 1 (Article 27) is the relevant requirement.
3. Article 27: The Core Transparency Obligation
Article 27 requires online platforms to set out in their Terms of Service, in plain and intelligible language, the main parameters of any recommender systems used, the relative importance of those parameters, and how users can influence them.
3.1 What Are "Main Parameters"?
You do not need to disclose your full algorithm or proprietary source code. The DSA requires disclosure of the main factors that influence ranking. Typical examples:
| Signal category | Example parameters |
|---|---|
| Content relevance | Keyword match score, topic classification, freshness |
| User behaviour | Click-through rate, dwell time, past interactions |
| Quality signals | User ratings, report counts, engagement velocity |
| Contextual | Time of day, location, device type |
| Commercial | Paid promotion, sponsored placement |
| Safety | Moderation status, trust score |
You must explain which of these (or similar) categories apply to your system and — crucially — their relative importance: does recency outweigh engagement? Does a paid boost override organic signals? Is safety filtering applied before or after relevance scoring?
3.2 Relative Importance
Regulators interpret "relative importance" as requiring more than a list. You must indicate whether parameters are:
- Applied as hard filters (must be present or absent) vs. ranking signals (influence score)
- Primary (dominant weight in the final rank) vs. secondary (tiebreakers or boosters)
- Dynamic (learned from user behaviour over time) vs. static (fixed business rules)
A ranked list of parameters with a one-sentence weight descriptor per parameter satisfies the requirement for most Tier 1 platforms.
3.3 User Influence Options
If your system allows personalisation (e.g., interest preferences, blocked topics, language filters), you must explain how users can access and modify these settings. If you provide no user influence options, you must say so clearly — and regulators may treat absence of opt-out as an aggravating factor in any enforcement proceeding.
4. The Opt-Out Requirement (Article 27(2) and Article 38)
Article 27(2) requires online platforms to offer users the ability to access content recommendations that are not based on profiling — at least when the user has not consented to profiling under GDPR. This requirement:
- Applies to all online platforms (not just LOPs/VLOPs)
- Means you must offer at least one alternative ordering mode — typically chronological, alphabetical, or unranked
- Does not require the alternative to be the default mode
- Must be accessible "with equal prominence" — not buried in a settings submenu
Practical implementation for SaaS:
// Simplified React example — sort mode toggle
type SortMode = "recommended" | "chronological" | "alphabetical";
interface FeedControlProps {
currentMode: SortMode;
onModeChange: (mode: SortMode) => void;
}
function FeedControl({ currentMode, onModeChange }: FeedControlProps) {
return (
<div role="group" aria-label="Content ordering preference">
<label>
<input
type="radio"
name="sort"
value="recommended"
checked={currentMode === "recommended"}
onChange={() => onModeChange("recommended")}
/>
Recommended (personalised)
</label>
<label>
<input
type="radio"
name="sort"
value="chronological"
checked={currentMode === "chronological"}
onChange={() => onModeChange("chronological")}
/>
Newest first (no profiling)
</label>
</div>
);
}
The preference should be persisted per user account and respected across sessions. If a user has not consented to personalisation under GDPR, the non-profiling mode should be the default.
5. What You Must Document
For DSA compliance purposes, your recommender system documentation should cover:
5.1 System Description
- What inputs does the system receive (user signals, content metadata, business rules)?
- What does it output (ranked list, score, filtered subset)?
- Is the system ML-based, rule-based, or hybrid?
- Who has the ability to override algorithmic outputs?
5.2 Parameter Registry
A parameter registry documents each signal used in ranking, its data source, its weight or role (filter vs. booster), and when it was introduced or last modified. This document is not published publicly but must be available to regulators on request.
5.3 User-Facing Disclosure
The public-facing policy that satisfies Article 27. Minimum content:
- Overview of the recommender system's purpose
- List of main parameters and their relative importance
- How users can view and adjust their profile/preference signals
- How to access the non-profiling alternative ordering mode
- Contact point for questions about algorithmic decisions
5.4 Change Log
Significant changes to the recommendation algorithm should be logged with a date and summary. If changes affect the Art. 27 disclosure material, the policy must be updated. This is particularly important for ML systems where the model re-trains continuously — document the re-training cadence and whether the parameter set itself changes.
6. Interaction with GDPR
Recommender systems typically rely on personal data — behavioural data, interaction history, inferred preferences — which makes GDPR directly relevant alongside the DSA.
| GDPR obligation | DSA interaction |
|---|---|
| Legal basis for profiling | The DSA does not create a new legal basis. If you rely on consent for personalisation, the Art. 27(2) non-profiling option is the mechanism users use to withdraw it. |
| Data minimisation (Art. 5(1)(c)) | Collect only the behavioural signals your algorithm actually uses. Document this in your RoPA. |
| Right to explanation (Art. 22) | Automated individual decisions that produce legal or similarly significant effects still require human review on request. Recommender systems that influence access to jobs, credit, housing, or healthcare may trigger Art. 22. |
| Right of access (Art. 15) | Users can request their profiling data — including the inferred preferences your system has built. Build an export mechanism for this data. |
| Privacy by design (Art. 25) | Differential privacy, k-anonymity, or on-device processing techniques can reduce the personal data footprint of recommendation signals. |
Key rule of thumb: If your recommender system processes personal data (almost all do), your DSA transparency policy and your GDPR privacy notice should reference each other. The "how we recommend content" section of your privacy notice and the "how our recommender system works" section of your ToS should be consistent.
7. The Transparency Report Obligation (VLOPs)
For Very Large Online Platforms, Article 42 requires a publicly available Transparency Report published at least every six months. For Tier 1 platforms (most SaaS), there is no mandatory transparency report, but publishing a voluntary annual report covering algorithmic changes, moderation rates, and user preference adoption is increasingly considered best practice — particularly in regulated sectors (financial services, healthcare) where users expect explainability.
8. Sector-Specific Considerations
Marketplaces and B2B platforms
If your platform surfaces business listings (e.g., freelancers, agencies, service providers) to paying customers, the DSA's P2B Regulation (Regulation (EU) 2019/1150) also applies. It requires you to disclose ranking parameters to the businesses being ranked (not just to consumers). The DSA amplifies this for the consumer side.
AI-powered recommendations
If your recommender uses an AI/ML model, note that the EU AI Act's transparency obligations (Article 50) may additionally apply if the system is used for purposes involving natural persons and produces outputs that influence their access to services. For AI recommenders that significantly affect user access to information (e.g., in news, education, or finance contexts), documenting the model card and providing an explanation pathway aligns with both DSA and AI Act obligations.
Job and talent platforms
Recommender systems that match job seekers with positions, or employers with candidates, may constitute "high-risk AI systems" under EU AI Act Annex III point 4 if the platform has more than 250 employees or annual turnover above €50M. In that case, you need a full conformity assessment, not just DSA transparency disclosure.
9. Enforcement and Penalties
DSA enforcement is handled by the Digital Services Coordinator (DSC) of each member state, coordinated by the European Commission for VLOPs. For Tier 1 platforms:
- National DSCs can open investigations and impose fines up to 6% of global annual turnover
- Fines require a formal infringement finding — a missing or inadequate Art. 27 disclosure is a likely audit trigger rather than an immediate fine
- Repeat violations within 15 months can trigger escalated enforcement
The DSC in Germany is the Bundesnetzagentur. In France it is the ARCOM. In Ireland (where many US tech companies are registered) the Coimisiún na Meán. For EU-headquartered platforms, jurisdiction follows the country of establishment.
10. 6-Step Compliance Checklist
- Map: Identify every recommender system in your product (feeds, search, notifications, recommendations, email digests)
- Document: Create an internal parameter registry for each system (inputs, weights, override rules, re-training cadence)
- Disclose: Update your Terms of Service or add a standalone "How our recommendation system works" page per Art. 27
- Opt-out: Implement at least one non-profiling alternative ordering mode, accessible with equal prominence
- Integrate GDPR: Align your ToS disclosure with your privacy notice; ensure your RoPA covers recommender system signals
- Review AI Act: If your system influences access to employment, credit, education, or healthcare and you exceed SME thresholds, check EU AI Act Annex III applicability
Summary
The DSA's recommender system transparency rules are not just about Very Large Online Platforms — they apply to all online platforms that rank, filter, or personalise content. Article 27 requires a plain-language disclosure of your main ranking parameters and their relative importance, plus at least one non-profiling ordering option. Compliance is achievable with a well-structured policy update and a UI toggle, but it requires actual documentation of your algorithm — not just a generic "we use AI to personalise your experience" statement. Pair this with your GDPR obligations around profiling and you will have a robust, audit-ready transparency programme.
Next in this series: EU DSA + GDPR + NIS2 Combined Platform Compliance Stack 2026 — the integrated framework for SaaS platforms that need to satisfy all three simultaneously.
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.