Warum brauchen Chemie-, Pharma- und Prozessunternehmen in Berlin eine eigene KI-Security & Compliance-Strategie?

ISO 27001 und TISAX bieten Rahmenwerke für Informationssicherheit, die sich grundsätzlich gut auf KI-Systeme anwenden lassen, erfordern aber eine spezifische Anpassung. Bei KI-Systemen müssen neben klassischen IT-Assets auch Modelle, Trainingsdaten und Inferenzpipelines als schützenswerte Assets betrachtet werden. Das bedeutet: Risikobewertung, Kontrollziele und Richtlinien müssen erweitert werden, um Modellversionen, Datensätze und Zugriffspfade zu berücksichtigen.

Praktisch beginnt die Arbeit mit einer Asset-Inventarisierung: Welche Modelle laufen in der Umgebung? Welche Datenquellen werden verwendet? Welche Schnittstellen existieren zu Produktions- oder Laborsystemen? Diese Übersicht ist Grundlage für die Implementierung technischer Kontrollen wie Netzwerksegmentierung, Verschlüsselung und IAM, aber auch für organisatorische Maßnahmen wie Rollen- und Verantwortungsdefinitionen.

Für TISAX-relevante Lieferkettenprozesse, z. B. bei der Zusammenarbeit mit OEMs oder Zulieferern, ist Auditierbarkeit zentral. Das bedeutet: Audit-Logs, Nachvollziehbarkeit von Änderungen an Modellen und klare Change-Management-Prozesse müssen implementiert werden. Automatisierte Compliance-Reports helfen, wiederholbare Nachweise zu liefern und Audits effizient zu bestehen.

Unsere Empfehlung ist ein pragmatischer, schrittweiser Ansatz: Zuerst die kritischen Pfade absichern (z. B. Modelle, die Produktionsprozesse beeinflussen), dann Governance- und Dokumentationsprozesse hochziehen und schließlich die restlichen Assets integrieren. So erreichen Unternehmen schnell eine auditable Basis und können darauf aufbauend Tiefe und Breite ihrer Sicherheitsmaßnahmen ausbauen.

Die Entscheidung zwischen Self-Hosting und Cloud-Betrieb ist nicht nur technisch, sondern stark von regulatorischen, rechtlichen und organisatorischen Faktoren abhängig. Für viele Pharma- und Chemie-Anwendungen mit sensiblen Daten oder IP ist Self-Hosting oft die bevorzugte Wahl, weil sie maximale Kontrolle über Daten, Zugriffe und Infrastruktur bietet. Self-Hosting vereinfacht Compliance-Anforderungen wie Datenlokalität, spezifische Retention-Regeln und kontrollierte Zugriffsrechte.

Cloud-Anbieter bieten hingegen Skalierbarkeit, Managed-Services und oft integrierte Sicherheitsfunktionen. In vielen Fällen ist ein hybrider Ansatz sinnvoll: kritische Modelle und sensible Datensätze on-premise, weniger sensible Workloads oder Entwicklungsumgebungen in zertifizierten Clouds. Wichtig ist, dass Cloud-Deployments mit klar definierten Data-Processing-Agreements, verschlüsselten Transferwegen und kontrolliertem Zugriff flankiert werden.

Technisch muss bei Self-Hosting sichergestellt werden, dass Infrastrukturkomponenten wie HSMs für Schlüsselmanagement, sichere Netzwerktrennung und regelmäßige Sicherheitsupdates vorhanden sind. Bei Cloud-Lösungen sind IAM, VPC-Konfigurationen, KMS und Audit-Logging entscheidend. Letztlich hängt die Wahl auch von Audit-Anforderungen und internen Policies ab.

Wir empfehlen eine Risikoanalyse, die rechtliche Vorgaben, Geschäftsrisiken und operative Fähigkeiten berücksichtigt. Für Unternehmen in Berlin, die Zugang zu Cloud-Talenten haben, kann Hybrid-Betrieb die beste Balance aus Kontrolle und Agilität bieten.

