DSGVO konforme KI Features in deinem SaaS bauen

Der Sprint, der zum Compliance Projekt wird

Das Modell funktioniert. Die Empfehlungen sehen gut aus, die Genauigkeit passt, und jemand sagt: "Lass uns das im nächsten Sprint ausliefern." Dann fragt jemand anderes: "Haben wir die Datenschutz Folgenabschätzung gemacht?" Stille. "Decken unsere Kundenverträge KI Verarbeitung ab?" Noch mehr Stille. Und aus einem Sprint von zwei Wochen wird ein Compliance Projekt von zwei Monaten, weil niemand an den Datenschutz gedacht hat, bis die Funktion gebaut war.

Diesen Kreislauf habe ich öfter durchlaufen, als mir lieb ist, beim Bau von GrowCentric.ai und von KI Funktionen für Kunden auf Ruby on Rails. Die gute Nachricht: Datenschutz für KI Funktionen ist weniger furchteinflößend, als er klingt. Der meiste Schmerz kommt daher, nicht zu wissen, was wann verlangt ist. Er ruht auf drei Säulen: dem Vertrag zur Auftragsverarbeitung, Datenschutz durch Technikgestaltung und der Datenschutz Folgenabschätzung. Bau sie in den Arbeitsablauf ein, und sie machen dich schneller, weil du aufhörst, Compliance an fertige Funktionen nachzurüsten.

Das ist die Anleitung, die ich gern gehabt hätte. Erst das Gesetz, dann der Code.

Welches Recht, für wen

Ein SaaS Unternehmen in Deutschland unterliegt der Datenschutz Grundverordnung (DSGVO) und ergänzend dem Bundesdatenschutzgesetz (BDSG). Private Unternehmen beaufsichtigen die Datenschutzbehörden der Länder.¹ Die DSGVO gilt außerdem für Anbieter außerhalb der EU, die Menschen in der EU Waren oder Dienste anbieten oder ihr Verhalten dort beobachten, du triffst also auf dieselben Regeln, egal ob dein Wettbewerber in Köln oder in London sitzt.² Für automatisierte Entscheidungen zählt Artikel 22 DSGVO, dazu weiter unten mehr.

Für das größere Bild, Modelle aus der Cloud, Beschäftigte, die Daten in Chatbots kopieren, und die KI Verordnung, fang mit KI im Unternehmen: der komplette Leitfaden an.

Säule 1: ein Vertrag zur Auftragsverarbeitung, der KI wirklich abdeckt

Artikel 28 verlangt einen verbindlichen Vertrag zwischen einem Verantwortlichen und jedem Auftragsverarbeiter, der in seinem Auftrag personenbezogene Daten verarbeitet.³ In den meisten B2B SaaS Produkten ist dein Kunde der Verantwortliche und du der Auftragsverarbeiter. Bekommt das Produkt KI Funktionen, beschreibt der bestehende Vertrag selten, was jetzt tatsächlich passiert.

Ein klassischer Vertrag zur Auftragsverarbeitung sagt, der Auftragsverarbeiter verarbeite personenbezogene Daten "nur auf dokumentierte Weisung des Verantwortlichen", um den Dienst zu erbringen. Das passt zu einem Produkt, das Daten speichert und wieder anzeigt. KI tut mehr: Sie analysiert, erkennt Muster, sagt vorher und trainiert manchmal.

Das habe ich beim Bau von GrowCentric.ai auf die harte Tour gelernt. Verbindet ein Kunde seine Kampagnendaten, analysiert das System Konversionsmuster, das Verhalten von Zielgruppen und die Wirksamkeit von Budgets. Das ist Verarbeitung weit über "speichern und wieder anzeigen" hinaus.

Was im Vertrag stehen muss

Artikel 28 Absatz 3 zählt acht Dinge auf, die der Vertrag vom Auftragsverarbeiter verlangen muss: nur auf dokumentierte Weisung handeln, Vertraulichkeit der Beschäftigten, Sicherheit, die Regeln für den Einsatz weiterer Auftragsverarbeiter, Unterstützung bei Anträgen Betroffener, Unterstützung bei Sicherheit, Meldung von Verletzungen und Folgenabschätzungen, Löschung oder Rückgabe der Daten am Ende und die Bereitstellung aller Informationen, die zum Nachweis nötig sind, Überprüfungen eingeschlossen.³

Für KI Funktionen brauchen mehrere davon schärfere Formulierungen:

Umfang und Zweck. Nicht "Erbringung des Dienstes". Nenn die Tätigkeiten: Inferenz (ein trainiertes Modell auf Kundendaten anwenden), Analyse (Muster für Berichte gewinnen), Merkmalsextraktion (Eingaben aus personenbezogenen Daten ableiten) und, falls es vorkommt, Modelltraining. Sie tragen unterschiedliche Risiken, und die Weisungen sollten jede davon abdecken.

