Insights

Research Regulation in Finland - 2026 Edition

katri.harjuvetelainen@regulyn.com (Katri Harjuveteläinen) — Wed, 29 Jul 2026 10:23:28 GMT

In Finland, research regulation is extensive and precisely defines how clinical trials may be conducted and data used. Staying up to date on these regulations while focusing on your daily work can be time-consuming.

At Regulyn, we have compiled key legislation related to clinical research and health and social services registry research. The goal is to make the work of researchers and healthcare professionals easier. This way, you can return focus to your passion.

This list is updated regularly (last updated May 1, 2026).

EU AI Act Risk Categories

katri.harjuvetelainen@regulyn.com (Katri Harjuveteläinen) — Tue, 28 Jul 2026 20:05:56 GMT

The EU Artificial Intelligence Act (“EU AI Act”) is the first comprehensive legal framework governing AI systems. It introduces a risk-based approach, classifying AI systems into four categories. This tiered approach ensures that regulatory burden matches the potential harm an AI system could cause.

Understanding these classifications is essential for organizations operating AI systems in the European market.

Prohibited AI Systems (Unacceptable Risk)

Certain AI practices are entirely banned within the EU due to unacceptable risks to fundamental rights and safety.

🚫 Prohibited practices include:

Subliminal manipulation techniques
Exploitation of vulnerabilities (related to age, disability, or socio-economic status)
Social scoring
Real-time remote biometric identification (narrow exceptions apply)
Biometric categorization using sensitive attributes (race, political opinions, sexual orientation)
Emotion recognition in workplace and educational settings
Untargeted scraping of facial images (from internet or CCTV)
Specific use cases in law enforcement (limited exceptions exist)
NEW: nudifiers and generation of unconsentual sexual images

The prohibition applies both to the intended purpose and the actual effect of an AI system. An AI system producing manipulative or exploitative effects falls under the prohibition even where such outcomes were unintended.

Compliance consideration: Organizations must ensure prohibited AI systems are not placed on the market, put into service, or used within EU territory. The ban applies regardless of where the system was developed.

Example: A multinational corporation cannot deploy emotion recognition technology to assess employee engagement, motivation, or dissatisfaction in its EU offices, even if the same system operates legally in non-EU locations.

High-Risk AI Systems

⚠️ High-risk AI systems face the most extensive regulatory requirements under the EU AI Act. Two pathways lead to high-risk classification.

First pathway: AI systems serving as safety components of products covered by EU harmonization legislation (such as medical devices, machinery, or aviation equipment), or products themselves subject to such legislation.

Second pathway: AI systems operating in specific application areas listed in Annex III:

Biometric identification and categorization
Management and operation of critical infrastructure
Education and vocational training (determining access, assessing learning outcomes)
Employment, worker management, and access to self-employment (recruitment, promotion, contract termination)
Access to essential private services and public assistance benefits
Law enforcement (risk assessments, evaluation of evidence reliability)
Migration, asylum, and border control management
Administration of justice and democratic processes

De minimis exception: Annex III systems avoid high-risk classification when they perform narrow procedural tasks, improve human activity results, or detect decision-making patterns—provided they do not replace human assessment and do not materially influence outcomes.

Compliance obligations for high-risk systems include:

Comprehensive risk management system
Data governance and management practices
Technical documentation
Automatic logging capabilities
Transparency and information provision
Human oversight measures
Accuracy, robustness, and cybersecurity requirements
Quality management system
Registration in EU database
Post-market monitoring
Incident reporting obligations

Obligations fall primarily on providers (those placing systems on the market or putting them into service). Deployers face specific requirements including human oversight implementation, input data monitoring, use according to instructions, and registration duties.

Examples:

Recruitment AI: An organization uses AI to screen CVs, rank candidates based on predicted performance, or recommend hiring decisions. This qualifies as high-risk employment AI requiring comprehensive documentation, risk management, and human oversight.

Medical device AI: A healthcare provider implements AI software analyzing real-time patient conversations to assess depression or anxiety severity. The system likely falls under both EU AI Act high-risk requirements (as safety component software) and Medical Device Regulation obligations, requiring dual compliance.

