Projektplanung: KI im KMU rechtssicher einsetzen

Eine Geschichte von einem, der auszog um ein LLM im 12-Mann KMU rechtssicher einzusetzen und möglichst nach ISO 41001 auch zu zertifizieren. Dies ist sozusagen die Projektplan-Ideen-Sammlung und das Struktur-Brainstorming.

Hinweis zur Nutzung dieses Dokuments

Dieser Projektplan wurde als strukturierte Arbeitsgrundlage erstellt und ordnet die technischen, organisatorischen und rechtlichen Schritte zur Einführung von Open WebUI + Ollama als on-premise betriebene KI-Lösung sowie den Weg zu einer möglichen ISO/IEC 42001-Zertifizierung ein.

Die rechtlichen Einschätzungen zu DSGVO, NIS2/BSIG-neu und dem EU AI Act beruhen auf dem öffentlich verfügbaren Rechtsstand von August 2026 und ersetzen keine Rechtsberatung im Einzelfall. Für rechtsverbindliche Aussagen (insbesondere zur Bestellpflicht eines Datenschutzbeauftragten, zur Erforderlichkeit einer Datenschutz-Folgenabschätzung und zur NIS2-Anwendbarkeit) wird empfohlen, eine auf Datenschutz- und IT-Sicherheitsrecht spezialisierte Kanzlei oder einen entsprechend qualifizierten externen Berater hinzuzuziehen.

Inhaltsverzeichnis

1. Executive Summary
2. Ausgangslage und Zielsetzung
3. Rechtlicher Rahmen – Überblick
4. Detailanalyse: Datenschutz (DSGVO / BDSG)
5. Detailanalyse: NIS2 / BSIG-neu
6. Detailanalyse: EU AI Act (KI-Verordnung)
7. ISO/IEC 42001 – Weg zur Zertifizierung
8. Technische Architektur und Umsetzung
9. Projektorganisation und Rollen
10. Phasenplan und Meilensteine
11. Risikomanagement
12. Kosten- und Ressourcenplanung
13. Erfolgskriterien
14. Nächste Schritte (erste 30 Tage)
15. Anhang 18

1. Executive Summary

Das Unternehmen plant die Einführung von Open WebUI als selbst gehostete, browserbasierte Oberfläche für lokale KI-Sprachmodelle (Basis: Ollama), um den 12 Mitarbeitenden einen datenschutzkonformen KI-Assistenten für Textarbeit, Wissenssuche in technischen Dokumentationen (RAG) und perspektivisch weitere Anwendungsfälle bereitzustellen (vollständig auf eigener Infrastruktur), ohne dass Unternehmens- oder Kundendaten an externe Cloud-Anbieter übertragen werden.

Der vorliegende Projektplan verfolgt drei parallele Zielsetzungen:

• Technische Einführung: robuster, performanter und sicher betriebener On-Premise-KI-Stack (Open WebUI, Ollama, RAG-Wissensdatenbank, Zugriffskontrolle).
• Rechtskonformität von Beginn an: Berücksichtigung von DSGVO/BDSG, dem EU AI Act sowie eine fundierte, unternehmensspezifische Prüfung der NIS2-Anwendbarkeit (BSIG-neu).
• Zertifizierungsfähigkeit: Aufbau eines KI-Managementsystems (AIMS), das die Anforderungen der ISO/IEC 42001 erfüllt und extern zertifiziert werden kann.

Zentrale Erkenntnisse vorab:

• On-Premise-Betrieb ist der datenschutzrechtliche Kernvorteil: Solange keine Daten an externe Modell-APIs, Websuche-Plugins oder Cloud-Dienste abfließen, entsteht keine Auftragsverarbeitung nach Art. 28 DSGVO gegenüber einem KI-Anbieter. Dieser Vorteil muss technisch und organisatorisch abgesichert sein (siehe Kapitel 4 und 8).
• NIS2 dürfte nach heutigem Stand nicht direkt verpflichtend sein: Bei 12 Mitarbeitenden liegt das Unternehmen voraussichtlich unter den Schwellenwerten für „wichtige“ oder „besonders wichtige Einrichtungen“. Die freiwillige Orientierung an den NIS2-Basismaßnahmen wird dennoch empfohlen, u. a. wegen möglicher Lieferketten-Anforderungen größerer Kunden (siehe Kapitel 5).
• Der EU AI Act betrifft das Unternehmen bereits heute in Teilen: insbesondere die Pflicht zur KI-Kompetenzvermittlung (Art. 4 KI-VO), die unabhängig von Unternehmensgröße seit Februar 2025 gilt. Hochrisiko-Pflichten sind für den geplanten Anwendungsfall nicht einschlägig (siehe Kapitel 6).
• ISO/IEC 42001 ist freiwillig, aber strategisch sinnvoll: Als Nachweis gegenüber Kunden aus der Mess- und Fertigungstechnik-Lieferkette und als strukturelle Grundlage für rechtssichere KI-Governance (siehe Kapitel 7).

Der geplante Gesamtzeitraum bis zur Zertifizierungsreife beträgt ca. 10–12 Monate, aufgeteilt in acht Projektphasen (Kapitel 10). Eine erste grobe Kostenschätzung findet sich in Kapitel 12.

2. Ausgangslage und Zielsetzung

2.1 Ausgangslage

Das Unternehmen ist ein KMU mit 12 Mitarbeitenden im Bereich der industriellen Messtechnik. Typische Datenkategorien in einem solchen Betrieb umfassen technische Zeichnungen und Konstruktionsdaten, Messprotokolle und Kalibrierdaten, Kundendokumentation (teils unter NDA), interne Prozess- und Qualitätsdokumentation (z. B. im Kontext von ISO 9001) sowie personenbezogene Daten von Mitarbeitenden, Kunden und Lieferanten. Diese Daten sind regelmäßig als Betriebs- und Geschäftsgeheimnisse im Sinne des Geschäftsgeheimnisgesetzes (GeschGehG) einzustufen und unterliegen häufig zusätzlich vertraglichen Geheimhaltungspflichten gegenüber Kunden aus der Fertigungsindustrie.

Cloud-basierte KI-Chat-Tools (z. B. ChatGPT, Copilot, Gemini in der Standardkonfiguration) würden bei dieser Datenlage einen Transfer an außereuropäische bzw. externe Anbieter bedeuten, was in einem sensiblen B2B-Umfeld mit Geheimhaltungspflichten sowohl datenschutzrechtlich als auch vertraglich riskant ist. Eine selbst gehostete, on-premise betriebene Lösung wie Open WebUI in Kombination mit Ollama vermeidet diesen Datenabfluss grundsätzlich, da Modell und Daten vollständig auf eigener Infrastruktur verbleiben.

2.2 Projektziele

