Warum ISO 42001 auf Ihrer Roadmap steht, ob Sie es wollen oder nicht
ISO/IEC 42001:2023 ist der erste internationale, zertifizierbare Managementsystem-Standard für künstliche Intelligenz. Wenn Sie jemals ein ISO-27001-Projekt durchlaufen haben, kennen Sie die Form bereits: ein Plan-Do-Check-Act-Zyklus um einen Satz von Kontrollen, ein Statement of Applicability, ein internes Audit und schließlich ein externes Zertifizierungsaudit. ISO 42001 bringt dieselbe Mechanik in AI-Systeme – von der Entwicklung über Governance, Monitoring bis zur Außerbetriebnahme.
Bis 2025 war das etwas, worüber man interessiert las. Anfang 2026 wird es zur Einkaufsanforderung. Enterprise-Kunden – besonders in regulierten Branchen – ergänzen ihre RFPs zunehmend um „ISO 42001 zertifiziert oder auf dem Weg zur Zertifizierung". Der EU AI Act erkennt ISO 42001 zudem ausdrücklich als Indiz für die Konformität mit mehreren AIMS-Pflichten an. Wer als Startup AI-Features baut oder an Enterprise-Kunden verkauft, kommt am Verständnis dieses Standards nicht mehr vorbei.
Dieser Beitrag behandelt die Engineering-Seite einer ISO-42001-Implementierung. Den Papierkram überlassen wir dem Compliance-Team, wo möglich, und fokussieren darauf, was Sie – die Leute, die die Systeme betreiben – wirklich bauen müssen.
Was der Standard tatsächlich verlangt
ISO 42001 definiert ein AI Management System (AIMS). Auf hoher Ebene:
- Klauseln 4–10 beschreiben das Managementsystem selbst – Kontext, Leadership, Planung, Support, Operation, Evaluation, Improvement. Das ist das ISO-typische Skelett, identisch zu 27001.
- Annex A listet 38 Kontrollen, die AI-spezifische Anliegen abdecken: Policies für AI, interne Organisation, Ressourcen (Daten, Tools, Menschen), Impact Assessments, AI-System-Lifecycle, Daten für AI, Informationen für Betroffene, Nutzung von AI-Systemen und Drittparteien-Beziehungen.
- Annex B ist die Umsetzungsleitlinie zu diesen Kontrollen.
- Annex C bildet AI-Ziele und Risikoquellen ab.
- Annex D deckt branchenspezifische Aspekte ab.
Der Zertifizierungsprüfer will Nachweise sehen, dass jede anwendbare Annex-A-Kontrolle implementiert, gepflegt und wirksam ist. Ihr Job als Engineers ist es, diese Nachweise wo immer möglich automatisiert zu erzeugen – die Alternative sind PDFs.
Wie es zu ISO 27001 passt
Wer bereits ein 27001-Programm betreibt, kann grob 40–50 % der Mechanik übernehmen. Wir haben die Überlappungs-Analyse für mehrere Kunden gemacht; hier die grobe Übersicht:
| ISO-27001-Kontrollbereich | ISO-42001-Äquivalent | Wiederverwendung % |
|---|---|---|
| Access Control | A.4 Resources (Zugriff auf AI-Systeme/Daten) | ~80 % |
| Kryptografie | Gilt für Model-Weights, Trainingsdaten | ~90 % |
| Lieferantenbeziehungen | A.10 Third-Party-Beziehungen | ~70 % |
| Incident Management | A.9 AI-System-Lifecycle – Incidents | ~60 % |
| Change Management | A.6 AI-System-Impact-Assessment | ~40 % |
| Risk Assessment | A.5 Assessing Impacts of AI Systems | ~30 % |
Die Bereiche mit der geringsten Wiederverwendung sind die AI-spezifischen: Impact Assessments auf Personen und Gruppen, Bias und Fairness, Modell-Lifecycle-Management und Erklärbarkeit. Planen Sie hier echte Engineering-Zeit ein.
Schritt 1: Den AIMS-Scope festlegen
Die erste Frage des Prüfers: Welche AI-Systeme sind im Scope? Die Antwort darf nicht „alles" oder „nichts" lauten. Sie muss ein definierter, verteidigbarer Satz von Systemen mit dokumentierbaren Grenzen sein.
Wir empfehlen einen Inventur-Ansatz. Bauen Sie ein Model-Registry – ja, ein echtes Stück Software, keine Tabelle – und behandeln Sie es als Source of Truth. Jedes AI-System im Scope hat einen Record. Hier ein minimales Schema:
# models/claude-rag-assistant.yaml
id: claude-rag-assistant
name: Customer Support RAG Assistant
owner: team-ai-platform
contact: [email protected]
deployment:
environment: production
regions: [eu-west-1]
endpoint: https://api.example.com/v1/assistant
classification:
purpose: customer-support
data_sensitivity: pii
risk_tier: high
eu_ai_act_tier: limited
affected_parties: [customers, support-agents]
model:
type: llm-rag
base_model: claude-sonnet-4.6
provider: anthropic
version_pinned: true
weights_location: vendor-hosted
data:
training_sources: none-fine-tuning
rag_sources:
- name: support-kb
location: s3://example-kb/support/
pii: false
- name: ticket-history
location: postgres://prod-rds/tickets
pii: true
retention_days: 365
governance:
impact_assessment_id: IA-2026-014
last_reviewed: "2026-01-15"
approved_by: [cto, dpo]
lifecycle:
stage: production
decommission_date: null
Jedes Modell im Registry löst einen Downstream-Workflow aus: Impact Assessment, falls keines existiert, Data-Governance-Check, Logging-Konfiguration, Monitoring-Dashboards und Audit Trail. Ein Mensch zeichnet ab, bevor der Record nach stage: production wandern darf.
Schritt 2: Risiko- und Impact-Assessment
ISO 42001 geht im Risiko-Assessment über 27001 hinaus. Sie bewerten Risiken nicht nur für die Organisation, sondern für Einzelpersonen und die Gesellschaft, die vom AI-System betroffen sind. Annex B.5 liefert das Framework: AI-System identifizieren, Kontext beschreiben, Auswirkungen (positiv wie negativ) benennen, Schweregrad und Eintrittswahrscheinlichkeit bewerten und die Entscheidung (fortsetzen, mitigieren, ablehnen) dokumentieren.
Ein schlankes Impact-Assessment-Template:
# Impact Assessment: <System Name>
## 1. System context
- Purpose and intended users
- Operating environment
- Data flows
## 2. Affected parties
- Direct users
- Third parties
- Vulnerable populations
## 3. Potential impacts
- Privacy
- Fairness / discrimination
- Safety
- Financial
- Autonomy and human oversight
## 4. Likelihood and severity
- Matrix scored 1-5 each
## 5. Mitigations
- Technical
- Procedural
## 6. Residual risk and decision
- Accept / mitigate / decline
- Approver and date
Legen Sie diese als Markdown in einem Compliance-Repo ab, das für alle außer einer kleinen Gruppe read-only ist, versioniert wird und per Model-ID aus dem Registry referenziert wird.
Schritt 3: Controls as Code
Die 38 Annex-A-Kontrollen sind das, was ein Prüfer nachvollzieht. Die meisten lassen sich mit Papier erfüllen, aber der schnellere Weg ist, so viele wie möglich als maschinell prüfbare Policy auszudrücken. Wir nutzen dafür OPA mit Rego. Das läuft in CI, in Admission Controllern und als Standalone-Check gegen das Model-Registry.
Eine Policy, die jedes Modell ohne Impact Assessment und DPO-Freigabe am Produktionsrollout hindert:
package ai.model_registry
default allow := false
deny contains msg if {
input.deployment.environment == "production"
input.classification.data_sensitivity == "pii"
not input.governance.impact_assessment_id
msg := sprintf("model %q handles PII but has no impact assessment", [input.id])
}
deny contains msg if {
input.deployment.environment == "production"
input.classification.risk_tier == "high"
not "dpo" in input.governance.approved_by
msg := sprintf("high-risk model %q missing DPO approval", [input.id])
}
deny contains msg if {
input.lifecycle.stage == "production"
not input.governance.last_reviewed
msg := sprintf("model %q has no review date", [input.id])
}
allow if {
count(deny) == 0
}
Eingesetzt in CI gegen jeden PR auf das models/-Verzeichnis:
- name: Validate model registry
run: |
for file in models/*.yaml; do
yq -o=json "$file" | \
opa eval -I -d policies/ \
"data.ai.model_registry.deny" --format=pretty
done
Jeder Merge, der einen Model-Record verändert, erzeugt einen Audit-Eintrag. Der Prüfer bekommt ein Git-Log.
Schritt 4: Data Governance für Training und RAG
Annex-A-Kontrolle A.7 deckt Daten für AI ab: Qualität, Provenienz, Aufbereitung und laufendes Management. Für eine LLM-basierte Anwendung bedeutet das meist:
- Trainingsdaten, falls Sie fine-tunen – Quelle, Lizenz, Einwilligung, PII-Bereinigung.
- RAG-Korpus – welche Dokumente indexiert sind, wie sie aktualisiert und auf Nutzeranfrage entfernt werden.
- Prompt- und Response-Logs – was Sie erfassen, wie lange Sie es behalten, wer es lesen darf.
Schließen Sie den S3-Bucket mit dem RAG-Korpus mit Object Lock, Versioning und Access Logging ab. Terraform:
resource "aws_s3_bucket" "ai_corpus" {
bucket = "example-ai-corpus-prod"
}
resource "aws_s3_bucket_versioning" "corpus" {
bucket = aws_s3_bucket.ai_corpus.id
versioning_configuration {
status = "Enabled"
}
}
resource "aws_s3_bucket_object_lock_configuration" "corpus" {
bucket = aws_s3_bucket.ai_corpus.id
rule {
default_retention {
mode = "GOVERNANCE"
days = 365
}
}
}
resource "aws_s3_bucket_logging" "corpus" {
bucket = aws_s3_bucket.ai_corpus.id
target_bucket = aws_s3_bucket.audit_logs.id
target_prefix = "s3-access/ai-corpus/"
}
resource "aws_cloudtrail" "ai_data_events" {
name = "ai-data-events"
s3_bucket_name = aws_s3_bucket.audit_logs.id
include_global_service_events = false
event_selector {
read_write_type = "All"
include_management_events = true
data_resource {
type = "AWS::S3::Object"
values = ["${aws_s3_bucket.ai_corpus.arn}/"]
}
}
}
Dieses CloudTrail-Setup liefert Zugriffslogs pro Objekt. Führen Sie sie ins SIEM ein und Sie haben einen verteidigbaren Evidence-Trail für den Prüfer.
Schritt 5: Modell-Lifecycle und Change Management
Jede wesentliche Änderung an einem Produktionsmodell löst eine Evaluation aus. Ein Upgrade des Base Models von Claude Sonnet 4.5 auf Sonnet 4.6 ist eine Änderung. Ein Tausch des Embedding-Models ist eine Änderung. Ein neues Tool für einen Agent ist eine Änderung. Jede davon durchläuft:
- Einen Change-Record (PR gegen das Model-Registry).
- Ein aktualisiertes Impact Assessment, falls sich Zweck, Nutzer oder Datensensibilität geändert haben.
- Eine Regressions-Evaluation gegen einen gespeicherten Benchmark.
- Ein Canary-Deployment mit Monitoring.
- Freigabe und Rollout.
Den Eval-Schritt überspringen die meisten Teams. Bauen Sie ihn jetzt. Eine minimale Python-Harness mit LangSmith, Promptfoo oder eigenen Skripten reicht. Das Ziel: „Produziert das neue Modell weiterhin akzeptable Outputs auf unserem Golden Dataset?"
Schritt 6: Performance-Monitoring und Incident Response
A.9 deckt operatives Monitoring und Incident Handling ab. Sie brauchen:
- Quality-Metriken – Task Completion, Halluzinationsrate, User-Feedback-Signale.
- Safety-Metriken – Refusal Rate, Policy-Verstöße, Jailbreak-Erkennung.
- Performance-Metriken – Latenz, Token-Verbrauch, Kosten.
- Drift Detection – Verschiebungen der Input-Verteilung über die Zeit.
Verdrahten Sie all das mit demselben Observability-Stack, den Sie für reguläre Services nutzen. OpenTelemetry-Spans für jeden LLM-Call, getaggt mit Model-ID, (gehashter) User-ID, Input- und Output-Token-Counts und einem Quality-Signal.
Incident Response ist die andere Hälfte. Wenn ein Modell sich fehlverhält – schädlichen Output produziert, einen Prompt leakt, gegen eine Policy verstößt – brauchen Sie ein Runbook, das binnen Minuten greift. Es sollte wie jedes andere Incident-Runbook aussehen: On-Call-Engineer gepaged, Erst-Triage, Containment (Modell deaktivieren oder auf Fallback routen), Untersuchung, Postmortem. Das einzig AI-spezifische: Das Postmortem kann einen Dataset-Review und eine Re-Evaluation erfordern, bevor das Modell wieder online geht.
Schritt 7: Internes Audit
ISO verlangt ein internes Audit vor der Zertifizierung. Behandeln Sie es nicht als Formsache. Wählen Sie einen Engineer, der nicht im Implementierungsteam war, geben Sie ihm das Statement of Applicability und lassen Sie ihn jede anwendbare Kontrolle zum Nachweis zurückverfolgen. Überall, wo er keinen automatisierten Nachweis findet, haben Sie eine Lücke. Schließen Sie sie, dann buchen Sie das externe Audit.
Gap-Analyse-Checkliste
Eine kurze Checkliste, die wir in Kundenmandaten für die Triage nutzen:
- Inventar der in-scope-AI-Systeme existiert und ist maschinenlesbar
- Jedes System hat einen Owner und einen Kontakt
- Für jedes System liegt ein Impact Assessment vor
- Provenienz der Trainingsdaten ist dokumentiert
- RAG-Korpus hat Access Logs und Object Versioning
- Modelländerungen durchlaufen PR-Review mit OPA-Checks
- Prompt-/Response-Logs haben definierte Retention und Zugriffskontrolle
- Quality- und Safety-Metriken werden in Produktion überwacht
- Incident-Runbook für AI-spezifische Themen existiert und wurde getestet
- Lieferanten-Due-Diligence auf Model-Vendors ist dokumentiert
- DPO und Security-Teams zeichnen high-risk Systeme ab
- Internes Audit wurde mindestens einmal durchgeführt
Wenn heute weniger als 7 davon zutreffen, liegen 4–6 Monate Arbeit vor der Zertifizierungsreife.
Nächste Schritte
ISO 42001 ist deutlich greifbarer, als es beim ersten Lesen wirkt, besonders für Teams, die bereits ISO 27001 oder SOC 2 haben. Der Trick: die Kontrollen als Engineering-Probleme behandeln, nicht als Dokumentationsprobleme – Registry bauen, Policy-as-Code verdrahten, Nachweise automatisieren, und der Papierkram erledigt sich von selbst. Wenn Sie Unterstützung beim Aufbau der Maschinerie oder bei einer Gap-Analyse wünschen, nehmen Sie Kontakt auf.