Ein PIA für ein KI-Projekt beginnt mit einer klaren Beschreibung des Projekts: Welche Daten werden verwendet, welche Verarbeitungsschritte sind geplant, welche Outputs entstehen und wer hat Zugriff? In Laborprojekten sind häufig personenbezogene Daten, genealogische oder patientenbezogene Informationen sowie proprietäre Messdaten betroffen — jeder dieser Datentypen erfordert spezifische Schutzmaßnahmen.

Im nächsten Schritt analysiert man Risiken: Re-Identifikation, fehlerhafte Inferenz, Datenlecks und Missbrauchspotenziale. Für jedes Risiko sollten technische und organisatorische Gegenmaßnahmen definiert werden, beispielsweise Pseudonymisierung, Zugriffsbeschränkungen, Output-Filters und Logging. Diese Maßnahmen werden mit den verbleibenden Rest-Risiken bewertet und priorisiert.

Die PIA muss zudem dokumentieren, wie das Prinzip der Datenminimierung umgesetzt wird, welche Rechtsgrundlage für die Verarbeitung besteht und wie Betroffenenrechte erfüllt werden. Bei Forschungsvorhaben können zusätzliche Anforderungen wie Ethikvotum oder Einwilligungen relevant sein — eine enge Abstimmung mit Datenschutzbeauftragten und ggf. Ethikkommissionen ist essenziell.

Abschließend empfiehlt sich ein Monitoring-Plan: die PIA ist kein einmaliges Dokument, sondern Teil eines kontinuierlichen Prozesses. Änderungen am Modell, neue Datensätze oder geänderte Nutzungsszenarien erfordern Nachbewertungen. So bleibt die PIA relevant und schützt langfristig vor Compliance-Lücken.

Red-Teaming ist ein praktisches Prüfverfahren, das KI-Systeme gegen reale Angriffs- und Missbrauchsszenarien testet. In der Prozessindustrie geht es dabei nicht nur um Datendiebstahl, sondern um Manipulationen von Inputs, gezielte Verfälschung von Sensorwerten oder das Auslösen falscher Steuerbefehle durch adversariale Eingaben. Red-Teaming deckt solche Schwachstellen auf, bevor sie in Produktion Schaden anrichten können.

Eine strukturierte Evaluation umfasst Black-Box-Tests (externe Angriffe), White-Box-Analysen (Code- und Architektur-Reviews) und Szenario-Tests, die menschliche Bediener und reale Prozessbedingungen simulieren. Hierbei sind klare Testkriterien, akzeptable Fehlerraten und Notfallprozesse zu definieren, die auch in BCP/DR-Pläne einfließen.

Red-Teaming sollte regelmäßig stattfinden und Teil des Release-Prozesses für Modelle sein. Ergebnisse müssen in konkrete Maßnahmen umgesetzt werden: Hardening der Modell-API, zusätzliche Input-Validierungen, Output-Sanitization oder Anpassungen an Zugriffskontrollen. Ohne diese Schleife bleibt Red-Teaming eine reine Exerzitium, statt operativer Schutzmaßnahme.

Für Unternehmen in Berlin ist es sinnvoll, externe Red-Teamer mit domänenspezifischer Erfahrung hinzuzuziehen und lokale Security-Communities zu nutzen, um auf dem neuesten Stand der Bedrohungslage zu bleiben. Die Kombination aus internen Tests und externem Review liefert die beste Absicherung.

Ein gut fokussierter Proof-of-Concept (PoC) kann in wenigen Wochen bis wenigen Monaten realisiert werden, abhängig vom Umfang, der Datenverfügbarkeit und der Komplexität der Integrationen. Bei Reruption beginnt ein typischer PoC mit Use-Case-Definition, Feasibility-Check, schnellem Prototyping und einer klaren Erfolgsmessung — genau wie in unserem standardisierten AI PoC-Angebot.

