# conn.AI Wissens-Volltext

> Vollständige Textfassung aller Fachartikel zu On-Premise-KI, Compliance
> und Softwareentwicklung, kombiniert für KI-Antwort-Engines und LLM-Kontext.
> Erstellt vom Anbieter G.P.C.3X GmbH. Stand: 2026-08-18.

Diese Datei enthält den redaktionell aufbereiteten Volltext der Wissens-Artikel
auf https://connai.de/wissen/. Die Kurzfassung mit Positionierung und FAQ steht
in https://connai.de/llms.txt

---

## Artikel 1: KI und DSGVO im Unternehmen: Was ist erlaubt und wann wird es kritisch?

- URL: https://connai.de/wissen/dsgvo-und-ki-im-mittelstand.html
- Thema: DSGVO, Rechtsgrundlage, Auftragsverarbeitung, Drittlandsuebermittlung
- Stand: 2026-08-18

Die DSGVO enthält kein generelles Verbot von KI. Maßgeblich sind vier
Fragen: Welche Daten fließen hinein, zu welchem Zweck, auf welcher
Rechtsgrundlage und wer verarbeitet sie mit? Zusätzliche Anforderungen
können entstehen, sobald personenbezogene Daten an einen externen Dienst
gehen oder Entscheidungen über Personen vorbereitet werden. Bleiben
Verarbeitung und Daten vollständig im eigenen Netz, entfällt für diesen
Schritt grundsätzlich die Drittlandsübermittlung, die übrigen Pflichten
bestehen fort.

### Wie das Thema im Alltag entsteht

Ein Mitarbeiter kopiert einen Kundenvertrag in einen KI-Assistenten, um sich
die Kernpunkte zusammenfassen zu lassen. Eine Kollegin aus der
Personalabteilung lässt sich zehn Bewerbungsunterlagen vorsortieren. Im
Vertrieb landet eine Kundenliste im Chat, weil das Formulieren der Serienmail
sonst zwei Stunden dauert.

Niemand davon handelt in böser Absicht. Trotzdem sind das drei Verarbeitungen
personenbezogener Daten, für die eine Rechtsgrundlage, gegebenenfalls ein
Vertrag mit dem Anbieter und ein Eintrag im Verarbeitungsverzeichnis
erforderlich sind. Auffallen tut es meist erst Monate später.

### Was die DSGVO verlangt

Die Datenschutz-Grundverordnung[1] enthält keine Sonderregeln für KI. Sobald
personenbezogene Daten verarbeitet werden, gelten dieselben Grundsätze wie
bei jeder anderen Software. Vier Punkte haben in der Praxis das meiste
Gewicht.

#### Rechtsgrundlage und Zweck

Jede Verarbeitung setzt eine Rechtsgrundlage nach Artikel 6 voraus, in
Betracht kommen etwa ein berechtigtes Interesse oder die Vertragserfüllung.
Der Zweck muss vorher feststehen. „Wir probieren mal aus, was das Modell
damit macht“ ist kein Zweck im Sinne der Verordnung.

#### Wann der Anbieter Auftragsverarbeiter ist

Verarbeitet ein externer Anbieter personenbezogene Daten ausschließlich im
Auftrag und nach Weisung des Unternehmens, ist er für diese Verarbeitung
grundsätzlich Auftragsverarbeiter. Dann ist regelmäßig ein Vertrag nach
Artikel 28 DSGVO erforderlich. Die konkrete datenschutzrechtliche Rolle hängt
von der tatsächlichen Verarbeitung ab, nicht allein von der Bezeichnung im
Vertrag. Anbieter stellen entsprechende Verträge üblicherweise nur in ihren
Geschäftskunden-Tarifen bereit.

#### Übermittlung in Drittländer

Bei Cloud-KI-Diensten ist zu prüfen, ob personenbezogene Daten in ein
Drittland übermittelt werden oder von dort aus zugänglich sind. Entscheidend
sind Anbieter, Tarif, technische Konfiguration und beteiligte
Unterauftragnehmer. Als Grundlage kommt unter anderem der
Angemessenheitsbeschluss der Kommission zum EU-US Data Privacy Framework von
2023[2] in Betracht, soweit der Anbieter zertifiziert ist. Eine Klage gegen
diesen Beschluss wurde im September 2025 in erster Instanz abgewiesen, das
Rechtsmittel ist beim Gerichtshof anhängig[3]. Zwei Vorgängerregelungen
wurden in der Vergangenheit aufgehoben.

#### Auskunft und Löschung

Betroffene können nach Artikel 15 Auskunft und nach Artikel 17 Löschung
verlangen. Beides setzt Kenntnis darüber voraus, wo die Daten liegen.
Speichert ein Dienst Eingaben zur Missbrauchsprüfung, kann der Nachweis einer
vollständigen Löschung schwierig werden.

### Wann zusätzliche Anforderungen entstehen

Nicht jede Nutzung wiegt gleich schwer. Die folgende Einordnung hilft bei der
ersten Sortierung und ersetzt keine Prüfung des Einzelfalls.

Typische Datenarten und ihr Risikoprofil:

| Was verarbeitet wird | Einordnung | Worauf es ankommt |
|---|---|---|
| Maschinen- und Sensordaten ohne Personenbezug | gering | DSGVO greift nicht, Geheimhaltung dennoch prüfen |
| Allgemeine Firmentexte, Angebote ohne Namen | gering | Geschäftsgeheimnisse, nicht Datenschutz |
| Kundenstammdaten, Verträge, Korrespondenz | mittel | Rechtsgrundlage, Auftragsverarbeitung, Drittlandsfrage |
| Beschäftigtendaten, Leistungsbezug | hoch | zusätzlich Beteiligungsrechte, häufig Folgenabschätzung |
| Bewerbungsunterlagen, Vorauswahl | hoch | Diskriminierungsrisiko, Artikel 22 bei automatisierten Entscheidungen |
| Gesundheits-, Sozial- oder Gewerkschaftsdaten | sehr hoch | besondere Kategorien nach Artikel 9, enge Ausnahmen |

### Sechs Fragen vor der Einführung

1. Welche Kategorien personenbezogener Daten fließen in die Anwendung?

2. Wo werden diese Daten verarbeitet und gespeichert?

3. Liegt ein Vertrag nach Artikel 28 DSGVO vor, und deckt er alle Schritte ab?

4. Findet eine Übermittlung in ein Drittland statt, und worauf stützt sie
sich?

5. Werden Eingaben für Training, Missbrauchsprüfung oder Support
gespeichert?

6. Lässt sich belegen, dass ein bestimmter Datensatz gelöscht wurde?

Wer diese sechs Fragen beantworten kann, hat den Großteil der Dokumentation
bereits beisammen.

### Welche Datenschutzfragen lokal einfacher werden

Ein lokal betriebenes KI-System löst den Datenschutz nicht. Es verarbeitet
weiterhin personenbezogene Daten, und die Pflichten aus der Verordnung gelten
unverändert. Verändern kann sich ein bestimmter Teil: die Übermittlung an
einen Dritten.

Wirkung des Betriebsorts auf einzelne Pflichten:

