Which laws may apply to you
A useful scope assessment records the entity, service or system, role, purpose, legal source and reason for inclusion or exclusion. An industry label alone does not establish all obligations.
Five questions
| Regulation | What determines applicability | Practical output |
|---|---|---|
| AI Act | System/model definition, role, intended purpose, EU nexus and Article 2 exclusions; Article 6 and Annexes I/III for high risk | Inventory, reasoned classification and obligations for each role |
| NIS2 / Czech law | Specific service, entity type, size including enterprise relationships, and special exceptions; Czech higher/lower regime rules | Record of regulated service assessment, regime and deadlines |
| GDPR | Material and territorial scope in Articles 2–3, processing operation and controller/processor role; not people’s citizenship | Purposes, legal bases, processing records and rights procedures |
| Data Act | User, data holder/recipient, manufacturer, related service or data processing service provider role; relevant chapter and exclusions | Data rights map, access process and contractual/technical switching plan |
| DORA | Listed Article 2 financial entities and exceptions; the special oversight framework for critical ICT providers follows Article 31 designation; ordinary ICT contracts carry duties without that designation | ICT framework, contract register, reporting and testing plan for the applicable regime |
AI Act: determine role and use separately
- Provider: develops an AI system or general-purpose AI model, or has it developed, and places it on the market or puts the system into service under its own name/trademark. Integrating a model API into your own product can create this role without training a model.
- Deployer: uses an AI system under its authority in a professional activity. A business can have both provider and deployer roles across different systems.
- Importer/distributor: defined supply-chain roles; selling under your own brand or substantially modifying a high-risk system can change the assessment. Apply Articles 3 and 25 rather than assuming every reseller is only a distributor.
- Territorial and material scope: assess Article 2, including non-EU providers/deployers where outputs are used in the Union, and applicable exclusions.
Use this sequence:
- Test the actual conditions of Article 5 prohibitions. Emotion inference based on biometric data in workplaces and educational institutions is prohibited subject to medical/safety exceptions; consent does not generally legalise it. Biometric identification and categorisation have distinct rules. Consult the detailed classification guide rather than classifying by a one-word label.
- Test Article 6(1): an Annex I product or its safety component and the relevant third-party conformity assessment condition. Healthcare AI is not all Annex III; medical devices can follow MDR/IVDR and Article 6(1). Apply the safety-component and conformity-assessment clarifications in Article 6(1a)–(1c); optimisation or automation without a safety function is insufficient, while failure endangering health and safety also matters. Article 2(2) limits application for Annex I Section B; any Article 2(13) limitation requires its conditions and the relevant delegated act.
- Test Annex III under Article 6(2), then any Article 6(3) exception; profiling of natural persons remains high risk for listed systems. Natural-person creditworthiness is point 5(b), with a financial-fraud exception; life/health insurance risk assessment and pricing is point 5(c). Employment monitoring can be point 4(b).
- Assess Article 50 transparency separately. It is not a statutory “medium-risk” class and can overlap with high risk. Provider output marking and deployer deepfake/public-interest text disclosure have different scope and exceptions.
- Map obligations to the resulting role and applicable dates. Annex IV documentation is not required merely because a company uses a GPAI API. FRIA under Article 27 applies to specified deployers/use cases, including private credit and life/health insurance cases; GDPR DPIA has its own high-risk processing test.
NIS2: service, size, exceptions and national regime
Annex I lists highly critical sectors; Annex II lists other critical sectors. They are not a direct essential/important lookup table. Annex I includes energy, transport, credit institutions, financial market infrastructure, healthcare, water, digital infrastructure, B2B ICT management, public administration and space. Annex II includes postal, waste, chemicals, food, specified manufacturing, selected digital providers and research. Use the exact activity definitions.
- Identify the service and entity type in Articles 2–3 and the annexes, then the relevant national implementation.
- Assess size under the Annex to Recommendation 2003/361/EC. Small enterprise: fewer than 50 annual work units and (turnover at most EUR 10 million or balance sheet total at most EUR 10 million). A medium enterprise is neither micro nor small and meets fewer than 250 units and (turnover at most EUR 50 million or balance sheet total at most EUR 43 million). Account for partner/linked enterprises, the latest approved accounting period, normally two consecutive periods for changing size status, and the special rule for new enterprises (Annex Articles 3–6). Raw employee headcount or turnover alone is not the complete calculation. NIS2 Article 2(1) excludes Article 3(4) of the Recommendation’s Annex. For Czech scope also apply Cybersecurity Act § 7 and its conditional exceptions.
- Check exceptions regardless of size, such as DNS/TLD and specified trust/communications services or designated critical entities. Do not extend them automatically to all cloud, data centre or CDN providers.
- Determine essential/important status under Article 3. Larger Annex I entities are generally essential; a medium-sized Annex I entity is not automatically essential. In Czechia separately determine the regulated service and higher/lower obligation regime under Act No. 264/2025 Coll. and implementing rules.
- Record notification, registration and subsequent deadlines. A supplier contract may require security controls without making the supplier a directly regulated entity.
For DORA financial entities that also fall within NIS2, apply the sector-specific relationship in DORA Article 1(2) and NIS2 Article 4 to equivalent duties. Insurance is not automatically a NIS2 banking entity, and ICT suppliers do not inherit a blanket exemption.
GDPR: purpose, territorial scope and lawful basis
GDPR covers processing in the context of an EU establishment and relevant offering or monitoring involving people in the EU by non-EU organisations, subject to Articles 2–3. Citizenship is not the test. Define the basis for each purpose instead of choosing it only from a data category.
| Processing | Assessment |
|---|---|
| Customer orders | Article 6(1)(b) can cover processing necessary for a contract to which the data subject is a party, or pre-contract steps at that person’s request; marketing is a separate purpose |
| Employment | Apply contractual and statutory needs, local employment law and proportionality; employee consent may not be freely given |
| Marketing and website analytics | GDPR and relevant electronic communications rules both matter; legitimate interest does not automatically replace cookie consent |
| B2B contacts | A named individual’s business contact details can be personal data; assess the basis and information duties |
| Health or other special categories | A basis under Article 6 and an Article 9(2) condition; explicit consent is one condition, not the only option |
Article 9 includes racial/ethnic origin, political opinions, religious/philosophical beliefs, trade union membership, genetic data, biometric data used for unique identification, health and sex life/sexual orientation. Criminal convictions/offences have a separate Article 10 regime. Pseudonymisation alone does not establish anonymity; assess personal-data status by identifiability and the means reasonably likely to be used (Article 4 and recital 26). A DPA under Article 28 is required where a supplier is a processor, not automatically for every supplier.
Three worked examples
| Example | Reasoned assessment |
|---|---|
| SaaS, 50 annual work units and EUR 5 million turnover | Fifty annual work units fails the small-enterprise staff criterion; still account for accounting-period and status-change rules. Verify the cloud service definition, related enterprises and national rules for NIS2. A support chatbot needs AI role/transparency assessment; customer/employee data invoke GDPR where in scope. Data Act switching depends on the offering. |
| Bank, 500 employees and EUR 100 million turnover | Assess DORA and its NIS2 relationship. AI natural-person creditworthiness scoring may be Annex III 5(b); financial fraud detection is not automatically high risk under that point. Consider Article 27 FRIA and GDPR Articles 22/35 separately. |
| Manufacturer, 100 employees and EUR 20 million turnover | Determine the actual manufacturing activity for NIS2. Predictive maintenance, safety control and worker evaluation have different AI classifications. Connected-product data and employee information create separate Data Act/GDPR questions. |
Record the conclusion
For each law retain scope, role, reasoning, sources, relevant exceptions, owner, date and a trigger for reassessment. Confirm uncertain boundaries before relying on a checklist result.
AI classification · NIS2 scope · GDPR processing · DORA scope · Data Act
Content reviewed: 6 September 2026. Primary sources: AI Act, Digital Omnibus on AI, NIS2, NÚKIB: registrace a lhůty, GDPR, DORA, Data Act, SME definition.