Weitere Auftragsverarbeiter. KI Funktionen bringen Unterauftragsverarbeiter mit, die Kunden nicht erwarten: einen gehosteten Modellanbieter, einen GPU Hoster, einen eigenen Inferenzdienst. Nach Artikel 28 Absatz 2 braucht ein Auftragsverarbeiter dafür die vorherige schriftliche Genehmigung des Verantwortlichen, gesondert oder allgemein, und muss bei einer allgemeinen Genehmigung beabsichtigte Änderungen mitteilen, damit der Verantwortliche Einspruch erheben kann.³ Liste jedes Glied der KI Kette auf, mit Zweck und den Daten, die es sieht.

Training. Diese Klausel machen die meisten KI SaaS Produkte falsch. Halte fest, ob Kundendaten irgendetwas trainieren, welche Art von Training (ein Modell pro Kunde oder ein gemeinsames), wie Kunden voneinander getrennt bleiben und ob ein Kunde widersprechen kann. Bei GrowCentric.ai lautet die Zusage: Die Kampagnendaten eines Kunden dienen nur der Optimierung dieses Kunden, und die Daten keines Kunden trainieren Modelle für andere Kunden. Die Architektur dahinter steht in DSGVO und KI: wenn das Recht auf Vergessenwerden das Modell erreicht.

Wo es läuft. KI Lasten laufen manchmal woanders als die Hauptanwendung. Liegt die Rails App in einem Rechenzentrum in Frankfurt, das Modell wird aber aus den USA ausgeliefert, ist das eine Übermittlung in ein Drittland, mit eigenen Bedingungen in Kapitel V.⁴ Halte fest, wo trainiert wird, wo die Inferenz läuft und wo die Modelldateien liegen.

Automatisierte Entscheidungen. Trifft die Funktion Entscheidungen über Menschen, halte fest, wer sie prüft und wie ein Mensch eine anfechten kann. Dazu komme ich bei Säule 2.

Rechenbeispiel: eine Anlage für die KI Verarbeitung

Den KI Teil des Vertrags führe ich als maschinenlesbare Anlage. Hier für ein erfundenes Unternehmen, Alstermail, ein SaaS für E Mail Marketing aus Hamburg unter alstermail.example:

module DPACompliance
  class AIProcessingSchedule
    def self.for_alstermail # Anlage zum Vertrag: ein Eintrag pro KI Verarbeitungstätigkeit
      {
        processing_activities: [
          {
            name: "Send time optimisation",
            purpose: "Recommending the send time for each campaign segment",
            data_categories: ["open and click events", "send timestamps", "segment ids"],
            personal_data_involved: true,
            aggregation: "Segment level, minimum 100 recipients per segment",
            automated_decision: false,
            sub_processors: ["German cloud host (hosting and inference)"],
            location: "Germany only",
            retention: "Raw events 12 months, segment statistics kept",
            training_use: "Per customer model on aggregated segments only"
          },
          {
            name: "Subject line suggestions",
            purpose: "Drafting subject line options for the customer to choose from",
            data_categories: ["campaign text written by the customer"],
            personal_data_involved: false,
            automated_decision: false,
            sub_processors: ["Hosted language model provider (EU region)"],
            location: "EU",
            retention: "Not retained by the provider under its API terms",
            training_use: "None. Recipient data is never sent to the model"
          }
        ],
        model_training_policy: "Customer data is aggregated before training. " \
                               "Models are per customer and never shared across accounts.",
        human_oversight: "Every suggestion is reviewed by the customer before a send.",
        data_subject_rights: "Requests are passed to the customer within two working days " \
                             "and completed within the one month deadline."
      }
    end
  end
end

Dieselbe Struktur füllt das Verzeichnis von Verarbeitungstätigkeiten nach Artikel 30⁵ und die Folgenabschätzung bei Säule 3. Eine Quelle, drei Verwendungen.

Kunden über neue Unterauftragsverarbeiter informieren

Bei einer allgemeinen Genehmigung muss der Kunde Gelegenheit zum Einspruch haben, bevor ein neuer Unterauftragsverarbeiter loslegt. Das Gesetz setzt keine feste Frist, also sollte der Vertrag es tun. Dieses Beispiel nimmt 30 Tage:

class SubProcessorRegistry
  NOTICE_PERIOD = 30.days # Frist aus dem Vertrag, keine gesetzliche

  def self.notify_controllers_of_change(product:, change:)
    Controller.where(product: product, active: true).find_each do |controller|
      SubProcessorChangeNotification.create!(
        controller: controller,
        change_type: change[:type], # :addition, :removal, :modification
        sub_processor_name: change[:name],
        purpose: change[:purpose],
        data_access_scope: change[:data_scope],
        location: change[:location],
        effective_date: NOTICE_PERIOD.from_now,
        objection_deadline: NOTICE_PERIOD.from_now,
        notified_at: Time.current
      )
      SubProcessorNotificationMailer.change_notification(controller, change).deliver_later
    end
  end
end

Säule 2: Datenschutz durch Technikgestaltung, im Code

Artikel 25 verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen: geeignete technische und organisatorische Maßnahmen, eingebaut, wenn die Verarbeitung entworfen wird, und standardmäßig nur die personenbezogenen Daten, die für den jeweiligen Zweck nötig sind.⁶ Das klingt abstrakt. In der Praxis läuft es auf sieben Entscheidungen hinaus, die fallen, bevor der KI Code geschrieben wird.

Für die Aufsicht ist es auch nicht abstrakt. Im Dezember 2024 verhängte die irische Datenschutzbehörde gegen Meta 251 Millionen € wegen einer Datenpanne von 2018. 130 Millionen € davon entfielen auf einen Verstoß gegen Artikel 25 Absatz 1, weil die Datenschutzgrundsätze nicht in die Gestaltung der Systeme eingebaut waren, und 110 Millionen € auf einen Verstoß gegen Artikel 25 Absatz 2, standardmäßig nur die nötigen Daten zu verarbeiten.⁷ Artikel 25 liegt im Bußgeldband bis 10 Millionen € oder 2 % des weltweiten Jahresumsatzes, je nachdem, was höher ist.⁸

Entscheidung 1: Zweckbindung auf Ebene des Modells

Jedes Modell bekommt einen dokumentierten Zweck, und der Code hält es an diesem Zweck fest. Eine Empfehlungsmaschine sollte sich nicht still als Profilingwerkzeug weiterverwenden lassen.

module PrivacyByDesign
  class PurposeBoundModel
    PERMITTED_PURPOSES = {
      car_recommendation: {
        permitted_inputs: %i[category_preferences price_range region session_signals],
        prohibited_inputs: %i[name email phone address financial_data],
        output_type: :ranked_listing_ids
      },
      send_time_optimisation: {
        permitted_inputs: %i[segment_id historical_open_rates day_of_week time_bucket],
        prohibited_inputs: %i[individual_email name browsing_history],
        output_type: :recommended_send_time
      },
      campaign_budget_allocation: {
        permitted_inputs: %i[channel_metrics historical_roas budget_constraints seasonal_index],
        prohibited_inputs: %i[individual_user_data personal_demographics],
        output_type: :budget_recommendation
      }
    }.freeze

    def initialize(purpose:)
      @purpose = purpose
      @config = PERMITTED_PURPOSES.fetch(purpose)
    end

    def validate_inputs(input_data)
      keys = input_data.keys.map(&:to_sym)
      violations = keys & @config[:prohibited_inputs]
      raise PrivacyViolationError, "#{violations} prohibited for #{@purpose}" if violations.any?

      unexpected = keys - @config[:permitted_inputs]
      Rails.logger.warn("Unexpected inputs #{unexpected} for #{@purpose}") if unexpected.any?
      true
    end
  end
end

Übergibt jemand der Empfehlungsmaschine versehentlich eine Mailadresse, schlägt es fehl, bevor irgendeine Verarbeitung stattfindet.

Entscheidung 2: Datenminimierung bei der Merkmalsbildung

In der Pipeline für die Merkmale beginnen die meisten Datenschutzprobleme von KI Systemen. Jemand zieht jede Spalte herein, die nützlich sein könnte, und das Modell verarbeitet jetzt Daten, die es nicht braucht. Artikel 5 sagt, personenbezogene Daten müssen dem Zweck angemessen und erheblich und auf das notwendige Maß beschränkt sein.⁹ Also wird jedes Merkmal mit seinem Grund registriert, und was verworfen wurde, wird protokolliert:

module PrivacyByDesign
  class MinimisedFeatureExtractor
    FEATURE_REGISTRY = {
      car_recommendation: {
        category_affinity: { extraction: :category_view_counts,
                             minimisation: "Category level only, no single listing tracking" },
        price_band:        { extraction: :price_range_histogram,
                             minimisation: "Five bands, no exact values" },
        region:            { extraction: :region_code,
                             minimisation: "Region level only, no precise location" }
      }
    }.freeze

    def extract_features(purpose:, raw_data:)
      registry = FEATURE_REGISTRY.fetch(purpose)
      features = registry.to_h { |name, cfg| [name, send(cfg[:extraction], raw_data)] }

      FeatureExtractionAudit.create!(
        purpose: purpose,
        features_extracted: features.keys,
        raw_fields_discarded: raw_data.keys - features.keys,
        extracted_at: Time.current
      )
      features
    end
  end