| Pflicht | Wirkung des lokalen Betriebs |
|---|---|
| Vertrag nach Artikel 28 mit dem Modellanbieter | kann entfallen, sofern kein externer Anbieter an der Verarbeitung beteiligt ist |
| Drittlandsübermittlung und deren Bewertung | kann entfallen, sofern keine externen Dienste oder Zugriffe beteiligt sind |
| Nachweis der Löschung | leichter, wenn Daten und Protokolle im eigenen Netz liegen |
| Nutzung der Eingaben für Training ausschließen | leichter, wenn die Daten das Netz nicht verlassen |
| Rechtsgrundlage und Zweckbindung | keine Änderung |
| Verarbeitungsverzeichnis | keine Änderung, der Eintrag kann kürzer ausfallen |
| Datenschutz-Folgenabschätzung | keine Änderung, richtet sich nach Zweck und Risiko |
| Information der Beschäftigten, Beteiligungsrechte | keine Änderung, organisatorische Pflicht |

Zusammengefasst: Der lokale Betrieb kann zwei der aufwändigsten Punkte
entfallen lassen, sofern tatsächlich keine externen Dienste beteiligt sind.
Die übrigen Pflichten bleiben bestehen.

### Ein Blick auf die KI-Verordnung

Neben der DSGVO greift die KI-Verordnung der EU[4]. Sie regelt nicht den
Schutz personenbezogener Daten, sondern das Inverkehrbringen und den Einsatz
von KI-Systemen nach Risikoklassen. Beide Regelwerke gelten nebeneinander. Die
Anwendungsfristen sind gestaffelt und wurden zwischenzeitlich angepasst,
weshalb pauschale Aussagen dazu wenig taugen. Die Einzelheiten stehen im
eigenen Beitrag dazu.

### Was conn.AI liefert, und was bei Ihnen bleibt

conn.AI liefert Edge-Server, Systemsoftware, Anbindung und den laufenden
Betrieb. Nutzdaten der Anwendungen bleiben auf der Hardware im Haus, Zugriffe
und Wartungstätigkeiten werden protokolliert. Soweit bei Fernwartung oder
Support personenbezogene Daten verarbeitet oder zugänglich werden können,
wird dieser Verarbeitungsschritt gesondert betrachtet und vertraglich
geregelt.

Das kann die technische Umsetzung und die Nachweisführung erleichtern.
Zweckbestimmung, Rechtsgrundlage, Verarbeitungsverzeichnis, Löschkonzept und
die Frage, welche Daten Beschäftigte überhaupt eingeben dürfen, bleiben
davon unberührt. Eine Nutzungsregel auf einer Seite Papier verhindert in der
Praxis mehr Vorfälle als jede Architekturentscheidung.

### FAQ zu KI und DSGVO

**Darf ich Kundendaten in ChatGPT eingeben?**

Das lässt sich nicht allgemein beantworten. Sobald personenbezogene Daten in
den Prompt wandern, liegt eine Verarbeitung im Sinne der DSGVO vor. Ein
Geschäftskundentarif und ein Vertrag nach Artikel 28 DSGVO können wichtige
Voraussetzungen abdecken. Ob personenbezogene Kundendaten verarbeitet werden
dürfen, hängt zusätzlich unter anderem von Zweck, Rechtsgrundlage,
Datenkategorie, Konfiguration des Dienstes und möglichen Zugriffen aus
Drittländern ab. Ein privat angelegtes Konto, das im Arbeitsalltag mitbenutzt
wird, deckt diese Voraussetzungen regelmäßig nicht ab.

**Ist ChatGPT im Unternehmen DSGVO-konform?**

Konform oder nicht konform ist keine Eigenschaft des Werkzeugs, sondern des
jeweiligen Einsatzes. Zu prüfen sind unter anderem: welcher Tarif genutzt
wird und ob dafür ein Vertrag nach Artikel 28 DSGVO besteht, welche Daten
tatsächlich eingegeben werden, ob und auf welcher Grundlage eine
Übermittlung in ein Drittland stattfindet, und ob die Beschäftigten wissen,
was zulässig ist. In der Praxis liegt der Schwachpunkt selten beim Vertrag
und häufig beim letzten Punkt.

**Ist On-Premise-KI automatisch DSGVO-konform?**

Nein. Ein lokaler Server verarbeitet weiterhin personenbezogene Daten.
Rechtsgrundlage, Zweckbindung, Verarbeitungsverzeichnis, Löschkonzept und
Zugriffskontrollen sind davon unberührt. Bleiben Verarbeitung, Nutzdaten und
Protokolle vollständig im eigenen Netz und bestehen keine entsprechenden
externen Zugriffe, entfällt für diesen Verarbeitungsschritt grundsätzlich
die Drittlandsübermittlung. Das kann die technische Umsetzung und die
Nachweisführung erleichtern. Die rechtliche und organisatorische Bewertung
bleibt davon unberührt.

**Welche Daten darf ich für lokale KI-Modelle verwenden?**

Der Betriebsort erweitert die Rechtsgrundlage nicht. Was für einen bestimmten
Zweck ohnehin nicht verwendet werden darf, darf auch auf eigener Hardware
nicht dafür verwendet werden. Was sich ändern kann: Findet keine
Übermittlung an einen externen Auftragsverarbeiter statt, entfällt für
diesen Schritt die Prüfung der Drittlandsübermittlung, und eine Löschung
lässt sich auf eigenen Systemen technisch nachvollziehen.

**Brauchen wir eine Datenschutz-Folgenabschätzung, wenn wir KI einsetzen?**

Das kann erforderlich sein. Artikel 35 DSGVO sieht eine Folgenabschätzung
vor, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte
und Freiheiten der Betroffenen zur Folge hat. Der Einsatz von KI ist für sich
genommen kein automatischer Auslöser. Als Risikofaktoren gelten unter anderem
umfangreiche Auswertungen von Beschäftigtendaten, systematische
Profilbildung, besondere Kategorien personenbezogener Daten und Entscheidungen
mit erheblicher Wirkung auf Personen. Die Aufsichtsbehörden führen Listen
von Verarbeitungen, für die eine Folgenabschätzung verpflichtend ist.

**Müssen wir Mitarbeiter informieren, wenn wir ein KI-System einsetzen?**

Werden personenbezogene Daten von Beschäftigten verarbeitet, können
Informationspflichten nach den Artikeln 13 und 14 DSGVO und, abhängig vom
Einsatz, Beteiligungsrechte des Betriebsrats relevant sein. Ist ein System
dazu geeignet, Verhalten oder Leistung zu überwachen, kommt in Betrieben mit
Betriebsrat regelmäßig eine Mitbestimmung nach § 87 Absatz 1 Nummer 6
Betriebsverfassungsgesetz in Betracht. Unabhängig davon hat sich eine
schriftliche Nutzungsregel bewährt, die festhält, welche Daten in welches
Werkzeug gegeben werden dürfen.

**Was passiert, wenn das EU-US Data Privacy Framework fällt?**

Für Übermittlungen, die sich auf den EU-US Data Privacy Framework stützen,
würde diese Grundlage entfallen. Je nach Dienst und Verarbeitung müssten
dann andere Übermittlungsinstrumente geprüft oder die Verarbeitung angepasst
werden. Vergleichbare Situationen gab es 2015 beim Safe-Harbor-Abkommen und
2020 beim Privacy Shield. Der Angemessenheitsbeschluss von 2023 gilt; eine
Klage dagegen wurde im September 2025 in erster Instanz abgewiesen, das
Rechtsmittel ist beim Gerichtshof anhängig.

