ISO 42001 for Self-Hosted Inference: Clause to Artefact

Search for ISO 42001 and the first page of results is written for someone procuring an AI vendor: draft a policy, appoint a committee, choose a certification body. That reader's model runs elsewhere. Move inference in-house and the clause list widens, because artefacts a provider's certificate supplied become yours to produce.

One note, once: this is engineering guidance, not legal advice. And ISO standards are paywalled — everything quoted here comes from ISO's own free previews, which stop at clause 4.4 in 42001, the Introduction in 42005, and inside the contents page in 42006. Past those boundaries this article gives clause numbers and published titles, nothing more: an artefact filed against a title is a filing decision, not a compliance claim.

The Role You Take On When You Stop Calling an API

Provides or uses — not AI vendors, not model trainers. Clause 4.1 then goes further. "The organization shall consider the intended purpose of the AI systems that are developed, provided or used by the organization. The organization shall determine its roles with respect to these AI systems." You decide which role you occupy, and you write the decision down.

NOTE 1 offers a list — informative guidance in ISO drafting, not a requirement — enumerating six roles, not two: "AI providers, including AI platform providers, AI product or service providers; AI producers, including AI developers, AI designers, AI operators, AI testers and evaluators, AI deployers, AI human factor professionals, domain experts, AI impact assessors, procurers, AI governance and oversight professionals; AI customers, including AI users; AI partners, including AI system integrators and data providers; AI subjects, including data subjects and other subjects; relevant authorities, including policymakers and regulators."

Read that against a team serving open-weights models on its own cluster. It is not by default an AI provider — that bullet covers platform, product and service providers, which is what you become by serving the system onward. It is an AI producer: that sub-list names AI operators and AI deployers. Both "self-hosting makes you a provider" and "self-hosting changes nothing" misread the same note. Clause 4.3 then bounds it — the scope "shall be available as documented information" — and that scope statement decides how much of everything else you owe.

The Clause Map: How ISO 42001 Is Laid Out

ISO/IEC 42001:2023 is a first edition dated 2023-12 from ISO/IEC JTC 1/SC 42, normatively referencing ISO/IEC 22989:2022 for terminology. Three structural facts. First, the risk work appears twice. The contents page lists 6.1.2 AI risk assessment, 6.1.3 AI risk treatment and 6.1.4 AI system impact assessment under Planning — then 8.2, 8.3 and 8.4 under Operation, same three titles. The preview's readable body stops at 4.4, so neither clause's requirement text is quotable: the contents page gives the duplication, not what either clause demands. Which number an artefact is filed under is a filing decision, not an answer to the other.

Both annexes are normative. The contents page reads "Annex A (normative) Reference control objectives and controls" and "Annex B (normative) Implementation guidance for AI controls". Not how ISO 27001 works, where the guidance sits in the separate, non-certifiable ISO 27002. Here it is inside the certifiable standard — so if you run an ISMS, do not import the reflex. ISO 27001 without inherited controls covers the shared machinery.

The Statement of Applicability is defined, and it is not a checklist you complete. It is "documentation of all necessary controls and justification for inclusion or exclusion of controls", and organizations "may even exceed the list in Annex A with additional controls established by the organization itself." Exclusions need justification; additions are anticipated. The second half is what bites — a self-hosted stack holds controls over weight provenance and serving configuration no API consumer describes.

Click to zoom

Evidence Your Inference Stack Already Emits

Three streams, each running for operational reasons rather than for an audit — which is what makes them evidence. kube-apiserver audit records. The mechanics are in Kubernetes audit logs into a SIEM you operate, not repeated here; the AI-specific delta is *which objects you select*. What decides which model serves traffic is the Deployment referencing an image and a model path, and the ConfigMap carrying the serving arguments. Select those and you hold a dated, attributable record of every change to what is served, filed against the clause titled 8.1 Operational planning and control. Note the ceiling: an inference request never appears here — it reaches the model server, not the API server.

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # The objects that decide which model serves traffic.
  - level: RequestResponse
    namespaces: ["inference"]
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "apps"
        resources: ["deployments"]
      - group: ""
        resources: ["configmaps"]

