You open a platform to watch one video, read one post or search for an answer. Within seconds, a system has decided what to place in front of you and what to leave further down the page. You can usually change a few visible settings, but the larger logic remains difficult to inspect. The Digital Services Act does not promise to publish every line of code. Instead, it builds a chain of accountability: explain the main choices, offer users a meaningful alternative, assess systemic risks, document the response and let qualified outsiders examine the evidence.
You search for a news story and the platform ranks several results before you have asked why one came first. You open a video service and the next recommendation is already waiting. The visible interface feels simple. The selection process is not.
A recommender system can use signals about content, context and user behaviour to decide what appears, in which order and with what degree of personalisation. The Digital Services Act, or DSA, treats that process as more than a private product decision for the largest online services.
Its approach is layered. Platforms must explain key aspects of their recommendation systems to users. The largest platforms and search engines must offer a non-profiling option. They must assess systemic risks, take steps to reduce them, document those steps and submit to oversight. Qualified researchers can then seek access to relevant evidence.
That is the central idea: transparency becomes an auditable chain. No single disclosure reveals everything, but each link should make the next question easier to ask.
The DSA Starts With the Screen
The first transparency obligation is user-facing. Article 27 requires providers that use recommender systems to describe their main parameters in clear and comprehensible terms. They must also explain how users can modify or influence those parameters.
“Parameters” does not mean that every user must receive a technical description of a model. In practice, the requirement is about the main factors shaping the recommendation and the controls available to the person receiving it. A platform should make the logic understandable enough for a user to see what kind of choice is being made.
That distinction matters because a vague statement such as “we personalise your experience” tells a user very little. It does not explain whether recent clicks, follows, viewing time, location, language, popularity or other signals play a significant role. Nor does it show where the user can change the balance.
The DSA does not require an interface to expose every internal variable. It requires an intelligible account of the main parameters and of the user’s ability to influence them. The practical test is whether the explanation helps someone understand why the system behaves differently when their choices change.
Consider a video platform that says it recommends clips based on “relevance and engagement.” That description may be too compressed to guide a user. A more useful explanation would identify the main categories of signals and show which controls affect the result, without pretending that the platform can reduce a complex system to one simple rule.
User-facing transparency therefore has two parts. One concerns explanation. The other concerns agency. Knowing that a system uses personalisation is not the same as having a meaningful way to alter it.
For professionals building consumer products, this changes the design brief. Recommendation controls cannot be treated as a legal footnote placed after the main experience. The control itself must be findable, understandable and connected to the system it is meant to influence.
Transparency is a chain, not a disclosure
The DSA links four questions: what does the system prioritise, what risks can it create, what has the platform done about them, and who can check the evidence?
Why Non-Profiling Options Matter
For very large online platforms and very large online search engines, Article 38 adds a more specific obligation: at least one recommender-system option must not be based on profiling.
Profiling is the use of personal data to evaluate or predict aspects of a person, often to personalise what they see. A non-profiling recommendation option does not necessarily mean that every result is random or identical for every user. It means the option is not based on a profile of that individual.
This is more meaningful than a general promise to “manage your preferences.” It gives users a different basis for receiving recommendations. The system might rely on contextual information, the characteristics of the content itself or other permitted signals rather than a personal behavioural profile.
The distinction is easy to miss in an interface. A platform may offer several feeds that look different while all depending heavily on the same profile. A genuine non-profiling option should change the basis on which the system selects or ranks content, not merely change the colour of the screen or the number of items displayed.
Why does this matter? Personalisation can make a service easier to use, but it also concentrates the platform’s influence over a person’s information environment. A user who can choose a non-profiling mode has a way to reduce that dependence on individual behavioural data.
The option also creates a useful comparison. Researchers, regulators and users can observe whether different recommendation logics produce different patterns of exposure. That comparison does not prove that one mode is safer or better in every case. It makes the consequences of the design choice more visible.
There is a practical challenge here. A platform must communicate what the alternative does without overselling it. “Not based on profiling” is a specific description of the input logic, not a guarantee that the resulting content will be neutral, diverse or free from all risks.
That caveat is important. The DSA’s non-profiling requirement gives users a meaningful alternative to one kind of personalisation. It does not turn the alternative into a complete answer to every problem associated with ranking, recommendation or content moderation.
What is a recommender system?
It is the set of rules, models and data that selects, ranks or personalises content, search results, products or accounts for a user.
From Recommendations to Systemic Risk
The DSA’s enhanced duties for very large platforms and search engines move the discussion beyond individual settings. These services must identify, analyse and assess systemic risks connected to the design and operation of their services.
A systemic risk is not simply one bad recommendation shown to one person. The term points to effects that may arise from the way a service operates at scale and affect a significant part of its users or the wider public. Recommender systems are relevant because they organise exposure: they decide what receives attention, how quickly it travels and which alternatives remain less visible.
The DSA explicitly connects this risk work to areas such as the dissemination of illegal content, threats to fundamental rights, civic discourse, public security and the protection of minors. The existence of a recommendation feature does not prove that a platform is creating any particular harm. It means the system belongs in the assessment of how such risks may arise.
This changes the question from “How accurate is the recommendation?” to “What does this design make more likely, and for whom?” Accuracy, clicks or time spent may be relevant product measures. They do not describe every consequence of a system that shapes people’s exposure to information.
Once a platform identifies risks, it must take mitigation measures. Mitigation means steps intended to reduce the risks, which may include changes to the design or functioning of the service or its recommendation systems. It does not mean that every risk disappears or that every measure works as intended.
A platform might alter ranking signals, add friction to a high-risk interaction, change how certain content is recommended, improve user controls or introduce safeguards for minors. The appropriate response depends on the risk assessment and the service. The DSA creates the obligation to assess and act; it does not provide one universal algorithmic fix.
Independent auditing and oversight complete this part of the chain. A risk report written by the platform is useful, but it remains an internal account unless external scrutiny can examine the methods, evidence and response. Documentation matters because an auditor or regulator needs to understand what the platform assessed and what changed afterwards.
For product and engineering teams, the consequence is direct. A recommender system is not only an optimisation layer. Its data, objectives, changes and observed effects may become part of the platform’s governance record.
Explanation is not code access
User-facing transparency explains the main parameters and available controls in understandable terms.
Technical access is different. It may involve internal data, documentation and secure research environments rather than public release of the software itself.
What Transparency Must Make Visible
It is tempting to translate algorithmic transparency into a demand for source-code publication. The DSA’s model is more targeted. It asks platforms to make the main logic, risks, decisions and supporting evidence sufficiently visible for different audiences.
Users need an explanation they can understand and a way to influence the main recommendation parameters. Regulators and auditors need information about risk assessments, mitigation measures and the operation of the service. Researchers may need data and technical documentation that cannot sensibly be placed in a public help centre.
These are related forms of transparency, but they are not interchangeable. A clear explanation for users will not tell a researcher how an exposure history was recorded. A data file will not, by itself, explain why a product team selected one ranking objective over another. A published model description cannot replace evidence about what the system actually did in production.
That is why documentation sits between explanation and scrutiny. The 2025 delegated regulation provides for supporting information that may include codebooks, changelogs and architectural documentation. A codebook defines fields and values. A changelog records relevant changes over time. Architectural information describes how technical components fit together.
Imagine that a researcher receives a field called recommendation_score. Without a codebook, the name does not reveal whether it is a probability, a rank, a transformed internal measure or something else. Without a changelog, the researcher may miss that its meaning changed halfway through the study. Without architectural context, it may be unclear where the value entered the recommendation process.
This is not paperwork for its own sake. It determines whether an analysis can be interpreted and, where possible, repeated. A dataset can be technically available yet scientifically weak if nobody can establish what its columns mean, which periods they cover or which systems produced them.
Transparency also needs a record of limits. Missing data, changed definitions, sampling choices and restricted fields can affect the conclusions. A useful documentation package should help an outside reader understand not only what can be studied, but also what cannot be inferred safely.
The result is less dramatic than opening a black box in one motion. It is more practical. The box becomes a set of connected records that different people can inspect for different purposes.
A useful transparency duty connects a platform’s design choice to an observable effect and a documented response.
How Vetted Researcher Access Works
Article 40 creates routes for research into systemic risks. Publicly available data can be accessed for research that contributes to detecting, identifying and understanding those risks. Vetted researchers can also request access to relevant non-public data held by very large platforms and search engines.
“Vetted” does not mean that a platform may simply choose its favourite critics or approve anyone who asks. It refers to a formal assessment of the researcher and the project under the DSA framework. The request must explain the research purpose and identify why particular data are necessary.
Commission Delegated Regulation (EU) 2025/2050, applicable from October 2025, operationalises this route. It establishes a central DSA data-access portal and a procedure involving Digital Services Coordinators. The aim is to replace an entirely informal exchange with a more structured way to submit, assess and manage requests.
A researcher therefore needs to make a case that is both specific and proportionate. “I want to understand the platform” is not a workable data request. A stronger request might identify a systemic-risk question, a defined population or period, the relevant exposure or recommendation records and the reason less sensitive data would not answer the question.
The platform then has to identify what relevant data exists and explain the conditions under which it can be accessed. Depending on sensitivity, the data may be transmitted to the researchers or made available through a secure processing environment.
A secure environment can restrict copying, extraction or other actions while still allowing analysis. That arrangement does not make research impossible. It can be a way to reduce risks when the requested data includes individual exposure histories or information used to personalise recommendations.
The regulation also addresses the information needed to understand the data. Supporting material may include data dictionaries, change records and architectural descriptions. Without these materials, an access right could produce a large but ambiguous collection of files.
There are limits. Access is not automatic for every person, every purpose or every dataset. The request must be relevant to the research framework, and security, confidentiality and protection concerns still shape the arrangement. Nor does researcher access require platforms to publish sensitive data to the general public.
That balance is central to the mechanism. Independent scrutiny needs more than public screenshots, but sensitive data cannot be treated as an unrestricted commons. The DSA attempts to create a controlled opening between those two extremes.
How a research request moves
The 2025 delegated regulation turns a broad access right into a more structured process.
- The researcher explains the project and the data needed.
- The request is assessed through the DSA framework and Digital Services Coordinators.
- The platform identifies relevant data and supporting documentation.
- Access is provided directly or through a secure processing environment when necessary.
What This Means in Practice
For a very large platform, the obligations form a connected operating discipline rather than a series of isolated compliance tasks.
First, the platform needs to know its recommendation systems. That includes the main parameters explained to users, the profiling and non-profiling options available, the data and components involved, and the changes made over time.
Second, it needs to connect those systems to its systemic-risk assessment. The relevant question is not only whether a recommender delivers content efficiently. It is whether the design can contribute to risks involving illegal content, fundamental rights, civic participation, security or minors, and how those risks are measured.
Third, mitigation must be documented as a response that can be examined. A platform should be able to describe which risk it identified, which intervention it selected, why it considered the intervention suitable and what evidence it uses to assess the result.
Fourth, the record must support external scrutiny. Auditors, regulators and vetted researchers do not necessarily need identical access. They do need enough information to understand the relationship between a system’s design, its outputs and the platform’s claims about its effects.
This can affect internal organisation. Product teams may need to preserve decisions that were once treated as temporary experiments. Data teams may need stable definitions and inventories. Legal and compliance teams may need to understand technical changes rather than reviewing a static description. Research-access teams may need to handle requests without turning every exchange into a new negotiation.
For users, the most visible result may be simpler: better explanations and a genuine non-profiling choice. Those features are the front door of the system. The less visible work behind them makes the choice more credible.
For researchers, the practical value will depend on the quality of implementation. A portal and a procedure do not guarantee relevant data, clean definitions or a successful study. Research findings will still depend on the question asked, the data supplied and the limits of the access environment.
For regulators, the chain creates more places to intervene. They can examine whether explanations are meaningful, whether risk assessments address the relevant systems, whether mitigation is documented and whether researcher access is being handled under the prescribed process.
That is also why the DSA should not be described as making algorithms fully transparent. It creates duties and routes for examination. Whether those routes reveal a particular system’s effects depends on the quality of the evidence and the seriousness of the scrutiny.
A controlled opening
Vetted-researcher access does not make personal or commercially sensitive platform data public. Relevance, security and the conditions of the research still shape what can be accessed and how.
Conclusion: Transparency That Can Be Tested
The DSA’s approach to recommender systems is neither a demand for total disclosure nor a permission slip for platforms to publish a few reassuring sentences. It builds a sequence.
Users should be told the main parameters shaping recommendations and how they can influence them. Very large platforms and search engines must provide at least one option that does not rely on profiling. The largest services must assess systemic risks, reduce them where necessary and document what they have done. Auditors, regulators and vetted researchers provide different forms of outside scrutiny.
The 2025 data-access rules make the research part more concrete. A reasoned request, a central portal, coordinator assessment, relevant documentation and secure processing arrangements give researchers a practical route toward non-public evidence. That route is controlled, not unlimited, but it reaches further than simply observing a public feed.
The useful question is therefore not “Did the platform reveal its algorithm?” That question treats transparency as a single event. Better questions are: What does the platform say the system relies on? What can users change? Which risks has the platform identified? What mitigation followed? Can an independent party examine the data and documentation needed to test those claims?
Those questions leave room for uncertainty. They also make uncertainty visible. That is the DSA’s more durable contribution: turning recommendation systems from private interfaces into objects that users can question, regulators can oversee and researchers can investigate under defined conditions.
Sources
- Regulation (EU) 2022/2065 of the European Parliament and of the Council of 19 October 2022 on a Single Market For Digital Services and amending Directive 2000/31/EC (Digital Services Act) — European Union
- Commission Delegated Regulation (EU) 2025/2050 of 1 July 2025 supplementing Regulation (EU) 2022/2065 of the European Parliament and of the Council by laying down the technical conditions and procedures under which providers of very large online platforms and of very large online search engines are to share data with vetted researchers — European Commission
- Commission Delegated Regulation (EU) 2025/2050 of 1 July 2025 supplementing Regulation (EU) 2022/2065 of the European Parliament and of the Council by laying down the technical conditions and procedures under which providers of very large online platforms and of very large online search engines are to share data with vetted researchers — European Commission
- How the Digital Services Act enhances transparency online — European Commission
- DSA: Very large online platforms and search engines — European Commission
- New measures unlock access to data from largest online platforms to support research — European Commission
- Commission holds roundtable on data access for vetted researchers — European Commission
Daymain Team