Quellen: DSGVO (EU 2016/679), KI-Verordnung (EU 2024/1689), Europaeische
Kommission zum EU-US Data Privacy Framework, Gericht der EU T-553/23
(Latombe), EDSA, BfDI.

Hinweis: Dieser Text ist eine allgemeine Einordnung und dient der Information.
Er ersetzt keine Rechtsberatung. Ob und welche Pflichten im Einzelfall gelten,
haengt von der konkreten Situation ab.

---

## Artikel 2: NIS2 und KI: Was Unternehmen seit Dezember 2025 beachten müssen

- URL: https://connai.de/wissen/nis2-und-ki-was-jetzt-zaehlt.html
- Thema: NIS2, BSIG 2025, Registrierung, Meldefristen
- Stand: 2026-08-18

Das deutsche NIS2-Umsetzungsgesetz gilt seit dem 6. Dezember 2025. Das BSI
ging zum Inkrafttreten von rund 29.500 betroffenen Einrichtungen in
Deutschland aus. Für betroffene Einrichtungen sieht das BSIG eine
Registrierung beim BSI, dokumentierte Risikomanagementmaßnahmen und eine
Erstmeldung erheblicher Sicherheitsvorfälle innerhalb von 24 Stunden vor.
KI-Systeme sind dabei kein Sonderfall: Sie gehören zur Verarbeitungskette und
damit in die Risikoanalyse.

### Ein Beispiel aus dem Betriebsalltag

Ein Zulieferer aus dem Maschinenbau, 180 Beschäftigte, beliefert unter
anderem einen regionalen Energieversorger. In der Instandhaltung läuft seit
einem Jahr ein Cloud-Assistent, der Wartungsprotokolle auswertet und
Störungsmeldungen vorsortiert. An einem Montagmorgen antwortet der Dienst
nicht mehr. Der Anbieter meldet nach vier Stunden eine
„Sicherheitsstörung“ ohne weitere Angaben.

Jetzt stellen sich drei Fragen gleichzeitig. Handelt es sich um einen
meldepflichtigen Vorfall? Welche Daten lagen zum Zeitpunkt der Störung beim
Anbieter? Und wer im Haus entscheidet das innerhalb der nächsten 24 Stunden?
Daran zeigt sich, ob NIS2 vorbereitet wurde oder nicht.

### Seit wann das Gesetz gilt

Die NIS2-Richtlinie[1] hätte bis Oktober 2024 in nationales Recht umgesetzt
sein müssen. Deutschland war deutlich später dran: Der Bundestag beschloss
das Umsetzungsgesetz am 13. November 2025, der Bundesrat stimmte am 21.
November zu, die Verkündung im Bundesgesetzblatt erfolgte am 5. Dezember
2025. Seit dem 6. Dezember 2025 ist das neue BSIG in Kraft[2].

Eine allgemeine Schonfrist enthält das Gesetz nicht. Das BSI ging zum
Inkrafttreten von rund 29.500 betroffenen Einrichtungen in Deutschland aus,
deutlich mehr als unter der vorherigen KRITIS-Regelung.

### Wer betroffen ist

Ob eine Einrichtung in den Anwendungsbereich fällt, hängt nach § 28 BSIG[3]
von zwei Bedingungen ab, die zusammentreffen müssen: der Zugehörigkeit zu
einem Sektor nach den Anlagen 1 und 2 und dem Überschreiten einer
Größenschwelle.

Größenschwellen nach § 28 BSIG:

| Einrichtungsart | Schwelle | Bußgeldrahmen nach § 65 BSIG |
|---|---|---|
| Besonders wichtige Einrichtung | mindestens 250 Beschäftigte, oder Jahresumsatz über 50 Mio. Euro und zudem Jahresbilanzsumme über 43 Mio. Euro | bis 10 Mio. Euro |
| Wichtige Einrichtung | mindestens 50 Beschäftigte, oder Jahresumsatz und Jahresbilanzsumme von jeweils über 10 Mio. Euro | bis 7 Mio. Euro |

Die Verknüpfung ist dabei wichtig: Die Umsatzschwelle wirkt nicht für sich
allein, sondern nur zusammen mit der Bilanzsumme. Betreiber kritischer Anlagen
sowie einzelne Gruppen wie Telekommunikationsanbieter und qualifizierte
Vertrauensdiensteanbieter erfasst das Gesetz unabhängig von der Größe.

Zu den Sektoren gehören unter anderem Energie, Verkehr, Gesundheit,
Trinkwasser, Abwasser, digitale Infrastruktur, Post, Chemie, Lebensmittel,
Abfallwirtschaft, Forschung sowie die Herstellung von Medizinprodukten,
Maschinen und Fahrzeugen. Die Einstufung nimmt jede Einrichtung selbst vor,
das BSI schreibt Betroffene nicht an.

### Welche Pflichten das Gesetz vorsieht

Pflichten und Fristen für betroffene Einrichtungen:

| Was das Gesetz vorsieht | Frist | Fundstelle |
|---|---|---|
| Registrierung beim BSI | 3 Monate ab Betroffenheit, Änderungen binnen 2 Wochen | § 33 BSIG |
| Risikomanagementmaßnahmen, 10 Bereiche | laufend, dokumentiert | § 30 BSIG |
| Erstmeldung eines erheblichen Sicherheitsvorfalls | 24 Stunden nach Kenntnis | § 32 BSIG |
| Meldung mit Bewertung | 72 Stunden | § 32 BSIG |
| Abschlussbericht | 1 Monat | § 32 BSIG |
| Billigung und Überwachung durch die Geschäftsleitung | laufend | § 38 BSIG |

Die zehn Maßnahmenbereiche aus § 30 BSIG[4] umfassen Risikoanalyse und
Sicherheitskonzepte, Bewältigung von Sicherheitsvorfällen, Aufrechterhaltung
des Betriebs und Krisenmanagement, Sicherheit in der Lieferkette, Sicherheit
bei Beschaffung, Entwicklung und Wartung, Bewertung der Wirksamkeit, Schulung
und Sensibilisierung, Kryptografie, Personal- und Zugriffssicherheit sowie
Multi-Faktor-Authentisierung und gesicherte Kommunikation.

### Was bedeutet das für KI-Systeme?

Im Gesetz kommt KI nicht als eigener Tatbestand vor. Ein KI-System, das Belege
liest, Maschinendaten auswertet oder Texte erzeugt, ist ein IT-System wie
jedes andere. Relevant wird es, sobald es an einem Prozess hängt, der zur
Diensterbringung gehört. Drei Punkte fallen in der Praxis auf.

#### Externe Dienste gehören in die Betrachtung der Lieferkette

Ein externer Cloud-Dienst, an dem ein operativer Prozess hängt, ist bei der
Sicherheit der Lieferkette zu berücksichtigen. § 30 BSIG nennt sie als einen
der zehn Maßnahmenbereiche. Dazu gehören üblicherweise eine Bewertung des
Anbieters, eine Regelung für Störungen und eine Absprache darüber, welche
Informationen im Vorfall bereitgestellt werden.

#### Stille Modellwechsel erschweren die Reproduzierbarkeit

Anbieter aktualisieren ihre Modelle im laufenden Betrieb. Was gestern eine
bestimmte Ausgabe lieferte, liefert heute eine andere. Für ein Verfahren,
dessen Ergebnisse nachvollziehbar sein müssen, ist das ein Risiko, das in die
Bewertung gehört.

#### Für die Meldung braucht es schnell belastbare Informationen