end

Entscheidung 3: Pseudonymisierung als Standard

Pseudonymisierung heißt, personenbezogene Daten so zu verarbeiten, dass sie ohne zusätzliche Informationen keiner Person mehr zugeordnet werden können, wobei diese Informationen gesondert aufbewahrt und durch technische und organisatorische Maßnahmen geschützt werden.¹⁰ Der Europäische Datenschutzausschuss (EDSA) hat dazu im Januar 2025 Leitlinien im Entwurf veröffentlicht, die Guidelines 01/2025, zur Konsultation.¹¹ Zwei Punkte zählen für alle, die bauen. Der Schlüssel liegt getrennt von den Daten. Und pseudonymisierte Daten sind weiterhin personenbezogene Daten, weil der Schlüssel existiert. Das senkt das Risiko. Aus dem Gesetz bringt es dich nicht heraus.

module PrivacyByDesign
  class Pseudonymiser
    def pseudonymise_for_training(records, purpose:)
      mapping_id = SecureRandom.uuid
      pseudonymised = records.map do |record|
        record.except(:user_id, :email, :name, :ip_address)
              .merge(pseudo_id: pseudonym(record[:user_id], mapping_id))
      end

      PseudonymMapping.create!(mapping_id: mapping_id, purpose: purpose,
                               expires_at: 90.days.from_now, access_level: "dpo_only",
                               record_count: records.size)
      { data: pseudonymised, mapping_id: mapping_id }
    end

    private

    def pseudonym(user_id, mapping_id) # HMAC Pseudonym: stabil innerhalb einer Zuordnung, verschieden zwischen Zuordnungen
      OpenSSL::HMAC.hexdigest("SHA256", KeyManagement.retrieve("pseudo_#{mapping_id}"), user_id.to_s)
    end
  end
end

Entscheidung 4: Pipelines, die die Rechtsgrundlage kennen

Jeder Verarbeitungszweck braucht eine Rechtsgrundlage nach Artikel 6.¹² Für personalisierte Funktionen steht in Deutschland eine zweite Regel davor: § 25 des Telekommunikation Digitale Dienste Datenschutz Gesetzes (TDDDG). Das Speichern von Informationen auf dem Endgerät und der Zugriff auf Informationen, die dort schon gespeichert sind, brauchen eine Einwilligung. Ausgenommen sind nur die Übertragung einer Nachricht und das, was unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten digitalen Dienst bereitstellen kann.¹³ Die deutschen Datenschutzbehörden legen beides eng aus: Gewünscht ist der Basisdienst, nicht automatisch jede Zusatzfunktion, und "unbedingt erforderlich" heißt technisch erforderlich für genau diesen Dienst, nicht wirtschaftlich nötig für das Geschäftsmodell.¹⁴ Inhalte nach den Interessen auszuwählen, die du aus dem Verhalten eines Menschen schließt, ist eine solche Zusatzfunktion. Für Empfehlungen habe ich das in KI Empfehlungen in Solidus bauen ausgeführt. Also prüft die Pipeline die Grundlage für jeden Zweck vor jedem Schritt, nicht nur bei der Erhebung:

module PrivacyByDesign
  class LegalBasisAwarePipeline
    PURPOSES = { # Die Rechtsgrundlage je Zweck wird einmal in der Folgenabschätzung festgelegt und hier durchgesetzt
      essential_service:      { basis: :contract,             consent_required: false },
      service_analytics:      { basis: :legitimate_interests, consent_required: false },
      personal_recommendations: { basis: :consent,            consent_required: true },
      model_training_contribution: { basis: :consent,         consent_required: true }
    }.freeze

    def process_for(user:, purpose:, data:)
      config = PURPOSES.fetch(purpose)
      consent = ConsentRecord.current_for(user: user, purpose: purpose)
      return nil if config[:consent_required] && !consent&.granted?

      ProcessingRecord.create!(user_id: user.id, purpose: purpose, legal_basis: config[:basis],
                               consent_id: consent&.id, data_categories: data.keys,
                               processed_at: Time.current)
      yield data
    end
  end
end

Für eine E Mail Plattform wie Alstermail zählt das in großem Maßstab: Ob das Engagement einer Empfängerin in die KI Analyse einfließt, hängt davon ab, wozu jede Empfängerin Ja gesagt hat, und die Prüfung läuft jedes Mal.