• Bereitstellung eines internen, DSGVO-konformen KI-Assistenten für alle 12 Mitarbeitenden (Textentwürfe, Zusammenfassungen, Recherche in interner Dokumentation, perspektivisch Unterstützung bei Angebots- und Berichtstexten).
• Aufbau einer RAG-gestützten Wissensdatenbank auf Basis interner technischer Dokumentation, Handbücher und Normen, ohne dass diese Inhalte das Unternehmen verlassen.
• Etablierung einer rechtssicheren Betriebsgrundlage (Datenschutz, KI-Nutzungsrichtlinie, Rollen- und Rechtekonzept).
• Aufbau eines KI-Managementsystems (AIMS) und Erlangung der Zertifizierung nach ISO/IEC 42001 innerhalb von ca. 12 Monaten nach Projektstart.
• Schaffung eines Referenzpunkts für Kundenanfragen und Ausschreibungen, die zunehmend einen Nachweis über verantwortungsvollen KI-Einsatz und Informationssicherheit verlangen.

2.3 Abgrenzung (Nicht-Ziele)

• Kein Einsatz der KI zur automatisierten Entscheidungsfindung gegenüber Kunden oder Bewerbenden (kein Profiling, keine automatisierten Einzelentscheidungen i. S. d. Art. 22 DSGVO).
• Keine Einbettung der KI-Komponente in physische Messprodukte oder Fertigungssteuerung im Rahmen dieses Projekts (dies würde die Einordnung als Hochrisiko-KI-System nach Anhang I EU-KI-VO neu erforderlich machen, siehe Kapitel 6.3).
• Kein produktiver Einsatz cloud-basierter KI-Zusatzfunktionen (externe Websuche, externe Bildgenerierung, externe Sprach-APIs) in der Grundkonfiguration, denn diese stünden im Widerspruch zum On-Premise-Ansatz (siehe Kapitel 8.6).
• Keine Personalentscheidungen oder Leistungsbewertungen auf Basis von KI-Auswertungen von Mitarbeitendendaten.

3. Rechtlicher Rahmen im Überblick

Die folgende Tabelle fasst zusammen, welche Regelwerke für das Projekt relevant sind, ob sie für ein Unternehmen dieser Größe verbindlich sind und was daraus konkret für das Projekt folgt. Die Detailanalyse erfolgt in den Kapiteln 4 bis 7.

Regelwerk	Verbindlichkeit	Kernpflicht	Bezug zum Projekt
DSGVO / BDSG	Verbindlich (immer)	Rechtmäßige, sichere Verarbeitung personenbezogener Daten	Verarbeitungsverzeichnis, TOMs, ggf. DSFA, ggf. Datenschutzbeauftragter
NIS2 / BSIG-neu	Voraussichtlich nicht direkt verpflichtend	Cybersicherheits-Risikomanagement, Meldepflichten	Freiwillige Orientierung empfohlen; Lieferketten-Relevanz gegenüber größeren Kunden prüfen
EU AI Act (KI-VO)	Teilweise verbindlich	KI-Kompetenz (Art. 4), Verbote (Art. 5), Transparenz (Art. 50)	Schulungspflicht Art. 4 einplanen; Hochrisiko-Pflichten nicht einschlägig
ISO/IEC 42001	Freiwillig	Aufbau eines AI-Managementsystems (AIMS)	Zertifizierungsziel des Unternehmens ist strukturiert das gesamte Projekt
GeschGehG	Verbindlich	Angemessene Geheimhaltungsmaßnahmen	Zugriffs- und Protokollierungskonzept für Konstruktions-/Messdaten
BetrVG (falls Betriebsrat vorhanden)	Bedingt verbindlich	Mitbestimmung bei Systemen mit Überwachungspotenzial (§ 87 Abs. 1 Nr. 6)	Frühzeitige Einbindung, KI-Nutzungsrichtlinie ggf. als Betriebsvereinbarung

Hinweis: Diese Übersicht ersetzt keine rechtliche Einzelfallprüfung. Insbesondere die NIS2-Einordnung hängt neben der Mitarbeiterzahl auch vom Jahresumsatz und von der Bilanzsumme des Unternehmens ab, die hier noch nicht bekannt sind (siehe Kapitel 5.2).

4. Detailanalyse: Datenschutz (DSGVO / BDSG)

4.1 Verantwortlichkeit und Rechtsgrundlagen

Das Unternehmen ist als Betreiber des On-Premise-Systems datenschutzrechtlich „Verantwortlicher“ im Sinne von Art. 4 Nr. 7 DSGVO für sämtliche personenbezogenen Daten, die über Open WebUI verarbeitet werden. Als Rechtsgrundlagen kommen in Betracht:

• Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse) für die allgemeine Nutzung als Effizienz- und Recherchewerkzeug, sofern eine Interessenabwägung dokumentiert wird.
• § 26 BDSG i. V. m. Art. 88 DSGVO für die Verarbeitung von Beschäftigtendaten im Rahmen der Nutzung (z. B. Nutzungsprotokolle, Prompt-Historie einzelner Mitarbeitender).
• Art. 6 Abs. 1 lit. b DSGVO , soweit Kundendaten im Rahmen der Vertragsdurchführung (z. B. Erstellung von Prüfberichten) verarbeitet werden.

Empfehlung: Die konkrete Rechtsgrundlage sollte je Anwendungsfall (Use Case) im Verarbeitungsverzeichnis dokumentiert werden (siehe 4.5).

4.2 Auftragsverarbeitung ist der zentrale Vorteil des On-Premise-Betriebs

Solange Open WebUI und die angebundenen Sprachmodelle ausschließlich lokal auf eigener Infrastruktur betrieben werden und keine Anfragen an externe Modell-APIs (z. B. OpenAI, Anthropic, Google) gesendet werden, entsteht keine Auftragsverarbeitung nach Art. 28 DSGVO gegenüber einem KI-Anbieter. Es müssen also grundsätzlich kein Auftragsverarbeitungsvertrag (AVV) und keine Prüfung eines Drittlandtransfers nach Kapitel V DSGVO für den KI-Kernbetrieb erfolgen.

Hinweis: Dieser Vorteil gilt nur, solange die Konfiguration konsequent eingehalten wird. Sobald in Open WebUI optionale Cloud-Funktionen aktiviert werden (externe Websuche-Anbieter, externe Bild-/Sprachgenerierung oder ein zusätzliches Cloud-Modell als Fallback) liegt für diese Funktionen wieder eine Datenübermittlung an Dritte vor, die einen AVV und ggf. eine Transfer-Folgenabschätzung erforderlich macht (siehe Kapitel 8.6). Dies sollte technisch (Deaktivierung in der Admin-Konfiguration) und organisatorisch (KI-Nutzungsrichtlinie) abgesichert werden.

4.3 Datenschutz-Folgenabschätzung (DSFA, Art. 35 DSGVO)

Ob eine DSFA verpflichtend ist, hängt vom konkreten Risiko der Verarbeitung ab. Für den Einsatz einer KI-Anwendung sprechen mehrere Indizien für eine DSFA-Pflicht bzw. für eine empfehlenswerte freiwillige Durchführung:

• Einsatz neuer Technologien (Art. 35 Abs. 1 DSGVO) KI-Sprachmodelle gelten nach verbreiteter Aufsichtspraxis regelmäßig als solche.
• Mögliche systematische und umfassende Bewertung persönlicher Aspekte, sofern die KI perspektivisch auch auf Personalunterlagen oder Bewerbungen angewendet würde (im aktuellen Scope ausgeschlossen, siehe 2.3).
• Deutsche Aufsichtsbehörden (Datenschutzkonferenz, DSK) empfehlen in ihren Orientierungshilfen zu KI-Anwendungen regelmäßig die Durchführung einer DSFA, auch unterhalb der zwingenden gesetzlichen Schwelle, als Nachweis der Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO).