Eine Meldung nach § 32 BSIG setzt Protokolldaten, Konfigurationsstände und
einen Zeitverlauf voraus. Liegen diese Informationen bei einem Dienstleister,
hängt ihre Verfügbarkeit an dessen Auskunftsbereitschaft. Die gesetzliche
Frist läuft davon unabhängig weiter. An dieser Schnittstelle wird aus einer
technischen Frage eine organisatorische.

### Was lokaler Betrieb bei Nachweisen erleichtert

Ein lokal betriebenes System erfüllt die Anforderungen des BSIG nicht von
sich aus. Das Gesetz verlangt Risikomanagementmaßnahmen und Prozesse, kein
Betriebsmodell. Ein lokaler Server ohne Patch-Prozess, ohne Protokollierung
und ohne benannte Zuständigkeit trägt dazu nichts bei.

Einen Unterschied macht der Betriebsort bei der Verfügbarkeit von
Informationen. Bleiben Protokolle, Konfigurationsstände und Zugriffe im
eigenen Netz, liegen sie dort, wo auch die Verantwortung liegt, und die Zahl
der Stellen, bei denen im Ernstfall nachgefragt werden muss, wird kleiner.

Einfluss des Betriebsorts auf einzelne Anforderungen:

| Anforderung | Wirkung des lokalen Betriebs |
|---|---|
| Protokolle für die Vorfallmeldung | können schneller verfügbar sein, sofern sie im eigenen Netz geführt werden |
| Nachvollziehbare Modell- und Softwarestände | leichter, wenn Updates geplant und dokumentiert eingespielt werden |
| Sicherheit in der Lieferkette | die Kette kann kürzer werden, entfällt aber nicht |
| Risikoanalyse und Sicherheitskonzept | keine Erleichterung, bleibt eigene Aufgabe |
| Schulung und Sensibilisierung | keine Erleichterung, organisatorische Pflicht |
| Registrierung und Meldewege | keine Erleichterung, unabhängig vom Betriebsmodell |

### Was conn.AI dazu beiträgt

conn.AI liefert Edge-Server, Systemsoftware, Anbindung und den laufenden
Betrieb. Zugriffs- und Wartungsprotokolle sind Teil des Betriebs, Software-
und Modellstände werden geplant und dokumentiert eingespielt. Nutzdaten der
Anwendungen bleiben auf der Hardware im Haus des Kunden. Soweit bei
Fernwartung oder Support Daten zugänglich werden können, wird dieser Schritt
gesondert betrachtet und vertraglich geregelt.

Diese Funktionen können die technische Nachweisführung unterstützen.
Risikomanagement, Meldeprozesse, die Einstufung des eigenen Unternehmens und
die in § 38 BSIG geregelte Verantwortung der Geschäftsleitung werden dadurch
nicht ersetzt.

### FAQ zu NIS2 und KI

**Bin ich mit 50 Mitarbeitern von NIS2 betroffen?**

Die Mitarbeiterzahl allein entscheidet das nicht. Nach § 28 BSIG müssen zwei
Bedingungen zusammentreffen: die Zugehörigkeit zu einem der in den Anlagen 1
und 2 des BSIG genannten Sektoren und das Überschreiten einer
Größenschwelle. Für wichtige Einrichtungen sieht das Gesetz mindestens 50
Beschäftigte vor, alternativ einen Jahresumsatz und eine Jahresbilanzsumme
von jeweils über 10 Millionen Euro. Liegt keine Sektorzugehörigkeit vor,
greift das Gesetz auch bei deutlich größeren Unternehmen nicht. Umgekehrt
können betroffene Einrichtungen über die Sicherheit der Lieferkette
Anforderungen an ihre Zulieferer weitergeben, ohne dass diese selbst reguliert
sind.

**Ab wann gilt NIS2 in Deutschland?**

Seit dem 6. Dezember 2025. Das NIS2-Umsetzungsgesetz wurde am 5. Dezember 2025
im Bundesgesetzblatt verkündet und trat am Folgetag in Kraft. Eine allgemeine
Übergangsfrist enthält das Gesetz nicht, die Pflichten gelten seitdem
unmittelbar.

**Muss ich mich beim BSI registrieren und bis wann?**

Für betroffene Einrichtungen sieht § 33 BSIG eine Registrierungspflicht vor.
Nach den Hinweisen des BSI beträgt die Frist drei Monate ab dem Zeitpunkt, zu
dem eine Einrichtung erstmals betroffen ist, Änderungen an den gemeldeten
Angaben sind binnen zwei Wochen nachzuziehen. Die Registrierung läuft in zwei
Schritten: zunächst eine Anmeldung beim Dienst "Mein Unternehmenskonto",
danach die Registrierung im BSI-Portal. Die Einstufung nimmt jede Einrichtung
selbst vor, das BSI schreibt Betroffene nicht an.

**Muss ein KI-Server unter NIS2 besonders abgesichert werden?**

Das BSIG enthält keine eigene Vorschrift für KI-Systeme. Ein Server, auf dem
Sprachmodelle oder Auswertungen laufen, ist aus Sicht des Gesetzes ein
IT-System wie jedes andere und fällt bei betroffenen Einrichtungen unter die
Maßnahmenbereiche nach § 30 BSIG, darunter Zugriffskontrolle, Kryptografie,
Behandlung von Sicherheitsvorfällen und Multi-Faktor-Authentisierung.
Praktische Bedeutung bekommt er, sobald er an einem Prozess hängt, der zur
Diensterbringung gehört. Dann ist er in Risikoanalyse und Wiederanlaufplanung
einzubeziehen.

**Ist On-Premise-KI automatisch NIS2-konform?**

Nein. Das BSIG verlangt Risikomanagementmaßnahmen und Prozesse, kein
bestimmtes Betriebsmodell. Ein lokal betriebener Server ohne Protokollierung,
ohne Patch-Prozess und ohne benannte Zuständigkeit trägt zur Erfüllung
ebenso wenig bei wie ein unkontrollierter Cloud-Zugang. Der Unterschied liegt
an anderer Stelle: Bleiben Protokolle, Konfigurationsstände und Zugriffe im
eigenen Netz, sind die Informationen für eine Nachweisführung schneller
verfügbar und die Lieferkette wird kürzer. Die rechtliche und
organisatorische Bewertung bleibt davon unberührt.

**Was sieht das Gesetz bei einer verspäteten Meldung vor?**

Verstöße gegen Pflichten aus dem BSIG sind bußgeldbewehrt. § 65 BSIG sieht
einen Rahmen von bis zu 10 Millionen Euro für besonders wichtige und bis zu 7
Millionen Euro für wichtige Einrichtungen vor. Hinzu kommt die in § 38 BSIG
geregelte Verantwortung der Geschäftsleitung, die die
Risikomanagementmaßnahmen zu billigen und ihre Umsetzung zu überwachen hat.
In der Praxis wirkt daneben der Aufsichtsdruck: Das BSI kann Nachweise,
Prüfungen und Anordnungen verlangen.

**Dürfen Betriebsdaten in einen Cloud-KI-Dienst gegeben werden, wenn eine Einrichtung unter NIS2 fällt?**