Entscheidung 5: Aufbewahrung, die wirklich löscht

Personenbezogene Daten dürfen nicht länger aufbewahrt werden, als der Zweck es verlangt.⁹ Steht in der Richtlinie 90 Tage, muss etwas sie am Tag 91 löschen.

module PrivacyByDesign
  class RetentionEnforcer
    RETENTION_POLICIES = { # Aufbewahrungsregeln des Beispiels: Geschäftsentscheidungen aus der Folgenabschätzung, keine gesetzlichen Fristen
      raw_interaction_data: 90.days,
      email_engagement_events: 12.months,
      search_query_logs: 30.days,
      training_features: 6.months,
      pseudonym_mappings: 90.days,
      consent_records: 6.years, # aufbewahrt, um die Einwilligung nachzuweisen
      audit_logs: 3.years
    }.freeze

    def enforce!
      RETENTION_POLICIES.each do |data_type, retention|
        purged = data_class_for(data_type).where("created_at < ?", retention.ago).delete_all
        Rails.logger.info("Retention: purged #{purged} #{data_type} older than #{retention.inspect}")
      end
    end
  end
end

Das lasse ich in jedem Produkt als täglichen Sidekiq Job laufen. Klingt selbstverständlich, und die meisten Teams vergessen es.

Entscheidungen 6 und 7: Inferenz, die Rechte achtet, und nachvollziehbare Protokolle

Sie hängen mit den Mustern für Protokollierung und gestufte Autonomie in der EU KI Verordnung für SaaS Entwickler und im Beitrag zu Agentic AI zusammen: Jede KI Entscheidung wird mit Eingaben, Ausgabe und Modellversion protokolliert, und ein Mensch kann sie prüfen und überstimmen.

Genau diese Protokollierung brauchen die Regeln zu automatisierten Entscheidungen. Artikel 22 DSGVO gibt einer Person das Recht, keiner ausschließlich auf automatisierter Verarbeitung beruhenden Entscheidung unterworfen zu werden, Profiling eingeschlossen, die ihr gegenüber rechtliche Wirkung entfaltet oder sie in ähnlicher Weise erheblich beeinträchtigt. Es gibt drei Ausnahmen: Die Entscheidung ist für einen Vertrag erforderlich, ein Gesetz erlaubt sie, oder die Person hat ausdrücklich eingewilligt.¹⁵ Bei Vertrag und Einwilligung muss der Verantwortliche angemessene Maßnahmen treffen, mindestens das Recht auf Eingreifen einer Person, auf Darlegung des eigenen Standpunkts und auf Anfechtung der Entscheidung.¹⁵ Und solche Entscheidungen dürfen nicht auf besonderen Kategorien personenbezogener Daten beruhen, außer mit ausdrücklicher Einwilligung oder aus einem erheblichen öffentlichen Interesse auf gesetzlicher Grundlage, jeweils mit angemessenen Schutzmaßnahmen.¹⁵

Die meisten KI Funktionen in einem SaaS erreichen diese Schwelle nie. Ein Vorschlag für die Versandzeit oder ein Produktkarussell hat auf niemanden eine erhebliche Wirkung. Kreditlimits, Bewerbungen, Versicherungsprämien und Kontoschließungen haben sie. Wisse, auf welcher Seite jede Funktion steht, und schreib es auf.

Säule 3: Folgenabschätzungen, die nicht in der Schublade liegen

Artikel 35 verlangt eine Datenschutz Folgenabschätzung (DSFA), bevor eine Verarbeitung beginnt, die voraussichtlich ein hohes Risiko für die Rechte und Freiheiten von Menschen mit sich bringt, "insbesondere bei Verwendung neuer Technologien".¹⁶

Für KI sind die deutschen Aufsichtsbehörden deutlich. Die DSK, die Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder, schreibt in ihrer Orientierungshilfe zu KI und Datenschutz, dass eine DSFA nötig ist, wenn die Verarbeitung voraussichtlich ein hohes Risiko zur Folge hat, und dass das beim Einsatz von KI Anwendungen vielfach der Fall sein wird.¹⁷ Ihre Liste der Verarbeitungen, für die eine DSFA durchzuführen ist, die sogenannte Muss Liste für den nicht öffentlichen Bereich, nennt KI ausdrücklich: Nummer 11 erfasst den Einsatz von künstlicher Intelligenz zur Verarbeitung personenbezogener Daten, um die Interaktion mit den Betroffenen zu steuern oder persönliche Aspekte der betroffenen Person zu bewerten, mit Kundensupport per KI als Beispiel. Nummer 14 erfasst umfassende Profile über das Kaufverhalten.¹⁸ Die Liste ist nicht abschließend und orientiert sich an den neun Kriterien der europäischen Leitlinien, die auf ein wahrscheinlich hohes Risiko hindeuten: vertrauliche oder höchst persönliche Daten, schutzbedürftige Betroffene, Verarbeitung in großem Umfang, systematische Überwachung, innovative Nutzung neuer Technologien, Bewerten oder Einstufen (Scoring), Abgleichen oder Zusammenführen von Datensätzen, automatisierte Entscheidungen mit Rechtswirkung oder ähnlicher Wirkung und Betroffene, die an der Ausübung eines Rechts oder der Nutzung eines Dienstes gehindert werden.¹⁸