Für KI-Security & Compliance bedeutet ein MVP oft: sicheres Self-Hosting für ein Modell, implementierte Audit-Logs, erste Data-Governance-Elemente (Klassifikation, Retention) und eine einfache Evaluation/Red-Teaming-Runde. Diese Kernbausteine erlauben eine erste Audit-Readiness und demonstrieren betriebliche Verbesserungen.

Wichtig ist die Vorbereitung: verfügbare Datensätze, klare Schnittstellen und Entscheidungsbefugnisse im Projektteam beschleunigen die Umsetzung erheblich. In Berlin profitieren Projekte von einfachem Zugang zu Tech-Talenten und kurzen Entscheidungswegen, wenn Stakeholder früh eingebunden werden.

Realistische Zeitpläne variieren: 4–8 Wochen für einen minimalen, evaluierten Prototyp; 3–6 Monate für eine auditfähige MVP-Implementierung. Transparente Milestones und ein klarer Produktionsplan sorgen dafür, dass ein PoC nicht im Labor verbleibt, sondern den Weg in den Betrieb schafft.

Ein multidisziplinäres Team ist entscheidend: Data Scientists und ML-Ingenieure entwickeln Modelle, Security-Architekten gestalten sichere Infrastrukturen, Compliance- und Legal-Experten bewerten regulatorische Risiken und Data Engineers sorgen für saubere, nachvollziehbare Datenpipelines. Zusätzlich sind Domänenexperten aus der Produktion oder dem Labor unverzichtbar, um Risiken und sinnvolle Acceptance-Kriterien zu definieren.

Operational Rollen wie ein Model Owner, ein Verantwortlicher für Datenqualität und ein Incident-Response-Team gewährleisten den laufenden Betrieb. Für Audit-Readiness sind zudem Rollen nötig, die Dokumentation, Change-Management und regelmäßige Reviews verwalten. Gute Kommunikation zwischen diesen Rollen ist oft der Schlüssel zum Erfolg.

In Berlin lässt sich oft schnell externes Know-how hinzuziehen, etwa für Red-Teaming oder spezialisierte Datenschutzfragen. Dennoch sollten kritische Rollen intern verankert sein, damit Wissen, Verantwortung und schnelle Reaktionsfähigkeit bestehen bleiben.

Unsere Erfahrung zeigt: Teams mit klar definierten Verantwortlichkeiten, regelmäßigen Trainings und integrierten Sicherheits- und Compliance-Checks erreichen deutlich schneller stabile, vertrauenswürdige KI-Systeme.

Reruption arbeitet nach dem Co-Preneur-Ansatz: Wir agieren nicht als klassische Berater, sondern als eingebettete Entwickler und Produktpartner. Obwohl unser Hauptsitz in Stuttgart ist, reisen wir regelmäßig nach Berlin und arbeiten vor Ort mit Ihren Teams, um Anforderungen schnell zu klären, Prototypen zu testen und Sicherheitsmaßnahmen praktisch umzusetzen.

Der Ablauf beginnt mit Use-Case-Definition und einer technischen Feasibility-Prüfung, gefolgt von einem schnellen Prototyp (PoC) und einer konkreten Evaluationsphase. Parallel entwickeln wir einen Production-Plan mit Architektur, Budget- und Timeline-Einschätzungen sowie einem Compliance-Fahrplan für ISO/TISAX/Datenschutz.

In Berlin legen wir großen Wert auf direkte Zusammenarbeit mit lokalen Stakeholdern — von Labormanagern bis zu IT-Sicherheitsbeauftragten —, um sicherzustellen, dass Implementierungen praxisnah und auditierbar sind. Unsere Arbeit ist Ergebnisorientiert: Wir liefern funktionierende Prototypen und umsetzbare Pläne, nicht nur Dokumentationen.

Wenn Sie möchten, starten wir mit einem standardisierten AI PoC, das innerhalb weniger Wochen eine technische Validierung liefert. Anschließend skaliert das Projekt in klaren Iterationen in Richtung Produktion und Audit-Readiness.