NIS2 enthält kein allgemeines Cloud-Verbot. Externe Dienste, an denen
operative Prozesse hängen, sind allerdings bei der Sicherheit der Lieferkette
zu berücksichtigen, die § 30 BSIG als einen der zehn Maßnahmenbereiche
nennt. Dazu gehören üblicherweise eine Bewertung des Anbieters, eine
Regelung für Störungen und die Frage, welche Informationen im Vorfall wie
schnell verfügbar sind. Sind Protokolldaten nicht rechtzeitig zu bekommen,
wird die Frist aus § 32 BSIG zum praktischen Problem. Ob ein konkreter
Einsatz in Ordnung geht, hängt von der jeweiligen Konstellation ab.

Quellen: NIS2-Richtlinie (EU 2022/2555), BSIG 2025 (gesetze-im-internet.de),
BSI-Pressemitteilung vom 05.12.2025, BSI-Themenseiten zu NIS-2-Pflichten,
Registrierung und Meldepflicht.

Hinweis: Dieser Text ist eine allgemeine Einordnung und dient der Information.
Er ersetzt keine Rechtsberatung. Ob und welche Pflichten im Einzelfall gelten,
haengt von der konkreten Situation ab.

---

## Artikel 3: Cyber Resilience Act 2026: Wer ist betroffen und welche Fristen gelten?

- URL: https://connai.de/wissen/cyber-resilience-act.html
- Thema: Cyber Resilience Act, Produktklassen, Fristen, Meldepflichten
- Stand: 2026-08-18

Der Cyber Resilience Act gilt grundsätzlich für Produkte mit digitalen
Elementen, die in der EU auf dem Markt bereitgestellt werden, von der
vernetzten Maschine bis zur eigenständig vertriebenen Software. In die
Pflicht genommen werden Hersteller, Importeure und Händler. Die Verordnung
ist seit dem 10. Dezember 2024 in Kraft, die Pflichten greifen gestaffelt: Ab
dem 11. September 2026 sind aktiv ausgenutzte Schwachstellen binnen 24 Stunden
zu melden, ab dem 11. Dezember 2027 gelten die übrigen Anforderungen.

### Aktueller Stand und Fristen

Die Verordnung (EU) 2024/2847[1] ist bereits geltendes Recht. Gestaffelt ist
die Anwendbarkeit der einzelnen Pflichten.

Gestaffelte Anwendung des CRA:

| Datum | Was anwendbar wird | Status |
|---|---|---|
| 10. Dezember 2024 | Verordnung in Kraft getreten | erledigt |
| 11. Juni 2026 | Regelungen zur Benennung von Konformitätsbewertungsstellen | anwendbar |
| 11. September 2026 | Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle | steht unmittelbar bevor |
| 11. Dezember 2027 | übrige Anforderungen für neu in Verkehr gebrachte Produkte | Vorbereitungszeit |

Die Meldepflichten kommen zuerst. Wer bis dahin keine benannte Kontaktstelle
und keinen festgelegten Ablauf hat, wird die 24-Stunden-Frist im Ernstfall
kaum halten können.

### Wer ist betroffen?

Die Verordnung nimmt drei Rollen in die Pflicht.

Rollen und ihre wesentlichen Pflichten:

| Rolle | Was die Verordnung vorsieht |
|---|---|
| Hersteller | Sicherheitsanforderungen umsetzen, Konformität bewerten, technische Dokumentation führen, Schwachstellen über den Unterstützungszeitraum behandeln, Meldungen absetzen |
| Importeur | vor der Bereitstellung prüfen, ob Konformitätsbewertung, Kennzeichnung und Unterlagen vorliegen |
| Händler | prüfen, ob Kennzeichnung und Herstellerangaben vorhanden sind, und bei Anhaltspunkten für Mängel handeln |

Der Punkt, der im Mittelstand am häufigsten übersehen wird: Wer eine
Maschine mit eigener Steuerungssoftware, ein Gerät mit Netzanbindung oder
eine Softwarelösung in Verkehr bringt, ist regelmäßig Hersteller im Sinne
der Verordnung. Das gilt auch dann, wenn sich das Unternehmen selbst als
Maschinenbauer versteht und die Software als Beiwerk betrachtet.

### Anwendungsbereich: welche Produkte erfasst sind

Erfasst sind grundsätzlich Produkte mit digitalen Elementen, also Hardware
und Software, die eine Datenverbindung zu einem Gerät oder Netz herstellen
können und in der EU auf dem Markt bereitgestellt werden[2]. Dazu zählen
vernetzte Geräte ebenso wie eigenständig vertriebene Software, etwa
Buchhaltungsprogramme oder mobile Anwendungen.

Ausgenommen sind unter anderem Bereiche, die bereits durch gleichwertige
sektorspezifische Regelungen abgedeckt sind, darunter Medizinprodukte,
Fahrzeuge und Luftfahrtausrüstung.

#### Sonderfall quelloffene Software

Maßgeblich ist, ob die Software im Rahmen einer kommerziellen Tätigkeit
bereitgestellt wird. Quelloffene Software außerhalb einer solchen Tätigkeit
fällt nicht in den Anwendungsbereich; nach den Auslegungshinweisen der
Kommission machen freiwillige Beiträge, öffentliche Förderung oder
Sponsoring eine Bereitstellung für sich genommen noch nicht kommerziell. Wer
quelloffene Software verkauft, kostenpflichtige Unternehmensversionen anbietet
oder sie anderweitig monetarisiert, wird regelmäßig als Hersteller
behandelt.

Daneben kennt Artikel 24 die Rolle des Verwalters quelloffener Software, also
einer Einrichtung, die die Entwicklung solcher Software dauerhaft
unterstützt. Für sie sieht die Verordnung deutlich geringere Pflichten vor,
im Kern eine Cybersicherheitsstrategie, aber keine CE-Kennzeichnung und keine
förmliche Konformitätsbewertung. Wird quelloffene Software Bestandteil eines
Produkts, das ein Unternehmen in Verkehr bringt, richtet sich die
Verantwortung für dieses Produkt nach den Herstellerpflichten.

### Produktklassen und Anhang III

Der Nachweisaufwand hängt an der Einstufung des Produkts. Die Verordnung
unterscheidet vier Gruppen.

Einstufung und vorgesehener Nachweisweg:

| Gruppe | Beispiele | Konformitätsbewertung |
|---|---|---|
| Sonstige Produkte mit digitalen Elementen | der größte Teil aller erfassten Produkte | Selbstbewertung durch den Hersteller |
| Wichtige Produkte, Klasse I (Anhang III) | Passwortmanager, Netzwerkverwaltung, Virenschutz, VPN | Selbstbewertung bei vollständiger Anwendung einer harmonisierten Norm, sonst benannte Stelle |
| Wichtige Produkte, Klasse II (Anhang III) | Firewalls, Systeme zur Angriffserkennung | benannte Stelle oder Zertifizierung vorgesehen |
| Kritische Produkte (Anhang IV) | Smartcards, Smart-Meter-Gateways | Zertifizierung nach europäischem Schema vorgesehen |

In der Praxis fällt ein Großteil der Produkte im Mittelstand in die erste
Zeile und kommt mit einer dokumentierten Selbstbewertung aus. Aufwendiger wird
es, sobald ein Produkt selbst eine Sicherheitsfunktion übernimmt. Ein früher
Blick in Anhang III lohnt deshalb, weil die Einstufung über Zeitplan und
Budget entscheidet.

### Was Hersteller jetzt vorbereiten können

Der Begriff der CRA-konformen Softwareentwicklung klingt größer, als er ist.
Auf die Entwicklungspraxis heruntergebrochen geht es um vier Themen.