Empfehlung: Eine DSFA sollte im Rahmen von Projektphase 1 durchgeführt werden, unabhängig von der abschließenden rechtlichen Einordnung ihrer Pflichtigkeit. Sie liefert zugleich einen wesentlichen Baustein für die spätere ISO/IEC 42001-Zertifizierung (Risikobewertung, siehe Kapitel 7.5) und für ein etwaiges NIS2-Risikomanagement (Kapitel 5).

4.4 Pflicht zur Bestellung eines Datenschutzbeauftragten (§ 38 BDSG)

Nach § 38 Abs. 1 Satz 1 BDSG besteht eine Bestellpflicht grundsätzlich erst, wenn in der Regel mindestens 20 Personen ständig mit der automatisierten Verarbeitung personenbezogener Daten befasst sind. Bei 12 Mitarbeitenden dürfte diese Schwelle in aller Regel nicht erreicht sein.

Wichtige Ausnahme: Nach § 38 Abs. 1 Satz 2 BDSG besteht die Bestellpflicht unabhängig von der Mitarbeiterzahl, sobald Verarbeitungen vorgenommen werden, die einer Datenschutz-Folgenabschätzung nach Art. 35 DSGVO unterliegen. Wird wie in 4.3 empfohlen für das KI-Projekt eine DSFA-Pflicht bejaht, entsteht damit möglicherweise auch unabhängig von der Betriebsgröße eine Pflicht zur Bestellung einer/eines Datenschutzbeauftragten.

• Diese Frage sollte frühzeitig im Rahmen der DSFA-Vorprüfung mit einer Fachperson geklärt werden.
• Auch unabhängig von einer rechtlichen Pflicht ist die freiwillige Benennung einer verantwortlichen Ansprechperson (intern oder als externer Datenschutzbeauftragter) für ein KMU dieser Größe im KI-Kontext empfehlenswert und wird von ISO/IEC 42001 im Sinne klarer Rollen und Verantwortlichkeiten ohnehin nahegelegt (siehe Kapitel 9).

Hinweis: Auf Bundesebene wird derzeit diskutiert, § 38 Abs. 1 BDSG ersatzlos zu streichen und die Bestellpflicht ausschließlich nach dem risikobasierten Ansatz von Art. 37 DSGVO zu richten (Ankündigung im Rahmen der „Föderalen Modernisierungsagenda“ vom 4. Dezember 2025, Umsetzung bis Ende 2026 angekündigt, Stand August 2026 noch nicht in Kraft). Der aktuelle Rechtsstand sollte zum Zeitpunkt der Umsetzung erneut geprüft werden.

4.5 Verzeichnis von Verarbeitungstätigkeiten (Art. 30 DSGVO)

Für jeden KI-gestützten Anwendungsfall (z. B. „interner Chat-Assistent“, „RAG-Wissenssuche technische Dokumentation“, „Textentwürfe Kundenkommunikation“) ist ein eigener Eintrag im Verarbeitungsverzeichnis anzulegen, mit Angaben zu Zweck, betroffenen Personengruppen, Datenkategorien, Rechtsgrundlage, Speicherdauer, technischen und organisatorischen Maßnahmen sowie – sofern zutreffend – Empfängern.

4.6 Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Für den On-Premise-Betrieb sind insbesondere folgende Maßnahmen umzusetzen und zu dokumentieren:

• Verschlüsselung der Daten at rest (Datenbank, Vektorspeicher, Dateisystem) und in transit (TLS/SSL über den Reverse Proxy, siehe Kapitel 8.5).
• Rollen- und Rechtekonzept in Open WebUI (Admin- vs. Nutzerrollen, Zugriffsbeschränkung auf Wissensbasen nach Bedarf).
• Protokollierung sicherheitsrelevanter Ereignisse (Zugriffe, administrative Änderungen) unter Beachtung der Zweckbindung. Des weiteren keine übermäßige Verhaltens- oder Leistungskontrolle einzelner Mitarbeitender.
• Regelmäßige, verschlüsselte Backups mit definiertem Wiederherstellungskonzept.
• Netzsegmentierung: Der KI-Server ist im internen Netz zu isolieren, kein direkter Zugriff aus dem Internet ohne VPN bzw. abgesicherten Reverse Proxy.
• Patch- und Versionsmanagement für Open WebUI, Ollama und die Betriebssystembasis.

4.7 Betroffenenrechte und Löschkonzept

Da RAG-Wissensdatenbanken auch personenbezogene Daten enthalten können (z. B. Ansprechpartner in Kundendokumenten, Namen in E-Mail-Anhängen), ist ein Löschkonzept erforderlich, das festlegt, wie Auskunfts-, Berichtigungs- und Löschbegehren (Art. 15–17 DSGVO) technisch in der Vektordatenbank umgesetzt werden können. Empfehlung: vor dem Einspielen von Dokumenten in die Wissensbasis eine Sichtung/Anonymisierung offensichtlich personenbezogener, nicht benötigter Inhalte vorsehen.

4.8 Beschäftigtendatenschutz und Mitbestimmung

Die Einführung eines KI-Systems, das grundsätzlich protokollier- und auswertbar ist, kann unter § 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig sein, sofern im Unternehmen ein Betriebsrat besteht (bei 12 Mitarbeitenden nicht zwingend vorhanden, aber möglich). Ist ein Betriebsrat vorhanden, sollte dieser frühzeitig eingebunden und eine Betriebsvereinbarung zur KI-Nutzung abgeschlossen werden. Ist kein Betriebsrat vorhanden, wird dennoch empfohlen, eine schriftliche KI-Nutzungsrichtlinie zu erstellen, die transparent regelt, was protokolliert wird und wozu (siehe Kapitel 4.9).

4.9 KI-Nutzungsrichtlinie für Mitarbeitende

Als verbindliches internes Dokument sollte eine KI-Nutzungsrichtlinie erstellt werden, die u. a. regelt:

• Zulässige und unzulässige Anwendungsfälle (z. B. keine Eingabe strategischer Geschäftsgeheimnisse Dritter ohne Freigabe, auch wenn diese on-premise verbleiben).
• Verbot der Umgehung technischer Schutzmaßnahmen (z. B. private Nutzung externer KI-Tools für dienstliche, vertraulichkeitsbelastete Inhalte).
• Umgang mit KI-generierten Inhalten (Kennzeichnungspflichten, Pflicht zur fachlichen Prüfung vor Weiterverwendung, insbesondere bei Mess- und Prüfdaten).
• Transparenzhinweise zu Protokollierung und Auswertung nach Art. 13/14 DSGVO.

5. Detailanalyse: NIS2 / BSIG-neu

5.1 Rechtlicher Hintergrund

