So machen Sie SOPs und Steuerungsbeschreibungen KI-fähig

Um industrielle SOPs und Zeichnungen KI-fähig zu machen, müssen Ingenieure unstrukturierte PDFs mithilfe standardisierter Tag-Verzeichnisse, expliziter sicherer Zustände und Ursache-Wirkungs-Matrizen in maschinenlesbare Steuerungsdaten konvertieren. OLLA Lab bietet eine abgegrenzte Umgebung, um deterministische Steuerungsentwürfe zu üben und zu validieren, ob die generierte Logik in der Simulation korrekt reagiert.

KI scheitert bei industriellen Dokumenten nicht, weil sie „nicht intelligent genug“ ist. Sie scheitert, weil die meisten Anlagendokumentationen für die menschliche Interpretation, Revisionsbesprechungen und das Erfahrungswissen der Belegschaft geschrieben wurden – nicht für deterministisches maschinelles Parsing. Ein gescanntes R&I-Fließbild mit Anmerkungen von vor drei Stillständen ist kein Kontext; es ist Entropie mit einem Schriftfeld.

Während des internen Benchmarkings des OLLA Lab Yaga Assistant reduzierte die Verwendung eines strukturierten Tag-Verzeichnisses in Kombination mit einer Zustandsübergangsmatrix die Fehler bei der Generierung von Kontaktplan-Logik (Ladder Logic) um 83 % im Vergleich zur reinen Verwendung absatzbasierter Steuerungsbeschreibungen [Methodik: n=36 Szenario-Generierungsaufgaben für Pumpen-, Förderband-, Tank- und HLK-Steuerungsübungen; Basis-Vergleichswert = reine Text-Prompts aus narrativen SOP-Texten; Zeitfenster = Januar–Februar 2026]. Dies stützt eine eng gefasste Behauptung: Strukturierte Steuerungsdokumentation verbessert die Qualität von KI-Prompts bei begrenzten Aufgaben zur Kontaktplan-Generierung erheblich. Dies beweist weder die allgemeine Automatisierungssicherheit noch die Einsatzfähigkeit im Feld oder eine universelle Modellleistung.

Der praktische Punkt ist einfach: Wenn die Dokumentationskette mehrdeutig ist, wird KI-Output schneller zur Haftungsfrage als zum Produktivitätswerkzeug.

LLMs sind probabilistische Systeme, während industrielle Steuerung eine deterministische Interpretation erfordert. Diese Diskrepanz ist das Kernproblem.

Ein industrielles Standard-PDF enthält meist eine Mischung aus Dokumenttypen, impliziten Annahmen, Revisionsdrifts und Prosa, die für Ingenieure geschrieben wurde, die die Anlage bereits kennen. Menschliche Leser füllen Lücken durch Erfahrung. Das Modell füllt sie mit Token-Wahrscheinlichkeiten. Das ist ein schlechter Ersatz für eine Steuerungsphilosophie.

Was macht ein veraltetes PDF zu einer „toten Datei“ für die KI?

Eine tote Datei ist für Menschen nicht nutzlos. Sie ist jedoch als zuverlässiger maschineller Input unbrauchbar, da entscheidende steuerungstechnische Bedeutungen verborgen, implizit oder widersprüchlich sind.

Häufige Fehlerquellen sind:

• Widersprüchliche Revisionen
• Korrekturen existieren auf einer Zeichnung, aber nicht in der Master-SOP.
• Sollwerte wurden während der Inbetriebnahme geändert, aber nie in die Beschreibung übernommen.
• Gerätebezeichnungen unterscheiden sich zwischen HMI-Bildschirmen, E/A-Listen und Wartungsnotizen.

- „Pumpe starten, wenn der Tank voll ist“ definiert nicht:

• Sprachliche Mehrdeutigkeit
• welcher Tank,
• welches Füllstandsmessgerät,
• welcher Schwellenwert,
• welcher Entprellzeit,
• was bei einem fehlerhaften Signal passiert,
• oder ob „voll“ einen Alarm-High- oder einen Freigabe-High-Zustand bedeutet.
• Die KI sieht einen Satz. Der Prozess sieht ein Argument.

