Zuletzt aktualisiert: 5. September 2026 · Version: 2.3
Redaktionshinweis: Dieser Artikel wurde mit KI-Unterstützung recherchiert und überarbeitet sowie menschlich redaktionell geprüft. Die technische Einordnung stützt sich auf Dokumentationen zu agentischen Coding-Systemen, Veröffentlichungen von BSI und ANSSI zur sicheren Softwareentwicklung, das BSI ICS-Security-Kompendium und die OPC-UA-Spezifikation. Rechtsangaben beziehen sich auf den EU AI Act, den Cyber Resilience Act, die EU-Maschinenverordnung, die DSGVO und das Betriebsverfassungsgesetz. Die rechtliche Einordnung dient der Orientierung und ersetzt keine Einzelfallprüfung. Quellenstand: 5. September 2026.
In 30 Sekunden
- KI-Coding-Agenten können Mikrocontroller, Sensoren, Displays und industrielle Schnittstellen deutlich schneller zu funktionsfähigen Prototypen verbinden.
- Besonders attraktiv sind read-only Anwendungen: CNC-Statusanzeigen, Retrofit-Sensorik, Werkzeugüberwachung, Prüfplätze, Andon-Boards und mobile Servicehilfen.
- Nicht geeignet für einen schnellen KI-Pilot sind Not-Halt, Schutzfunktionen, Bewegungssteuerung, automatische G-Code-Änderungen oder andere sicherheitskritische Maschinenfunktionen.
- Der richtige Architekturgrundsatz lautet: Maschinendaten lesen, Steuerung und Sicherheitskreis unangetastet lassen, Netze segmentieren und Ergebnisse außerhalb des Agenten prüfen.
- Aus einem Laboraufbau wird erst durch reproduzierbaren Build, industrielle Hardware, Updatekonzept, Security-Nachweise und Konformitätsprüfung ein verantwortbares Betriebsmittel oder Produkt.
Was Unternehmen jetzt tun sollten
- Einen rein lesenden Pilotfall wählen: Ein Signal beobachten und verständlich anzeigen, aber keine Maschine steuern.
- OT-Grenzen vor dem Prompt festlegen: erlaubte Datenpunkte, verbotene Schreibzugriffe, Netzsegment, Rollen und Abbruchkriterien dokumentieren.
- Den Agenten als Entwicklungswerkzeug behandeln: Quellcode, Bibliotheken, Builds und Firmware werden versioniert, geprüft und reproduzierbar erstellt.
- Nach 30 Tagen über den Produktpfad entscheiden: verwerfen, als internes Werkzeug härten oder mit industrieller Hardware und formaler Konformitätsbewertung weiterentwickeln.
Eine CNC meldet Stillstand, doch die Instandhaltung erfährt es zu spät. Ein Prüfplatz erzeugt Messwerte, die weiterhin per Hand übertragen werden. Genau solche kleinen digitalen Lücken können KI-Coding-Agenten schneller in einen testbaren Hardware-Prototyp übersetzen.
Für Entscheider lautet die Frage nicht, ob KI eine Maschine programmieren kann. Entscheidend ist, ob ein begrenztes Werkzeug Suchzeit, Medienbrüche oder Reaktionszeit messbar reduziert – ohne neue Risiken in die Produktion zu tragen. Der wirtschaftliche Hebel ist schnelleres Lernen vor der Investition, nicht ungeprüfte Automatisierung.
Was mit KI-gestütztem Hardware-Prototyping gemeint ist
Ein KI-Coding-Agent ist mehr als eine Code-Vervollständigung. Systeme wie Claude Code, Codex oder vergleichbare agentische Entwicklungswerkzeuge können in einer freigegebenen Umgebung Dateien lesen, Quellcode ändern, Compiler und Tests aufrufen, Dokumentation durchsuchen und angeschlossene Entwicklungsgeräte über vorhandene Werkzeuge ansprechen.
Im Embedded- und Industrieumfeld entsteht daraus eine Werkzeugkette:
Fachliches Problem → Coding-Agent → versionierter Quellcode → Testgerät oder Industrie-Gateway → Sensor, Display oder Maschinendaten → fachliche Abnahme
Der Agent kann die mittleren Schritte beschleunigen. Problemdefinition, Risikogrenze und Abnahme bleiben menschliche und organisatorische Aufgaben. Das ist besonders wichtig, weil eingebettete Software nicht nur Daten verarbeitet: Sie kann physische Geräte beobachten oder beeinflussen.
Merksatz: Nicht die KI steuert die Maschine. Die KI beschleunigt die Entwicklung eines begrenzten Werkzeugs, dessen Rechte, Datenwege und Abnahme Menschen verbindlich festlegen.
Minimaler Tech-Stack für den Start
- Testhardware: Entwicklungsboard oder kleiner Industrie-PC außerhalb der Maschinensteuerung.
- Datenweg: simulierte Daten, CSV-Export oder ausschließlich lesender Zugriff über ein freigegebenes Gateway.
- Ausgabe: lokales Display, E-Paper oder Test-Dashboard mit Zeitstempel und Verbindungsstatus.
- Entwicklungsbasis: versioniertes Repository, festgeschriebene Abhängigkeiten und reproduzierbarer Build.
- Fallback: sichtbarer Fehlerzustand, dokumentierter Rückbau und unverändert nutzbarer Altprozess.
Wann sich ein Pilot besonders lohnt
Der stärkste Pilot beginnt nicht mit einer verfügbaren Platine, sondern mit einem kleinen, wiederkehrenden Betriebsproblem. Besonders gute Voraussetzungen bestehen, wenn mindestens zwei der folgenden Merkmale zusammenkommen:
- Heterogener Maschinenpark: Unterschiedliche Baujahre und Hersteller verhindern eine einheitliche Oberfläche.
- Viele Medienbrüche: Zustände werden abgelesen, auf Papier notiert und später manuell in Excel, MES oder Ticketsystem übertragen.
- Häufige Umrüstungen: Varianten, kleine Losgrößen oder wechselnde Prüfabläufe erzeugen Informations- und Suchaufwand.
- Lokale Informationslücke: Die Daten existieren, stehen aber nicht dort zur Verfügung, wo Mitarbeiter entscheiden oder handeln.
- Unklare Nutzenhypothese: Vor einer größeren Investition muss erst bewiesen werden, dass Anzeige, Sensor oder Assistenz den Prozess tatsächlich verbessert.
Weniger geeignet ist ein KI-gestützter Eigenbau, wenn bereits ein etabliertes Standardprodukt die Anforderung abdeckt, eine Sicherheitsfunktion betroffen ist oder niemand den späteren Betrieb übernehmen kann.
Acht Einsatzszenarien für Industrie und Mittelstand
| Szenario | Konkreter Nutzen | Sinnvoller Pilot | Messgröße | Risiko |
|---|---|---|---|---|
| CNC-Statusanzeige | Auftrag, Restzeit, Stillstand und Störstatus direkt an der Maschine anzeigen | Nur freigegebene Statuswerte lesen; keine Parameter schreiben | Reaktionszeit und Anteil korrekt dargestellter Zustände | Niedrig |
| Werkzeugzustand | Vibration, Temperatur oder Laufzeit als Hinweis auf Verschleiß verdichten | Separater Sensor; Empfehlung statt automatischer Eingriff | Bestätigte Hinweise, Fehlalarme und vermiedene ungeplante Prüfungen | Mittel |
| Retrofit-Datenerfassung | Alte Anlagen ohne moderne Telemetrie schrittweise beobachtbar machen | Galvanisch getrennte Sensorik oder freigegebene Gateway-Schnittstelle | Verfügbare Datenpunkte, Datenlücken und Integrationsaufwand | Mittel |
| Andon und Eskalation | Störung, Materialmangel oder Prüfbedarf sichtbar und zielgerichtet melden | Anzeige plus Quittierung; bestehende Sicherheitslogik bleibt unverändert | Zeit bis Quittierung und Anteil korrekt adressierter Meldungen | Niedrig |
| Qualitäts-Prüfplatz | Messfolge führen, Werte erfassen und Vollständigkeit prüfen | Nicht sicherheitskritisches Produktmerkmal; menschliche Endfreigabe | Dokumentationszeit, fehlende Prüfschritte und Nacharbeitsquote | Mittel |
| Digitale Arbeitsanweisung | Auftragsspezifische Schritte, Zeichnungen oder Warnhinweise am Arbeitsplatz zeigen | E-Paper oder Display mit freigegebenen Inhalten aus DMS oder MES | Suchzeit, Rückfragen und Nutzung der aktuellen Dokumentversion | Niedrig |
| Behälter und Materialfluss | Füllstand, Zielplatz oder Nachschubbedarf dezentral anzeigen | Testbereich mit wenigen Ladungsträgern und klarer Fallback-Regel | Fehlleitungen, Suchzeit und rechtzeitig ausgelöster Nachschub | Niedrig |
| Energie- und Medienmonitoring | Druckluft, Strom oder Temperatur für Verbesserungsmaßnahmen sichtbar machen | Zusätzliche Messung ohne Eingriff in Abrechnung oder Anlagenregelung | Gefundene Lastspitzen, Leckagehinweise und Messabdeckung | Niedrig |
Die Risikostufe bezieht sich auf den beschriebenen Pilotumfang, nicht auf das Thema an sich. Ein Werkzeugzustands-Sensor ist vergleichsweise beherrschbar, solange er lediglich einen Prüfhinweis erzeugt. Wenn derselbe Prototyp automatisch Vorschub, Drehzahl oder Werkzeugwechsel verändert, wird daraus eine steuernde und potenziell sicherheitsrelevante Funktion.
Integrationsmuster: vom einfachen Export bis zur OT-Schnittstelle
Die Integration sollte so einfach und passiv wie möglich beginnen. Nicht jeder Pilot braucht direkten Maschinenzugriff oder eine dauerhafte Cloud-Verbindung.
Vom risikoarmen zum produktionsnahen Einstieg:
- CSV-Export: historische Testdaten; Datenalter sichtbar machen.
- Digitale IOs: einfache Zustände; elektrisch trennen und Schutzkreise nicht berühren.
- Modbus-Gateway: Register aus Bestandsanlagen; Zugriffe filtern und auf Lesezugriffe begrenzen.
- OPC UA: semantische Maschinen- und Alarmdaten; Zertifikate, Rollen und Adressraum konfigurieren.
- MQTT: Sensor- und Ereignisdaten; Broker, Topics, Identitäten und Aufbewahrung kontrollieren.
- E-Paper oder Display: lokale Ausgabe; Zeitstempel, Verbindungsstatus und Fallback anzeigen.
Für einen Retrofit-Stack lässt sich daraus ein wiederverwendbares Muster bilden: Sensor oder bestehende Maschinenschnittstelle, industrielles Gateway, kontrollierter Datenkanal, lokales Dashboard und Audit-Log. Der Coding-Agent beschleunigt Adapter und Oberfläche; Sicherheitsgrenzen und Betriebsverantwortung bleiben standardisiert.
Datenqualität und Datenhoheit entscheiden über den Nutzen
Read-only reduziert das Risiko eines Eingriffs, garantiert aber noch keinen geschäftlichen Nutzen. Ein Statusdisplay ist wertlos, wenn Zustände verspätet eintreffen, unterschiedliche Maschinen denselben Begriff verschieden verwenden oder der Zeitstempel fehlt. Vor dem ersten Feldtest braucht jeder Datenpunkt deshalb einen Eigentümer, eine Definition, eine erwartete Aktualisierungsfrequenz und eine Regel für fehlende oder widersprüchliche Werte.
Datenhoheit betrifft nicht nur den Speicherort. Unternehmen sollten festlegen, welche Rohdaten das OT-Netz verlassen dürfen, wo Protokolle und abgeleitete Werte gespeichert werden, wie lange sie aufbewahrt werden und wer sie mit Auftrags-, Qualitäts- oder Mitarbeiterdaten verknüpfen darf. Für einen Edge-Wartungsassistenten kann die richtige Lösung bewusst ohne Cloud-Zwang arbeiten: freigegebene Dokumente und Fehlercodes liegen lokal, Aktualisierungen werden kontrolliert eingespielt und jede ausgegebene Empfehlung bleibt auf ihre Quelle zurückführbar.
Daten-Schnellcheck: Ist der Wert eindeutig definiert? Ist sein Zeitstempel sichtbar? Erkennt das System veraltete oder fehlende Daten? Bleibt die Quelle nachvollziehbar? Ist geregelt, ob eine Verknüpfung Personenbezug erzeugt?
CNC-Szenario 1: Auftrags- und Maschinenstatus direkt am Arbeitsplatz
Viele CNC-Betriebe besitzen einen heterogenen Maschinenpark. Neuere Anlagen liefern Daten über OPC UA oder Herstellerschnittstellen, ältere Maschinen nur über Signale, Protokolle oder nachgerüstete Gateways. Ein kleines Display an der Maschine kann aus wenigen freigegebenen Datenpunkten eine verständliche Ansicht erzeugen:
- aktueller Auftrag und Arbeitsgang,
- Maschinenzustand wie Produktion, Rüsten, Warten oder Störung,
- geplantes Auftragsende oder verbleibende Bearbeitungszeit,
- nächste freigegebene Wartungs- oder Prüfanweisung.
Der Coding-Agent unterstützt beim Prototyp der Anzeige, beim Mapping der Datenpunkte und bei automatisierten Tests. Die CNC-Steuerung wird nicht verändert. Der Zugriff erfolgt über eine dokumentierte, ausschließlich lesende Schnittstelle. OPC UA ist dafür interessant, weil der Standard den Austausch zwischen Sensoren, Steuerungen, MES und Unternehmenssystemen einschließlich Authentifizierung, Verschlüsselung und Integritätsschutz abbildet. Die konkrete sichere Konfiguration bleibt dennoch Aufgabe des Betreibers.
Empfohlener Datenweg: CNC oder PLC → freigegebene OPC-UA-/Herstellerschnittstelle → industrielles Edge-Gateway in eigener OT-Zone → Anzeige. Das Experimentierboard hängt nicht direkt an der Maschinensteuerung.
Der messbare Nutzen liegt nicht in „mehr KI“, sondern in kürzeren Reaktions- und Suchwegen. Für den Piloten reichen deshalb drei Kennzahlen: Zeit bis eine Störung sichtbar ist, Zeit bis die zuständige Rolle informiert ist und Anteil korrekt dargestellter Zustände. Produktivitätsversprechen werden erst aus realen Betriebsdaten abgeleitet.
CNC-Szenario 2: Werkzeugverschleiß früher erkennen
Ein zusätzlicher Vibrations- oder Temperatursensor kann Zustandsdaten unabhängig von der Maschinensteuerung erfassen. Der erste Pilot muss noch keine KI-Anomalieerkennung enthalten. Häufig ist es wertvoller, Rohsignal, Grenzwert und manuell bestätigten Werkzeugzustand sauber zu erfassen. Erst mit dieser Datenbasis lässt sich prüfen, ob ein statistisches oder maschinelles Lernverfahren einen zusätzlichen Nutzen bringt.
Der Coding-Agent kann Firmware, Datenpufferung, Visualisierung und Export beschleunigen. Die fachliche Wahrheit kommt jedoch aus Bearbeitungsprozess und Instandhaltung. Ein Alarm darf zunächst nur eine Kontrolle auslösen. Eine automatische Änderung von Schnittparametern oder ein Maschinenstopp gehört nicht in den ersten Pilot.
CNC-Szenario 3: Rüst- und Prüfassistenz
Ein mobiles oder fest montiertes Display kann Rüstschritte, Spannmittel, Werkzeugliste und Prüfpunkte auftragsbezogen anzeigen. Taster, Scanner oder RFID können bestätigen, dass das richtige Werkzeug oder Messmittel bereitliegt. Das ist besonders bei kleinen Losgrößen und häufigen Wechseln interessant.
Auch hier sollte das System assistieren, nicht die Verantwortung verschleiern. Eine grüne Anzeige darf nur erscheinen, wenn alle deterministisch prüfbaren Bedingungen erfüllt sind. Freitext einer KI ist kein Sicherheitsnachweis. Kritische Maße und Freigaben bleiben in den etablierten Qualitätsprozessen.
Weitere Szenarien außerhalb der CNC-Fertigung
Instandhaltung: vom Fehlercode zur passenden Arbeitsanweisung
Ein Servicegerät kann Maschinen-ID, Fehlercode und Anlagenzustand lesen und anschließend die passende freigegebene Anleitung anzeigen. Ein Sprachmodell kann bei der Suche helfen, sollte aber nur aus kontrollierten Dokumenten antworten. Ersatzteilbestellungen oder Parameteränderungen bleiben freigabepflichtig.
Qualitätssicherung: flexible Prüfadapter in kleinen Serien
Für wechselnde Produkte sind individuelle Prüfadapter häufig zu teuer. Mikrocontroller mit Display, Scanner und Messschnittstelle können eine geführte Prüfung abbilden. Ein Coding-Agent senkt den Aufwand für Varianten. Vor dem Einsatz müssen Messmittel, Kalibrierung, Toleranzen und Rückverfolgbarkeit unabhängig geprüft sein.
Logistik: E-Paper für Ladungsträger und Materialbereitstellung
Stromsparende E-Paper-Anzeigen können Behälterstatus, Zielort oder Nachschubsignal darstellen. Ein Pilot mit wenigen Behältern prüft Lesbarkeit, Funkabdeckung, Batterielaufzeit und Fehlerfälle. Fällt das Display aus, muss weiterhin erkennbar sein, wohin Material gehört.
Gebäude und Energie: Transparenz ohne Eingriff in die Regelung
Zusätzliche Temperatur-, Feuchte-, Druckluft- oder Stromsensoren können Verlustquellen sichtbar machen. Der sichere Einstieg ist die Beobachtung. Sobald der Prototyp Heizung, Lüftung, Lasten oder Ventile automatisch steuert, ändern sich Risiko, Architektur und Verantwortlichkeit.
Die rote Linie: Was ein schneller Prototyp nicht steuern sollte
Diese Grenze ist keine Technikfeindlichkeit. Sie schützt den Lernraum. Ein Prototyp darf schnell entstehen, weil seine Wirkung klein, reversibel und kontrolliert ist. Sicherheitsfunktionen benötigen dagegen eine geeignete Architektur, qualifizierte Komponenten, Risikobeurteilung, Validierung und den regulären Maschinenbauprozess.
Vom Experimentierboard zur industriellen Lösung
| Stufe | Technik | Ziel | Freigabe |
|---|---|---|---|
| Labor | Entwicklungsboard, Testdaten, separates Netz | Machbarkeit und Nutzerfeedback | Engineering und Fachbereich |
| Industriepilot | Industrie-Gateway, Gehäuse, dokumentierte Schnittstelle, OT-Segment | Stabilität und Betriebsnutzen | OT, Security, Betrieb, gegebenenfalls Datenschutz und Betriebsrat |
| Produktivbetrieb | verwaltete Geräte, signierte Firmware, Monitoring, Update- und Supportprozess | dauerhafter, skalierbarer Betrieb | formaler Änderungs- und Abnahmeprozess |
| Kundenprodukt | Serienhardware, technische Dokumentation, Schwachstellen- und Konformitätsprozess | Marktbereitstellung | Herstellerverantwortung und Konformitätsbewertung |
Ein günstiges Board darf die Idee beweisen. Es sollte nicht allein deshalb im Werk bleiben, weil der Prototyp funktioniert. Temperaturbereich, EMV, Stromversorgung, Steckverbindungen, Ersatzteilverfügbarkeit, Watchdog, sichere Bootkette und Wartbarkeit entscheiden über den Dauerbetrieb.
Sicherheitsarchitektur für den Pilot
Das BSI empfiehlt für industrielle Steuerungs- und Automatisierungssysteme unter anderem Segmentierung, minimale Berechtigungen und einen sicheren Entwicklungslebenszyklus. Für KI-gestütztes Prototyping ergibt sich daraus eine klare Architektur:
- Entwicklung und Produktion trennen: Der Coding-Agent arbeitet nicht im produktiven OT-Netz.
- Read-only bevorzugen: Datenzugriff erfolgt über freigegebene Gateways, Datenpuffer oder replizierte Testdaten.
- Identitäten begrenzen: Eigene Servicekonten, minimale Rechte, keine geteilten Admin-Zugänge und keine Secrets im Prompt.
- Artefakte kontrollieren: Repository, festgeschriebene Abhängigkeiten, Software Bill of Materials, reproduzierbarer Build und signierte Firmware.
- Fehlerfälle testen: Netzverlust, veraltete Daten, Sensorfehler, Neustart, unterbrochenes Update und manipulierte Eingaben.
- Rollback sicherstellen: Golden Image, dokumentierter Rückweg und physisch erreichbarer Abschaltpunkt.
BSI und ANSSI weisen bei KI-Coding-Assistenten außerdem darauf hin, dass generierter Quellcode durch Entwickler geprüft und reproduziert werden sollte. Sensible Informationen wie API-Schlüssel gehören nicht in Prompts. Der bestehende AI-Fabrik-Praxis-Hub zu KI-Coding-Assistenten, Governance und Plattformwahl bietet eine passende Ampellogik für Autonomiestufen und Berechtigungen.
Typische Fehler im ersten Pilot
- Zu viel auf einmal: Sensorik, Dashboard, Prognosemodell, Cloud-Plattform und automatische Aktion werden in ein einziges Vorhaben gepackt. Besser ist ein Signal, eine Anzeige und eine messbare Nutzenhypothese.
- Zu frühe KI auf dem Gerät: Ein Sprach- oder ML-Modell wird eingeplant, obwohl feste Regeln den Pilot transparenter und robuster lösen. Der Coding-Agent kann die Entwicklung beschleunigen, ohne dass die Firmware selbst KI enthalten muss.
- Fehlender Fallback: Bei Netzverlust, leerer Batterie oder veralteten Daten zeigt das Gerät weiterhin einen scheinbar gültigen Zustand. Störung und Datenalter müssen sichtbar sein; der bestehende Prozess bleibt verfügbar.
- Prototyp wird stillschweigend zum Dauerbetrieb: Das günstige Board bleibt nach erfolgreicher Demo jahrelang an der Maschine. Ein zeitlich begrenzter Pilot braucht deshalb ein festes Ende und eine Entscheidung über industrielle Hardware.
- Unklare Zuständigkeit: Niemand besitzt Firmware, Zertifikate, Datenmodell und Updateprozess. Vor dem Feldtest müssen technischer Owner, fachlicher Owner und Freigabeverantwortung benannt sein.
Zwischenfazit: Ein guter Pilot beweist genau eine betriebliche Verbesserung und liefert belastbare Antworten zu Datenweg, Ausfallverhalten und Verantwortung. Benötigt der erste Test bereits mehrere Maschinen, Cloud-Plattform und Steuerzugriff, ist der Umfang zu groß.
Recht und Mitbestimmung in Deutschland
Schon im Labor zählen sichere Entwicklung, Secrets-Schutz und eine dokumentierte Grenze zur Produktions-OT. Im Werk kommen Änderungsfreigabe sowie – bei Personenbezug – Datenschutz und Betriebsrat hinzu. Dauerbetrieb und Marktbereitstellung verschieben den Schwerpunkt auf Industriehardware, Lebenszyklusprozesse, Risikobeurteilung und Herstellerpflichten.
EU-Maschinenverordnung: Softwareänderungen können Herstellerpflichten auslösen
Die EU-Maschinenverordnung 2023/1230 gilt nach aktueller EUR-Lex-Übersicht ab 20. Januar 2027. Sie erfasst Software ausdrücklich als möglichen Teil von Maschinen und Sicherheitskomponenten. Wer eine Maschine physisch oder digital wesentlich verändert und dadurch neue Gefährdungen erzeugt oder bestehende Risiken erhöht, kann für die geänderte Maschine Herstellerpflichten übernehmen. Ein per KI erzeugtes Steuerungs-Update ist deshalb nicht einfach „nur Software“.
Für den ersten Pilot ist die Konsequenz eindeutig: Sicherheitskreis, Bewegungslogik und freigegebene Steuerungssoftware bleiben unangetastet. Jede spätere schreibende Integration durchläuft Risikobeurteilung, Änderungsmanagement und Konformitätsprüfung.
Cyber Resilience Act: Vernetzte Produkte brauchen einen Lebenszyklus
Wird aus dem Aufbau ein kommerziell bereitgestelltes Produkt mit digitalen Elementen, wird der Cyber Resilience Act relevant. Er verlangt unter anderem Cyberrisikobewertung, technische Dokumentation, Schwachstellenbehandlung, sichere Updates und eine Komponentenübersicht beziehungsweise SBOM. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle gelten ab 11. September 2026; die meisten übrigen Pflichten ab 11. Dezember 2027.
DSGVO und Betriebsrat: Maschinendaten können Beschäftigtendaten werden
Maschinenzustände wirken zunächst sachlich. Werden sie jedoch Schichten, Bedienern, Leistungszeiten oder Fehlerquoten zugeordnet, können personenbezogene Daten entstehen. Dann sind Zweckbindung, Datenminimierung, Zugriffsschutz und gegebenenfalls eine Datenschutz-Folgenabschätzung zu prüfen.
Technische Einrichtungen, die Verhalten oder Leistung von Beschäftigten überwachen sollen, können die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG auslösen. § 90 BetrVG sieht außerdem eine frühe Unterrichtung und Beratung bei der Planung technischer Anlagen, Arbeitsverfahren und Arbeitsabläufe einschließlich KI-Einsatz vor. Eine CNC-Statuslösung sollte deshalb von Beginn an klarstellen, ob sie Anlagenzustände oder Mitarbeiterleistung bewertet.
EU AI Act: KI-Kompetenz gilt auch für Entwickler und Betreiber
Nicht jedes Embedded-Projekt ist ein Hochrisiko-KI-System. Die Risikoeinstufung hängt vom späteren Verwendungszweck ab. Die Pflicht zur Förderung von KI-Kompetenz nach Artikel 4 des EU AI Act gilt jedoch bereits seit Februar 2025. Entwickler und Fachanwender müssen die Grenzen des Coding-Agenten, sichere Berechtigungen, Prüfpflichten und Eskalationswege kennen.
Ein 30-Tage-Pilot für einen CNC-Betrieb
Hypothetisches Szenario: Ein mittelständischer Fertiger betreibt eine CNC-Zelle aus Maschinen verschiedener Baujahre. Ein zusätzliches E-Paper-Display soll vier freigegebene Zustände, den Zeitstempel des letzten Updates und passende, redaktionell freigegebene Wartungshinweise anzeigen. Das System schreibt keine Werte zurück, bewertet keine Mitarbeiter und ersetzt weder CNC-Bedienung noch Instandhaltungsfreigabe.
- Woche 1 – Nutzen und Grenze: Produktion, Instandhaltung, OT und IT definieren Zustände, Nutzer, Schnittstelle, Datenalter, Fallback und verbotene Funktionen. Als illustrative Abnahmekriterien werden mindestens 99 Prozent Übereinstimmung mit dem freigegebenen Maschinenstatus und eine sichtbare Warnung nach zwei ausgebliebenen Aktualisierungszyklen festgelegt.
- Woche 2 – Laboraufbau: Der Coding-Agent unterstützt beim Datenadapter und der Anzeige. Zunächst werden aufgezeichnete oder simulierte Daten genutzt.
- Woche 3 – Abgesicherter Feldtest: Das Display erhält ausschließlich lesenden Zugriff über ein Gateway in einem getrennten Segment. Netzverlust und veraltete Daten werden sichtbar angezeigt.
- Woche 4 – Entscheidung: Das Team bewertet Reaktionszeit, Anzeigequalität, Fehlalarme, Reproduzierbarkeit, Security-Befunde und den Aufwand für industrielle Hardware. Zusätzlich wird geprüft, ob eine zweite Person Build, Geräteeinrichtung und Rückbau allein mit der Dokumentation durchführen kann.
Go/No-Go-Regel: Ein Pilot ist nur erfolgreich, wenn ein zweiter Entwickler die Firmware reproduzieren kann, die Anzeige bei Daten- oder Netzausfall sicher reagiert und kein unkontrollierter Schreibpfad zur Maschine existiert. Eine hübsche Demo allein reicht nicht.
Wer die Abnahme unterschreibt
- Fachlicher Owner: bestätigt Nutzen, verständliche Zustände und betrieblichen Fallback.
- Technischer Owner: verantwortet Architektur, Code, Tests, Datenpfad, Rollback und Dokumentation.
- Organisation: erteilt Betriebs- und Security-Freigabe; bei Bedarf kommen Datenschutz, Arbeitsschutz, Betriebsrat und Produkt-Compliance hinzu.
Das Go für den Feldtest gilt nur gemeinsam: technischer Nachweis und belegter Betriebsnutzen gehören zusammen.
Wann kaufen besser ist als selbst bauen
KI-Coding-Agenten machen Eigenentwicklungen schneller, aber nicht automatisch wirtschaftlicher. Ein Standardproblem sollte weiterhin mit einem Standardprodukt gelöst werden. Selbstbau lohnt sich vor allem, wenn das Unternehmen eine spezifische Kombination aus Datenquelle, Bedienung, Bauform oder Prozesslogik testen muss.
Faustregel: Kaufen bei Standardfunktion, hoher Verfügbarkeit, Zulassungsrelevanz oder fehlendem internem Owner. Selbst prototypisieren bei einer klaren Daten- oder Bedienlücke, kleiner Testzahl und strategischer Differenzierung.
Entscheidungsmatrix nach Aufwand, Nutzen und Risiko
| Anwendungsfall | Aufwand | Nutzenpotenzial | Risiko | Entscheidung |
|---|---|---|---|---|
| Lokale Status- oder Andon-Anzeige | Niedrig | Mittel bis hoch | Niedrig bei read-only | Selbst prototypisieren |
| Retrofit-Sensorik mit mehreren Maschinentypen | Mittel | Hoch bei konkreter Datenlücke | Mittel | Pilot selbst, Industrialisierung mit Partner |
| Geführter Qualitäts- oder Wartungsplatz | Mittel | Mittel bis hoch | Mittel, abhängig von Freigabewirkung | Standardprodukt prüfen, Lücke gezielt ergänzen |
| Schreibender Eingriff oder Sicherheitsfunktion | Hoch | Potentiell hoch | Sehr hoch | Kaufen oder spezialisierten Integrator einsetzen |
Wann der ROI kippt
Der Eigenbau wird wirtschaftlich unattraktiv, sobald die Integrationsbesonderheit kleiner ist als der dauerhafte Betriebsaufwand. In die Rechnung gehören nicht nur Board, Entwicklungsstunden und Lizenzkosten, sondern auch Gehäuse, Industrie-Gateway, Zertifikate, Geräteverwaltung, Ersatzteile, Security-Updates, Tests, Dokumentation, Support und Ausfallfolgen über die geplante Lebensdauer.
Eine einfache Entscheidungsregel lautet: Standardfunktion kaufen, spezifische Nutzenhypothese prototypisch testen, strategisch differenzierende Lösung erst nach belegtem Nutzen selbst produktisieren. Je mehr Standorte, Gerätevarianten, Schreibrechte und regulatorische Anforderungen hinzukommen, desto früher verschiebt sich die Entscheidung zu einem etablierten Produkt oder einem spezialisierten Integrator.
Wer Agenten einsetzt, sollte zudem keine unklaren Prozesse in Hardware gießen. Der Beitrag Ihr Unternehmen braucht keinen KI-Agenten erklärt, warum klare Verantwortlichkeiten und stabile Abläufe vor der Automatisierung kommen.
FAQ
Kann ein KI-Coding-Agent direkt eine CNC-Maschine programmieren?
Technisch kann ein Agent Dateien, Postprozessoren, Makros oder Schnittstellencode erzeugen. Für den betrieblichen Einsatz dürfen diese Ergebnisse aber nicht ungeprüft an die Maschine gelangen. G-Code, Werkzeugkorrekturen und Steuerungsparameter benötigen Simulation, fachliche Prüfung und den etablierten Freigabeprozess.
Sind günstige Mikrocontroller für die Produktion geeignet?
Für Labor und Machbarkeitsnachweis häufig ja. Für dauerhaften Werkseinsatz müssen unter anderem Temperaturbereich, EMV, Stromversorgung, Gehäuse, Lebensdauer, sichere Updates und Ersatzteilfähigkeit passen. Oft wird die Prototypsoftware anschließend auf Industriehardware oder ein verwaltetes Edge-Gateway übertragen.
Braucht jedes Szenario künstliche Intelligenz auf dem Gerät?
Nein. Häufig ist der Coding-Agent nur das Entwicklungswerkzeug. Die Firmware selbst kann vollständig deterministisch arbeiten. Das ist für viele Anzeigen, Sensor-Gateways und Prüfadapter sogar die bessere, nachvollziehbarere Lösung.
Was ist bei älteren CNC-Anlagen der beste Einstieg?
Ein separater, ausschließlich lesender Datenpfad. Je nach Maschine kann das eine freigegebene Herstellerschnittstelle, OPC UA, ein industrielles Gateway oder zusätzliche externe Sensorik sein. Direkte Eingriffe in Steuerung und Sicherheitskreis sind für einen ersten Pilot ungeeignet.
Welche Kennzahlen sollte ein Pilot messen?
Zeit bis zum ersten reproduzierbaren Prototyp, Anteil korrekt dargestellter Zustände, Reaktion auf Ausfälle, Entwicklungsaufwand, offene Sicherheitsbefunde und erwarteter Aufwand für einen industriellen Produktpfad. Reine Code- oder Promptmengen sind keine Geschäftsmessgröße.
Wie erkennt man früh, dass der Pilot zu groß geworden ist?
Ein deutliches Warnsignal ist, wenn vor dem ersten belastbaren Nutzertest bereits mehrere Maschinen, Cloud-Anbindung, ein eigenes KI-Modell und schreibende Steuerungszugriffe nötig erscheinen. Dann sollte das Team den Umfang auf eine Maschine, einen Datenweg, eine Anzeige und eine messbare Nutzenhypothese zurücksetzen. Lässt sich kein kleiner, reversibler Test formulieren, ist das Vorhaben kein Pilot mehr, sondern ein reguläres Integrationsprojekt.
Fazit
KI-Coding-Agenten lohnen sich in der Industrie vor allem für kleine digitale Lücken, deren Nutzen sich vor einer größeren Investition prüfen lässt. Aus dem schnellen Prototyp wird aber erst durch belastbare Technik, klare Verantwortung und einen geregelten Produktpfad eine industrielle Lösung.
Entscheidungsblock: Starten Sie, wenn sich das Vorhaben auf eine Maschine, wenige freigegebene Datenpunkte, eine Anzeige und eine messbare Kennzahl begrenzen lässt. Stoppen oder neu schneiden Sie es, sobald Personenauswertung, Sicherheitsfunktionen oder schreibende Maschinenzugriffe Voraussetzung für den ersten Nutzennachweis werden.
Quellen
- BSI und ANSSI: AI Coding Assistants, 2025.
- BSI: ICS-Security-Kompendium, abgerufen am 5. September 2026.
- BSI: Empfehlungen für Hersteller und Integratoren von ICS, abgerufen am 5. September 2026.
- OPC Foundation: OPC Unified Architecture – Overview and Concepts, abgerufen am 5. September 2026.
- OPC Foundation: OPC UA Security Architecture, abgerufen am 5. September 2026.
- EUR-Lex: EU-Maschinenverordnung – Überblick und Anwendungsfristen, abgerufen am 5. September 2026.
- EUR-Lex: Verordnung (EU) 2023/1230 über Maschinen.
- EUR-Lex: Cyber Resilience Act – Überblick und Anwendungsfristen, abgerufen am 5. September 2026.
- EUR-Lex: Verordnung (EU) 2024/1689 – EU AI Act.
- EUR-Lex: Datenschutz-Grundverordnung.
- Bundesministerium der Justiz: § 87 BetrVG und § 90 BetrVG.