vLLM's own metrics. vllm:request_success_total is a counter labelled with both finished_reason and model_name. vllm:cache_config_info is an Info-style metric "used for information about an instance that does not change - so it only needs to be observed at startup". vllm:lora_requests_info reports running_lora_adapters and waiting_lora_adapters as comma-separated label values — which fine-tuned variant served traffic, though vLLM's own docs call that encoding "quite misguided". Retained, these are the series filed against the clause titled 9.1 Monitoring, measurement, analysis and evaluation.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: aims-inference-evidence
  namespace: inference
spec:
  groups:
    - name: aims.evidence
      interval: 1m
      rules:
        # Retained under a name you own, not vLLM's.
        - record: aims:inference_requests:increase1h
          expr: |
            sum by (model_name, finished_reason) (
              increase(vllm:request_success_total[1h])
            )

        # aims_approved_model_info: an exporter over the approved-model
        # list in the repo holding the Statement of Applicability.
        - alert: UnapprovedModelServingTraffic
          expr: |
            sum by (model_name) (
              increase(vllm:request_success_total[15m])
            ) > 0
            unless on (model_name)
            sum by (model_name) (aims_approved_model_info)
          for: 5m

OpenTelemetry GenAI spans. gen_ai.operation.name and gen_ai.provider.name are the two attributes at requirement level Required on an inference span, and the span name convention is the operation name followed by the requested model. Enough to reconstruct which operation hit which model and when — without a word of the conversation. That restraint is deliberate, and easily undone.

Model Provenance and Change Control You Can Prove

Two tools, two artefacts, and the gap between them is where writing on this subject goes wrong. Sigstore's model_signing covers the weights: it records the signed model as an in-toto statement whose subjects are "a list of (file path, digest) pairs", under predicate type https://model_signing/signature/v1.0, in a DSSE envelope inside a Sigstore bundle. Verification makes it evidence: the tool will "compute the model's file hashes again to compare against the signed ones", so a tampered weight file fails, not just a tampered signature. And "signing events are recorded to Sigstore's append-only transparency log" where a verifier checks a proof of inclusion — a record your administrators cannot quietly rewrite. The SBOM, Sigstore and admission control argument, applied to weights.

# Per-file digests over the directory: what gets signed.
model_signing digest ./models/llama-3.1-8b-instruct

# sigstore is the default method. --use-ambient-credentials is what
# makes it keyless off the CI workload's OIDC token; without it the
# CLI falls back to the interactive OIDC flow.
model_signing sign ./models/llama-3.1-8b-instruct \
  --use-ambient-credentials \
  --signature ./models/llama-3.1-8b-instruct/model.sig

# The identity constraints are the control: without them the
# check only proves somebody signed it.
model_signing verify ./models/llama-3.1-8b-instruct \
  --signature ./models/llama-3.1-8b-instruct/model.sig \
  --identity "https://github.com/example-org/model-release/.github/workflows/sign.yaml@refs/heads/main" \
  --identity-provider "https://token.actions.githubusercontent.com"

Kyverno covers the container image, and its docs contradict themselves on version. The overview lists ImageValidatingPolicy on policies.kyverno.io/v1 as "Stable (since v1.18)", the CEL-based types "introduced in v1.14 (April 2025)". The policy's own page carries a feature-state badge naming v1.19 — a docs-version marker, not a promotion date; on 1.18 the type is present and stable. What v1.19 changed is the legacy side: ClusterPolicy on kyverno.io/v1, which carried the older verifyImages rules, is now "Deprecated (v1.19), removed in v1.20".

apiVersion: policies.kyverno.io/v1
kind: ImageValidatingPolicy
metadata:
  name: model-server-image-provenance
spec:
  validationActions: [Deny]
  matchConstraints:
    resourceRules:
      - apiGroups: ['']
        apiVersions: ['v1']
        operations: ['CREATE', 'UPDATE']
        resources: ['pods']
  matchImageReferences:
    - glob: 'registry.example.com/inference/*'
  attestors:
    - name: ci
      cosign:
        keyless:
          identities:
            - subject: 'https://github.com/example-org/inference-images/.github/workflows/build.yaml@refs/heads/main'
              issuer: 'https://token.actions.githubusercontent.com'
  attestations:
    - name: sbom
      referrer:
        type: sbom/cyclone-dx
  validations:
    - expression: >-
        images.containers.map(image, verifyImageSignatures(image, [attestors.ci])).all(e, e > 0)
      message: 'image is not signed by the release workflow'
    - expression: >-
        images.containers.map(image, verifyAttestationSignatures(image, attestations.sbom, [attestors.ci])).all(e, e > 0)
  validationConfigurations:
    mutateDigest: true # pin to a digest, not a mutable tag
    verifyDigest: true
    required: true