Die EU-Richtlinie (EU) 2022/2555 (NIS2) wurde in Deutschland mit deutlicher Verzögerung durch das „Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung“ (NIS2UmsuCG) umgesetzt. Das Gesetz wurde am 5. Dezember 2025 im Bundesgesetzblatt verkündet und trat am 6. Dezember 2025 ohne Übergangsfrist in Kraft; es novelliert das BSI-Gesetz grundlegend (BSIG-neu). Bundesweit sind schätzungsweise rund 29.500 Unternehmen unmittelbar betroffen; die Registrierungspflicht beim BSI-Portal (freigeschaltet am 6. Januar 2026) lief für betroffene Einrichtungen am 6. März 2026 ab.

5.2 Anwendbarkeitsprüfung für das Unternehmen

Die NIS2-Pflichten treffen „wichtige“ und „besonders wichtige Einrichtungen“. Die Einordnung erfolgt zweistufig: zunächst über die Sektorzugehörigkeit (Anhang I/II der Richtlinie), danach über Größenklassen.

Schritt 1 – Sektorzugehörigkeit

Die Herstellung von Mess-, Kontroll-, Navigations- und ähnlichen Instrumenten fällt unter die NACE-Gruppe C26 („Herstellung von Datenverarbeitungsgeräten, elektronischen und optischen Erzeugnissen“), die in Anhang II der NIS2-Richtlinie als Teilbereich des „verarbeitenden Gewerbes“ ausdrücklich als sonstiger kritischer Sektor („wichtige Einrichtung“) gelistet ist. Ein industrielles Messtechnik-Unternehmen ist damit sektoral grundsätzlich im Anwendungsbereich von NIS2, die endgültige Anwendbarkeit hängt jedoch von der Größenklasse ab (Schritt 2).

Schritt 2 – Größenklasse

NIS2 nimmt Kleinst- und Kleinunternehmen grundsätzlich vom Anwendungsbereich aus. Maßgeblich ist die EU-KMU-Definition:

Kategorie	Mitarbeitende	Jahresumsatz	oder Bilanzsumme	NIS2-Status
Kleinstunternehmen	< 10	≤ 2 Mio. €	≤ 2 Mio. €	Regelmäßig ausgenommen
Kleines Unternehmen	< 50	≤ 10 Mio. €	≤ 10 Mio. €	Regelmäßig ausgenommen
Mittleres Unternehmen	< 250	≤ 50 Mio. €	≤ 43 Mio. €	„Wichtige Einrichtung“ möglich

Einordnung: Mit 12 Mitarbeitenden liegt das Unternehmen unterhalb der 50-Personen-Schwelle für „kleine Unternehmen“. Sofern zusätzlich der Jahresumsatz bzw. die Bilanzsumme 10 Mio. € nicht übersteigt (was bei dieser Betriebsgröße die Regel sein dürfte, aber unternehmensspezifisch zu bestätigen ist), greifen die direkten NIS2-Pflichten nach heutigem Kenntnisstand voraussichtlich nicht.

Von der Größenausnahme unabhängig gilt NIS2 dennoch für bestimmte Einrichtungstypen unabhängig von ihrer Größe (u. a. Betreiber öffentlicher Telekommunikationsnetze, qualifizierte Vertrauensdiensteanbieter, DNS-Diensteanbieter/TLD-Registrare, öffentliche Verwaltungen, als kritisch nach dem KRITIS-Dachgesetz eingestufte Einrichtungen sowie Einrichtungen, die alleinige Anbieter eines für die Aufrechterhaltung kritischer gesellschaftlicher oder wirtschaftlicher Tätigkeiten wichtigen Dienstes in Deutschland sind). Keiner dieser Ausnahmetatbestände dürfte auf ein Messtechnik-KMU dieser Größenordnung typischerweise zutreffen; eine kurze Prüfung im Rahmen von Projektphase 1 wird dennoch empfohlen (siehe Anhang A).

5.3 Indirekte Relevanz: Lieferkettensicherheit

Auch ohne eigene NIS2-Pflicht kann das Unternehmen mittelbar betroffen sein: NIS2-verpflichtete Kunden (z. B. größere Maschinenbau- oder Automobilzulieferer, die selbst als „wichtige“ oder „besonders wichtige Einrichtung“ gelten) müssen die Sicherheit ihrer Lieferkette bewerten (Art. 21 NIS2-Richtlinie) und geben Sicherheitsanforderungen zunehmend vertraglich an Zulieferer weiter, auch an kleinere Partner wie hier ein Messtechnik-KMU. Ein dokumentiertes Informationssicherheits- und KI-Risikomanagement wird hier zunehmend zum Wettbewerbs- und Ausschreibungsfaktor, unabhängig von der eigenen NIS2-Pflicht.

5.4 Empfehlung für das Projekt

• Keine formale NIS2-Registrierung vornehmen, solange die Schwellenwerte nicht erreicht werden (unnötiger bürokratischer Aufwand).
• Die NIS2-Basismaßnahmen nach § 30 BSIG-neu (u. a. Risikomanagement, Vorfallserkennung und -meldeprozesse, Backup- und Notfallmanagement, Kryptografie- und Verschlüsselungskonzepte, Zugriffskontrolle, Schulung, Lieferkettensicherheit) freiwillig als Orientierung für die technische Absicherung des KI-Systems heranziehen. Diese decken sich weitgehend mit den Kontrollen, die ohnehin für ISO/IEC 42001 und Art. 32 DSGVO benötigt werden (siehe Kapitel 4.6, 7.5, 8.5).
• Die freiwillige Registrierungsmöglichkeit beim BSI (für nicht-verpflichtete Unternehmen im Rahmen des BSIG-neu vorgesehen) kann optional geprüft werden, wenn das Unternehmen aktiv mit erhöhter Cyber-Resilienz gegenüber Kunden werben möchte.
• Die Größeneinstufung sollte bei künftigem Wachstum (Überschreiten von 50 Mitarbeitenden oder 10 Mio. € Umsatz/Bilanzsumme) erneut geprüft werden, da dann eine NIS2-Pflicht entstehen kann.

6. Detailanalyse: EU AI Act (KI-Verordnung)

6.1 Rolle des Unternehmens

Beim geplanten Einsatz von Open WebUI mit vortrainierten offenen Sprachmodellen (z. B. über Ollama) agiert das Unternehmen datenschutz- und produktrechtlich als „Betreiber“ (Deployer) im Sinne von Art. 3 Nr. 4 KI-VO, nicht als „Anbieter“ (Provider). Anbieterpflichten (Konformitätsbewertung, technische Dokumentation des Modells) treffen die Modellhersteller, nicht das anwendende KMU, es sei denn, das Unternehmen würde eigene Modelle so grundlegend anpassen oder unter eigenem Namen weitergeben, dass es selbst zum Anbieter würde (im geplanten Scope nicht vorgesehen).

6.2 Verbotene Praktiken (Art. 5 KI-VO)

Die Verbote bestimmter KI-Praktiken (u. a. Social Scoring, bestimmte Formen biometrischer Kategorisierung, manipulative Systeme) sind bereits seit dem 2. Februar 2025 anwendbar. Für den geplanten internen Assistenz- und Wissenssuche-Anwendungsfall ist keine Berührung mit diesen Verbotstatbeständen ersichtlich.

6.3 Einordnung als Hochrisiko-KI-System (Anhang III)