Der Fehler, den die meisten Entwickler machen: Sie behandeln die DSFA als einmaliges Dokument, das jemand aus der Rechtsabteilung schreibt und das dann vergessen wird. Eine nützliche DSFA ist ein technisches Artefakt, das neben dem Code liegt und sich ändert, wenn sich die Verarbeitung ändert.

class DPIAGenerator
  CRITERIA = %i[evaluation_or_scoring automated_decisions systematic_monitoring
                sensitive_data large_scale matching_datasets vulnerable_people
                innovative_technology preventing_rights].freeze

  def generate(ai_feature:)
    triggered = CRITERIA.select { |c| ai_feature.meets?(c) }
    {
      metadata: { feature: ai_feature.name, version: ai_feature.version,
                  assessed_at: Time.current, review_due: 6.months.from_now },
      description: { processing: ai_feature.processing_description,
                     data_categories: ai_feature.data_categories,
                     data_subjects: ai_feature.data_subject_categories,
                     purpose: ai_feature.stated_purpose },
      necessity_and_proportionality: { legal_basis: ai_feature.legal_basis,
                                       minimisation: ai_feature.minimisation_evidence,
                                       retention: ai_feature.retention_policy,
                                       rights: ai_feature.rights_mechanisms,
                                       automated_decision_safeguards: ai_feature.adm_safeguards },
      screening: { criteria_triggered: triggered,
                   dpia_required: triggered.include?(:innovative_technology) && triggered.size >= 2 }, # Faustregel: innovative Technologie plus ein weiteres Kriterium. Nr. 11 der DSK Liste kann schon allein greifen
      risks: ai_feature.risks,
      mitigations: ai_feature.mitigation_measures,
      consultation: { dpo_opinion: nil, prior_consultation_required: false }
    }
  end
end

Rechenbeispiel: die Vorprüfung der Zielgruppensegmentierung in GrowCentric.ai

Das ist die Bewertung für die Funktion zur Zielgruppensegmentierung in GrowCentric.ai.

Was sie tut: Sie analysiert Kampagnendaten, um Verhaltenscluster für das Targeting zu finden, gruppiert Nutzer nach Engagement, Kaufsignalen und Surfverhalten und empfiehlt, welche Segmente ein Kunde ansprechen sollte.

Erfüllte Kriterien: Bewerten oder Einstufen (sie profiliert Zielgruppensegmente), innovative Technologie (Segmentierung mit maschinellem Lernen) und Verarbeitung in großem Umfang (Kampagnendaten über viele Menschen). Drei Kriterien, innovative Technologie darunter, und eine KI, die persönliche Aspekte bewertet, fällt unter Nummer 11 der Muss Liste. Eine DSFA ist also Pflicht.

Risiken: diskriminierendes Targeting, wenn Segmente mit geschützten Merkmalen zusammenhängen, undurchsichtiges Profiling, weil Menschen nicht wissen, dass sie segmentiert wurden, und Abfluss von Informationen, wenn ein Segment etwas Sensibles über die Menschen darin verrät.

Maßnahmen: Segmente entstehen nur aus aggregierten Daten, mit mindestens 50 Nutzern pro Kohorte. Geschützte Merkmale sind von der Merkmalsbildung ausgeschlossen. Die Definitionen der Segmente sind transparent und prüfbar. Kunden können jedes Segment vor dem Einsatz prüfen und überstimmen. Der Herkunftsnachweis hält fest, welche Daten in jedes Segment eingeflossen sind.

Restrisiko: niedrig, weil keine personenbezogenen Daten eines Einzelnen in die Segmentierung gelangen. Die Funktion arbeitet mit statistischen Mustern, nicht mit persönlichen Profilen.

Das ist eine nützliche DSFA. Kein juristisches Dokument von 50 Seiten. Eine technische Bewertung, die sich auf Entscheidungen im Code abbilden lässt.

Rechenbeispiel: was die Bußgeldobergrenze für ein kleines SaaS heißt