Compliance consideration: Organizations often benefit from structured legal support when implementing high-risk AI systems given the breadth of obligations and potential penalties for non-compliance (up to €35 million or 7% of global annual turnover).

Limited-Risk AI Systems

🤖 Limited-risk AI systems trigger primarily transparency obligations under Chapter IV of the EU AI Act. While not explicitly defined as a risk category, these systems typically involve human interaction or synthetic content generation.

Transparency requirements apply when:

AI systems interact directly with natural persons (Article 50)
AI generates or manipulates image, audio, or video content (deepfakes)
AI generates or manipulates text for public information purposes

Provider obligations include:

Disclosing AI interaction to users (chatbots, virtual assistants)
Labeling AI-generated or manipulated content (synthetic media)
Designing systems to enable deployers to meet their transparency obligations

Deployer obligations include:

Informing natural persons when emotion recognition or biometric categorization AI processes their data
Disclosing deepfakes and AI-manipulated text published to inform the public (exceptions for authorized detection activities, content clearly labeled as parody/satire)

Example: A government agency implements an AI chatbot on its public website to help citizens navigate services and locate information. The chatbot must clearly disclose to users that they are interacting with an AI system rather than a human agent.

Compliance consideration: Transparency obligations may also arise under other regulations, particularly GDPR Article 13-14 (information to data subjects) and Article 22 (automated decision-making). Organizations should ensure coordinated compliance across applicable frameworks.

Minimal-Risk AI Systems

🆗 Some AI applications fall into the minimal-risk category, facing no specific obligations under the EU AI Act. These systems pose no risk to safety, health, or fundamental rights.

The Act encourages but does not mandate voluntary codes of conduct for minimal-risk AI. Organizations may adopt such codes to demonstrate responsible AI practices and align with broader governance expectations.

Examples:

Spam filtering: Email systems using AI to detect and categorize spam messages

Video enhancement: Creative software applying AI for color correction, resolution enhancement, or editing assistance

Compliance consideration: While the EU AI Act imposes no specific requirements, minimal-risk AI remains subject to other applicable regulation. GDPR requirements apply where personal data processing occurs. Sector-specific rules may impose additional obligations depending on the application context.

Classification Methodology

Determining correct risk classification requires systematic analysis.

Prohibited use check: Does the system or its effects fall within Article 5 prohibitions?
Harmonized legislation assessment: Does the AI system serve as a safety component for products under EU harmonization legislation?
Annex III evaluation: Does the system operate in a listed high-risk application area? If yes, does the de minimis exception apply?
Transparency trigger analysis: Does the system interact with humans or generate synthetic content?

Compliance consideration: Classification is not always straightforward, particularly for general-purpose AI systems, AI components within larger products, or systems with multiple functions. Organizations facing classification uncertainty benefit from legal assessment early in development or deployment planning.

Practical Next Steps

Organizations operating AI systems in the EU market should prioritize:

System inventory: Document all AI systems in use or development, including purpose, data sources, and deployment contexts
Classification assessment: Apply the risk-based framework to each identified system
Obligation mapping: Identify specific compliance requirements for each classified system
Gap analysis: Assess current practices against required documentation, technical measures, and governance structures
Implementation planning: Develop timelines and resource allocation for achieving compliance

Organizations with high-risk AI systems face the most substantial compliance burden and should consider structured legal support to ensure comprehensive implementation of required controls.

SRB Ruling - Can pseudonymization make data anonymous?

katri.harjuvetelainen@regulyn.com (Katri Harjuveteläinen) — Tue, 28 Jul 2026 19:27:48 GMT

The Court of Justice of the European Union delivered a landmark judgment in September 2025 that fundamentally clarifies how pseudonymization affects data protection obligations.

The ruling in EDPS v SRB (C-413/23 P) addresses a question that compliance teams have wrestled with for years: when does pseudonymized data stop being personal data?

The Case: Banking Resolution and Data Sharing

The dispute arose from the 2017 resolution of Banco Popular Español. The Single Resolution Board (SRB) collected comments from affected shareholders and creditors through an online consultation process. Participants provided identity documents during registration, then submitted comments through a form that assigned each comment a unique code.