#### Sichere Voreinstellungen

Das Produkt wird in einem sicheren Zustand ausgeliefert: keine
Standardpasswörter, keine unnötig offenen Dienste, Verschlüsselung dort, wo
Daten übertragen werden. Wer die Absicherung dem Kunden überlässt, erfüllt
die Anforderung nicht.

#### Bekannte Bestandteile

Eine Stückliste der verwendeten Komponenten samt Versionen. Ohne diese Liste
lässt sich bei einer neu bekannt gewordenen Schwachstelle die eigene
Betroffenheit nicht beantworten. Genau diese Frage stellt im Ernstfall der
Kunde, und zwar am selben Tag.

#### Ein Prozess für Schwachstellen

Eine erreichbare Kontaktstelle für Meldungen, ein Verfahren zur Bewertung,
ein Weg, Updates auszuliefern, und eine Aufzeichnung darüber, was wann
behoben wurde. Der Unterstützungszeitraum ist festzulegen und für Käufer
erkennbar zu machen.

#### Nachweisbare Dokumentation

Risikobewertung, Testergebnisse, Konformitätserklärung. Ohne Unterlagen ist
die Bewertung nicht belegbar, auch wenn die Technik in Ordnung ist.
Erfahrungsgemäß dauert dieser Teil länger als erwartet.

### Die Meldepflichten ab September 2026

Meldungen erfolgen ab dem 11. September 2026 über die CRA Single Reporting
Platform an das zuständige CSIRT[2].

Vorgesehene Meldefristen:

| Zeitpunkt | Was vorgesehen ist |
|---|---|
| 24 Stunden | Frühwarnung nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Vorfalls |
| 72 Stunden | weitere Angaben, soweit verfügbar |
| 14 Tage | Abschlussbericht zur Schwachstelle, gerechnet ab Bereitstellung eines Updates |
| 1 Monat | Abschlussbericht zu einem Sicherheitsvorfall |

Die Fristen ähneln denen aus NIS2, richten sich aber an einen anderen
Adressaten: NIS2 nimmt den Betreiber in die Pflicht, der CRA den Hersteller.
Ein Unternehmen kann beides zugleich sein.

### Welche Rolle der Betriebsort beim CRA spielt

Der CRA ist Produktrecht. Maßgeblich ist, was ein Unternehmen in Verkehr
bringt, nicht, wo seine Systeme stehen. Ein lokal betriebenes KI-System macht
aus einem nicht konformen Produkt daher kein konformes.

Einen Unterschied macht der Betriebsort bei den Nachweisen. Liegen
Entwicklung, Test und Auslieferung in der eigenen Hand, lassen sich
Komponentenstände, Konfigurationen und Testergebnisse ohne Umweg belegen.
Hängt ein Teil der Verarbeitung an einem externen Dienst, ist dessen Beitrag
in die eigene Dokumentation aufzunehmen, ohne ihn selbst kontrollieren zu
können.

Einfluss des Betriebsorts auf einzelne Nachweise:

| Anforderung | Wirkung des lokalen Betriebs |
|---|---|
| Nachweis der ausgelieferten Komponentenstände | leichter, wenn alle Stände im eigenen Haus geführt werden |
| Reproduzierbare Tests vor der Auslieferung | leichter, wenn keine Abhängigkeit von fremden Modellständen besteht |
| Einhaltung der 24-Stunden-Frist | teilweise, die benötigten Informationen können schneller verfügbar sein |
| Einstufung nach Anhang III | keine Änderung, richtet sich nach dem Produkt |
| Konformitätsbewertung und technische Dokumentation | keine Änderung, bleibt eigene Aufgabe |
| Unterstützungszeitraum und Update-Auslieferung | keine Änderung, vertragliche und organisatorische Zusage |

### conn.AI als Lieferant im CRA-Kontext

Der CRA betrifft uns selbst. Wer einen Edge-Server mit Software ausliefert,
steht vor denselben Fragen wie jeder andere Hersteller: bekannte Bestandteile,
sichere Voreinstellungen, ein Verfahren für Schwachstellen, ein festgelegter
Unterstützungszeitraum. Dokumentierter Betrieb und geplante Updates sind bei
conn.AI deshalb Teil des Leistungsumfangs.

Für die von conn.AI bereitgestellten Komponenten dokumentieren wir unter
anderem Softwarestände, Updateprozesse und relevante Betriebsinformationen.
Diese Unterlagen können in die eigene technische Dokumentation und Bewertung
des Kunden einfließen. Die Einstufung und Konformitätsbewertung des
Produkts, das ein Kunde selbst in Verkehr bringt, bleibt davon unberührt.

### FAQ zu Cyber Resilience Act

**Wer ist vom Cyber Resilience Act betroffen?**

Die Verordnung nimmt Hersteller, Importeure und Händler von Produkten mit
digitalen Elementen in die Pflicht, die in der EU auf dem Markt bereitgestellt
werden. Der größte Teil der Anforderungen richtet sich an Hersteller: Sie
haben die Sicherheitsanforderungen umzusetzen, die Konformität zu bewerten,
die technische Dokumentation zu führen und Schwachstellen über den
Unterstützungszeitraum zu behandeln. Importeure und Händler haben zu
prüfen, ob die erforderlichen Nachweise und Kennzeichnungen vorliegen. Für
den Mittelstand ist vor allem eines relevant: Wer eine Maschine mit eigener
Steuerungssoftware oder ein Gerät mit Netzanbindung in Verkehr bringt, ist
regelmäßig Hersteller im Sinne der Verordnung, auch wenn sich das
Unternehmen nicht als Softwarehersteller versteht.

**Ab wann gilt der Cyber Resilience Act?**

Die Verordnung ist am 10. Dezember 2024 in Kraft getreten, die Pflichten
greifen gestaffelt. Seit dem 11. Juni 2026 gelten die Regelungen zur Benennung
von Konformitätsbewertungsstellen. Ab dem 11. September 2026 sind aktiv
ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle zu melden.
Ab dem 11. Dezember 2027 gelten die übrigen Anforderungen für Produkte, die
neu in Verkehr gebracht werden.

**Was ist ein wichtiges Produkt nach Anhang III?**

Anhang III führt Produktkategorien mit erhöhtem Risiko auf, unterteilt in
Klasse I und Klasse II. Zu Klasse I zählen unter anderem Passwortmanager,
Netzwerkverwaltung, Virenschutz und VPN-Software. Klasse II umfasst Kategorien
mit höherem Risiko, etwa Firewalls und Systeme zur Angriffserkennung. Der
Unterschied liegt im Nachweisweg: Für Klasse I sieht die Verordnung eine
Selbstbewertung vor, wenn eine harmonisierte Norm vollständig angewendet
wird, andernfalls ist eine benannte Stelle einzubeziehen. Für Klasse II ist
die Beteiligung einer benannten Stelle oder eine Zertifizierung vorgesehen.

**Gilt der CRA auch für reine Software?**

Ja. Der Anwendungsbereich umfasst Produkte mit digitalen Elementen, und dazu
zählt eigenständig vertriebene Software ebenso wie Hardware mit Software
darin. Buchhaltungsprogramme, mobile Anwendungen und Spiele fallen darunter.
Maßgeblich ist, dass das Produkt eine Datenverbindung zu einem Gerät oder
Netz herstellen kann und in der EU auf dem Markt bereitgestellt wird.

