B2B SaaS — GDPR first, AI Act next
A B2B software provider established in the Union rarely touches its customers' end users directly. It runs the systems in which other companies process their own data, which puts it on the processor side of the GDPR for most of what it does — and that side is contractual before it is technical. The centre of gravity is therefore the Article 28 chain: the agreement with each customer, the authorisation and the back-to-back terms for every sub-processor, and the transfer question that appears the moment one of those sub-processors sits outside the Union. Everything else attaches conditionally. AI features raise a role question under the AI Act that has to be answered per feature rather than per company; connected products or data-processing services can pull in the Data Act; sector membership can pull in NIS2. The Digital Services Act, by contrast, is normally not in the picture at all, because a B2B application is not an intermediary service that stores or transmits information provided by recipients on their behalf.
- GDPR · processor side
- AI Act · only with AI functions
- Data Act · conditional
- NIS2 · sector-dependent
- DSA · not activated
Sector profile for orientation. It describes what a profile of this shape typically reaches in EU digital law — not what applies to your company. That determination is a legal assessment and belongs to a mandate.
One regime carries the profile, the rest attach conditionally
The GDPR runs continuously in this profile because the product is a processing operation performed on behalf of others. The remaining acts each need their own hook, and none of them fires simply because software is involved. Naming the hook is the whole exercise.
Regime footprint
| Regime & norm | Why it bites | What to do first |
|---|---|---|
| GDPR · Art. 28 | Processing on behalf of a controller needs a contract with the prescribed content; sub-processors require authorisation and the same obligations passed down the chain. | Keep one current sub-processor list per product and one data processing agreement template, and check that what the template promises matches what the infrastructure actually does. |
| GDPR · Art. 32 | Security of processing is owed by the processor in its own right, not only through the customer contract. | Maintain a single control set with evidence, and answer customer security questionnaires out of it rather than writing a new description each time. |
| GDPR · Art. 30(2) | A processor keeps its own record of the categories of processing carried out for each controller. | Derive the record from the product's data flows rather than from the sales catalogue, and update it when a sub-processor changes. |
| GDPR · Art. 44 et seq. | A sub-processor outside the Union turns every customer contract into a transfer question, including support access from third countries. | Inventory sub-processors by country, transfer instrument and access path, and record where remote support can reach personal data. |
| AI Act · role first | The act attaches to roles — provider, deployer, importer, distributor — per AI system, not to companies. An embedded model, a bought-in model and an in-house feature can place the same company in different roles. | Determine the role per feature before reading any duty list. The role check playbook walks through the questions. |
| Data Act | Relevant where the offering belongs to a connected product or a related service, or where it is a data-processing service caught by the switching provisions. | Classify the offering against the act's own definitions first; the answer decides whether an access and switching strand exists at all. |
| NIS2 | Applies through entity type and size, not through the fact of selling software. Cloud computing, data centre, managed service and managed security service providers are named among the digital providers. | Check entity classification and size thresholds, and remember that national transposition decides the details of registration and supervision. |
The Digital Services Act is deliberately absent. It addresses intermediary services — mere conduit, caching and hosting — and a business application that processes its customers' own data on their instructions is normally none of those. Leaving a regime out is part of the answer: a duty list that contains obligations you do not owe is not more careful, it is less usable. The role question under the AI Act is worked through in the AI Act role check.
Three seams that cost coordination
Each act on its own can be worked through. What costs time is the places where two of them reach for the same feature, the same dataset or the same contract clause, and neither gives way.
An AI feature inside processing on behalf
The moment a feature runs a model, two chains meet on the same code path. The AI Act asks who the provider of the system is and what documentation, transparency and risk work that role carries; the GDPR asks whether the customer's instructions still cover what the model does with the data — including training, evaluation and improvement. Answering only one of the two produces a contract that the product cannot keep, or a product that the contract does not permit.
Automated decisions made in the customer's name
If the software decides — a score, a ranking, a rejection — the person affected has rights under Art. 22 GDPR, and those rights are owed by the controller, which is usually the customer. The provider nevertheless has to build them: human intervention, the ability to express a point of view, and meaningful information about the logic involved cannot be retrofitted from outside the product. And Art. 22 AI Act is a different norm about authorised representatives; a cross-reference that omits the regime sends the wrong team to work.
Data Act access meets the GDPR legal basis
Where the product sits in a connected-product chain, the access and sharing rights of the Data Act apply even to data that is personal data — but then only within a legal basis under the GDPR, and the two acts describe the same records with different vocabularies. The boundary between product data that must be made available and personal data that may only be shared on a basis has to be drawn before the first request arrives, because the response deadline is no place to start the analysis.
Structure for a profile that is mostly contract work
- Obligation cockpitDuties per service and per role, with the source node attached, so the processor strand of the GDPR stays separate from whatever an AI feature adds — and so a second product does not inherit the first product's list.
- Collision mapThe seams above as curated walk-throughs, including the numbering traps where identical article numbers carry unrelated duties in different acts.
- Radar watchChange entries tagged to the profile, each with the date its watchlist was last reconciled. It reports a state; it does not claim to be a live feed.
- Role check for AI featuresThe provider-versus-deployer question answered per feature and recorded with its reasoning, so the answer survives the next release and the next customer questionnaire.
- Deliverables, marked DRAFTObligation register, sub-processor and transfer overview, a gap report. Everything the suite generates carries a DRAFT mark: no signature, no assessment, no liability. It becomes an assessment only when the law firm Theo Funk takes it into a mandate and signs it off.
Where the software stops
Everything above is orientation drawn from a public corpus and readable back to its sources: structured self-assessment and decision support, not an evaluation of a specific company and not legal advice. Whether your contracts carry the chain, whether a feature makes you a provider under the AI Act, whether a transfer instrument holds — those are legal assessments and belong to the law firm Theo Funk under a separate mandate. Regingada UG (haftungsbeschränkt) builds the software and takes on appointed EU-representative functions; the firm does the legal work.
A worked profile of this shape: the model case on a provider of recruiting AI — a company whose product is software until an AI feature changes its role. All profiles: model cases. Background reading: playbooks.
Orientation, not legal advice
This sector profile and the suite provide orientation and information only. They are not legal advice. Individual-case advice is provided exclusively by the law firm Theo Funk under a separate mandate. Regingada UG (haftungsbeschränkt) — the software company and appointed EU representative — and the law firm are strictly separated.