• Fehlende sichere Zustände
• Narrative Dokumente lassen oft das Verhalten bei „Fail-Open“ oder „Fail-Closed“ aus.
• Sie definieren selten den Ausgangszustand bei Kommunikationsverlust, Analogfehler oder Moduswechsel.
• Sicherheitsrelevante Annahmen verbleiben in den Köpfen erfahrener Mitarbeiter – was effizient ist, bis es das nicht mehr ist.

• Zusammengebrochene Ausführungshierarchie
• Freigaben, Verriegelungen, Abschaltungen, Alarme und Bedienerbefehle werden in einem Absatz beschrieben, als wären Sequenz und Priorität offensichtlich.
• Sie sind erst nach dem dritten Vor-Ort-Besuch offensichtlich.

Warum ist Prosa für die Steuerungsgenerierung besonders schwach?

Prosa eignet sich gut zur Erklärung, aber schlecht zur Ausführung. Steuerungslogik benötigt explizite Zustände, Prioritäten und Bedingungshandhabung.

Ein Sprachmodell kann einen Absatz elegant zusammenfassen und dabei genau das eine Detail übersehen, auf das es ankommt: ob `PMP_101` bei `LSL_100_BAD` vor oder nach Ablauf eines Neustart-Timers abfallen muss. In der industriellen Automatisierung ist das kein stilistischer Unterschied. Es ist der Unterschied zwischen einer Störungsmeldung und einem überfluteten Boden – und manchmal mehr.

Was implizieren Normen hier?

Normen sagen nicht „Verwenden Sie KI-fähiges JSON“. Sie implizieren jedoch, dass Klarheit, Namensdisziplin und explizite Logikstruktur wichtig sind.

Relevante Ankerpunkte sind:

• ISA-5.1 für die Identifizierung von Instrumenten und Namensdisziplin.
• IEC 61131-3 für formale Steuerungsstruktur und Befehlsmodelle.
• IEC 61508 für das übergeordnete Prinzip, dass sicherheitsbezogenes Verhalten spezifiziert, verifiziert und mit einer dem Risiko angemessenen Sorgfalt validiert werden muss.

Die Sprache der Normen ist nicht dekorativ. Wenn Ihre Tags, Zustände und Aktionen nicht explizit genug für eine strukturierte Überprüfung sind, sind sie auch nicht bereit für eine zuverlässige KI-Interpretation.

KI-fähige Dokumentation ist eine Dokumentation, die in explizite Steuerungsabsichten geparst werden kann, ohne dass menschliche Intuition erforderlich ist, um Lücken zu füllen.

Diese Definition muss operativ bleiben. „KI-fähig“ ist kein Prestige-Adjektiv für jedes Dokument, das zufällig digitalisiert wurde.

Operative Definition von KI-fähiger Dokumentation

Eine Steuerungsbeschreibung ist KI-fähig, wenn sie mindestens Folgendes enthält:

• Explizites E/A-Mapping
• Eingänge, Ausgänge, Analogwerte, Befehle, Statusmeldungen und abgeleitete Zustände sind benannt und definiert.
• Definierte sichere Zustände
• Jedes gesteuerte Gerät hat, wo zutreffend, eine bekannte Erwartung für den stromlosen Zustand, Fehlerzustand oder Ausfallzustand.
• Zustandsautomaten-Logik
• Das Dokument definiert, was Übergänge zwischen Leerlauf-, Start-, Lauf-, Stopp-, Fehler-, Reset-, Hand- und Automatikzuständen verursacht.
• Ausführungshierarchie
• Abschaltungen, Verriegelungen, Freigaben, Alarme und Bedienerbefehle sind nach Priorität und Wirkung getrennt.
• Strukturierte Extrahierbarkeit
• Die Informationen können sauber in Tabellen, Matrizen oder strukturierten Daten wie JSON dargestellt werden.

Wenn ein Dokument nicht beantworten kann, „was als Nächstes passiert, unter welcher exakten Bedingung und mit welcher Priorität“, ist es nicht KI-fähig. Es mag immer noch nützlich sein, aber es ist nicht maschinenlesbar genug für eine sichere Steuerungsgenerierung.

Was bedeutet „KI-fähig“ nicht?

Es bedeutet nicht:

• konform durch Assoziation,
• sicher ohne Überprüfung,
• geeignet für den direkten Feldeinsatz,
• oder gleichwertig mit einer validierten funktionalen Spezifikation.