Click to zoom

The Impact Assessment Is a Document, Not a Dashboard

ISO/IEC 42005:2025, "AI system impact assessment", is a first edition dated 2025-05 shipping an informative Annex A titled "Guidance for use with ISO/IEC 42001" — the join between the documents is written down. Its preview stops at the Introduction, so what follows is the contents page, not requirements. Clause 6, "Documenting the AI system impact assessment", files material under 6.4 Data information and quality, 6.5 Algorithm and model information (down to 6.5.5 Information on model development), and 6.6 Deployment environment (6.6.1 Geographical area and languages, 6.6.2 Deployment environment complexity and constraints). That is its filing structure — the shape an assessment takes, not a list of shalls. I have not read the clause bodies, and nor has whoever told you 42005 "requires" a deployment-environment section.

Fields your stack fills from artefacts it already holds:

• Model identity, and what actually served — name, version and per-file digests from the model_signing bundle with its transparency-log entry, plus vllm:request_success_total by model_name and vllm:lora_requests_info for the adapter: what ran, not what the design document said would run.
• Deployment environment — cluster, region, accelerator, quantization and serving arguments, from the two objects the audit overlay already versions and attributes.

And the fields no exporter fills: why the system exists, who it affects, which harms you considered and rejected, what you decided about those you accepted. 42005 ships an informative Annex C harms and benefits taxonomy for exactly that argument. A dashboard reports what happened; an impact assessment records what you decided would be acceptable beforehand, and by whom.

Where Self-Hosted AIMS Evidence Breaks

Telemetry is not a record. Recording rules under names you control, kept for a stated window, turn a scrape into documented information. A debugging sampler and fifteen days of retention do not.

Content capture is opt-in, and should stay opt-in. Five attributes on the GenAI inference span carry requirement level Opt-In, and all five are content-bearing: gen_ai.input.messages, gen_ai.output.messages, gen_ai.system_instructions, gen_ai.tool.definitions, gen_ai.prompt.variable. Nothing records conversation content by default, and turning capture on for better evidence collides with minimisation duties you already carry — see DPDP residency and on-prem PHI inference. Redact at the Collector, and redact correctly — the one configuration here where a wrong version is worse than none.

processors:
  attributes/genai-minimise:
    actions:
      # Four fixed content keys, matched exactly.
      - key: gen_ai.input.messages
        action: delete
      - key: gen_ai.output.messages
        action: delete
      - key: gen_ai.system_instructions
        action: delete
      - key: gen_ai.tool.definitions
        action: delete

      # The fifth is a templated namespace: telemetry carries
      # gen_ai.prompt.variable.user_name, never the bare key, so a
      # key-exact delete matches nothing.
      - pattern: ^gen_ai\.prompt\.variable\..*$
        action: delete

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes/genai-minimise, batch]
      exporters: [otlphttp/evidence]
    # Same processor again: content lands on events/logs where
    # spans lack structured attributes, so traces-only redacts
    # nothing.
    logs:
      receivers: [otlp]
      processors: [attributes/genai-minimise, batch]
      exporters: [otlphttp/evidence]

Both comments describe silent failures. An entry whose key is the bare string gen_ai.prompt.variable deletes nothing, logs nothing and raises no error, while every prompt-template variable reaches the evidence store and whoever wrote the rule believes it scrubbed. And the conventions state that structured attributes are "supported on events (or logs) and may not yet be supported on spans", so redaction attached only to traces leaves the same content intact one pipeline over. A minimisation control that quietly does nothing is a false assurance you repeat to an auditor.