Ein interner KI-Assistent für Textarbeit und technische Wissenssuche fällt nicht unter die in Anhang III der KI-VO gelisteten Hochrisiko-Anwendungsfälle (u. a. Personalauswahl, Bonitätsprüfung, biometrische Identifizierung, kritische Infrastruktursteuerung). Solange die in Kapitel 2.3 beschriebene Abgrenzung eingehalten wird, ist der Anwendungsfall nicht hochrisikobehaftet.

Hinweis: Unabhängig davon hat der sogenannte „Digital Omnibus on AI“ – eine politische Einigung von Rat und Europäischem Parlament vom 7. Mai 2026 – die vollständigen Pflichten für eigenständige Hochrisiko-KI-Systeme nach Anhang III ohnehin von August 2026 auf den 2. Dezember 2027 verschoben (Anhang-I-Produkte: 2. August 2028). Die formale Verabschiedung im EU-Amtsblatt stand zum Stand dieses Dokuments (August 2026) noch aus; bis zur endgültigen Veröffentlichung gilt formal weiterhin der ursprüngliche Zeitplan. Für den hier beschriebenen Anwendungsfall ist dies ohnehin nachrangig, da keine Hochrisiko-Einordnung vorliegt.

6.4 Pflichten, die bereits jetzt gelten

Art. 4 KI-VO – KI-Kompetenz (AI Literacy): Seit dem 2. Februar 2025 sind Anbieter und Betreiber von KI-Systemen verpflichtet, ausreichende KI-Kompetenz bei ihrem Personal und sonstigen im Auftrag mit dem Betrieb und der Nutzung von KI-Systemen befassten Personen sicherzustellen. Diese Pflicht gilt unabhängig von der Unternehmensgröße und ist im Projektplan als verbindliche Aufgabe (Schulung aller Nutzenden vor Produktivstart) verankert – siehe Kapitel 10, Phase 4.

Art. 53 KI-VO – GPAI-Pflichten: Transparenz- und Dokumentationspflichten für Allzweck-KI-Modelle (General Purpose AI) sind seit August 2025 anwendbar, die Durchsetzung beginnt ab August 2026. Diese Pflichten treffen primär die Modellanbieter (z. B. Entwickler der eingesetzten offenen Modelle), nicht das nutzende KMU als Betreiber.

Art. 50 KI-VO – Transparenzpflichten: Ab dem 2. August 2026 gilt die Pflicht, mit KI generierte oder veränderte Inhalte kenntlich zu machen, sofern diese nach außen (z. B. gegenüber Kunden) verwendet werden. Dies ist relevant, sobald der KI-Assistent zur Vorbereitung kundengerichteter Texte eingesetzt wird und sollte in der KI-Nutzungsrichtlinie (Kapitel 4.9) geregelt werden.

6.5 Fazit

Die unmittelbaren rechtlichen Pflichten aus dem EU AI Act sind für den geplanten Anwendungsfall überschaubar. Die wichtigste konkrete Aufgabe ist die Sicherstellung der KI-Kompetenz nach Art. 4 KI-VO durch Schulung. Governance-Elemente, die für den AI Act ohnehin sinnvoll sind (Rollen, Risikobewertung, Dokumentation, Transparenz), decken sich weitgehend mit den Anforderungen der ISO/IEC 42001 (Kapitel 7) und sollten synergetisch aufgebaut werden.

7. ISO/IEC 42001 – Weg zur Zertifizierung

7.1 Was ist ISO/IEC 42001?

ISO/IEC 42001:2023 ist der erste internationale Standard für ein KI-Managementsystem (Artificial Intelligence Management System, AIMS). Er folgt wie ISO 9001 (Qualität) und ISO/IEC 27001 (Informationssicherheit) der High-Level-Structure (HLS) der ISO-Managementsystemnormen und ist nach dem PDCA-Zyklus (Plan–Do–Check–Act) aufgebaut. Die Norm ist branchenunabhängig anwendbar und für Organisationen jeder Größe konzipiert, die KI-Systeme entwickeln, betreiben oder nutzen.

7.2 Nutzen für das Unternehmen

• Strukturierter Nachweis eines verantwortungsvollen, kontrollierten KI-Einsatzes gegenüber Kunden, insbesondere gegenüber größeren Zulieferpartnern und öffentlichen Auftraggebern, bei denen ISO 42001 zunehmend als Ausschreibungskriterium oder Vertrauenssignal nachgefragt wird.
• Systematische Vorbereitung auf künftige EU-AI-Act-Pflichten: Die AIMS-Dokumentation (Risikobewertung, Rollen, Kontrollen) lässt sich für Konformitätsnachweise weiterverwenden.
• Synergien mit vorhandenen Managementsystemen: Messtechnik-Unternehmen verfügen häufig bereits über ein Qualitätsmanagementsystem nach ISO 9001 oder/und ISO/IEC 17025 (Kalibrierlabore), die HLS-Struktur erlaubt eine weitgehende Integration statt eines Parallelsystems.
• Interne Wirkung: Klare Verantwortlichkeiten und dokumentierte Prozesse reduzieren das Risiko von Fehlnutzung, Datenschutzverstößen und Wissensverlust bei einem KMU dieser Größe.

7.3 Geltungsbereich (Scope) festlegen

Empfehlung für den Zertifizierungsumfang: „Bereitstellung und Betrieb eines internen, on-premise gehosteten KI-Assistenzsystems auf Basis von Open WebUI und lokal betriebenen Sprachmodellen einschließlich retrieval-gestützter Wissenssuche (RAG) für die Mitarbeitenden des Unternehmens am Standort [Ort].“ Ein eng gefasster, realistischer Scope beschleunigt die Zertifizierung erheblich gegenüber einem unternehmensweiten AIMS für alle denkbaren KI-Anwendungen.

7.4 Fahrplan zur Zertifizierung

Für ein KMU dieser Größenordnung ist ein realistischer Zeitrahmen von ca. 9–12 Monaten bis zur Zertifizierungsreife anzusetzen (Literaturwerte nennen 6–18 Monate je nach Ausgangslage). Der Fahrplan gliedert sich in fünf Kernschritte, die im Phasenplan (Kapitel 10) zeitlich verankert sind:

Schritt	Inhalt	Ergebnis
1. Gap-Analyse	Abgleich Ist-Zustand gegen ISO/IEC 42001 Kapitel 4–10 und Anhang A	Maßnahmenliste mit Priorisierung
2. Projektteam & Governance	Benennung AIMS-Verantwortlicher, KI-Politik verabschieden	KI-Politik, Rollenmatrix
3. Risikobewertung	KI-spezifische Risiko- und Auswirkungsbewertung je Anwendungsfall	Risikoregister (Kapitel 11)
4. Dokumentation	AIMS-Handbuch, Verfahrensanweisungen, Nachweise (Schulung, Audits)	Vollständige AIMS-Dokumentation
5. Interne Audits & Review	Internes Audit, Management-Review, Korrekturmaßnahmen	Auditbericht, Freigabe zur Zertifizierung

7.5 Kernanforderungen im Überblick

Wie bei ISO 9001/27001 gliedert sich die Norm in sieben Hauptkapitel:

• Kontext der Organisation (Kap. 4): interessierte Parteien, Scope-Definition.
• Führung (Kap. 5): KI-Politik, Rollen und Verantwortlichkeiten – bei 12 Mitarbeitenden häufig in Doppelfunktionen (siehe Kapitel 9).
• Planung (Kap. 6): Risiken und Chancen, KI-Ziele, Auswirkungsbewertung (AI Impact Assessment) je System.
• Unterstützung (Kap. 7): Ressourcen, Kompetenz (Schnittstelle zu Art. 4 KI-VO), Bewusstsein, Kommunikation, dokumentierte Information.
• Betrieb (Kap. 8): operative Planung und Steuerung des KI-Lebenszyklus, Lieferanten-/Drittanbietermanagement.
• Bewertung der Leistung (Kap. 9): Monitoring, internes Audit, Management-Review.
• Verbesserung (Kap. 10): Umgang mit Nichtkonformitäten, kontinuierliche Verbesserung.

Ergänzend definiert Anhang A konkrete Kontrollen (u. a. zu KI-Richtlinie, Ressourcenmanagement, Daten für KI-Systeme, Transparenz gegenüber Betroffenen, Nutzung von Drittanbieter-/Open-Source-Komponenten wie Ollama-Modellen, sowie zur Bewertung gesellschaftlicher Auswirkungen). Diese Kontrollen sollten 1:1 auf die in Kapitel 8 beschriebene technische Architektur gemappt werden.

7.6 Zertifizierungsprozess

• Stage-1-Audit: Dokumentenprüfung durch die Zertifizierungsstelle (Prüfung von AIMS-Handbuch, KI-Politik, Risikoregister, Verfahrensanweisungen).
• Stage-2-Audit: Wirksamkeitsprüfung vor Ort bzw. remote (Interviews, Stichproben, technische Prüfung der umgesetzten Kontrollen).
• Zertifikatserteilung bei erfolgreichem Audit, Gültigkeit i. d. R. 3 Jahre.
• Jährliche Überwachungsaudits (Surveillance Audits) zur Aufrechterhaltung des Zertifikats.
• Re-Zertifizierungsaudit nach Ablauf des dreijährigen Zyklus.

7.7 Wahl der Zertifizierungsstelle

Es wird empfohlen, ausschließlich eine bei der Deutschen Akkreditierungsstelle (DAkkS) bzw. einer gleichwertigen europäischen Akkreditierungsstelle akkreditierte Zertifizierungsstelle zu beauftragen (z. B. TÜV-Gesellschaften, DNV, DEKRA oder vergleichbare Anbieter. Die konkrete Auswahl sollte über mind. zwei bis drei Vergleichsangebote erfolgen, inklusive Erfahrung mit KMU und mit produzierenden Unternehmen).

8. Technische Architektur und Umsetzung

Die technische Basis folgt dem vom Unternehmen vorgeschlagenen Ansatz (Open WebUI + Ollama, Docker-basiert) und wird um die für ein sicheres, zertifizierungsfähiges KMU-Setup notwendigen Absicherungen ergänzt.

8.1 Zielarchitektur

Empfohlen wird ein Docker-Compose-Deployment auf einem dedizierten, physisch im Unternehmen befindlichen Server (alternativ: Mini-Server/Mac-Mini-Klasse für den Einstieg, mit Option auf Aufrüstung). Das LLM-Backend benötigt für den Kernbetrieb keine ausgehende Internetverbindung. Ein weitgehend netzisolierter („air-gap-naher“) Betrieb ist möglich und aus Datenschutz- und Sicherheitssicht auch empfehlenswert.

8.2 Komponentenübersicht

Komponente	Funktion	Empfehlung für das Projekt
Open WebUI	Frontend, Nutzer-/Rechteverwaltung, RAG-Oberfläche	Versionsgepinnt betreiben (kein „:main“-Tag), regelmäßige kontrollierte Updates
Ollama	Lokale Modell-Runtime	Modellwahl nach Kapitel 8.4, keine automatische Cloud-Anbindung
Vektordatenbank (RAG)	Speicherung/Suche in Wissensbasis	Start mit integrierter ChromaDB; bei wachsendem Dokumentenbestand Qdrant erwägen
Reverse Proxy (nginx/Caddy)	Verschlüsselter, kontrollierter Zugriff im Firmennetz	TLS-Zertifikat, Zugriff nur aus internem Netz/VPN
Nutzerverwaltung	Authentifizierung	Nach Möglichkeit Anbindung an bestehendes Verzeichnis (z. B. via SSO/LDAP), sonst individuelle Konten je Mitarbeiter/in

8.3 Hardwareplanung

Für 12 Nutzende mit überwiegend sequenzieller Nutzung (kein Hochlast-Massenbetrieb) genügt in der Regel ein Server mit einer Consumer- bis Prosumer-GPU (z. B. Klasse RTX 4000/4060 Ti 16 GB oder vergleichbar) für Modelle im Bereich von 7-14 Milliarden Parametern in quantisierter Form. Für höhere Qualitätsanforderungen oder mehr gleichzeitige Nutzung sollte eine GPU mit mehr VRAM (24 GB+) budgetiert werden. Ein reiner CPU-Betrieb ist möglich, aber für den Produktiveinsatz mit mehreren gleichzeitigen Nutzenden spürbar langsamer und wird nicht empfohlen. Die konkrete Dimensionierung sollte nach einer kurzen Pilotphase (Phase 3) anhand der tatsächlichen Nutzungslast validiert werden.

8.4 Modellauswahl – Kriterien

Die konkrete Modellauswahl ist eine technische Entscheidung im Projektverlauf, sollte aber anhand folgender Kriterien getroffen und dokumentiert werden (relevant auch für ISO 42001 Anhang A, „Daten für KI-Systeme“):

• Offene, klar lizenzierte Modellgewichte (Lizenzbedingungen für kommerzielle Nutzung prüfen).
• Qualität in deutscher Sprache und in technisch-fachsprachlichen Kontexten (Messtechnik-Terminologie).
• Ressourcenbedarf passend zur verfügbaren Hardware (siehe 8.3).
• Nachvollziehbare Herkunft und Update-/Support-Historie des Modellanbieters (Dokumentationspflicht im Rahmen von Art. 53 KI-VO trifft zwar den Anbieter, sollte aber als Auswahlkriterium für den Betreiber dienen).
• Keine automatische Telemetrie oder Kontaktaufnahme zu externen Servern im Regelbetrieb.

8.5 Sicherheitskonzept

• Netzsegmentierung (eigenes VLAN für den KI-Server), kein direkter Internetzugriff auf das Backend.
• Zugriff ausschließlich über abgesicherten Reverse Proxy mit TLS-Zertifikat, idealerweise nur aus dem internen Netz bzw. über Firmen-VPN erreichbar.
• Rollen-/Rechtekonzept: Admin-Rolle auf IT-Verantwortliche(n) beschränkt, Standardnutzende ohne Zugriff auf Systemkonfiguration.
• Protokollierung sicherheitsrelevanter Ereignisse mit definierter, datenschutzkonformer Aufbewahrungsfrist.
• Regelmäßige, geprüfte Backups (3-2-1-Prinzip empfohlen) und dokumentiertes Wiederherstellungsverfahren.
• Definierter Patch- und Update-Prozess für alle Komponenten (Open WebUI, Ollama, Betriebssystem, Container-Basisimages).
• Diese Maßnahmen decken sich weitgehend mit den freiwillig herangezogenen NIS2-Basismaßnahmen (Kapitel 5.4) und den Art. 32-DSGVO-Anforderungen (Kapitel 4.6).