**Fällt Open Source unter den Cyber Resilience Act?**

Maßgeblich ist, ob die Software im Rahmen einer kommerziellen Tätigkeit
bereitgestellt wird. Quelloffene Software, die außerhalb einer solchen
Tätigkeit bereitgestellt wird, fällt nicht in den Anwendungsbereich; nach
den Auslegungshinweisen der Kommission machen freiwillige Beiträge,
öffentliche Förderung oder Sponsoring eine Bereitstellung für sich genommen
noch nicht kommerziell. Wer quelloffene Software verkauft, kostenpflichtige
Unternehmensversionen anbietet oder sie anderweitig monetarisiert, wird
regelmäßig als Hersteller behandelt. Artikel 24 schafft daneben die Rolle
des Verwalters quelloffener Software mit deutlich geringeren Pflichten. Wird
quelloffene Software Bestandteil eines Produkts, das ein Unternehmen in
Verkehr bringt, richtet sich die Verantwortung für dieses Produkt nach den
Herstellerpflichten.

**Was bedeutet CRA-konforme Softwareentwicklung?**

Im Kern vier Themen. Erstens sichere Voreinstellungen, also keine
Standardpasswörter und keine unnötig offenen Dienste im
Auslieferungszustand. Zweitens eine Stückliste der verwendeten Komponenten,
damit sich bei einer neu bekannt gewordenen Schwachstelle die eigene
Betroffenheit beantworten lässt. Drittens ein Prozess, der Schwachstellen
aufnimmt, bewertet und Updates ausliefert, mitsamt einer erreichbaren
Kontaktstelle für Meldungen. Viertens die Dokumentation dieser Punkte, weil
die Konformitätsbewertung sonst nicht belegbar ist. Technisch ist davon wenig
neu, organisatorisch für viele Unternehmen schon.

**Was ist ab dem 11. September 2026 zu melden?**

Aktiv ausgenutzte Schwachstellen in einem Produkt und schwerwiegende
Sicherheitsvorfälle, die dessen Sicherheit beeinträchtigen. Die Meldungen
erfolgen über die CRA Single Reporting Platform an das zuständige CSIRT. Die
Verordnung sieht eine Frühwarnung binnen 24 Stunden vor, nach 72 Stunden
weitere Angaben. Der Abschlussbericht ist bei Schwachstellen binnen 14 Tagen
nach Bereitstellung eines Updates vorgesehen, bei Sicherheitsvorfällen binnen
eines Monats. Diese Pflicht greift, bevor die übrigen Anforderungen im
Dezember 2027 anwendbar werden.

**Wie lange sind Sicherheitsupdates bereitzustellen?**

Über den Unterstützungszeitraum, den der Hersteller festlegt und angibt. Er
richtet sich nach der erwarteten Lebensdauer des Produkts und beträgt nach
der Verordnung grundsätzlich mindestens fünf Jahre, sofern die erwartete
Lebensdauer nicht kürzer ist. Der Zeitraum muss für Käufer erkennbar sein.
Bei Investitionsgütern mit zehn oder fünfzehn Jahren Nutzungsdauer wird das
zu einer Frage der Kalkulation.

Quellen: Verordnung (EU) 2024/2847, BSI-Themenseite Cyber Resilience Act,
Europaeische Kommission, ENISA.

Hinweis: Dieser Text ist eine allgemeine Einordnung und dient der Information.
Er ersetzt keine Rechtsberatung. Ob und welche Pflichten im Einzelfall gelten,
haengt von der konkreten Situation ab.

---

## Artikel 4: Vibe Coding im Mittelstand

- URL: https://connai.de/wissen/vibe-coding.html
- Thema: KI-gestützte Softwareentwicklung, IP-Schutz, lokale Modelle

In der Entwickler-Community hat sich 2025 ein neuer Begriff etabliert: Vibe
Coding. Gemeint ist eine Arbeitsweise, in der Software nicht mehr Zeile für
Zeile geschrieben, sondern in Absichten formuliert und von einem KI-Assistenten
umgesetzt wird. Der Produktivitätsschub ist real. Das Problem im Mittelstand:
wo landet der Code, wenn ich ihn einer Cloud-KI zeige?

### Was Vibe Coding wirklich meint

Der Begriff geht auf einen Beitrag von Andrej Karpathy vom 2. Februar 2025
zurück. Sinngemäß: Man übergibt sich dem „Vibe" mit dem KI-Assistenten,
akzeptiert Vorschläge, ohne jede Zeile im Detail zu verstehen. Klassisches
Programmieren war Zeichen für Zeichen, der Entwickler kannte jede Zeile.
Beim Vibe Coding verschiebt sich der Schwerpunkt: Man beschreibt in natürlicher
Sprache, was passieren soll, der Assistent generiert einen Vorschlag, man
prüft, formt weiter. Der Code wird zum Ergebnis eines Dialogs, nicht mehr
zum manuellen Bauwerk.

Der Stack Overflow Developer Survey 2024 zeigt: 76 Prozent der Entwickler
nutzen bereits oder planen den Einsatz von KI-Werkzeugen im Alltag.

### Warum Cloud-KI beim Coding kritisch ist

**Jeder Prompt ist eine Preisgabe.** Wenn ein Entwickler Code an einen
Cloud-Assistenten schickt, geht dieser Code in der Regel an den Anbieter,
meist auf US-Servern. Das umfasst nicht nur den kleinen Auszug, den er
einfügt, sondern auch den weiteren Kontext, den der Assistent zur Beantwortung
braucht. Kunden-Namen, interne Bezeichnungen, Preisformeln, Sicherheits-
routinen können darin vorkommen.

**Zusicherungen sind nur so gut wie ihre Belege.** Alle bekannten Anbieter
sichern zu, dass Business-Eingaben nicht zum Training verwendet werden. In
der Realität heißt das: nicht für das offizielle Trainings-Datenset. Für
Missbrauchsprüfung, Sicherheits-Analyse und Systemverbesserung können die
Daten trotzdem verarbeitet werden.

**Nachweispflicht bleibt beim Unternehmen.** Wenn eine DSGVO-Anfrage kommt
oder eine NIS2-Meldung fällig ist, muss man wissen, welche Daten wann an
welchen Anbieter gegangen sind. Bei einem Entwicklerteam mit freier
Cloud-KI-Nutzung ist das praktisch nicht mehr zu rekonstruieren.

### Wie Vibe Coding im eigenen Haus funktioniert

Lokale Sprachmodelle sind in den letzten anderthalb Jahren sprunghaft besser
geworden. Für einen Großteil täglicher Coding-Aufgaben liefern sie Ergebnisse,
die im Alltag mit Cloud-KI vergleichbar sind. Der Abstand zur absoluten Spitze
besteht noch, aber für die 80-Prozent-Aufgaben eines mittelständischen
Entwicklerteams ist er nicht relevant.

Praktisch:
- Ein Edge-Server mit GPU steht im eigenen Rechenzentrum.
- Ein lokal betriebenes Modell bedient die Entwicklungsumgebung über eine Standard-Schnittstelle.
- Der Code verlässt das Haus nicht.
- Nutzung, Prompts und Antworten können auditiert werden.

### FAQ zu Vibe Coding

