Klausel 4: Context of the Organization
Die erste Frage, die ISO 42001 stellt, ist nicht "Wie gut ist dein System?" Sondern: "Weißt du überhaupt, was du hast?"
Worum es geht
Klausel 4 ist das Fundament deines AIMS. Bevor du Risiken bewertest, Policies schreibst oder Audits planst, musst du drei Dinge klären:
- In welchem Umfeld arbeitest du?
- Wer hat ein Interesse an deiner KI?
- Was genau gehört in den Scope deines AIMS?
Klingt einfach. Ist es auch, wenn du weißt, worauf es ankommt. Die meisten Unternehmen scheitern nicht an der Technik, sondern daran, dass sie ihren eigenen Kontext nicht sauber aufgeschrieben haben.
4.1 Context of the Organization: Dein Umfeld verstehen
Was du tun musst
Bestimme, welche externen und internen Faktoren für dein Unternehmen relevant sind. Nicht alle Faktoren, die es gibt, sondern nur die, die beeinflussen, ob dein AIMS seine Intended Outcomes erreichen kann.
Zwei Begriffe, die du kennen musst:
Purpose ist der Zweck deiner Organisation. Nicht der Zweck des AIMS, sondern warum dein Unternehmen existiert. Ein Maschinenbauer baut Maschinen. Ein Krankenhaus versorgt Patienten. Dein Purpose bestimmt, welche Kontextfaktoren relevant sind.
Intended Outcomes sind die strategischen Ergebnisse, die dein AIMS erreichen soll. Zum Beispiel: vertrauenswürdige KI, regulatorische Readiness, Haftungsminimierung. Das können mehrere sein. Verwechsle sie nicht mit AI Objectives aus Klausel 6. Intended Outcomes sind strategisch, AI Objectives sind messbar.
Externe Faktoren
Denk an alles, was du nicht kontrollierst, aber was dich betrifft:
Regulierung ist meistens der wichtigste Punkt. Der EU AI Act, die DSGVO, branchenspezifische Normen wie IATF 16949 in der Automobilindustrie oder die MDR in der Medizintechnik.
Marktumfeld spielt eine Rolle, wenn deine Kunden anfangen, nach KI-Governance zu fragen. In der Automobilindustrie passiert das gerade. Die OEMs werden ISO 42001 als Nachweis verlangen, genau wie sie es mit ISO 27001 gemacht haben.
Technologische Entwicklung ist relevant, wenn sich deine KI-Landschaft schnell verändert. Wie schnell veralten deine Modelle? Bist du abhängig von einem Cloud-Provider, der seine APIs ändern kann?
Gesellschaftliche Erwartungen betreffen dich, wenn deine KI Entscheidungen trifft, die Menschen betreffen. Wie steht deine Belegschaft zu KI? Gibt es einen Betriebsrat, der mitredet?
Interne Faktoren
Kompetenz ist oft der kritischste Punkt. Hast du Leute, die KI verstehen? Oder hängt alles an einer Person, die, wenn sie geht, das gesamte KI-Wissen mitnimmt?
IT-Infrastruktur bestimmt, wo deine KI läuft. On-Premise, Cloud, Hybrid. Das hat direkten Einfluss auf Datenschutz und Kontrolle.
Organisationskultur entscheidet, ob dein AIMS gelebt wird oder in der Schublade landet. Ist KI bei euch ein Innovationsthema oder ein Angstthema?
Bestehende Managementsysteme wie ISO 9001 oder ISO 27001 sind ein Vorteil. Du baust darauf auf, statt bei null anzufangen.
Was viele falsch machen: 4.1 vs. 4.2
Das ist die häufigste Verwechslung in der gesamten Norm, und sie wird in PECB-Prüfungen gezielt abgefragt.
Die DSGVO ist ein externer Faktor. Sie gehört in die Kontextanalyse unter 4.1. Die Datenschutzbehörde hingegen ist eine interessierte Partei. Sie gehört in das Stakeholder-Register unter 4.2.
Wenn in deinem Stakeholder-Register "DSGVO" als interessierte Partei steht, hast du die Ebenen verwechselt. Regulierungen sind Faktoren. Die Behörden, die sie durchsetzen, sind Stakeholder.
Musst du das dokumentieren?
Die Norm sagt: nein. Sie fordert nur, dass du die Faktoren "bestimmst" (shall determine). Aber in der Praxis erwartet jeder Auditor ein Dokument. Eine Kontextanalyse, ein SWOT, ein PEST, irgendetwas Nachvollziehbares. Ohne schriftliche Evidenz wird es im Audit schwierig.
→ So hat es die Musterfirma gemacht: Kontextanalyse ansehen
4.2 Interested Parties: Wer hat ein Interesse an deiner KI?
Was du tun musst
Drei Schritte, und alle drei müssen erkennbar sein:
- Identify: Welche Parteien sind für dein AIMS relevant?
- Determine Requirements: Welche Anforderungen haben sie?
- Decide: Welche dieser Anforderungen adressierst du durch dein AIMS?
Der Zwei-Stufen-Filter
Stufe 1, Relevanz: Nicht jeder Stakeholder deines Unternehmens ist ein AIMS-Stakeholder. Dein Büromaterial-Lieferant hat keinen Bezug zu deinen KI-Aktivitäten. Dein AI Provider hat einen sehr direkten Bezug. Der Filter "relevant to the AIMS" ist explizit in der Norm.
Stufe 2, Adressierung: Aus den Anforderungen der relevanten Parteien entscheidest du bewusst, welche du durch dein AIMS bearbeitest und welche nicht. Diese Entscheidung musst du dokumentieren. Sie ist der prüfbare Moment im Audit.
Viele Unternehmen machen den ersten Schritt (Stakeholder auflisten) und den zweiten (Anforderungen notieren), aber vergessen den dritten (Entscheidung treffen). Genau das ist die Lücke, die Auditoren finden.
Die KI-spezifischen Rollen
ISO 42001 bringt Stakeholder-Kategorien mit, die es in keinem anderen Managementsystem gibt:
AI Provider ist das Unternehmen, das dir die KI-Lösung bereitstellt. AI Producer ist, wer sie gebaut hat. AI Customer bist du als Nutzer. AI User sind die Menschen, die täglich damit arbeiten. AI Partner liefert Komponenten oder Daten zu.
Und dann gibt es AI Subjects. Das sind die Menschen, über die deine KI Entscheidungen trifft oder Informationen ableitet. Bewerber, Kunden, Mitarbeiter, Patienten. Diese Gruppe wird am häufigsten vergessen und ist gleichzeitig die wichtigste.
In Deutschland kommen noch Rollen dazu, die nicht in der ISO stehen, aber real sind: Betriebsrat, interne Ethik-Boards, Gewerkschaftsvertreter.
Was viele falsch machen
AI Subjects fehlen. Wenn dein Stakeholder-Register keine Betroffenen enthält, über die deine KI entscheidet, hast du die wichtigste Gruppe ausgelassen. Das fällt auf.
Adressierungsentscheidung fehlt. Stakeholder aufzulisten reicht nicht. Du musst für jede Anforderung sagen: "Wird durch unser AIMS adressiert: ja oder nein." Ohne diese Entscheidung fehlt der prüfbare Moment.
→ So hat es die Musterfirma gemacht: Stakeholder-Register ansehen
4.3 Scope: Was ist drin, was ist draußen?
Was du tun musst
Definiere den Geltungsbereich deines AIMS. Welche Organisationseinheiten, welche Standorte, welche KI-Systeme, welche Prozesse sind eingeschlossen? Und was ist bewusst ausgeschlossen?
Das ist die härteste Anforderung in Klausel 4
Warum? Weil der Scope als Documented Information vorliegen muss. Das heißt: versioniert, freigegeben, gepflegt, auffindbar. Die Norm sagt es explizit: "shall be available as documented information."
Eine PowerPoint mit dem Titel "AIMS Scope v0.1 Entwurf" ist keine Documented Information. Das ist ein Entwurf. Ohne finalisierten, freigegebenen Scope gibt es kein AIMS. Das ist in der Regel eine Major Nonconformity im Audit, das schwerste Finding.
Die Schnittstellen-Falle
Dein Scope muss drei Dinge berücksichtigen:
- Die Ergebnisse deiner Kontextanalyse (aus 4.1)
- Die Anforderungen deiner Stakeholder (aus 4.2)
- Die Schnittstellen und Abhängigkeiten zu anderen Organisationen
Punkt 3 ist bei KI besonders kritisch. KI-Lieferketten sind per Definition multi-organisational. Deine Qualitätskontrolle wurde von einem externen AI Provider gebaut. Dein Predictive-Maintenance-Modell läuft auf AWS. Deine Trainingsdaten kommen von einem Datenlieferanten.
All diese Schnittstellen gehören in den Scope. Nicht jedes technische Detail, aber die Fragen: Wer liefert was? Wo liegt die Verantwortung? Was passiert, wenn der Provider etwas ändert?
Ausschlüsse begründen
Du musst nicht alles in den Scope nehmen. Wenn dein HR-Bereich keine KI nutzt, kann er draußen bleiben. Aber schreib auf, warum. "HR ist ausgeschlossen, da dort keine KI-Systeme im Einsatz sind." Ein Satz reicht.
Ohne Begründung wird jeder Auditor fragen: "Warum ist HR draußen? Nutzen die vielleicht doch KI, zum Beispiel im Recruiting?"
Integration statt Isolation
Wenn du schon ISO 9001 oder ISO 27001 hast: Dein AIMS-Scope muss nicht separat sein. Er kann sich überschneiden. Die Norm sagt explizit, dass Integration erlaubt und erwünscht ist. Das ist kein zusätzliches Silo. Das ist eine Erweiterung dessen, was du schon hast.
Was viele falsch machen
Scope nicht dokumentiert. Der häufigste Fehler. "Steht im Kopf" oder "wissen alle" reicht nicht. Documented Information ist Pflicht.
Scope ohne Schnittstellen. Du nutzt eine KI von einem externen Anbieter, aber im Scope steht nichts darüber. Das ist eine relevante Lücke.
"AIMS muss isoliert sein." Stimmt nicht. Integration mit bestehenden Managementsystemen ist ausdrücklich erlaubt und spart dir massiv Aufwand.
Scope ist "Entwurf". Version 0.1, Draft, Arbeitsfassung. All das erfüllt nicht die Anforderung an Documented Information.
→ So hat es die Musterfirma gemacht: Scope-Statement ansehen
Zusammenfassung
| Bereich | Kernfrage | Documented Information erforderlich? | |---|---|---| | 4.1 Context | In welchem Umfeld arbeitest du? | Nein, aber Auditor erwartet Evidenz | | 4.2 Interested Parties | Wer hat ein Interesse an deiner KI? | Nein, aber Auditor erwartet Evidenz | | 4.3 Scope | Was ist im AIMS drin? | Ja. Pflicht. |
Die 6 häufigsten Fehler bei Klausel 4
1. DSGVO als Stakeholder. Die DSGVO ist ein Gesetz, also ein externer Faktor (4.1). Die Datenschutzbehörde ist ein Stakeholder (4.2).
2. Stakeholder ohne Adressierungsentscheidung. Register vorhanden, Anforderungen gelistet, aber nirgends steht, welche davon das AIMS adressiert.
3. AI Subjects vergessen. ISO 9001 und ISO 27001 kennen keine AI Subjects. ISO 42001 schon. Wenn deine KI über Menschen entscheidet, gehören sie ins Register.
4. Scope als Entwurf. Entwürfe sind keine Documented Information. Der Scope muss finalisiert, versioniert und freigegeben sein.
5. Scope ohne Schnittstellen. Externe AI Provider, Cloud-Services und Datenlieferanten fehlen im Scope, obwohl sie Teil der KI-Lieferkette sind.
6. Ausschlüsse ohne Begründung. HR, Marketing oder andere Bereiche sind ausgeschlossen, aber niemand hat aufgeschrieben warum.
→ Weiter: Klausel 5, Führung → Zurück zur Übersicht
Begriffe in diesem Artikel: Context of the Organization, Interested Parties, Scope, Documented Information, Intended Outcomes, Purpose, AI Provider, AI Producer, AI Customer, AI User, AI Subject, AI Partner, Major Nonconformity, Statement of Applicability (SoA), SWOT, PEST