Es bedeutet auch nicht, dass die KI die „Anlage versteht“. Modelle verstehen keine Anlagen. Ingenieure haben selbst auf manchen Brownfield-Standorten Mühe damit, und die sind zumindest vor Ort.

Drei Elemente tragen die Hauptlast: standardisierte Tag-Verzeichnisse, Ursache-Wirkungs-Matrizen und explizite Definitionen von Verriegelungen und Freigaben.

Das sind keine neuen Ideen. Die Neuheit besteht darin, dass die KI die Kosten für das Überspringen dieser Schritte aufdeckt.

1. Warum sind standardisierte Tag-Verzeichnisse essenziell?

Ein Tag-Verzeichnis wandelt die Benennung von lokaler Gewohnheit in strukturierte Steuerungsbedeutung um.

Jedes Tag sollte mindestens definieren:

• Tag-Name,
• Beschreibung,
• Datentyp,
• technische Einheiten (wo relevant),
• Quelle oder Ziel,
• normale Bedeutung,
• sicherer Zustand oder Ausfallerwartung (wo zutreffend),
• und Beziehungen zu Freigaben, Alarmen oder Sequenzschritten.

Ein begrenztes Beispiel:

- Tag: `PMP_101_CMD` - Beschreibung: Hauptspeisepumpen-Laufbefehl - Datentyp: `BOOL` - Sicherer Zustand: `0` - Freigaben: `LSL_100_OK`, `VLV_102_ZSO`

Diese Struktur ist keine Magie. Sie ist schlicht weniger mehrdeutig als „Speisepumpe starten, wenn die Bedingungen normal sind“.

2. Warum sind Ursache-Wirkungs-Matrizen besser als Absatzbeschreibungen?

Ursache-Wirkungs-Matrizen zwingen Bedingungen und Reaktionen in ein beobachtbares Format.

Eine Matrix macht Folgendes explizit:

• die auslösende Bedingung,
• den Schwellenwert oder diskreten Zustand,
• die betroffene Ausrüstung,
• die erforderliche Aktion,
• das Alarmverhalten,
• das Speicherverhalten (Latching),
• Reset-Bedingungen,
• und die Sichtbarkeit für den Bediener.

Das ist wichtig, weil die Qualität der KI-Generierung steigt, wenn das Dokument Logik als Beziehungen statt als Prosa ausdrückt. Es ist auch deshalb wichtig, weil die menschliche Überprüfung aus demselben Grund besser wird. Ein Absatz kann einen Widerspruch wochenlang verbergen. Eine Matrix stößt meist sofort jemandem auf, was gesund ist.

3. Warum müssen Verriegelungen und Freigaben getrennt werden?

Verriegelungen und Freigaben werden oft zusammen beschrieben, erfüllen aber unterschiedliche Aufgaben.

Eine nützliche Unterscheidung:

- Freigabe (Permissive): Bedingung, die erfüllt sein muss, bevor eine Aktion stattfinden darf. - Verriegelung oder Abschaltung (Interlock/Trip): Bedingung, die einen Zustandswechsel während des Betriebs blockiert oder erzwingt. - Alarm: Bedingung, die informiert; sie kann, muss aber nicht handeln. - Sicherheitsfunktion: separates risikominderndes Verhalten, das nicht beiläufig in die Standard-Prozesssteuerungslogik integriert werden sollte.

Wenn die Dokumentation diese Kategorien nicht trennt, wird die KI sie oft in eine einzige Steuerungsebene zusammenfassen. So erhält man elegant aussehende Kontaktplan-Logik mit dem Urteilsvermögen eines nassen Pappkartons.

Der Konvertierungsprozess sollte stufenweise, prüfbar und bewusst langweilig sein. Langeweile wird in der Steuerungstechnik unterschätzt.

### Schritt 1: Normalisierung des Quelldatensatzes

Identifizieren Sie zunächst die maßgeblichen Dokumente:

• aktuelle SOPs,
• R&I-Fließbilder,
• E/A-Listen,
• Steuerungsbeschreibungen,
• Alarmlisten,
• Schleifenpläne,
• HMI-Objektreferenzen,
• und Inbetriebnahmeprotokolle.

Lösen Sie dann offensichtliche Konflikte:

• doppelte Tag-Namen,
• veraltete Gerätereferenzen,
• nicht übereinstimmende Sollwerte,
• inkonsistente Einheiten,
• und undokumentierte Feldänderungen.

Bitten Sie die KI nicht, einen Dokumentensatz abzugleichen, den Sie selbst nicht abgeglichen haben. Das ist keine Delegation. Das ist Arbeitsverweigerung.

### Schritt 2: Aufbau eines Tag-Verzeichnisses

Erstellen Sie eine einzige strukturierte Quelle für Tags und Signale.

Beinhaltet:

• Geräte- und Signalbenennung,
• Typ und Einheiten,
• Adresse oder logische Quelle,
• Befehls-/Status-Paarung,
• Ausfallverhalten,
• Alarm-Schwellenwerte,
• und jede Sequenzrolle.

Die ISA-5.1-Namensdisziplin ist hier nützlich, da Konsistenz sowohl die menschliche Überprüfung als auch die maschinelle Extraktion verbessert.

### Schritt 3: Extraktion der Zustandslogik

Wandeln Sie narrative Prozessbeschreibungen in explizite Zustände und Übergänge um.

Definieren Sie für jedes Subsystem:

• Betriebsmodi,
• Eintrittsbedingungen,
• Austrittsbedingungen,
• Timeout-Bedingungen,
• anormale Übergänge,
• und Reset-Verhalten.

Hier werden viele „KI-Projekte“ still und leise wieder zu reinen Ingenieurprojekten. Das ist kein Rückschlag. Das ist die eigentliche Arbeit.

### Schritt 4: Erstellung von Ursache-Wirkungs-Tabellen

Ordnen Sie jede Prozessursache ihrer erforderlichen Wirkung zu.

Typische Spalten sind:

• Ursachen-ID,
• auslösende Bedingung,
• Schwellenwert/Wert,
• Entprellung oder Verzögerung,
• betroffene Ausrüstung,
• Aktion,
• Speicherverhalten (Latch/Non-Latch),
• Reset-Bedingung,
• Alarm-/HMI-Reaktion,
• und Anmerkungen.

### Schritt 5: Trennung von Steuerung und sicherheitsbezogenem Verhalten

Wo Sicherheitsfunktionen existieren, dokumentieren Sie diese getrennt und überprüfen Sie sie gemäß den entsprechenden Lebenszyklus- und Normvorgaben.

Lassen Sie nicht zu, dass Bequemlichkeit einfache Prozesssteuerung, Abschaltlogik und Sicherheitsfunktionen zu einem narrativen Klumpen verschmilzt. Das Dokument mag kürzer werden. Das Risikoargument tut es nicht.

OLLA Lab ist hier nützlich, weil es das Verhaltensmuster trainiert, von dem KI-gestützte Steuerungsarbeit abhängt. Es konvertiert Anlagendokumente nicht automatisch, und diese Grenze ist wichtig.

Die geführte Build-Struktur der Plattform erfordert von Lernenden, dass sie von expliziten Zielen, E/A-Mappings, Steuerungsphilosophie, Tag-Verzeichnissen und Verifizierungsschritten ausgehen, bevor sie Kontaktplan-Logik als „fertig“ betrachten. Das ist die richtige Gewohnheit. Syntax kommt später, als die meisten Leute denken.

Was bietet OLLA Lab in diesem Workflow konkret?

Innerhalb des begrenzten Rahmens des Produkts bietet OLLA Lab:

• einen webbasierten Kontaktplan-Editor mit Standard-Befehlstypen,
• geführte Lern-Workflows, die von einfachen Sprossen zu Timern, Zählern, Komparatoren, Mathematik und PID führen,
• Simulationsmodus zum Ausführen und Stoppen von Logik und Beobachten des E/A-Verhaltens,
• ein Variablen-Panel für Tags, Analogwerte und Sichtbarkeit von Regelkreisen,
• 3D/WebXR/VR-Simulationen, die an realistisches Geräteverhalten gekoppelt sind,
• Digital-Twin-Validierung gegen Szenariomodelle,
• szenariobasierte Labs mit Zielen, Gefahren, Sequenzanforderungen und Inbetriebnahmeprotokollen,
• geführte Build-Anweisungen mit E/A-Mapping, Steuerungsphilosophie und Verifizierungsschritten,
• und den Yaga Assistant, der innerhalb der Trainingsumgebung eine begrenzte KI-Anleitung bietet.