8.6 Kontrolle und Deaktivierung kritischer Cloud-Funktionen

Open WebUI bietet zahlreiche optionale Erweiterungen (externe Websuche-Anbieter, externe Bildgenerierung, externe Sprach-/Transkriptionsdienste, Cloud-Modelle als Zusatzoption). Diese Funktionen sind leistungsfähig, widersprechen jedoch dem On-Premise- und Datenschutzkonzept dieses Projekts, sobald sie personenbezogene oder vertrauliche Daten an Dritte übermitteln.

Hinweis: Empfehlung: Sämtliche externen/cloud-basierten Erweiterungen in der Administrationsoberfläche standardmäßig deaktiviert lassen. Sollen einzelne Cloud-Funktionen künftig dennoch genutzt werden (z. B. eine externe Websuche für nicht-vertrauliche Recherchen), ist dies vorab datenschutzrechtlich zu bewerten (Auftragsverarbeitungsvertrag, ggf. Transfer-Folgenabschätzung bei Drittlandbezug) und in der KI-Nutzungsrichtlinie ausdrücklich zu regeln.

9. Projektorganisation und Rollen

Bei einem Unternehmen mit 12 Mitarbeitenden ist eine vollständige Trennung aller Rollen auf unterschiedliche Personen unrealistisch. ISO/IEC 42001 verlangt jedoch klar dokumentierte Verantwortlichkeiten, auch dann wenn eine Person mehrere Rollen in Personalunion wahrnimmt. Entscheidend ist die schriftliche Fixierung, nicht die Anzahl der Köpfe.

Rolle	Verantwortung	Besetzungsempfehlung (12-MA-KMU)
Projektleitung / Geschäftsführung	Gesamtverantwortung, Freigabe KI-Politik, Budget	Geschäftsführung
AIMS-/KI-Verantwortliche(r)	Aufbau und Pflege des KI-Managementsystems, Ansprechperson für Audits	Geschäftsführung oder benannte Führungskraft, ggf. mit externer Unterstützung
IT-Administration	Technischer Betrieb, Sicherheitskonfiguration, Patch-Management	Interne IT-Zuständigkeit oder externer IT-Dienstleister
Datenschutz-Ansprechperson / DSB	DSFA, Verarbeitungsverzeichnis, Betroffenenanfragen	Extern zu bestellender Datenschutzbeauftragter empfohlen (siehe Kapitel 4.4)
Key User / Multiplikatoren	Fachliche Rückmeldung aus den Abteilungen, Schulungsunterstützung	1–2 erfahrene Mitarbeitende aus der Fachpraxis
Externe Beratung ISO 42001 (optional)	Gap-Analyse, Auditvorbereitung	Bei Bedarf punktuell hinzuziehen, insbesondere vor Stage-1-Audit

10. Phasenplan und Meilensteine

Der Gesamtzeitraum bis zur Zertifizierungsreife beträgt ca. 10–12 Monate. Mehrere Phasen laufen bewusst parallel, um die begrenzten personellen Kapazitäten eines 12-Personen-Betriebs realistisch abzubilden. Der Aufbau des AIMS (Phase 5) beginnt bereits während der technischen Implementierung und läuft bis zur internen Auditreife mit.

#	Phase	Monat	Wesentliche Ergebnisse
0	Projektinitiierung & Scoping	1	Projektauftrag, Zieldefinition, Scope-Festlegung ISO 42001, Budgetfreigabe
1	Rechtliche Grundlagenarbeit	1–2	DSFA, Klärung DSB-Pflicht, Verarbeitungsverzeichnis, NIS2-Kurzcheck, KI-Nutzungsrichtlinie (Entwurf)
2	Technisches Konzept & Beschaffung	2–3	Hardwareauswahl, Netzwerk-/Sicherheitskonzept, Modellauswahl, Beschaffung
3	Implementierung & Pilotbetrieb	3–4	Installation Open WebUI/Ollama, RAG-Aufbau, Testbetrieb mit Kerngruppe
4	Rollout & Schulung	4–5	Schulung aller Mitarbeitenden (inkl. Art. 4 KI-VO), produktiver Rollout, KI-Nutzungsrichtlinie final
5	Aufbau AIMS nach ISO 42001	3–8	KI-Politik, Rollenmatrix, Risikoregister, Dokumentation (läuft parallel ab Pilotstart)
6	Interne Audits & Management-Review	8–9	Internes Audit, Korrekturmaßnahmen, Freigabe durch Geschäftsführung
7	Zertifizierungsaudit (Stage 1 + 2)	9–11	Auswahl Zertifizierungsstelle, Dokumentenprüfung, Vor-Ort-/Remote-Audit
8	Zertifikatserteilung & Betrieb	ab 11–12	Zertifikat, laufender Betrieb, jährliches Überwachungsaudit, kontinuierliche Verbesserung

11. Risikomanagement

Das folgende Risikoregister bildet zugleich einen Baustein der nach ISO/IEC 42001 Kapitel 6 geforderten Risikobewertung und sollte im Projektverlauf laufend fortgeschrieben werden.

Risiko	Kategorie	Wahrsch.	Auswirkung	Maßnahme
Versehentliche Aktivierung von Cloud-Plugins (Websuche, externe API)	Datenschutz	Mittel	Hoch	Admin-Konfiguration sperren, KI-Nutzungsrichtlinie, regelmäßige Konfigurationsprüfung
Geringe Akzeptanz bei Mitarbeitenden	Organisation	Mittel	Mittel	Frühe Einbindung, verständliche Schulung, Key User als Multiplikatoren
Unzureichende Hardware-Performance im Praxisbetrieb	Technik	Mittel	Mittel	Pilotphase zur Lastvalidierung vor Vollausbau, Hardware skalierbar planen
Know-how-/Geheimnisabfluss über Prompt-Eingaben bei künftiger Cloud-Erweiterung	Datenschutz / GeschGehG	Niedrig (bei Einhaltung 8.6)	Hoch	Technische Deaktivierung, klare Richtlinie, Schulung zu Geheimhaltungspflichten
Fehlerhafte KI-Ausgaben bei technischer Interpretation von Messdaten (Halluzination)	Fachlich / Qualität	Mittel	Hoch	Verbindliche Pflicht zur fachlichen Prüfung vor Weiterverwendung, keine automatisierte Freigabe von KI-Texten in Prüfberichten
Verzögerung durch begrenzte interne Kapazität (12-MA-Betrieb)	Projekt	Hoch	Mittel	Realistische Zeitplanung, punktuelle externe Unterstützung bei Datenschutz und ISO 42001
Modell-Deprecation / Wegfall der Lizenz eines genutzten offenen Modells	Technik	Niedrig	Mittel	Modellwahl dokumentieren, Wechsel auf Alternativmodell als Notfallplan vorsehen
Nichterreichen der Zertifizierungsreife im geplanten Zeitraum	Projekt / Zertifizierung	Mittel	Mittel	Frühzeitige Gap-Analyse, iterative interne Audits statt „Big Bang“ vor Stage 1