Die Pflichten aus Artikel 25 und Artikel 35 liegen im unteren Bußgeldband. Die Obergrenze sind 10 Millionen € oder 2 % des weltweiten Jahresumsatzes, je nachdem, was höher ist.⁸

$$\text{cap} = \max(F,\; p \times T)$$

Dabei ist $F$ der feste Betrag, 10 Millionen €, $p$ der Prozentsatz als Dezimalzahl, $0{,}02$, $T$ der weltweite Jahresumsatz im vorangegangenen Geschäftsjahr, und $\max$ nimmt den größeren der beiden Werte. $\text{cap}$ ist die Obergrenze. Prozente als Dezimalzahlen stehen in Grundlagen: Prozent.

Alstermail hat einen Umsatz von 3 Millionen € (die Zahl des Beispiels):

$$0{,}02 \times 3.000.000 = 60.000$$

Dabei ist $0{,}02$ der Satz von 2 % und $3.000.000$ der Umsatz in Euro. Der höhere Wert von 60.000 € und 10 Millionen € sind 10 Millionen €, für jedes Unternehmen mit einem Umsatz unter $10.000.000 \div 0{,}02 = 500.000.000$ Euro ist also der feste Betrag die Obergrenze. Niemand erwartet, dass eine Hamburger E Mail Plattform für eine fehlende DSFA Millionen zahlt. Die Obergrenze zeigt nur, wie ernst das Gesetz die Pflicht nimmt, und die Aufsicht wägt jeden Fall nach seinen Umständen.

Lebendig halten

Eine DSFA ist ein lebendes Dokument. Ich halte meine in der Versionsverwaltung neben den Funktionen, die sie bewerten, und der Code stößt eine Überprüfung an, wenn sich die Verarbeitung ändert:

class DPIALifecycleManager
  def check_for_review_triggers(ai_feature:)
    dpia = DPIA.current_for(feature: ai_feature)
    triggers = []
    triggers << "Scheduled review due" if dpia.review_due <= Date.current
    triggers << "New data category" if added_data_category?(ai_feature, dpia)
    triggers << "New sub processor" if added_sub_processor?(ai_feature, dpia)
    triggers << "Scale increase" if scale_increased?(ai_feature, dpia)
    triggers << "New automated decision" if added_automated_decision?(ai_feature, dpia)
    triggers << "Model architecture change" if model_changed?(ai_feature, dpia)

    if triggers.any?
      DPIAReviewRequest.create!(dpia: dpia, triggers: triggers, requested_at: Time.current)
      DPIAReviewNotifier.notify(dpia: dpia, triggers: triggers)
    end
    triggers
  end
end

Wie die drei Säulen zusammenpassen

Es sind keine getrennten Arbeitsstränge. Es sind Schichten einer Architektur.

Lies es von oben: Der Vertrag sagt, was erlaubt ist, der Code setzt es durch, die Folgenabschätzung prüft es. Jede Änderung der Verarbeitung führt zurück zum Vertrag und zur Folgenabschätzung, bevor sie ausgeliefert wird.

Sie hängen auch mit dem übrigen Recht zusammen. Der Artikel zum Recht auf Vergessenwerden behandelt die Bearbeitung von Löschanträgen. Der Artikel zur KI Verordnung behandelt die Transparenzpflichten, die seit dem 2. August 2026 gelten, und die Hochrisikoregeln, die jetzt am 2. Dezember 2027 beginnen, und ein Betreiber kann in der Grundrechte Folgenabschätzung nach dieser Verordnung auf seine DSFA verweisen, statt sie zu wiederholen.¹⁹ Der Artikel zum Cyber Resilience Act behandelt die Sicherheit der Infrastruktur darunter.

Dieselben Muster gelten für jedes Produkt: Kampagnenoptimierung in GrowCentric.ai, Engagementanalyse auf einer E Mail Plattform, Suchranking in einem lokalen Branchenverzeichnis, Autoempfehlungen und Preise auf Solidus. Verschiedene Funktionen, dieselbe Architektur.

Die Checkliste mit zehn Punkten

Bevor du eine KI Funktion auslieferst:

1. Vertrag aktualisiert? Deckt die Vereinbarung mit dem Kunden genau diese KI Verarbeitung ab?
2. Unterauftragsverarbeiter aufgelistet? Ist jeder Anbieter der KI Infrastruktur dokumentiert, und hatten die Kunden Gelegenheit zum Einspruch?
3. Zweck dokumentiert? Hält der Code das Modell an einem festgelegten Zweck fest?
4. Daten minimiert? Bekommt das Modell nur die Daten, die es braucht?
5. Pseudonymisiert? Werden Kennungen ersetzt, bevor die Daten das Modell erreichen, und liegt der Schlüssel getrennt?
6. Rechtsgrundlage geprüft? Achtet die Pipeline die Einwilligung jeder Person, wo die Einwilligung die Grundlage ist, und die nach § 25 TDDDG, wo das Endgerät betroffen ist?
7. Aufbewahrung durchgesetzt? Werden die Daten gelöscht, wenn die Frist endet?
8. Protokoll aktiv? Wird jede KI Entscheidung mit Eingaben, Ausgaben und Modellversion protokolliert?
9. DSFA gemacht? Hast du gegen die Kriterien und die Muss Liste geprüft, die Risiken bewertet und die Maßnahmen festgehalten?
10. Menschliche Aufsicht vorhanden? Kann ein Mensch jede KI Entscheidung prüfen und überstimmen, und können Betroffene eine Entscheidung nach Artikel 22 anfechten?

Zehnmal Ja, und du stehst gut da. Nicht fertig, denn Datenschutz ist nie fertig, aber weit vor den meisten KI SaaS Produkten.

Unterm Strich

Datenschutz für KI Funktionen läuft auf drei Dokumente und sieben Entscheidungen hinaus. Die Dokumente sind der Vertrag zur Auftragsverarbeitung, die Aufzeichnung der Technikgestaltung und die Folgenabschätzung. Die Entscheidungen sind Zweckbindung, Minimierung, Pseudonymisierung, eine geprüfte Rechtsgrundlage, Aufbewahrung, Inferenz, die Rechte achtet, und nachvollziehbare Protokolle.

Nichts davon braucht ein Jurastudium. Es braucht eine technische Denkweise, angewandt auf rechtliche Anforderungen. Schreib die Compliance in den Code, nicht in ein Dokument in der Schublade. Bau die Muster einmal, und sie funktionieren überall: in jedem Produkt, jeder Funktion, jedem Markt.

Footnotes

1. Bundesministerium der Justiz und für Verbraucherschutz, Bundesdatenschutzgesetz (BDSG), § 40 Aufsichtsbehörden der Länder, Gesetze im Internet, https://www.gesetze-im-internet.de/bdsg_2018/__40.html

2. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 3, räumlicher Anwendungsbereich, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

3. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 28, Auftragsverarbeiter, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

4. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Kapitel V, Übermittlungen personenbezogener Daten an Drittländer, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

5. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 30, Verzeichnis von Verarbeitungstätigkeiten, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

6. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 25, Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

7. Data Protection Commission, Irish Data Protection Commission fines Meta €251 Million, 17. Dezember 2024, https://www.dataprotection.ie/en/news-media/press-releases/irish-data-protection-commission-fines-meta-eu251-million

8. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 83 Absatz 4, Bußgelder, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

9. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 5 Absatz 1 Buchstaben c und e, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

10. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 4 Nummer 5 (Pseudonymisierung), EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

11. Europäischer Datenschutzausschuss, Guidelines 01/2025 on Pseudonymisation, öffentliche Konsultation vom 17. Januar bis 14. März 2025, https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en

12. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 6, Rechtmäßigkeit der Verarbeitung, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

13. Bundesministerium der Justiz und für Verbraucherschutz, Telekommunikation Digitale Dienste Datenschutz Gesetz (TDDDG), § 25 Schutz der Privatsphäre bei Endeinrichtungen, Absätze 1 und 2, Gesetze im Internet, https://www.gesetze-im-internet.de/ttdsg/__25.html

14. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Orientierungshilfe der Aufsichtsbehörden für Anbieter:innen von digitalen Diensten (OH Digitale Dienste), Version 1.2, Randnummern 76, 78 und 80, DSK, November 2024, https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf

15. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 22, automatisierte Entscheidungen im Einzelfall einschließlich Profiling, Absätze 1 bis 4, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

16. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 35, Datenschutz Folgenabschätzung, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

17. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Orientierungshilfe Künstliche Intelligenz und Datenschutz, Version 1.0, 6. Mai 2024, Randnummer 39, https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf

18. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Liste der Verarbeitungstätigkeiten, für die eine DSFA durchzuführen ist (nicht öffentlicher Bereich), Version 1.1, 17. Oktober 2018, Nummern 11 und 14 und Hinweise, https://www.datenschutzkonferenz-online.de/media/ah/20181017_ah_DSK_DSFA_Muss-Liste_Version_1.1_Deutsch.pdf

19. Europäisches Parlament und Rat, Verordnung (EU) 2026/1744 (Digital Omnibus zur KI), Artikel 1 Nummer 13, zur Änderung von Artikel 27 Absatz 4 der Verordnung (EU) 2024/1689, Amtsblatt der Europäischen Union, 24. Juli 2026, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ:L_202601744