The SRB shared coded comments with Deloitte for valuation purposes—but not the registration data needed to identify the authors. The European Data Protection Supervisor found this violated transparency obligations. The SRB argued the comments were not personal data from Deloitte's perspective. The case reached the CJEU.

Three Key Rulings

1. Personal Opinions Are Personal Data

The Court ruled that personal opinions and views constitute personal data because "as an expression of a person's thinking, [they] are necessarily closely linked to that person." This applies regardless of whether the content explicitly identifies the author.

The Court emphasized that when information constitutes personal opinions, no additional examination of content, purpose, or effect is needed to establish that it "relates to" a natural person under Article 4(1) GDPR (and Article 3(1) of Regulation 2018/1725). The subjective nature of opinions creates an inherent link to their authors.

This builds on the Court's earlier ruling in Nowak (C-434/16), where examiner comments about a candidate's performance were held to constitute personal data both about the candidate and the examiner.

2. Pseudonymization Can Make Data Anonymous

The Court's most significant holding addresses pseudonymization directly. Pseudonymized data "must not be regarded as constituting, in all cases and for every person, personal data" when "pseudonymization may, depending on the circumstances of the case, effectively prevent persons other than the controller from identifying the data subject in such a way that, for them, the data subject is not or is no longer identifiable."

This means the same dataset can be:

Personal data for the controller (who retains the means to re-identify individuals)
Anonymous data for recipients (who lack any reasonable means of identification)

The critical factors are whether the recipient has access to:

The additional information needed for re-identification
Legal means to obtain such information
Practical ability to cross-reference with other data

The risk of identification must be "insignificant", meaning identification is prohibited by law or impossible in practice because it would require disproportionate effort in terms of time, cost, and labor.

3. Controllers Must Disclose All Recipients When Collecting Data

The third ruling resolves the procedural question: when must the controller inform data subjects about recipients?

The Court held that the obligation under Article 15 to inform data subjects about recipients applies "prior to the transfer of the data at issue and irrespective of whether or not those data were personal data" from the recipient's perspective after pseudonymization. The assessment of whether data are personal must be made:

At the time of collection (not transfer)
From the controller's perspective (not the recipient's)

This timing matters because the information allows data subjects to "decide, in full knowledge of the facts, whether to provide or, on the contrary, refuse to provide the personal data being collected." The transparency obligation protects the relationship between the data subject and the controller - it cannot depend on what happens after data are transferred to third parties.

Put simply, this means that the controller must include all foreseeable disclosures into the privacy notice, regardless of whether the data is anonymous to the recipient or not.

Practical Recommendations

Organizations processing pseudonymized data should:

Review and update privacy notices. Privacy notices provided at data collection should identify all entities that will receive personal data, regardless of pseudonymization. This is particularly important for research studies and clinical trials with extended timelines and multiple data recipients.
Document pseudonymization measures. Organizations should create detailed records of technical measures preventing re-identification by recipients, organizational measures (contractual restrictions, access controls) and risk assessments of identification likelihood.
Conduct recipient-specific assessments. When sharing pseudonymized data, organizations should evaluate each recipient's ability to identify individuals and document why data should be considered anonymous from that recipient's perspective.
Train staff on the distinction. The ruling confirms that "personal data" is not a fixed characteristic of a dataset—it depends on who is processing the data and what means they have available. Teams need to understand when data transition from personal to anonymous.
Consider contractual protections. When sharing pseudonymized data, contracts should explicitly prohibit recipients from attempting re-identification and from combining the data with other sources that could enable identification.

Conclusion

The EDPS v SRB judgment brings needed clarity to pseudonymization's role in data protection. Pseudonymization can make data anonymous, but only when technical and organizational measures effectively prevent identification by the recipient.

For controllers, this ruling emphasizes that transparency obligations attach at the point of collection and not at what happens after collection. For recipients, it confirms that careful assessment is needed before treating pseudonymized data as anonymous.

The practical effect is that pseudonymization becomes a more reliable privacy-enhancing technique when properly implemented, but controllers bear the burden of demonstrating that recipients genuinely cannot identify individuals.

This ruling brings new opportunities for data sharing but only if implemented properly.