**Sind lokal betriebene Modelle schon gut genug zum Programmieren?**
Für viele praktische Aufgaben ja. Öffentlich verfügbare Modelle wie
Qwen2.5-Coder, DeepSeek-Coder-V2 oder Llama 3.3 erreichen bei etablierten
Coding-Benchmarks Ergebnisse, die noch vor einem Jahr Cloud-Modellen
vorbehalten waren.

**Was braucht es hardwareseitig?**
Für ernsthafte Nutzung durch ein Entwicklungsteam empfiehlt sich ein Edge-Server
mit GPU. Die genaue Dimensionierung hängt von Modellwahl und Anzahl
gleichzeitiger Nutzer ab.

**Wie sieht ein realistischer Einstieg aus?**
Ein Testlauf mit ein bis drei Personen, ein klar abgegrenzter Anwendungsfall,
ein festes Zeitfenster. Nach vier bis sechs Wochen weiß man, was funktioniert,
was nicht, und ob eine Ausweitung sinnvoll ist.

Quellen: Wikipedia „Vibe coding" (mit Karpathy-Beleg), Stack Overflow Developer
Survey 2024, GitHub Copilot Business Privacy Statement, ChatGPT-Datenleck
20.03.2023 (OpenAI Blogbeitrag), Ollama-Projekt.

---

## Artikel 5: KI-Agenten in der Softwareentwicklung

- URL: https://connai.de/wissen/ki-agenten-softwareentwicklung.html
- Thema: Agentengestützte Entwicklung, Harness-Konzept, Context Engineering

Agentengestützte Softwareentwicklung ist kein Trend mehr, um den man sich in
Ruhe eine Meinung bilden kann. Sie ist da, sie funktioniert, und sie verändert
Projekte messbar. Was sich dabei längst nicht so schnell ändert, sind die
Anforderungen an einen sauberen Betrieb, an Regulatorik, Zugriffe und Robustheit.

### Was gerade wirklich passiert

Bis vor etwa einem Jahr galt: KI-Assistenten helfen an einzelnen Stellen, aber
wer sie an ein großes Regelwerk band, sah nach ein paar hundert Zeilen Code das
Chaos. Diese Grenze hat sich verschoben. Die neuen Modell-Generationen halten
sich zuverlässig an große Guideline-Kataloge, arbeiten über lange Sessions
diszipliniert und können komplexe Vorgaben zu Architektur, Testing und
Dokumentation umsetzen.

Praxisberichte aus mehrmonatigen Experimenten sprechen von Geschwindigkeits-
Gewinnen jenseits jeder bisherigen Vorstellung: ganze Enterprise-Anwendungen
mit hunderten User-Stories, vollständigen Test-Suiten und produktionsreifer
Dokumentation, entwickelt in Wochen statt Personenjahren. Selbst wenn man diese
Zahlen konservativ interpretiert und mehr als die Hälfte abzieht, bleibt eine
Neuvermessung der Produktivität übrig, die kein Team ignorieren kann.

### Die Branche vor dem Umbau

Custom-ERP-Anbieter, gewachsen über 20 oder 30 Jahre, kommen an der neuen
Realität nicht vorbei. Historisch entstandene Monolithe mit riesigen Klassen
und tiefen Vererbungsketten sprengen bereits das Kontextfenster moderner
Modelle in der reinen Analyse-Phase. Ohne belastbare Test-Suite ist an ein
Refactoring nicht zu denken. Währenddessen bauen Zwischenhändler und Endkunden
mit kleinen Teams eigene Lösungen. Nicht in gleicher Funktionsbreite, aber
oft nach dem Pareto-Prinzip nah genug an dem, was ihre Anwender wirklich
brauchen. Die Branche kannibalisiert sich gerade selbst.

### Der Trick liegt nicht im Prompt, sondern im Kontext

Die Ergebnisse entstehen nicht durch besonders cleveres Chat-Ping-Pong, sondern
weil das Team Zeit in den sogenannten Harness investiert: eine Sammlung
strukturierter Dateien, die dem Agenten sagen, wie in diesem Unternehmen
entwickelt wird. Architektur-Regeln, Coding-Guidelines, Test-Strukturen,
gekoppelt an statische Analyse-Werkzeuge, die nach jedem Schritt prüfen, ob
der Agent im Rahmen geblieben ist. In der Community spricht man von
Context Engineering.

Vier Regeln haben sich in der Praxis herausgeschält:
- Kontext-Dateien nicht automatisch generieren lassen, sondern selbst schreiben und pflegen.
- Sessions kurz halten, eine pro Feature, dann neu starten.
- Statisch und dynamisch trennen (Kernkontext bei jeder Session, Details bei Bedarf).
- Kontext nach jedem Feature abgleichen.

### Wo aus Werkzeug ein Betriebsproblem wird

Die Tools sind da, die Qualität stimmt, das Team ist begeistert. Dann kommt
die IT-Sicherheit vorbei. Dann fragt der Datenschutzbeauftragte, welche Daten
in welche Cloud fließen. Dann will die Geschäftsführung wissen, wer haftet,
wenn ein Agent produktiv etwas Falsches tut. Und plötzlich ist das Werkzeug
ein Betriebsthema.

Genau an dieser Stelle setzt conn.AI an. Nicht bei den Coding-Tools selbst,
sondern bei der Betreiber-Schicht darunter. Ein Edge-Server im Haus, ein
lokal betriebenes Modell, dokumentierte Zugriffe, protokollierte Nutzung, ein
Update- und Konfigurationsprozess, der einen Audit übersteht. Damit werden aus
zwei Zeilen KI-Werbung ein System, das man über Jahre betreiben, in Reviews
vorzeigen und in einem Vorfall belastbar zurückverfolgen kann.

### FAQ zu KI-Agenten in der Softwareentwicklung

**Ist das nicht schon wieder ein Hype?**
Vor zwei Jahren war es einer. Heute ist es Betriebspraxis in einer wachsenden
Zahl von Entwicklungsteams. Der Unterschied liegt in der neuen Generation
von Modellen, die seit Anfang 2026 zuverlässig große Regel- und Richtlinien-
Kataloge einhalten.

**Was heißt „Harness"?**
Eine Sammlung von Regeln, Vorgaben und Prüfwerkzeugen, die einem KI-Agenten
zeigen, wie er in einem konkreten Unternehmenskontext arbeiten soll.

**Muss man dafür sein eigenes Modell trainieren?**
Nein. Es geht um Kontext, nicht um Training. Ein starkes vorhandenes Modell
(Claude Opus/Sonnet oder Open-Weight wie Qwen3-Coder, DeepSeek-Coder) wird
mit dem Kontext des Unternehmens ausgestattet.

**Ersetzt das jetzt die Entwickler?**
Kurzfristig nicht, mittelfristig verändert es das Berufsbild in Richtung
Architekt/Product-Owner/Kontrolleur. Wer die Grundlagen von Architektur,
Anforderungen und Test versteht, gewinnt massiv an Wirkung.

Quellen: Anthropic Claude-Modell-Übersicht, Stack Overflow Developer Survey
2024, Anthropic Engineering Blog „Effective context engineering for AI agents",
agents.md-Standard, METR Research, Ollama.

---

## Rechtliche und Anbieter-Informationen

- Anbieter: G.P.C.3X GmbH, Kolonnenstraße 8, 10827 Berlin, Deutschland
- USt-ID: DE458691190
- Kontakt: kontakt@gpc3x.com, +49 30 20848672
- Impressum: https://connai.de/impressum.html
- Datenschutz: https://connai.de/datenschutz.html