The conventions are Development, not Stable, and they moved. The GenAI semantic conventions have left the main OpenTelemetry semantic-conventions repository for a dedicated one, and the old page says so: "This page has moved and is no longer maintained in this repository." A pipeline pinned there stops tracking the spec without failing. Same caution on the vLLM metric names — vLLM's design document carries a Deprecated Metrics section. Version the mapping in Git and treat both as current-release facts, not interfaces.

Scope drift. The certificate names a scope. Meanwhile a team adds a model, a cluster, a fine-tune, an agent that calls tools, and nothing objects. That is what the alert above is for: cheaper to be told an unapproved model_name is serving traffic than to find the gap at a surveillance audit.

Reading an AIMS Certificate at Clause Level

ISO/IEC 42006:2025 — "Requirements for bodies providing audit and certification of artificial intelligence management systems", first edition 2025-07 — is the standard your certification body is held to. Its preview stops inside the contents page, so the published text yields titles — still informative. In the body, 9.1.3 is Scope of certification, 9.1.4 is Determining audit time, and 9.6.5 is Suspending, withdrawing or reducing the scope of certification — a scope can move after issue. Annex A, titled Audit time, is marked normative, so audit time follows a normative method rather than the body's discretion alone — which is not the same as a fixed duration, and the preview does not carry the method.

For requirement text you must go to the draft. ISO/IEC FDIS 42006:2025 — the final draft, not the published standard — has a longer preview carrying clause bodies. Three things from it, every one the draft:

• In the draft, 7.1.2 requires the body to "define the competence requirements for each certification function", Table 1 splitting knowledge and skills across three: application review, certification decision, and auditing.
• In the draft, 7.1.3.3.1 states that "The certification body audit team shall have knowledge of the legal obligations that apply to artificial intelligence" — and in Table 1 that row is marked across all three functions, not only the auditing one.
• In the draft, 5.3.2 requires the body to demonstrate insurance "or an alternative mechanism" covering personal injury, property damage and financial loss "in proportion to the turnover (i.e. annual gross revenue) of the clients under audit or certification".

The labelling is not pedantry: draft and published text differ in the headings themselves — the FDIS titles 7.1.3 "Determination of specific technical competence requirements" where the published contents page has "Specific technical competence requirements". Where the wording moved, the requirement may have moved with it.

Three questions follow. What scope is printed on the certificate — the inference platform, or a governance function above it? When would the body reduce it? And what does a certificate not do: under EU AI Act Article 40 a presumption of conformity attaches only to harmonised standards whose references are published in the Official Journal, and ISO 42001 is not one — what that leaves you is a separate argument.

Exit Ramps: Keeping the Evidence Portable

An AIMS accumulates a record over years. The design question is whether it survives a change of runtime, observability backend or certification body — all three change before the standard does.

• Keep the evidence store yours. OTLP into a collector you run, remote-write into storage you operate, audit records into your own SIEM. Evidence in a vendor's tenancy has a retention window that is a line item in their contract — see exit-cost modelling.
• Keep the provenance format open. in-toto statements, DSSE envelopes and Sigstore bundles are specifications with independent implementations, not a proprietary export: a bundle signed today verifies with somebody else's tool in five years.
• Keep the mapping in Git, beside the Statement of Applicability. One table: clause title, artefact, emitter, retention, owner. It is what a new certification body reads on day one, and why vLLM's metric names get projected through recording rules under names you chose — swapping runtimes then rewrites one rule file, not the mapping. Held in a GRC product's schema, that product has quietly entered your AIMS scope.

The Long Game: A Control Set That Outlives the Model

Certification is a cycle, not an event: surveillance and recertification are clause titles in ISO/IEC 42006, and your body sets the periods. The horizon is longer anyway — 42001 is a first edition, 42005 and 42006 arrived in 2025, harmonised standards under the AI Act are still being written. Each will be revised while evidence you collect now sits inside its retention window.

Which is the argument for anchoring the control set to artefacts rather than prose. A model generation lasts months; a clause-to-artefact table anchored to signed digests, retained series, audit records and a scope statement in Git survives a model swap, a runtime swap and a standard revision, because what changes is the mapping, not the evidence. It is why the production vLLM platform you run for latency also makes the management system provable, as SOC 2 on infrastructure you own compounds. Build the evidence layer as infrastructure and each audit is cheaper than the last; buy it as a product and it resets whenever the product, the provider or the standard does.