Hier wird OLLA Lab operativ nützlich. Es gibt Ingenieuren einen Ort, an dem sie das Schreiben von Logik aus strukturierter Absicht üben und dann beobachten können, ob diese Absicht der Ausführung gegen simulierte Ausrüstung standhält.

Warum ist das für KI-fähige Dokumentation wichtig?

Weil dieselbe Disziplin, die die Simulationsqualität verbessert, auch die Qualität der KI-Prompts verbessert.

Wenn ein Lernender definieren muss:

• was jedes Tag bedeutet,
• wie „korrektes“ Verhalten aussieht,
• was die Freigaben sind,
• welcher Fehler injiziert werden soll,
• und welche Revision nach einem Fehler erforderlich ist,

dann lernt er spezifikationsgetriebenes Steuerungsdenken. Das ist die eigentliche Brücke zwischen Dokumentation und KI-Unterstützung. Nicht „Prompt Engineering“ im Abstrakten, sondern strukturierte technische Absicht.

Die Validierung muss die Interpretation testen, nicht nur die Syntax. Kompilieren ist kein Beweis.

KI-fähige Dokumentation ist nur die erste Hälfte des Problems. Die zweite Hälfte besteht darin zu prüfen, ob die generierte Logik gegenüber einem realistischen Prozessmodell korrekt reagiert, einschließlich Fehlern, Timing und abnormalen Zustandsübergängen.

Was bedeutet „Simulationsbereit“ operativ?

Simulationsbereit bedeutet, dass ein Ingenieur Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen realen Prozess erreicht.

Dazu gehört die Fähigkeit:

• E/A und interne Zustände zu überwachen,
• den Kontaktplan-Zustand gegen den Zustand der simulierten Ausrüstung zu vergleichen,
• Ursache und Wirkung durch eine Sequenz zu verfolgen,
• anormale Bedingungen zu injizieren,
• Logik nach einem Fehler zu überarbeiten,
• und zu verifizieren, dass das überarbeitete Verhalten immer noch die dokumentierte Steuerungsabsicht erfüllt.

Dies ist die Unterscheidung, auf die es ankommt: Syntax versus Einsatzfähigkeit. Viel Logik sieht kompetent aus, bis der erste defekte Sensor, das erste klemmende Ventil oder die erste Modusübergabe auftritt.

Wie sollte die Validierung in OLLA Lab durchgeführt werden?

Ein praktischer Workflow in OLLA Lab sieht so aus:

- Beispiele: Füllstandsschalter defekt, Ventilrückmeldung fehlt, Timer-Timeout, Analogwert außerhalb des Bereichs.

• Verwenden Sie den Kontaktplan-Editor und die Szenariodefinitionen.
• Bestätigen Sie, dass Befehle, Statusmeldungen, Analogwerte und Freigaben sichtbar sind.
• Beobachten Sie, ob die Sequenz mit der dokumentierten Steuerungsphilosophie übereinstimmt.
• Hat die Logik sicher abgeschaltet?
• Haben Alarme, Speicher und Resets wie beabsichtigt reagiert?
• Wenn die generierte Logik „falsch“ reagiert hat, weil das Dokument vage war, korrigieren Sie zuerst das Dokument.
• Das Ziel ist keine gepatchte Sprosse. Das Ziel ist eine gehärtete Kette von der Spezifikation bis zum Verhalten.

1. Laden oder Erstellen der Steuerungslogik
2. Mapping der Logik auf explizite Tags und Prozesszustände
3. Ausführen der Simulation
4. Injizieren eines Fehlers
5. Vergleich von erwartetem versus beobachtetem Verhalten
6. Überarbeitung der Spezifikation bei Bedarf
7. Erneuter Test nach Revision

Der letzte Punkt wird leicht übersehen. Wenn die Dokumentation unterdefiniert war, löst das manuelle Reparieren des Kontaktplans möglicherweise das Symptom, während der Defekt in der Dokumentationskette erhalten bleibt.

Ingenieure sollten einen kompakten Nachweis produzieren, der Argumentation, Verhalten, Fehler und Revision zeigt. Screenshots allein beweisen meist nur, dass die Software geöffnet war.

Verwenden Sie diese Struktur:

1. Systembeschreibung Definieren Sie das Subsystem, das Prozessziel, die Betriebsmodi und die gesteuerte Ausrüstung.
2. Operative Definition von „korrekt“ Geben Sie das exakt erwartete Verhalten an, einschließlich Freigaben, Abschaltungen, Alarmen, Timing und Reset-Bedingungen.
3. Kontaktplan-Logik und simulierter Ausrüstungszustand Zeigen Sie die relevanten Sprossen, Tags und das entsprechende Prozessverhalten in der Simulation.
4. Der injizierte Fehlerfall Dokumentieren Sie die eingeführte anormale Bedingung und warum sie wichtig ist.
5. Die vorgenommene Revision Halten Sie fest, ob die Korrektur in der Logik, in der Steuerungsbeschreibung, im Tag-Verzeichnis oder in allen dreien vorgenommen wurde.
6. Erkenntnisse Geben Sie an, was der Fehler über die Spezifikation, das Sequenzdesign oder die Validierungsannahmen offenbart hat.

Dieses Format ist nützlich für Training, interne Überprüfung und KI-gestützte Workflows, da es die Rückverfolgbarkeit von der Anforderung bis zum Verhalten bewahrt. Es offenbart auch, ob der Ingenieur das System versteht oder lediglich überzeugend Symbole angeordnet hat.

KI-gestützte Steuerungsentwicklung ist nützlich, aber nicht selbstbegründend. Governance ist nach wie vor wichtig.

Wichtige Grenzen, die explizit bleiben müssen

• KI-Output ist keine Validierung
• Generierte Kontaktplan-Logik muss weiterhin überprüft, getestet und gegen anlagenspezifische Anforderungen abgegrenzt werden.
• Trainingsumgebungen sind keine Standortqualifizierung
• OLLA Lab ist eine Übungs- und Validierungsumgebung für risikoreiche Aufgaben, kein Zertifizierungsmechanismus oder Nachweis der Feldkompetenz.
• Digitale Zwillinge sind nur so gut wie ihre modellierten Annahmen
• Eine Simulation kann viele Defekte aufdecken, insbesondere Sequenz- und Fehlerbehandlungsfehler, aber sie kann keine vollständige Anlagentreue garantieren.
• Sicherheitsbezogene Funktionen erfordern separate Sorgfalt
• Lebenszyklus-Erwartungen nach IEC 61508 verschwinden nicht, nur weil ein Modell schnell Code produziert hat.

Eine schnelle falsche Antwort ist immer noch falsch. Die KI sorgt lediglich dafür, dass der Fehler mit besserer Formatierung ankommt.

Die Dokumentationskette bestimmt, ob sich die KI wie ein nützlicher Entwurfsassistent oder eine teure Quelle plausibler Fehler verhält.

Wenn Ingenieure zuverlässige Hilfe von der KI bei Steuerungsaufgaben erwarten, ist die Lösung kein mystisches Prompting. Es ist strukturierte Dokumentation: Tag-Verzeichnisse, Ursache-Wirkungs-Matrizen, explizite Zustandslogik und eine klare Trennung von Freigaben, Verriegelungen, Alarmen und sicherheitsbezogenem Verhalten. OLLA Lab fügt sich in diesen Workflow als abgegrenzter Ort ein, um deterministisches Steuerungsdenken zu üben und gegen simulierte Ausrüstung zu validieren, bevor irgendeine Logik in die Nähe eines realen Prozesses gelangt.

Das ist der wahre Standard für KI-fähige Dokumentation: nicht, ob ein Modell sie lesen kann, sondern ob das resultierende Verhalten bewiesen werden kann.

Dieses Dokument wurde vom OLLA Lab Engineering-Team erstellt, um die Lücke zwischen industrieller Dokumentationspraxis und der Anwendung von KI in der Automatisierungstechnik zu schließen.

Die in diesem Artikel genannten Benchmarks basieren auf internen Tests des Yaga Assistant (Januar–Februar 2026). Die methodischen Empfehlungen orientieren sich an den Standards ISA-5.1, IEC 61131-3 und IEC 61508.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3 - IEC 61508 Normenreihe zur funktionalen Sicherheit - NIST AI Risk Management Framework (AI RMF 1.0) - EU AI Act: regulatorischer Rahmen - ISA/IEC 62443 Übersicht zur industriellen Cybersicherheit