12. Kosten- und Ressourcenplanung

Die folgenden Angaben sind grobe Orientierungswerte auf Basis marktüblicher Bandbreiten für Beratung, Hardware und Zertifizierung in Deutschland (Stand 2026) und ersetzen keine konkreten Angebote. Es wird empfohlen, vor der Budgetfreigabe mindestens zwei bis drei Vergleichsangebote für die kostenintensiven Positionen (Beratung, Zertifizierung) einzuholen.

Position	Art	Grobe Schätzung	Anmerkung
Hardware (Server/GPU, Netzwerkkomponenten)	Einmalig	ca. 3.000 – 12.000 €	abhängig von Modellgröße und Nutzerlast; Software selbst ist Open Source (kostenfrei)
Externe IT-Einrichtung/Setup-Unterstützung (optional)	Einmalig	ca. 1.500 – 5.000 €	Docker-Setup, Absicherung, RAG-Konfiguration, falls nicht intern abgedeckt
Externer Datenschutzbeauftragter (falls nicht intern)	Laufend, jährlich	ca. 2.000 – 6.000 €/Jahr	abhängig von Umfang und Anbieter, für ein KMU dieser Größe
Externe Beratung ISO 42001 (Gap-Analyse, Auditvorbereitung)	Einmalig	ca. 4.000 – 15.000 €	stark abhängig vom internen Vorwissen und vorhandenen Managementsystemen (z. B. ISO 9001)
Zertifizierungsaudit (Stage 1 + 2)	Einmalig, dann jährlich (Überwachung)	ca. 4.000 – 10.000 €	abhängig von Zertifizierungsstelle und Scope; jährliche Überwachungsaudits günstiger
Schulung Mitarbeitende (KI-Kompetenz, Nutzung)	Einmalig + laufend	ca. 1.000 – 3.000 €	kann teilweise intern durchgeführt werden
Interne Personalzeit (Projektleitung, IT, Fachbereiche)	Laufend über Projektlaufzeit	nicht in Euro beziffert	bei 12 Mitarbeitenden signifikanter Faktor – realistische Kapazitätsplanung erforderlich

13. Erfolgskriterien

• Alle 12 Mitarbeitenden sind geschult und nutzen den KI-Assistenten aktiv für mindestens einen dokumentierten Anwendungsfall.
• Keine gemeldeten Datenschutz- oder Geheimnisschutzvorfälle im Zusammenhang mit der KI-Nutzung.
• Verarbeitungsverzeichnis, DSFA und KI-Nutzungsrichtlinie sind vollständig dokumentiert und aktuell.
• Erfolgreicher Abschluss von Stage-1- und Stage-2-Audit und Erteilung des ISO/IEC-42001-Zertifikats innerhalb des geplanten Zeitrahmens.
• Positives Feedback der Mitarbeitenden zur Nutzbarkeit (z. B. über kurze interne Befragung nach 1 und je 3 Monaten Produktivbetrieb).
• Nachweisbare Zeitersparnis in mindestens einem definierten Anwendungsfall (z. B. Dokumentenrecherche, Textentwürfe, Standard-Supportfälle).

14. Nächste Schritte (erste 30 Tage)

• Projektauftrag durch die Geschäftsführung formal freigeben, Budget grob abstecken.
• AIMS-/KI-Verantwortliche(n) benennen (auch in Personalunion mit Geschäftsführung möglich).
• Rechtsberatung bzw. externen Datenschutzberater für DSFA-Vorprüfung und Klärung der DSB-Pflicht kontaktieren.
• NIS2-Kurzcheck (Anhang A) intern durchführen und dokumentieren, insbesondere Jahresumsatz/Bilanzsumme gegen die Schwellenwerte prüfen.
• Erste technische Anforderungen (Nutzerzahl, gewünschte Anwendungsfälle, vorhandene Hardware) erfassen und Angebote für Server-Hardware einholen.
• Grobe Marktsichtung von ISO/IEC 42001-Zertifizierungsstellen und ggf. Beratungsunternehmen starten (Angebotsvergleich).
• Kick-off-Meeting mit allen Mitarbeitenden zur Projektankündigung und Erwartungsklärung durchführen.

15. Anhang

Anhang A – NIS2-Anwendbarkeits-Kurzcheck

• Beschäftigt das Unternehmen in der Regel 50 oder mehr Personen? (Falls nein → weiter prüfen)
• Übersteigt der Jahresumsatz 10 Mio. € oder die Bilanzsumme 10 Mio. €? (Falls nein → NIS2-Pflicht i. d. R. nicht einschlägig)
• Ist das Unternehmen alleiniger Anbieter eines für Deutschland kritischen Dienstes, qualifizierter Vertrauensdiensteanbieter, TLD-/DNS-Anbieter, Telekommunikationsanbieter oder nach dem KRITIS-Dachgesetz als kritisch eingestuft? (Falls nein → keine größenunabhängige Sonderpflicht)
• Verlangt ein wesentlicher Kunde vertraglich NIS2-nahe Sicherheitsnachweise im Rahmen der Lieferkette? (Falls ja → freiwillige Orientierung an NIS2-Basismaßnahmen empfohlen, unabhängig von eigener Pflicht)

Anhang B – DSFA-Vorprüfung (Kurzcheck nach Art. 35 Abs. 3 DSGVO / DSK-Kriterien)

• Werden Verhaltens- oder Leistungsdaten einzelner Mitarbeitender systematisch ausgewertet?
• Werden besondere Kategorien personenbezogener Daten (Art. 9 DSGVO) verarbeitet oder in der Wissensbasis abgelegt?
• Kommt eine neuartige Technologie mit unklarer Risikoeinschätzung zum Einsatz (KI-Sprachmodelle gelten regelmäßig als solche)?
• Werden Daten in großem Umfang (viele Dokumente/Personen) automatisiert verarbeitet oder durchsuchbar gemacht?
• Ergibt sich aus mehreren „Ja“-Antworten ein erhöhtes Risiko, ist eine DSFA durchzuführen bzw. zumindest zu dokumentieren, warum keine erforderlich ist.

Anhang C – Wesentliche Rechtsgrundlagen (Übersicht)

• Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung, DSGVO)
• Bundesdatenschutzgesetz (BDSG), insb. §§ 26, 38
• Richtlinie (EU) 2022/2555 (NIS2-Richtlinie) sowie das deutsche Umsetzungsgesetz NIS2UmsuCG (novelliertes BSI-Gesetz, BSIG-neu), in Kraft seit 6. Dezember 2025
• Verordnung (EU) 2024/1689 (KI-Verordnung / EU AI Act), insb. Art. 4, 5, 50, 53
• Digital Omnibus on AI → politische Einigung vom 7. Mai 2026 zur Fristverschiebung der Hochrisiko-Pflichten (formale Verabschiedung zum Stand August 2026 ausstehend)
• ISO/IEC 42001:2023 → Artificial intelligence Management system
• Gesetz zum Schutz von Geschäftsgeheimnissen (GeschGehG)
• Betriebsverfassungsgesetz (BetrVG), insb. § 87 Abs. 1 Nr. 6 (soweit Betriebsrat vorhanden)