Iso-42001 on lo0 — Tech Blog

Virtual keys, budgets and limits in LiteLLM: the layer that decides who gets the GPU, and the four things the documentation gets wrong

Tue, 08 Sep 2026 07:30:00 +0200

Third article in the operational track of the control layer. The pair with Langfuse covered observability, and day 2 of the proxy covered availability. Here it is governance: who can call, which model, how much and on what budget. The economic model behind those figures is in FinOps and multi-tenancy with LiteLLM.

TL;DR

On a platform running on your own GPUs there is no provider invoice to put consumption in order. Capacity is fixed, known and shared, so someone has to impose the allocation, and that someone is the gateway.

The hierarchy has six levels: organisation, team, team member, internal user, key and end customer, plus the project and tag scopes. Each level’s budgets are evaluated independently and all of them have to pass. They neither add up nor cancel each other out, with one exception.

The exception is in the code and it is the most important governance trap in the system. A key that belongs to a team suppresses the check of its owner’s personal budget, unless apply_user_budget_to_team_keys is enabled. A user with a hundred-euro cap who works with their team’s key spends whatever the team allows.

Rotating a key preserves its spend. /key/regenerate does an UPDATE on the same row changing the hash, so spend, max_budget and the budget window remain intact. It accepts a grace period, stored in a table of its own, and if the period’s format is wrong it is ignored without blocking anything.

The v3 limiter is already the default in 1.100.0, and you go back to the previous one with an environment variable. Its window is sliding, sixty seconds, anchored to the first request, and the counters are incremented with Lua scripts inside Redis using Redis’s own timestamp to close the race between replicas.

And four points where the official documentation does not match the code, verified against tag v1.100.0: an exhausted budget returns 429, not 400; the audited actions are six, not three; /key/info and /key/list are GET, not POST; and the v3 limiter carries a docstring saying it is not production-ready while it is the one loaded by default.

You are here: the gateway as an administrative boundary

Without this layer, an in-house inference platform has a single mode of operation: whoever knows the URL consumes. It works while there is one team. It stops working the day there are three, or the day someone connects an agent that fires twenty calls per interaction and wrecks everyone else’s time to first token.

The two questions this layer answers are different and have to be kept apart. The capacity one is instantaneous: how many requests and how many tokens per minute each consumer can push, so the fleet does not saturate and latency stays within the service agreement. The cost one is cumulative: how much each consumer has spent this month against its budget. They are configured in the same place, applied at different moments and fail in different ways.

The analogy: the building’s key ring

An office building hands out keys at three levels. The master opens everything and the building manager has it. The floor keys open a whole floor and each tenant company has one. And the office keys open one office.

Three properties of that system are the ones that matter here. A key is replaced without changing the lock of the whole building, and the tenant keeps their parking space and their electricity meter: that is rotation preserving the spend. A lost key is cancelled from the central panel without collecting anything physical: that is blocking from the interface. And the record of who took out each key and when lives in a separate book, which is what you show an inspector: that is the audit table.

The analogy breaks at one point, and that point is where this system’s governance flaw lives. In the building, having a floor key does not cancel the office’s consumption limit. In LiteLLM, it does.

The hierarchy, and the line that breaks it

The levels and their management endpoints:

Level	Endpoints	Budget
Organisation	`/organization/new`, `/organization/member_add`, …	`max_budget`
Team	`/team/new`, `/team/member_add`, `/team/block`, …	`max_budget`
Team member	`/team/member_add` with `max_budget_in_team`	Its own row in the budgets table
Internal user	`/user/new`, `/user/update`, …	`max_budget`
Key	`/key/generate`, `/key/update`, …	`max_budget`, `soft_budget`
End customer	`/customer/new`, and the parallel `/end_user/*` set	`max_budget`

The default behaviour is the right one for a multi-tenant platform: each scope carries its own counter and the check of each one is independent of the rest. A request passes if all of them pass.

And then there is this condition, which lives in the authorisation checks:

is_team_key = team_object is not None and team_object.team_id is not None
if is_team_key and general_settings.get("apply_user_budget_to_team_keys") is not True:
 return

Translated: when the key belongs to a team, the check of the budget of the user who owns that key returns without evaluating anything. The personal cap exists in the database, is visible in the interface, and is not applied.

For a deployment where personal budgets are decorative, it makes no difference. For one where the per-person cap is the control that was shown to someone as a guarantee that a user cannot overrun the platform, it is a hole. The line that closes it is one:

general_settings:
 apply_user_budget_to_team_keys: true

Virtual keys: the complete life cycle

The endpoints all exist and some of them are not where you expect:

Route	Method	What for
`/key/generate`	POST	Create
`/key/update`	POST	Modify
`/key/info`	GET	Query one
`/key/list`	GET	List
`/key/delete`	POST	Delete
`/key/regenerate`	POST	Rotate
`/key/block`, `/key/unblock`	POST	Suspend and reactivate
`/key/health`	POST	Check that key’s callbacks

The two marked in bold are GET, and several examples in the documentation suggest otherwise. /key/health is not what its name suggests either: it does not validate the key or its budget, it checks the logging callbacks associated with it.

There are many creation parameters, and these are the ones that govern:

curl -X POST 'https://gateway.interno/key/generate' \
 -H 'Authorization: Bearer sk-...' \
 -d '{
 "key_alias": "equipo-datos-notebooks",
 "team_id": "t-datos",
 "models": ["llama-70b", "qwen-30b"],
 "max_budget": 250,
 "budget_duration": "30d",
 "tpm_limit": 400000,
 "rpm_limit": 600,
 "max_parallel_requests": 8,
 "duration": "90d",
 "tags": ["produccion", "notebooks"]
 }'

Alongside those there are controls that are rarely used and solve specific problems: model_max_budget to set a per-model cap within the same key, model_tpm_limit and model_rpm_limit for the same thing with capacity, enforced_params to require certain keys to always arrive with given fields, allowed_routes so an application key cannot touch the management endpoints, and blocked to be born suspended.

How they are stored

A key’s hash is a single-pass hexadecimal SHA-256, with no salt and no derivation function:

hashed_token = hashlib.sha256(token.encode()).hexdigest()

The row lives in LiteLLM_VerificationToken, with the hash as primary key, and it contains the accumulated spend, the limits, the expiry, the allowed models and the rest of the configuration.

Two consequences to be clear about before an audit. The first is that this hash is not designed to resist a dictionary attack against the database, and the code itself acknowledges it in a comment about encryption key derivation, where it admits that a single-pass unsalted SHA-256 is not a derivation function and that moving to HKDF would be more defensible in an audit. The real mitigation is that virtual keys are generated with enough entropy, not the strength of the hash. The second is that LITELLM_SALT_KEY plays no part here: that variable encrypts the stored provider credentials, not the virtual keys.

There is a trap around that variable that takes down a whole deployment. If it is not defined, it falls back to the master key. Rotating LITELLM_MASTER_KEY without having first set your own LITELLM_SALT_KEY leaves every stored provider credential unreadable, and the failure does not block: it logs an error and returns null, so the symptom shows up as models that stop authenticating with no explanation. Setting LITELLM_SALT_KEY on day one, and never touching it, is one of the things that saves the most grief.

Rotation

/key/regenerate does not create a new key and delete the old one. It updates the same row changing the hash, so the accumulated spend, the maximum budget and the reset window are preserved. For a monthly chargeback this is exactly what you want: rotating mid-month does not zero the counter.

It also accepts a grace period, so the old key remains valid while consumers update:

curl -X POST 'https://gateway.interno/key/sk-vieja/regenerate' \
 -H 'Authorization: Bearer sk-...' \
 -d '{"grace_period": "24h"}'

The old hash is stored in a separate table with its revocation date. Without that parameter, revocation is immediate, and the default value can be set with LITELLM_KEY_ROTATION_GRACE_PERIOD.

A detail with teeth: if the period’s format is wrong, the system logs a warning and continues with no grace period. The rotation completes, the old key dies on the spot, and all that is left is a log line. In an automated rotation procedure, that combination of “carry on” and “warn in the log” is what produces the outage at three in the morning.

What exactly happens when a budget runs out

The code raises BudgetExceededError with status 429. The documentation says 400 in one place, and there the code wins. Its being a 429 has a practical implication: OpenAI clients retry automatically on a 429, so an exhausted budget turns into a retry storm against a gateway that is going to keep rejecting. Internal clients should distinguish the reason, which travels in the message.

The messages are templates and state the scope, the spend and the cap:

Budget has been exceeded! Key=<clave> Current cost: <gasto>, Max budget: <tope>
Budget has been exceeded! Team=<equipo> Current cost: <gasto>, Max budget: <tope>
ExceededBudget: User=<usuario> over budget. Spend=<gasto>, Budget=<tope>
ExceededBudget: End User=<cliente> over budget. Spend=<gasto>, Budget=<tope>
Budget has been exceeded! Organization=<org> ...
Budget has been exceeded! Tag=<etiqueta> ...

Two clarifications about the comparison. It is spend >= cap, with the equals sign included, so landing exactly on the cap already blocks. And the soft budget, soft_budget, blocks nothing: it only writes a log line when it is crossed. It serves to warn, not to contain, and building an alert on top of it is the right way to use it.

The rest of the rejections, with their codes:

Situation	Code	Behaviour
Budget exhausted	429	Message with scope, spend and cap
Expired key	401	It also deletes the cache entry, so the expiry takes effect across the whole fleet without waiting for the TTL
Model not allowed	403	Different error type depending on the scope: key, team, user, organisation or project
Blocked key	Generic exception	`Key is blocked. Update via /key/unblock if you're an admin.`

The last row is an inconsistency in the project worth knowing about: blocking raises an exception with no explicit type or code, while expiry and model access do carry them. Any alert that discriminates by error type will not see blocks the way it sees the rest.

A useful note about allowed models: the check accepts both the alias and the underlying model, so a key authorised for llama-70b can call it by its alias or by its real name with no additional configuration.

Capacity limits: the v3 limiter

This is the most significant silent change of the year in this layer. In 1.100.0, the limiter loaded by default is the third version. Going back to the previous one has to be asked for explicitly:

LEGACY_MULTI_INSTANCE_RATE_LIMITING=true

There is no flag to turn it on, only to turn it off. And it carries a contradiction worth knowing before trusting it: the file itself still opens with a comment saying it is under development and not production-ready, while it is the one running. The design is avowedly inspired by Envoy’s.

The window is sliding and lasts sixty seconds, configurable with LITELLM_RATE_LIMIT_WINDOW_SIZE. It is not an exact rolling log nor a clock-aligned window: it anchors to the first request and resets once the window size has elapsed from that moment. For one-minute limits, the difference from a calendar window shows up at the edges and rarely matters.

What does matter is Redis. The counters are incremented with Lua scripts executed inside Redis, using Redis’s own timestamp and not the pod’s, precisely so window resets are deterministic across replicas and to close the race between checking and counting. Without Redis, each pod counts on its own and the effective limit is multiplied by the number of pods. A limit of 600 requests per minute with five replicas is a limit of 3,000.

There is an inherent imprecision in the token limits that Redis does not solve. The number of output tokens is not known until the response finishes, so the limiter counts with an estimate before the call and reconciles afterwards. The possible excess is, per in-flight request, the difference between the estimate and the real figure. With high concurrency and long responses, that allows the cap to be exceeded within a window. To protect the fleet, the concurrent request limit (max_parallel_requests) is a more direct instrument than tokens per minute.

What the client sees

When limited, a 429 with the message giving the scope, the current limit, what is left and when it resets. And three headers: retry-after with the window size, that is 60 by default, plus rate_limit_type and reset_at.

On the success path, the informational headers use a nested format of their own:

x-ratelimit-api_key-remaining-requests
x-ratelimit-api_key-limit-tokens
x-ratelimit-team-remaining-requests

They are not the standard names x-ratelimit-limit-requests that OpenAI and compatibles emit, so a client expecting the usual format will find nothing. There is also an open issue about these headers being lost on streaming responses, which is most of an assistant’s traffic.

Identity: beyond the static key

Handing out keys by hand works with three teams and stops working with thirty. The two routes for connecting the gateway to corporate identity:

JWT. It is enabled with enable_jwt_auth and configured with the litellm_jwtauth block, which maps token fields to LiteLLM entities: the team comes from team_id_jwt_field, the user from user_id_jwt_field, the organisation from org_id_jwt_field. It supports dot notation for nested claims, automatic creation of users and teams with user_id_upsert and team_id_upsert, role-based access control with enforce_rbac, per-team model restriction with enforce_team_based_model_access, and several issuers at once. The issuer’s public key is cached with a TTL of 600 seconds by default.

general_settings:
 enable_jwt_auth: true
 litellm_jwtauth:
 team_id_jwt_field: "groups"
 user_id_jwt_field: "sub"
 user_email_jwt_field: "email"
 enforce_rbac: true
 enforce_team_based_model_access: true
 team_id_upsert: true

OIDC for the admin interface. With Keycloak you use the generic provider, and the variables are PROXY_BASE_URL, GENERIC_CLIENT_ID, GENERIC_CLIENT_SECRET, GENERIC_AUTHORIZATION_ENDPOINT, GENERIC_TOKEN_ENDPOINT, GENERIC_USERINFO_ENDPOINT, plus a set of attributes to map the identifier, the email, the name and the role, and GENERIC_ROLE_MAPPINGS_* to translate Keycloak groups into LiteLLM roles. Login is rate-limited and sessions have a TTL of their own.

For automatic provisioning there is SCIM in the enterprise version, with base /scim/v2, and deprovisioning a user blocks their keys and takes them out of the authentication cache. That part is not in the open tree, so it cannot be verified against the code.

This fits with the identity work already covered in hardening and secrets of the sovereign stack and in the article on MCP authentication with Keycloak, which uses the same issuer.

Audit: what gets recorded

The table is LiteLLM_AuditLog and its columns are what you would expect from a change log:

id, updated_at, changed_by, changed_by_api_key,
action, table_name, object_id, before_value, updated_values

It stores the previous value and the new one, and attributes the change to an actor and to the key it was made with.

Three clarifications the documentation does not capture well.

The actions are six, in the past tense: created, updated, deleted, blocked, unblocked and rotated. The documentation mentions three. That blocking, unblocking and rotation are actions in their own right is exactly what is needed to reconstruct a credential’s life cycle for an auditor.

The scope is wider than advertised. Besides teams, users, keys and models, changes to the proxy configuration and to the SSO configuration are audited. A change of identity issuer is recorded.

The default depends on the licence. The resolution order is litellm_settings.store_audit_logs, then the variable LITELLM_STORE_AUDIT_LOGS, and if neither is set, it stays enabled in enterprise and disabled in the open version. An OSS deployment that assumes there is an audit trail does not have one:

litellm_settings:
 store_audit_logs: true

Two more pieces for a serious chain of evidence. The actor attribution can be passed with the LiteLLM-Changed-By header, and its use is restricted by the key’s or the team’s configuration, so any caller cannot forge it. And the events can be shipped out with audit_log_callbacks and its S3 parameters, which is what allows depositing them in an immutable store with object lock.

That last part is what turns the record into evidence. The Postgres table is mutable by anyone with database access, and as of September 2026 it has no indexes, so querying it by date range over a long history will not be comfortable either.

What this demonstrates to an auditor, and what it does not

This is the part that decides whether the setup is good enough for a regulated customer. With everything above configured, the platform sustains without difficulty:

Access control via corporate identity, with onboarding and offboarding in the identity provider and not in the gateway, and with the role determining which models are reachable. Segregation between tenants, with independent counters per organisation, team and person. Traceability of administrative changes, with actor, time, previous value and new value, exportable to an immutable store. And demonstrable consumption limits, with the evidence of the rejection in the spend log.

What it does not cover, and has to be solved elsewhere:

The record of the interactions is not this. The audit table records configuration changes, not model calls. The calls are in the spend log and in the traces, and traces are best-effort, which is the discussion in the first article in the series.

The integrity of the record is not something Postgres provides. Without export to immutable storage, the evidence is only as strong as the database permissions.

The content of the prompts is a separate problem, with its own personal-data treatment and its own decision about whether it is stored, masked or not logged at all.

And a warning about the control that tends to be shown first: while apply_user_budget_to_team_keys is not enabled, the per-person cap is not being applied to team keys. Showing that field in the interface as proof of a control that is not executed is the kind of finding a competent auditor discovers. The complete control mapping is in ENS, ISO 42001 and the EU AI Act.

Checklist

apply_user_budget_to_team_keys: true if personal budgets have to be enforced.
LITELLM_SALT_KEY set on day one, different from the master key and never rotated lightly.
store_audit_logs: true explicitly, without trusting the default.
audit_log_callbacks towards an immutable store if an audit has to be sustained.
Redis mandatory if there is more than one replica, or the limits get multiplied by the number of pods.
max_parallel_requests per key, on top of the per-minute limits, to protect the fleet from a runaway agent.
allowed_routes on application keys, so they cannot reach the management endpoints.
soft_budget with an alert on top, understanding that it does not block.
Rotation with a verified grace_period, because an invalid format revokes on the spot.
JWT against Keycloak as soon as there are more than a handful of teams, with enforce_rbac and enforce_team_based_model_access.

Traps and things that are not what they look like

A user’s cap is not enforced. They are using a team key and apply_user_budget_to_team_keys is missing.

Clients retry in a loop against an exhausted budget. The code is 429 and the OpenAI libraries retry 429s automatically.

The soft budget has stopped nothing. It does not block, it only logs.

The per-minute limits are enforced at double or triple. There is no Redis, and each replica keeps its own count.

The client does not see the limit headers. The names are nested and proprietary, and in streaming there is an open issue where they get lost.

There is no audit log. It is an OSS deployment and the default there is disabled.

The models stop authenticating after rotating the master key. There was no fixed LITELLM_SALT_KEY, and the encrypted provider credentials can no longer be decrypted.

The rotation cut the service on the spot. The grace_period carried a format the system did not understand and it carried on without it.

Blocking a key does not fire the alert. It is raised as a generic exception, without the type that expiry and model access do carry.

Closing

The keys and budgets layer is the one that turns a shared URL into a platform with tenants. It is well solved in LiteLLM and has more depth than the documentation suggests, with per-model budgets inside a key, multiple budget windows, per-tag limits and rotation that preserves the history.

Out of the whole article, two things take the attention. The apply_user_budget_to_team_keys line, because it is the difference between having a control and believing you have one. And setting LITELLM_SALT_KEY, because its default turns a routine rotation of the master key into an outage that is hard to diagnose. Both are one line of configuration and both are discovered late.

Sources

LiteLLM, Virtual Keys (parámetros de creación, ciclo de vida, rotación): https://docs.litellm.ai/docs/proxy/virtual_keys.
LiteLLM, Budgets, Rate Limits (jerarquía, presupuestos por nivel, clientes finales): https://docs.litellm.ai/docs/proxy/users.
LiteLLM, JWT Token Auth (bloque litellm_jwtauth y todos sus campos): https://docs.litellm.ai/docs/proxy/token_auth.
LiteLLM, Audit Logs y administración múltiple (la cabecera LiteLLM-Changed-By): https://docs.litellm.ai/docs/proxy/multiple_admins.
LiteLLM, SCIM (aprovisionamiento automático, versión enterprise): https://docs.litellm.ai/docs/tutorials/scim_litellm.
LiteLLM, litellm/proxy/auth/auth_checks.py en la etiqueta v1.100.0 (la condición de apply_user_budget_to_team_keys y los mensajes de presupuesto agotado): https://github.com/BerriAI/litellm/blob/v1.100.0/litellm/proxy/auth/auth_checks.py.
LiteLLM, litellm/proxy/management_endpoints/key_management_endpoints.py en v1.100.0 (rutas, rotación sobre la misma fila, periodo de gracia): https://github.com/BerriAI/litellm/blob/v1.100.0/litellm/proxy/management_endpoints/key_management_endpoints.py.
LiteLLM, litellm/proxy/hooks/parallel_request_limiter_v3.py y litellm/proxy/hooks/__init__.py en v1.100.0 (el limitador v3 como valor por defecto, la ventana, los scripts Lua): https://github.com/BerriAI/litellm/blob/v1.100.0/litellm/proxy/hooks/parallel_request_limiter_v3.py.
LiteLLM, litellm/exceptions.py en v1.100.0 (BudgetExceededError con código 429): https://github.com/BerriAI/litellm/blob/v1.100.0/litellm/exceptions.py.
LiteLLM, litellm/proxy/common_utils/encrypt_decrypt_utils.py en v1.100.0 (LITELLM_SALT_KEY cayendo en la clave maestra, y el comentario sobre la derivación de claves): https://github.com/BerriAI/litellm/blob/v1.100.0/litellm/proxy/common_utils/encrypt_decrypt_utils.py.
LiteLLM, schema.prisma en v1.100.0 (LiteLLM_VerificationToken, LiteLLM_AuditLog, la tabla de claves deprecadas): https://github.com/BerriAI/litellm/blob/v1.100.0/schema.prisma.
LiteLLM, issue #27748 — cabeceras x-ratelimit-* perdidas en respuestas en streaming con el limitador v3: https://github.com/BerriAI/litellm/issues/27748.

Technical controls: the ENS × ISO 42001 × EU AI Act cross-mapping over the on-premise LLM architecture

Mon, 01 Jun 2026 06:30:00 +0200

Third post in the blog’s AI governance trilogy. The first, ISO/IEC 42001, broke down the certifiable management system. The second, EU AI Act, broke down the directly applicable legal regulation. This one covers the third framework that appears when the client is a Spanish public administration or an essential-services entity: the ENS (Esquema Nacional de Seguridad, Spain’s national security framework, Royal Decree 311/2022). The editorial challenge: triple compliance is not the arithmetic sum of three jobs; it is one single set of technical evidence labelled for three lenses. This post takes apart how that evidence is built, measure by ENS measure.

TL;DR

Royal Decree 311/2022 updated the Spanish Esquema Nacional de Seguridad (ENS), aligning it with NIS2 and with the modern cyber-threat landscape. It applies mandatorily to the entire Spanish public sector (central, regional and local administration, universities, autonomous bodies) and to suppliers that provide IT services to them. The framework defines 74 security measures organised into three blocks (organisational framework org, operational framework op, protection measures mp), three application categories (Basic / Medium / High) according to the assessment of five dimensions (Confidentiality, Integrity, Traceability, Authenticity, Availability), and an Annex II with the measure × category matrix that dictates what is required at each level. This post maps the technical measures relevant to LLM systems (those of the op block: planning, access control, operation, external services, continuity, monitoring; and those of the mp block: communications, applications, information, services) against Annex A of ISO/IEC 42001 and the operational articles of the EU AI Act (Arts. 9 to 15, 17, 72 and 73), and shows that the overlap is massive: a single technical artefact from the blog’s OSS stack, the OTel spans of tracing, the datasets versioned with DVC, the LLM Guard scanners, the guardrail decisions, the incidents of the retrain loop, simultaneously satisfies ENS measures, 42001 controls and AI Act articles, provided it is labelled with the correct codes from the moment it is captured. The editorial thesis: the difference between a system that passes all three audits and one that suffers three separate certifications is not budget, it is disciplined labelling and a common vocabulary. The post builds the master table of triple compliance, walks through the case of the multi-tenant chatbot for a High-category public administration as a live checklist, and closes with the five traps of triple compliance.

The analogy: the triple inspection of a critical building

A critical building, say the control centre of a regional electricity grid, a reference hospital, or a 112 emergency response centre, goes through three different inspections of the same physical elements:

The regional inspection reviews the planning permit, local fire regulations and accessibility under regional legislation.
The European inspection reviews CE marking of equipment and conformity with EU directives on energy efficiency.
The ISO quality inspection reviews processes and maintenance under a management standard.

All three inspectors look at the same fire detector hanging from the ceiling. The regional one wants to see the installation certificate with the installer company’s number; the European one wants to see the CE mark stamped on the casing; the ISO one wants to see the monthly maintenance record with signatures. There is only one detector. The evidence each inspector needs is different. If the building management team kept one folder per inspector, the installation certificate, the photo of the CE mark and the maintenance sheet would live in three places, and on audit day inconsistencies between the three folders would surface. The professional way to operate: one single file per asset, with tags pointing at the three sets of legislation.

The on-premise LLM system is that critical building. The OTel spans from tracing are the fire detector: a single technical piece that satisfies ENS measure op.exp.8 (activity logging), 42001 control A.8.2 (information to interested parties), and EU AI Act article 12 (record-keeping) provided the spans carry the correct metadata: traceparent propagated, gen_ai.* semantic conventions, WORM retention, PII redacted by LLM Guard Vault. Without consistent labelling from capture onwards, audit day produces three folders that do not add up.

The analogy matters because it bounds an architectural decision: labelling evidence is not a compliance topic, it is a technical design topic. It is decided when the OTel Collector is set up, when the Vault schema is designed, when the format of retrain incidents is agreed. Postpone it, and the debt compounds.

ENS in 15 seconds

Regulatory framework: Royal Decree 311/2022, of 3 May, in force since 5 May 2022. It replaces RD 3/2010. It implements the update of the Esquema with NIS2, the NCS (Estrategia Nacional de Ciberseguridad, Spain’s national cybersecurity strategy) and the post-2020 reality.
Mandatory scope: the Spanish public sector (central, regional and local administration, universities, autonomous bodies), public-sector entities with their own legal personality, and private suppliers that provide IT services to them (a very important clause in consultancy: if your client is the Junta de Andalucía, the Comunidad de Madrid or Bilbao City Council, you fall under ENS by contractual extension).
Operational applicability in 2026: any AI project financed with NextGenerationEU European funds, plus any project with public data, plus any integration with electronic administrative systems.
Categorisation: three categories, Basic / Medium / High, according to the assessment of the five dimensions (C, I, T, A, D). The category dictates which measures are required and at what depth.
Certification: for Medium and High categories, a formal audit by an accredited body. For Basic category, self-assessment. Certification cycle is biennial.
Authority: the Centro Criptológico Nacional (CCN-CERT, Spain’s national cryptologic centre), part of the CNI intelligence agency. It maintains the ens.ccn.cni.es portal with the STIC guides (800 series).
Total number of measures: 74, organised into three blocks, plus Annex II with the measure × category matrix that defines what applies at each level.

The five security dimensions and their AI mapping

To classify the system as Basic / Medium / High, the ENS requires each dimension to be rated on a scale (not applicable / low / medium / high). The final category is the highest of the five. For LLM systems, the typical rating:

Dimension	Meaning	Typical LLM rating	Reason
C Confidentiality	Information protected from disclosure	Medium-High	PII in prompts, secrets in context, intellectual property in the RAG corpus
I Integrity	Information protected from modification	Medium-High	An altered RAG corpus produces false answers; a manipulated model produces directed bias
T Traceability	Actions attributable to users	High	Audit: who asked what, when, what were they answered, which dataset trained the model?
A Authenticity	Identity of users and origin of information	Medium	Robust authentication plus identification of chunks by source
D Availability	Service available when needed	Medium	Typical SLA, known recovery time

Typical result: Medium category for internal LLM systems with no sensitive data, High if they handle PII or regulated sectoral data (health, tax, judicial). The category triggers different controls.

The three blocks of measures

Organisational framework (org), 4 measures that always apply, transversal:

org.1 Security policy
org.2 Security regulations
org.3 Security procedures
org.4 Authorisation process

Operational framework (op), 31 measures in 6 subgroups, these are how it is operated:

op.pl Planning (5)
op.acc Access control (6)
op.exp Operation (10)
op.ext External services (4)
op.cont Service continuity (4)
op.mon System monitoring (2)

Protection measures (mp), 39 measures in 7 subgroups, these are what is protected:

mp.if Facility protection (7)
mp.per Personnel management (4)
mp.eq Equipment protection (4)
mp.com Communications protection (4)
mp.si Information media protection (5)
mp.sw Application protection (2)
mp.info Information protection (6)
mp.s Service protection (4)

Of those 74, roughly 25 matter operationally for LLM systems. The rest are either transversal (policies, personnel management, physical facilities) or specific to other layers (telephony, physical media in the literal sense). The rest of this post drops down to the 25 relevant ones.

Technical mapping: key ENS measures × 42001 controls × EU AI Act articles

What follows, by ENS subgroup, are the measures relevant to LLM with their cross-mapping. The Technical evidence from the blog column points to the operational artefact that materialises the measure.

Operational framework — planning (`op.pl`)

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`op.pl.1` Risk analysis	Formal periodic analysis, MAGERIT or OCTAVE methodology	A.5.4 (alignment with AI risk treatment)	Art. 9 Risk management	Risk document linked to the LLMOps pipeline + evals metrics
`op.pl.2` Security architecture	Architecture documentation, layer segregation	A.4.2 documented info	Art. 15 (technical robustness)	Seven stack layers + seven deployment phases
`op.pl.3` Acquisition	Acquisition criteria that include security	A.10.3 suppliers	Art. 53 (GPAI obligations)	OSS vs hyperscalers lock-in analysis + copyright analysis
`op.pl.4` Sizing	Capacity to support the expected load	A.4.5 system resources	Art. 15 (consistent performance)	Five maturity levels + GPU capacity study
`op.pl.5` Certified components	Preference for certified components	A.10.5 third parties	Art. 53 + Art. 15	OSS inventory with licence analysis + supply chain audit (cosign + SLSA)

Operational framework — access control (`op.acc`)

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`op.acc.1` Identification	Unique identification of users and processes	A.3.2 roles	Art. 14 (human oversight)	Keycloak / OIDC + JWT with unique `sub` + `user_id_hashed` in OTel spans
`op.acc.2` Access requirements	Need to know, authorisation	A.9.4 intended use	Art. 14 + Art. 26 (deployer)	Per-tenant allowlist in the AI Gateway + RBAC over adapters
`op.acc.3` Segregation of duties	No incompatible accumulation	A.3.2 + A.3.3	Art. 17 (QMS)	Separate roles: AI lead / data steward / SRE / DPO
`op.acc.5` Authentication	Proportionate mechanism, MFA at High	A.4.4 tooling	Art. 14	Keycloak + WebAuthn + mandatory MFA for High category
`op.acc.6` Local access	Protection against physical access	mp.if + A.4.5	Art. 15 (cybersec)	Cluster in a datacenter with physical control (strictly outside the blog’s scope)
`op.acc.7` Remote access	VPN, encryption, endpoint control	A.4.5 + mp.com	Art. 15	WireGuard / Defguard + mTLS for administrative access to the cluster

Operational framework — operation (`op.exp`)

This is the densest subgroup and the one that overlaps most with the LLM architecture.

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`op.exp.1` Asset inventory	CMDB with all system components	A.4 resources	Art. 49 (EU DB registration)	Inventory of models, adapters and datasets in a CMDB + Helm tags + OpenLineage lineage
`op.exp.2` Security configuration	Documented hardened configuration	mp.eq + A.4	Art. 15	vLLM, KServe and Cilium configurations documented in GitOps + CIS Benchmarks for K8s
`op.exp.3` Configuration management	Traceable and authorised changes	A.6.2 + A.4.2	Art. 9 + Art. 15	GitOps with Argo CD / Flux + mandatory PR review + immutable tags
`op.exp.5` Change management	Changes planned, authorised, recorded	A.6.2.6 + clause 8	Art. 9 (lifecycle) + Art. 72 (post-market)	CI/CD pipeline from the LLMOps post + change advisory board
`op.exp.6` Protection against malicious code	Antivirus, EDR, malware control	mp.eq	Art. 15 (cybersec)	Image scanning (Trivy / Grype) + container runtime security (Falco / Tetragon)
`op.exp.7` Incident management	Detection → response → recovery procedure	A.3.3 + clause 10	Art. 73 (serious incident reporting)	Incident-driven retrain + CCN-CERT channel + notification template
`op.exp.8` Activity logging	Auditable logs, minimum 2-year retention at High category	A.8.2	Art. 12 + Art. 19	OTel GenAI tracing + Tempo / Jaeger + Loki
`op.exp.9` Incident management records	Incident log with root cause and corrective action	clause 10	Art. 73	Ticketing system + structured retrain incident events
`op.exp.10` Record protection	Immutable logs, cryptographic integrity, guaranteed retention	A.8.2 + A.4.2	Art. 12	WORM storage (Ceph + immutable bucket) + log signing (sigstore) + 24-36 month retention
`op.exp.11` Cryptographic keys	Key lifecycle management, HSM at High category	mp.info.4	Art. 15	HashiCorp Vault / SOPS + HSM (Yubico, AWS KMS on-prem) for High category

Operational framework — external services (`op.ext`)

Critical when the system integrates GPAI (Llama, Mistral) hosted elsewhere, or when the deployer is a third party.

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`op.ext.1` Contracting external services	Contract with security clauses, SLA, right to audit	A.10.3 suppliers	Art. 25 + Art. 53	Contract with ENS clauses + annual audit review + Cloud Act analysis
`op.ext.2` Alternative means	Plan B if the supplier goes down	A.4.5 + clause 6	Art. 15 (resilience)	Multi-cluster with failover + qualified alternative GPAI (Llama→Mistral→Qwen)
`op.ext.3` Supply chain protection	Assessment of suppliers and sub-suppliers	A.10 + clause 6	Art. 53 + NIS2 supply chain	SBOM + cosign + SLSA + continuous vulnerability scanning
`op.ext.4` System interconnection	Interconnection agreements, secure gateways	mp.com + A.4.5	Art. 15	API Gateway with mTLS + JWT signing + rate limiting + WAF

Operational framework — continuity (`op.cont`)

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`op.cont.1` Impact analysis	BIA per system	A.5.5 (impacts on individuals)	Art. 9 (risk management)	Documented BIA with RPO / RTO per system
`op.cont.2` Continuity plan	Documented DRP, RTO/RPO	clause 6 + A.4	Art. 15 (resilience)	DRP + Velero K8s backups + DVC datasets in a secondary bucket
`op.cont.3` Periodic testing	Drills at a defined frequency (annual at High category)	clause 9 (evaluation)	Art. 15	Annual game-day with a simulated disaster + recovery stopwatches
`op.cont.4` Alternative means	Capacity to continue with degraded means	clause 6 + A.4.5	Art. 15	Secondary cluster in a different datacenter + reserved GPU pool + replicated datasets

Operational framework — monitoring (`op.mon`)

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`op.mon.1` Intrusion detection	IDS/IPS over network and applications	A.9.2 use	Art. 15 (cybersec)	Guardrails as a semantic WAF + LLM Guard PromptInjection + Tetragon eBPF runtime
`op.mon.2` Metrics system	Measurable operational metrics, auditable dashboard	clause 9 (performance evaluation)	Art. 72 (post-market monitoring)	Prometheus + VictoriaMetrics + Grafana + Langfuse dashboards
`op.mon.3` Surveillance (High category)	24×7 monitoring with alerting	clause 9 + clause 10	Art. 72 + Art. 73	SOC with SIEM alerts (Wazuh, OpenSearch, Vector + custom) + on-call rotation

Protection measures — communications (`mp.com`)

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`mp.com.1` Secure perimeter	Firewall, segmentation, DMZ	A.4.5	Art. 15	Cilium NetworkPolicy + Calico + ingress controllers with WAF (mod_security)
`mp.com.2` Confidentiality protection	Encryption in transit (TLS 1.2+ mandatory, 1.3 recommended)	A.4.5	Art. 15	TLS 1.3 mandatory + cert-manager + Let’s Encrypt or an internal CA
`mp.com.3` Integrity and authenticity protection	Encryption + origin authentication	A.4.5 + A.4.4	Art. 15	Intra-cluster mTLS + JWT signing at the gateway + checksums on artifacts
`mp.com.4` Flow separation	Segmentation of mgmt vs production vs external traffic	A.4.5	Art. 15	Cilium policies + network namespaces + east-west / north-south segregation

Protection measures — applications (`mp.sw`)

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`mp.sw.1` Application development	Secure SDLC, code review, SAST/SCA	A.6.2.3 responsible design	Art. 9 + Art. 15	Forgejo CI with SAST (Semgrep, CodeQL) + SCA (Trivy, Grype) + mandatory PR review
`mp.sw.2` Acceptance and go-live	Acceptance tests, eval gates before production	A.6.2.5 V&V	Art. 9 + Art. 15	Eval gates from the evals post + canary deploy + pre-go-live metrics

Protection measures — information (`mp.info`)

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`mp.info.1` Personal data	GDPR compliance + technical and organisational measures	A.5.5 + A.7.6	Art. 10 + Art. 26	LLM Guard Vault + Presidio + minimisation in RAG corpus curation
`mp.info.2` Information classification	Labelling by level (public / internal / confidential / restricted)	A.7.2 data	Art. 10	Schema contracts from data versioning with a `classification` field
`mp.info.3` Encryption	At-rest minimum at Medium category, High category with HSM	A.4.5 + mp.eq	Art. 15	LUKS / dm-crypt on disks + encryption in the Ceph bucket + keys in Vault
`mp.info.4` Electronic signature	Documents signed with a valid certificate (Medium category and above)	A.8.2	Art. 12	Log signing with sigstore + signing of published models with cosign
`mp.info.5` Timestamps	Qualified timestamp for temporal integrity (High category)	A.8.2	Art. 12	Timestamping with a qualified TSA + RFC 3161 on critical events
`mp.info.6` Document cleaning	Removal of unauthorised metadata, anonymisation	A.7.6 + A.5.5	Art. 10	LLM Guard Anonymize (input) + Sensitive (output) + Vault with TTL

Protection measures — services (`mp.s`)

ENS measure	Requirement	42001 control	AI Act article	Technical evidence
`mp.s.1` Email	Anti-spam, anti-malware, optional encryption	A.4.5	—	Outside the direct LLM scope
`mp.s.2` Protection of web services and applications	WAF, hardening, vulnerability management	A.9.2 + mp.com	Art. 15 (cybersec)	AI Gateway (LiteLLM / Envoy AI / Kong AI) with policies + ModSecurity + Cloudflare-like
`mp.s.3` Protection against denial of service	Rate limiting, anti-DDoS, capacity planning	A.4.5 + A.9.2	Art. 15	Rate limiting at the gateway + token quotas + circuit breakers
`mp.s.4` Protection against external threats (High category)	Advanced monitoring, threat intel	A.9.2 + clause 9	Art. 15 + Art. 72	Guardrails, 4 lines + advanced LLM Guard scanners + threat intel feed (CCN-CERT MISP)

Master table of triple compliance — the 25 relevant controls consolidated

The key reading of the table: one row per technical capability. The organisation does not build three solutions for “activity log” (ENS) + “information to interested parties” (42001) + “record-keeping” (AI Act). It builds one single piece of OTel tracing with the correct metadata and presents it labelled for whichever inspector is asking.

The labelling typically materialises in three mechanisms:

Tags in the CI/CD pipelines: every artefact produced carries tags ens:op.exp.8, iso42001:A.8.2, aia:art.12 in its Helm / Argo CD metadata.
Semantic OTel attributes: gen_ai.compliance.ens = "op.exp.8", gen_ai.compliance.iso42001 = "A.8.2" as custom attributes on the relevant spans (not standard yet, but useful internally).
A mapping table in the wiki: a living document of ENS measure → 42001 control → AI Act article → technical runbook + owner + last verification. This is the artefact the auditor consults.

Applied case: multi-tenant chatbot for public administration

A variant of the multi-tenant chatbot from the forensic post, where the client is now a Spanish regional government offering citizen assistance on administrative procedures. The three lenses:

ENS: applies mandatorily, being public sector plus a service to citizens. Category High (citizens’ PII plus a critical service).
ISO 42001: the regional government requires certification from the supplier as a contractual condition.
EU AI Act: if the chatbot informs about procedures but decides nothing on the citizen’s behalf, it is limited risk (Art. 50 transparency). If it automates decisions (admission to a programme, refusal of a benefit), it is high risk.

We assume high risk for the most demanding walkthrough.

The chatbot’s 25 key technical capabilities consolidated

Technical capability	ENS	42001	AI Act	Status
Robust citizen authentication	`op.acc.5` (MFA High category)	A.4.4	Art. 14	Cl@ve + digital certificate + WebAuthn
Unique tenant + user identification	`op.acc.1`	A.3.2	Art. 14 + 26	JWT with `tenant_id` + `user_id_hashed`
Per-tenant allowlist	`op.acc.2`	A.9.4	Art. 14	LiteLLM Proxy with policies + Envoy filter
Encryption in transit, mTLS	`mp.com.2-3`	A.4.5	Art. 15	TLS 1.3 + cert-manager + intra-mesh mTLS
Encryption at rest + HSM keys	`mp.info.3` + `op.exp.11`	A.4.5	Art. 15	LUKS + Vault + Yubikey or nCipher HSM
PII anonymisation input/output	`mp.info.1 + .6`	A.7.6	Art. 10	LLM Guard Vault + Presidio + Llama Guard 4
Traceable logging + WORM	`op.exp.8 + .10`	A.8.2	Arts. 12 + 19	OTel + Tempo + Loki + Ceph WORM 36 months
Log signing + timestamps	`mp.info.4 + .5`	A.8.2	Art. 12	sigstore + qualified TSA (FNMT)
Runtime threat detection	`op.mon.1 + mp.s.4`	A.9.2	Art. 15	Guardrails, 4 lines + Tetragon + Falco
Operational metrics dashboard	`op.mon.2`	clause 9	Art. 72	Prometheus + Grafana + Langfuse
24×7 SOC surveillance	`op.mon.3` (High category)	clause 9	Art. 72	SOC with SIEM + on-call rotation
Incident management with notification	`op.exp.7 + .9`	clause 10	Art. 73	Incident-driven retrain + CCN-CERT channel
CI/CD pipeline with eval gates	`mp.sw.1 + .2`	A.6.2.3-5	Arts. 9 + 15	Forgejo CI + Semgrep + Trivy + DeepEval gates
Backups + DRP	`op.cont.1-4`	clause 6 + A.4	Art. 15	Velero + DVC datasets in a secondary bucket + annual game-day
Systematic risk analysis	`op.pl.1`	A.5 + cl.6	Art. 9	MAGERIT + FRIA + ISO/IEC 23894 impact assessment
Documented secure architecture	`op.pl.2`	A.4.2	Art. 15	Seven layers + seven phases
Supplier management	`op.ext.1 + .3`	A.10.3	Art. 53	Contracts with ENS clauses + SBOM + Cloud Act analysis per GPAI
Certified components	`op.pl.5`	A.10.5	Art. 53	Inventory with licence + supply chain audit
Configuration hardening	`op.exp.2 + .3`	A.4 + A.6	Art. 15	CIS Benchmarks for K8s + GitOps + immutable tags
Protection against malicious code	`op.exp.6`	mp.eq	Art. 15	Image scanning + runtime security
Asset inventory	`op.exp.1`	A.4	Art. 49	CMDB + Helm tags + OpenLineage
Network segmentation	`mp.com.4`	A.4.5	Art. 15	Cilium NetworkPolicy + namespaces
Rate limiting + anti-DoS	`mp.s.3`	A.4 + A.9	Art. 15	LiteLLM rate limit + token quotas
Information classification	`mp.info.2`	A.7.2	Art. 10	Schema contracts with a `classification` field
Transparency towards the user	—	A.9.4	Art. 50	UI banner + disclaimer in responses

Result: the 25 technical capabilities are common to all three frameworks. Only two require evidence for a single framework in isolation: mp.info.4-5 (qualified signature and timestamp, ENS-specific, not required so literally by 42001 or the AI Act) and Art. 50 (transparency banner, AI Act-specific). The rest are the same technical piece with three labels. A well-organised team certifies all three in series with only marginal extra work between the second and the third.

The five traps of triple compliance

Trap 1 — Measuring the same thing three times. Inexperienced teams create three separate dashboards (one for ENS, another for 42001, another for the AI Act) with the same metrics duplicated. The result: three sources of truth that diverge, three audit teams with different figures, three corrections to resolve one and the same deviation. The rule: one metric, three labels.

Trap 2 — Losing the control that covers only one framework. mp.info.4 (electronic signature) is ENS-specific and gets forgotten while the team is focused on 42001 + AI Act. On ENS audit day, the gap surfaces. Solution: the master table keeps every control visible, orphans included.

Trap 3 — Bias towards the most recent framework. The team spends 80% of the effort on the AI Act because it is the newest, and forgets the rigour of the ENS, which has been in force for 14 years. The ENS measures are technically more prescriptive than the AI Act (which is legally stricter but leaves implementation freedom). Moving up a level to ENS High category introduces specific requirements (HSM, qualified timestamps, 24×7 surveillance) that the AI Act does not spell out. The ENS deserves respect for its technical detail, not for its legal stature.

Trap 4 — Mixing ENS Medium and High categories. The Annex II matrix of RD 311/2022 dictates which measures are required and at what depth per category. Moving from Medium to High changes 15-20 controls, which is not marginal. The category is decided at the start of the project and documented; changing it halfway forces a complete re-audit.

Trap 5 — Audit fatigue inside the technical team. Three audits a year (biennial ENS + annual 42001 surveillance + ad-hoc AI Act by the authority) exhausts the team if they are not planned and if evidence is not reused. The professional approach: one single quarterly internal audit cycle with rotating scope, producing evidence consumable by all three external auditors. The difference between 30 days a year and 90 days a year lost to audits is the discipline of single evidence plus disciplined labelling.

What we have not covered (upcoming posts)

The CCN-CERT STIC series applicable to AI systems: STIC 800-159 (web service operation), STIC 800-105 (cryptography), STIC 800-150 (cloud environments). Each adds technical detail on how to materialise the ENS measures.
The GDPR as a fourth lens: privacy and personal data protection. It overlaps with mp.info.1 and with A.7.6 of 42001 plus Art. 10 of the AI Act. Material for an analogous pass over LOPDGDD + GDPR + AEPD against the three frameworks seen here.
Concrete templates of technical evidence with minimum fields: a log entry with every attribute required by the three lenses, an incident report with every field demanded by the three frameworks, a unified ENS / AI Act / 42001 declaration of conformity.
The NextGenerationEU funds case: specific compliance requirements for AI projects financed with European funds, where the AI Act + ENS are contractually mandatory.
42001 + ENS High category combined with DORA (Digital Operational Resilience Act, Reg. 2022/2554) for Spanish financial entities deploying AI.

References

RD 311/2022 — por el que se regula el Esquema Nacional de Seguridad. https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191.
CCN-CERT — Portal ENS: https://ens.ccn.cni.es/. Guías STIC Series 800.
CCN-STIC 803 — Valoración de los sistemas y de la información. Metodología para asignar categoría ENS.
CCN-STIC 804 — Esquema Nacional de Seguridad. Guía de implantación.
CCN-STIC 824 — Informe del estado de seguridad. Plantilla para auditoría ENS.
MAGERIT v3 — Metodología de Análisis y Gestión de Riesgos del Ministerio de Asuntos Económicos. Insumo de op.pl.1.
ISO/IEC 42001:2023 — Sistema de gestión IA. Norma certificable que solapa con ENS.
Regulation (EU) 2024/1689 (EU AI Act) — texto consolidado.
NIS2 (Dir. 2022/2555) — directiva de ciberseguridad que el ENS implementa parcialmente en su versión 2022.

ISO/IEC 42001: the operations manual for the AI system — how the AIMS fits over the on-premise LLM platform described in this blog

Mon, 01 Jun 2026 06:00:00 +0200

This post closes an asymmetry the blog had been accumulating: we have described in detail the technical platform (seven stack layers, seven deployment phases, five maturity levels), the operational pipeline (six LLMOps stages), the data pieces (corpus curation, versioning), the eval / safety pieces (evals, guardrails, LLM Guard) and the observe pieces (OTel GenAI tracing). What had not appeared is the governance layer a regulated client asks for on top of all that. ISO/IEC 42001 is that layer.

TL;DR

ISO/IEC 42001:2023 is the first certifiable international standard that defines how an AI system is managed. It is not a technical standard (it does not say “use this inference engine” or “this safety threshold”): it is a management standard, a cousin of ISO 27001 and ISO 9001. From both it inherits the Annex SL structure, seven mandatory clauses running through context, leadership, planning, support, operation, performance evaluation and improvement, and it adds an Annex A with 38 AI-specific controls in 9 sections: policies, internal organisation, resources, impact assessment, lifecycle, data, information to interested parties, use, third parties. The thesis of this post is that the technical architecture described in this blog directly covers between 60% and 80% of the A controls with no extra work. The LLMOps pipeline materialises A.6, versioning and curation materialise A.7, guardrails and evals materialise A.9, OTel tracing materialises A.8. The rest is governance discipline that does not appear in the code (a written AI policy, impact assessments per system, a stakeholder register, role decisions between provider/producer/customer, mandatory documentation), and that is precisely what separates a real certification from performative compliance. The post maps the correspondence control by control, cross-references it with the EU AI Act (seven articles directly aligned with 42001: 9, 10, 11, 12, 13, 14, 17), with NIS2 (asset register, incident notification, supply chain) and with ENS (Esquema Nacional de Seguridad, Spain’s national security framework, RD 311/2022, Basic/Medium/High categories), lists the seven mandatory minimum documents an auditor asks for, presents the blog’s multi-tenant chatbot as a live 42001 checklist, and closes with the five usual traps (confusing 42001 with EU AI Act compliance, over-documenting without measuring, ignoring A.5 until the audit, assuming 27001 covers the AI part, thinking certification is a one-off project rather than a living system).

The analogy: the aircraft operations manual

A modern aircraft, an A350, a Boeing 787, a drone certified for urban delivery, does not fly because it has good engines. It flies because the organisation that operates it has an Operations Manual approved by the aviation authority (EASA in Europe, the FAA in the US, AESA in Spain as a delegated body). The manual does not contain the engine blueprints, which the manufacturer certifies; it contains the procedures: who is captain on each flight, which checklist is run before each take-off, which periodic inspections happen at 100, 500 and 2,000 flight hours, which external suppliers are authorised to touch which components, what is documented after each incident, what to do when a new alert appears on the panel. The authority does not sit in on every flight: it reads the manual, randomly audits the traceability of past flights against the manual, and if everything adds up, it keeps the certification in place.

An AI system in production, the multi-tenant chatbot from the forensic post, a copilot for lawyers, a credit scoring system, is exactly the same. It flies because the model is good, the LLMOps pipeline is well built, the guardrails catch the bad cases. But it certifies because the organisation operating it has an AIMS (AI Management System) described in an auditable manual. ISO/IEC 42001 is that manual: its mandatory table of contents (Annex SL, seven clauses) and its catalogue of AI-specific controls (Annex A, 38 controls). The auditor does not sit next to the MLOps engineer: they read the AI policy, review the impact assessments of the most recently deployed systems, check that incident retrain is documented, verify third-party contracts, audit a sample of Langfuse traces cross-checked against dataset_hash and prompt_id. And if everything adds up, they certify.

The analogy matters because it frames the right question: 42001 does not certify the model or the code. It certifies the way of operating the complete system. A team can have the best OSS stack in the world and fail the audit because it has no written AI policy and no documented decision about which role (provider vs producer vs customer) it occupies towards its clients. And the reverse: a team with a modest model but with operations-manual discipline can certify without acrobatics.

ISO/IEC 42001 in 15 seconds

Publication: December 2023, ISO/IEC JTC 1/SC 42 (the ISO/IEC subcommittee for AI).
Status in 2026: an active standard, certifiable by accredited bodies (BSI, AENOR, TÜV, Bureau Veritas, A-LIGN, Schellman). Not yet formally recognised as a harmonised standard under the EU AI Act, but it provides the management base to lean on.
Compatibility: it shares the Annex SL structure with ISO 9001 (quality), 27001 (information security), 27701 (privacy), 22301 (continuity), 20000-1 (IT services). Organisations with integrated management systems (IMS) add it with 20-40% of the effort it would take to implement from scratch.
Applicability: any organisation that develops, provides, deploys or uses AI systems. It is not limited to developers: a company that consumes a hosted LLM and integrates it into its own product is within scope.
Certification: a 3-year cycle with an initial audit (Stage 1: documentation review + Stage 2: on-site audit) and annual surveillance audits. Typical cost: 15,000-60,000 € for the initial one depending on size; 6,000-20,000 € per annual surveillance.

What 42001 does not do:

It does not say which models to use or which thresholds to apply.
It does not certify the individual model (that is done by specific evaluations such as a NIST AI RMF profile or EU AI Act technical documentation).
It does not replace the EU AI Act or the GDPR: it is complementary. Implementing it well makes legal compliance easier but does not guarantee it.
It is not a technical standard for explainability or robustness (those are ISO/IEC 25059, 24029, 23894 and others in the SC 42 family).

Distinction from neighbouring frameworks

Framework	Nature	Scope	Certifiable	Overlap with 42001
ISO/IEC 42001:2023	Management standard	AIMS for any AI system	Yes	—
EU AI Act (Reg. 2024/1689)	Binding legal regulation	AI systems in the EU, risk-categorised	No (it is law)	Arts 9, 10, 11, 12, 13, 14, 17
NIS2 (Dir. 2022/2555)	Cybersecurity directive	Essential/important entities	Via the national scheme	Asset register, incident, supply chain
ENS (RD 311/2022)	Spanish security regulation	Public sector and its suppliers	Yes (B/M/A categories)	Traceability, incident management
ISO/IEC 27001	Management standard	Information security	Yes	Annex SL structure + Annex A overlap
ISO/IEC 27701	Management standard	Privacy (extends 27001)	Yes	PII in training data
NIST AI RMF 1.0	Voluntary framework	AI risk management	No	Conceptually aligned, not identical
ISO/IEC 23894	Technical standard	AI risk management	No	Input to A.5 (impact assessment)
ISO/IEC 5259	Family	Data quality for AI	No	Input to A.7 (data)

Three distinctions that matter operationally and are a recurring source of confusion with clients:

ISO 42001 ≠ EU AI Act compliance. Holding the 42001 certification makes it easier to demonstrate articles 9-17 of the European Regulation, but the Regulation requires things 42001 does not cover directly (CE marking of high-risk systems, registration in the European database, declaration of conformity, specific post-market monitoring). Implementing 42001 first and then filling the AI Act gaps is the standard route.
ISO 27001 is not enough. 27001 covers confidentiality, integrity and availability of information. The AI side is missing: bias, opacity, model drift, training corpus quality, human evaluation, impact on affected persons. 42001 is a complement, not a substitute. Organisations that already have 27001 in place have an advantage because they share half the documentation.
NIS2 ≠ AI safety. NIS2 requires registering critical assets, notifying incidents within 24 h, and managing the digital supply chain. AI systems can be within NIS2 scope if they form part of the critical asset (an LLM serving customer support in a financial entity is), but NIS2 does not audit model quality. 42001 does.

The seven clauses (Annex SL): the mandatory table of contents

The seven clauses, from clause 4 to clause 10, are common to all modern management standards (Annex SL, also called the “High Level Structure”). That means an organisation with ISO 9001 or 27001 already in place recognises the structure. Clauses 1-3 are introductory (scope, normative references, terms).

Clause 4 — Context of the organisation

Identify the external context (applicable regulation, customer expectations, social risks) and the internal context (strategy, culture, capabilities). Identify the interested parties and their expectations: customers, regulators, affected persons, employees, suppliers. Define the scope of the AIMS: which AI systems are in and which are out.

The usual gap: organisations that say “all our AI systems are in scope” without having enumerated them. The auditor asks for the list. Without a list, there is no scope.

Clause 5 — Leadership

Top management must approve and publish an AI policy, assign roles and responsibilities (typically AI lead, AI risk owner, data officer), and demonstrate commitment through resources, communication and oversight. The policy is an auditable document and must be made available to staff and interested parties.

The usual gap: a generic AI policy copied off the internet, with no measurables and no concrete objectives. The auditor asks how compliance with it is measured. Without metrics, the policy is theatre.

Clause 6 — Planning

Identify risks and opportunities of the AIMS (not of the individual model). Define measurable AI objectives, with deadlines and owners. Plan changes to the AIMS.

The usual gap: confusing AIMS risks (what happens if we do not document correctly?) with model risks (what happens if the model is biased?). The first belongs here; the second goes to A.5.

Clause 7 — Support

Resources: human, technical, financial, infrastructure. Competence of personnel (documented training). Awareness of the policy among personnel. Internal and external communication. Documented information (the backbone of the management system: policy, procedures, records, evidence).

The usual gap: documentation scattered across Confluence/Notion/Drive with no version control and no recorded approvals. The auditor asks about the last change: who approved it? when? on what grounds?

Clause 8 — Operation

The most operational clause. It requires:

Operational planning and control: how the AI system’s lifecycle is managed day to day. → Covered in the blog by the six-stage LLMOps pipeline.
Impact assessment (linked to A.5).
AI system lifecycle management (linked to A.6).
Data for AI systems (linked to A.7).

This is the clause that materialises in controls A.5, A.6 and A.7. On its own it adds no new requirements: it links to Annex A.

Clause 9 — Performance evaluation

Monitoring, measurement, analysis, evaluation. Internal audits (planned, with criteria, scope, frequency, recorded results). Management review (typically quarterly or half-yearly, with a mandatory agenda: inputs, evidence, decisions, actions).

The usual gap: there is OTel tracing + Langfuse + Grafana and plenty of data, but there is no formal management review agenda with documented minutes. The auditor asks for the minutes. Without minutes, there is no review.

Clause 10 — Improvement

Nonconformity and corrective action: when something fails, it is recorded, root cause is analysed, a correction is agreed, effectiveness is verified. Continual improvement: the system evolves deliberately.

The usual gap: Jira tickets with technical post-mortems but no formal “ISO nonconformity” record closed out with an effectiveness check. They are two distinct artefacts, even if they can be integrated.

The 38 Annex A controls: the AI-specific catalogue

Unlike Annex SL (which is common), Annex A is 42001’s AI-specific signature. The 38 controls are organised into 9 sections (A.2 to A.10; A.1 is the introduction) covering the AI-specific risks: opacity, bias, drift, corpus quality, impact on affected persons, third-party dependency. Each control has an objective (what it aims to achieve) and implementation guidance in Annex B.

Section	Focus	# controls
A.2	AI-related policies	2
A.3	Internal organisation	3
A.4	Resources for AI systems	6
A.5	Impact assessment	5
A.6	AI system lifecycle	4
A.7	Data for AI systems	5
A.8	Information for interested parties	4
A.9	Use of AI systems	3
A.10	Third parties and customer relationships	4
Total	—	38

What follows is the section-by-section mapping of the controls onto material we have already covered in the blog. The editorial intent is to show which gaps remain once the technical architecture is in place, so that the road to certification does not start from zero.

Cross-mapping: 38 controls ↔ blog posts

A.2 — AI policies (2 controls): PARTIAL

A.2.2 AI policy: the organisation must have a documented AI policy, approved by management, reviewed periodically, communicated and available. It covers principles, scope and commitments.
A.2.3 Alignment with other policies: the AI policy is not an orphan, it aligns with existing security, privacy, quality and ethics policies.

Gap: this is not a code matter. The AI policy is a document that the organisation’s management approves and signs. The blog teaches a neutral, technical editorial stance (no hype, sovereignty, OSS by default under ENS/NIS2), but that is not any specific organisation’s AI policy. Each client has to draft and sign their own.

Minimum template: 1-2 pages with: principles (transparency, human oversight, fairness, accountability, sustainability), scope (which systems), measurable commitments (annual review, impact assessment before deployment, team training), governance (who approves what).

A.3 — Internal organisation (3 controls): GAP

A.3.2 AI roles and responsibilities: roles defined, non-overlapping, communicated. Typically: AI lead, AI risk owner, data steward, AI ethics officer (which may be a single person in small organisations).
A.3.3 Reporting of AI incidents/concerns: a channel for anyone (internal or external) to report a problem with an AI system, with documented follow-up.
A.3.4 Identification of stakeholders: a maintained list of stakeholders (customers, affected persons, regulators, partners) and their expectations.

Gap: also not technical. An organisational decision. The usual way to cover it is to appoint an AI lead (which may be the CIO, the CTO or a new role depending on size), reuse the security reporting channel (typically already in place because of 27001) by extending it to AI, and maintain a live stakeholder register.

A.4 — Resources (6 controls): COVERED

A.4.2 Documented information: documentation of the AIMS.
A.4.3 Data resources: identification and management of the data available for training, evaluation and operation.
A.4.4 Tooling resources: development, validation and monitoring tools.
A.4.5 System resources: hardware, infrastructure, compute.
A.4.6 Human resources: competent personnel.
A.4.7 Financial resources: budget.

Covered by the blog in the three architectural posts:

Anatomy of the stack: seven layers: A.4.5 system resources, A.4.4 tooling.
Seven deployment phases: A.4.5 + A.4.7 (budget implicitly).
Five maturity levels: A.4.5 + A.4.6 (team maturity).
OSS tooling catalogue: A.4.4 tooling.
Data versioning with DVC and lakeFS: A.4.3 data resources.

A.5 — Impact assessment (5 controls): PARTIAL

A.5.2 AI impact assessment process: a documented impact assessment procedure.
A.5.3 Documentation of AI impact assessments: records of the assessments carried out.
A.5.4 Alignment with AI risk treatment: the impact assessment’s decisions feed risk treatment.
A.5.5 Impacts on individuals: specific dimensions covering affected persons (rights, discrimination, privacy).
A.5.6 Societal impacts: dimensions covering society (information, social rights).

Partial: the method exists in the ISO/IEC SC 42 family. ISO/IEC 23894:2023 is the technical standard for AI risk management and NIST AI RMF 1.0 is the freely usable American equivalent. But the organisation has to write its procedure and run it per system before deployment. It is not code, it is discipline.

Minimum template for the impact assessment (3-5 pages per system):

Description of the system (what it does, who it serves, underlying model and stack).
Stakeholders identified.
Potential impacts (intended and unintended) on people, groups and society.
Fairness and robustness metrics applied, with thresholds and results.
Mitigations applied (guardrails, evals, human oversight, rate limiting).
Accepted residual risks, with signed justification.
Review cadence (typically annual, or on substantial change).

A.6 — AI system lifecycle (4 controls): COVERED

A.6.2.2 Objectives for responsible development of AI: responsible development objectives defined per system.
A.6.2.3 Processes for responsible AI design and development: design and development procedures.
A.6.2.4 AI system requirements and specifications: formal specification of the system.
A.6.2.5 Verification and validation: V&V before and during operation.
A.6.2.6 Deployment: deployment procedures.
A.6.2.7 Operation and monitoring: continuous operation and monitoring.
A.6.2.8 Documentation: lifecycle documentation.

Covered by the blog:

The six-stage LLMOps pipeline: the complete master map of the lifecycle.
Anatomy of an LLM request: the forensic version of how it runs in production.
Continuous fine-tuning in production: the A.6.2.3 + A.6.2.5 + A.6.2.6 + A.6.2.7 discipline in real operation.
Evals: the layer after tracing: A.6.2.5 verification and validation.
Retrain: A.6.2.7 operation + continuous iteration.
Modern alignment: DPO, KTO, ORPO, SimPO: A.6.2.3 responsible design.
MLOps landscape 2026: the tooling landscape.

A.7 — Data for AI systems (5 controls): COVERED

A.7.2 Data for development and enhancement of AI: data management policy and procedures for development and improvement.
A.7.3 Acquisition of data: acquisition procedures (origin, authorisation, quality).
A.7.4 Quality of data for AI systems: measurable quality criteria.
A.7.5 Data provenance: data lineage.
A.7.6 Data preparation: preparation procedures (chunking, anonymisation, labelling).

Covered by the blog:

RAG corpus curation: the active librarian: A.7.4 + A.7.5 + A.7.6 in detail (five layers: schema, dedup, PII, anti-contamination, lineage).
Data versioning: DVC and lakeFS: A.7.2 + A.7.5 (the four data artefacts versioned with lineage).
Reranker and hybrid retrieval: A.7.6 preparation + filtering.
LLM Guard: A.7.6 runtime anonymisation with Vault.

A.8 — Information for interested parties (4 controls): COVERED

A.8.2 System documentation and information for users: technical documentation available.
A.8.3 External reporting: the capacity to report to authorities where applicable.
A.8.4 Communication of incidents to users: notification to users when there is an incident.
A.8.5 Information for interested parties: information for other stakeholders.

Covered by the blog:

LLM tracing with OpenTelemetry GenAI: A.8.2 per-request traceability, A.8.3 the capacity to extract forensic reporting.
Prompt versioning with Langfuse and MLflow: A.8.2 documented versioning.
Guardrails and safety in LLMs: A.8.4, gen_ai.guardrail.* spans as the basis for incident notification.
LLM Guard: A.8.4 incident events for retrain.

A.9 — Use of AI systems (3 controls): COVERED

A.9.2 Processes for responsible use of AI: responsible use procedures.
A.9.3 Objectives for responsible use of AI: objectives.
A.9.4 Intended use of AI systems: documentation of the intended use.

Covered by the blog:

Guardrails and safety in LLMs: A.9.2 + A.9.3 (the four lines of defence).
LLM Guard: A.9.2 operational detail.
Evals: the layer after tracing: A.9.3 measurement of objectives.
Retrain: A.9.2 closed loop.

A.10 — Third parties and customer relationships (4 controls): COVERED

A.10.2 Allocation of responsibilities: distribution of responsibilities between AI roles.
A.10.3 Suppliers: procedures for AI suppliers.
A.10.4 Customers: procedures towards customers.
A.10.5 Third parties: procedures for third parties.

Covered by the blog:

The parallel catalogue: OSS vs hyperscalers: A.10.3 supplier assessment with lock-in and contractual sovereignty analysis.
The OSS catalogue for LLMOps: A.10.5 third-party inventory (OSS components with licences and governance).
Anatomy of an LLM request: A.10.2 + A.10.4 in the multi-tenant case.

The roles defined by the standard

ISO/IEC 22989:2022 (AI vocabulary, complementary to 42001) defines six roles. Each organisation has to decide which ones it occupies and document it:

Role	Definition	Main responsibility	Example
AI provider	Organisation that provides the AI system to others	Makes the system available	OpenAI provides GPT-5 via API
AI producer	Organisation that develops the AI system	Design, development, validation	Meta produces Llama 4
AI customer	Organisation that acquires the AI system	Selection, integration, oversight	A consultancy integrating an LLM into its own product
AI partner	Organisation collaborating with another AI role	Shared	A GPU hardware manufacturer
AI subject	Person or group affected by the system	Recipient of the impact	The chatbot’s end user
Relevant authority	Regulator with jurisdiction	External oversight	AEPD, CNMC, EU AI Act authorities

An organisation can occupy several roles at once, which changes the applicable controls. A common pattern in consultancy is: producer + customer + provider towards the end client. The A.10 responsibilities are modulated by the roles.

Example role mapping for the multi-tenant chatbot from the forensic post:

Base model manufacturer (Llama 4): AI producer of the base model.
OSS stack operator (the consultancy): AI producer of the LoRA adapter + AI provider of the chatbot to its clients + AI customer of Meta’s base model.
End client (the insurer): AI customer of the chatbot + AI provider of the customer support service.
The policyholder: AI subject.
AEPD + EU AI Act authority: relevant authority.

Each box in the table generates different obligations. The consultancy, being producer of the adapter, must document A.6 (lifecycle) and A.7 (data) for the adapter. Being provider of the chatbot, it must document A.10.4 (customers). Being customer of the base model, it must document A.10.3 (suppliers) and validate that Meta does its part.

Impact levels and proportionality

42001 does not demand the same rigour of every system. Clause 6.1.2 and control A.5 introduce impact as a modulator. The standard does not define strict categories (unlike the EU AI Act, which does define “prohibited / high risk / limited risk / minimal”), but it recommends using levels according to severity and probability.

Industry practice in 2026 aligns the 42001 levels with the EU AI Act categories:

42001 level	EU AI Act	Examples	Control depth
High	High risk (Annex III)	Credit scoring, HR, health, critical infrastructure	Exhaustive impact assessment, mandatory human oversight, continuous monitoring, adversarial evals, detailed logging, half-yearly management review
Medium	Limited risk	Customer service chatbots that do not automate decisions, productivity assistants	Standard impact assessment, complete guardrails, annual review
Low	Minimal risk	Spam filters, non-personalised content recommendations	Lightweight impact assessment, basic controls

This proportionality is operationally key: implementing 42001 at maximum rigour for a low-risk system is waste; relaxing it on a high-risk one is non-compliance.

The seven minimum AIMS documents

An auditor at Stage 1 (documentation review) asks for between seven and ten documents. The seven essentials:

AI policy (clause 5.2 + A.2.2). 1-2 pages. Approved by management, dated, versioned.
AIMS scope (clause 4.3). List of AI systems in scope, inclusion criteria.
Stakeholder register (clause 4.2 + A.3.4). A maintained list with expectations.
AIMS risk register (clause 6.1). Risks of the management system, not of each model.
Impact assessment procedure (A.5.2) + records of assessments carried out (A.5.3). The procedure plus one or more assessments done.
AI lifecycle procedure (A.6.2), which can literally read “see the six-stage LLMOps pipeline” with references to technical runbooks.
Data management procedure (A.7.2), covering acquisition, quality, provenance, preparation, anonymisation.

Common additional documents:

Responsible use policy (A.9.2) with permitted and non-permitted use types.
AI third-party management procedure (A.10.3, A.10.5) with assessment criteria for AI suppliers.
Internal audit plan + management review agenda (clauses 9.2 + 9.3).

For an organisation with a mature OSS stack, documents 6 and 7 are references to technical artefacts that already exist (pipeline runbooks, DVC configurations, the PII policy in LLM Guard). The real documentary effort sits in documents 1, 2, 3, 4 and 5.

Applied case: the blog’s multi-tenant chatbot → 42001 checklist

We take the system described in the forensic post, a multi-tenant customer support chatbot for insurers on an on-premise OSS stack, and walk it as a 42001 auditor would.

Clause 4 — Context. The AIMS scope includes the chatbot and excludes the internal HR system (a different AI). Stakeholders identified: client insurers, affected policyholders, the AEPD, the EU AI Act authority (once it enters into force on 2 Aug 2026), the supplier Meta (base model), the hardware supplier NVIDIA. → Documented.

Clause 5 — Leadership. AI policy signed by the CEO, in force. Roles assigned: AI lead (CTO), AI risk owner (CISO), data steward (Head of Data), quarterly AI ethics committee. → Documented.

Clause 6 — Planning. AIMS risk register: incomplete documentation, team churn, dependency on a single GPU supplier, EU AI Act regulatory change. AIMS objectives for 2026: 42001 certification before Q4, EU AI Act high-risk compliance before 2 Aug. → Documented.

Clause 7 — Support. Resources: a 4×H100 SXM cluster + the seven stack layers. Competence: 2 MLE + 2 SRE + 1 part-time AI ethics, all with documented training. Communication: AI policy on the intranet + handbook. → Documented.

Clause 8 — Operation. Operating procedures = the six-stage LLMOps pipeline. Impact assessment run before deployment + annual review + review on substantial change (defined as: base model change, major adapter change, expansion to a new tenant). → Documented.

Clause 9 — Evaluation. Monitoring: Langfuse + Tempo + VictoriaMetrics + Grafana. Mandatory dashboard metrics: F1 per guardrail category over real traffic, statistical drift, RAG faithfulness, refusal rate. Quarterly internal audit with written criteria. Half-yearly management review with signed minutes. → Documented.

Clause 10 — Improvement. Incident-driven retrain tickets mapped as nonconformities when severity ≥ HIGH. Documented root cause analysis. Effectiveness verified at the next eval gate. → Documented.

Annex A — By section:

A.2 (Policies): AI policy + responsible use policy. → Documented.
A.3 (Organisation): roles assigned, reporting channel, stakeholder register. → Documented.
A.4 (Resources): seven deployment phases + OSS catalogue + training plan + annual budget. → Documented.
A.5 (Impact): procedure + per-system assessments + fairness metrics applied. → Documented.
A.6 (Lifecycle): LLMOps pipeline + continuous fine-tuning + retrain. → Documented.
A.7 (Data): data versioning + RAG corpus curation + LLM Guard Vault + Presidio. → Documented.
A.8 (Information to parties): OTel tracing + Langfuse + gen_ai.guardrail.* spans + notification to tenants within SLA. → Documented.
A.9 (Use): guardrails + evals + responsible use policy. → Documented.
A.10 (Third parties): OSS vs hyperscalers with lock-in analysis + Meta contract for the base model + contracts with tenants. → Documented.

Result of the walkthrough: certifiable. The typical gaps (A.2.2 written policy, A.3 roles, A.5 impact assessment procedure) are covered as formal documents. The operational clauses (8, 9, 10) lean on the blog’s technical architecture. The distance between “having the architecture” and “having certification” is measured in documentary discipline, not in code.

Cross-mapping with the EU AI Act, NIS2 and ENS

EU AI Act (Reg. 2024/1689) — seven directly aligned articles

EU AI Act article	Topic	Aligned 42001 control	Applies to
Art. 9	Risk management system	A.5 + clause 6	High-risk systems
Art. 10	Data and data governance	A.7 (all)	High-risk systems
Art. 11	Technical documentation	A.6 + A.4.2	High-risk systems
Art. 12	Record-keeping (logs)	A.8.2 + OTel tracing	High-risk systems
Art. 13	Transparency to deployers	A.8.5 + A.10.4	High-risk systems
Art. 14	Human oversight	A.9.2 + documented oversight	High-risk systems
Art. 17	Quality management system	Clauses 4-10	High-risk providers

The main obligations for high-risk systems enter into application on 2 August 2026. Implementing 42001 now builds the management base that deadline demands.

What is missing for EU AI Act compliance that 42001 does not cover:

CE conformity of high-risk systems (declaration of conformity, marking, registration in the EU database).
The specific post-market monitoring required by Art. 72.
Serious incident reporting to authorities within legal deadlines (not only to users).
Transparency obligations towards users for limited-risk systems (Art. 50): chatbots, deepfakes, generated content.
The Art. 5 prohibitions (social scoring, manipulation, real-time biometrics with exceptions).

NIS2 (Dir. 2022/2555) — three pillars with overlap

Asset register (Art. 21.2.f): AI systems within NIS2 scope must be in the asset inventory. → Overlaps with A.4 + clause 4.3 (scope).
Incident notification (Art. 23): significant incidents are notified within 24 h (initial alert) + 72 h (detailed report). → Overlaps with A.3.3 (reporting) + clause 10 (improvement).
Supply chain security (Art. 21.2.d): security assessment of the digital supply chain. → Overlaps with A.10.3 (suppliers).

For essential NIS2 entities that also use AI systems, 42001 covers the AI-specific part that NIS2 requires by inference but does not spell out.

ENS (RD 311/2022)

The Spanish Esquema Nacional de Seguridad already expressly addresses AI in its Annex II (ENS controls). The Basic/Medium/High categories align with the 42001 impact levels. The ENS controls on traceability (op.exp.8), activity logging (op.exp.10) and incident management (op.exp.7) are covered by the same technical artefacts as A.8 and A.5 of 42001. An organisation certified at ENS High category with AI systems is a reasonable effort away from adding 42001.

The five usual certification traps

Trap 1 — Confusing 42001 with EU AI Act compliance. Passing the 42001 audit does not imply conformity with the European Regulation. They are distinct universes with a 60-70% overlap. The trap surfaces when the client asks for CE marking of the high-risk system and the organisation produces only the 42001 certificate.

Trap 2 — Over-documenting. Two-hundred-page manuals with procedures copied from templates, with no measurables and no evidence of application. The auditor asks for the last execution of the procedure; with no records, the procedures are ornament. The practical rule: prefer short documents referencing live technical artefacts to long self-contained ones.

Trap 3 — Under-measuring. Defining AIMS objectives with no operational metrics. “Improve model quality” is a null objective; “F1 per guardrail category ≥ 0.85 over real traffic, measured weekly, reviewed quarterly in the management review” is an auditable objective. The blog has insisted on this in every post on evals, guardrails and retrain.

Trap 4 — Ignoring A.5 until audit day. The impact assessment is the most underrated control and the first one the auditor asks for. Without per-system assessments carried out before deployment, there is no way to demonstrate A.5. The trap surfaces when there is no longer time to produce credible retrospective assessments.

Trap 5 — Assuming 27001 covers the AI part. Organisations that already have 27001 sometimes think “we have half of it done”. That is true for Annex SL (structure) and for A.5/A.6/A.7 of 27001 (not of 42001) as far as infosec goes. It is false for A.5 of 42001 (impact assessment), A.7 of 42001 (AI-specific data quality), A.9 (responsible use) and A.10.4 (AI customers). You have to add, not assume.

What we have not covered (upcoming posts)

Concrete templates of the seven mandatory documents, with drafting examples and metrics. Material for a post along the lines of “The AIMS manual in 7 documents” with a reference frame.
Detailed article-by-article mapping to the EU AI Act with the checklist of technical evidence derivable from the blog’s OSS stack. Especially Arts 11 (technical documentation), 14 (human oversight) and 72 (post-market monitoring).
The combined ENS High category + 42001 case: which ENS controls are covered by which AIMS artefacts, avoiding duplication.
NIST AI RMF 1.0 vs 42001 comparison: many international clients ask for both. How the same artefacts are recycled to satisfy the two frameworks.
42001 for LLM agents and MCP: the new dimensions that emerge when the AI system is agentic (excessive agency, tool use, graduated autonomy). The guardrails post introduced line 3 (tool GR); 42001 has open gaps in this terrain and SC 42 is working on addenda.

References

ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. ISO. https://www.iso.org/standard/81230.html.
ISO/IEC 22989:2022 — Information technology — Artificial intelligence — Artificial intelligence concepts and terminology. Define los roles AI provider/producer/customer/partner/subject.
ISO/IEC 23894:2023 — Information technology — Artificial intelligence — Guidance on risk management. Insumo de A.5.
ISO/IEC 38507:2022 — Governance implications of the use of AI by organizations. Complemento de gobierno.
ISO/IEC 5259 — Data quality for analytics and machine learning (familia). Insumo de A.7.
EU AI Act (Regulation 2024/1689) — texto consolidado en EUR-Lex. Entrada en vigor de obligaciones de alto riesgo: 2 ago 2026.
NIS2 (Directive 2022/2555) — texto consolidado en EUR-Lex.
ENS — Real Decreto 311/2022 — Esquema Nacional de Seguridad, BOE-A-2022-7191.
NIST AI RMF 1.0 (2023) — https://www.nist.gov/itl/ai-risk-management-framework.
EUR-Lex EU AI Act consolidated text — https://eur-lex.europa.eu/eli/reg/2024/1689.
A-LIGN / BSI / Schellman — blogs sobre experiencia de auditoría 42001 con casos reales 2024-2025.

EU AI Act: the technical dossier, article by article, over the blog's on-premise LLM architecture

Mon, 01 Jun 2026 05:30:00 +0200

Sister post to the mapping onto ISO/IEC 42001. That one broke down the AI management system, the certifiable standard. This one breaks down the binding legal regulation that applies without any certification: the EU AI Act is direct law in all 27 Member States, with no transposition and with explicit penalties of up to 35 million euros or 7% of worldwide turnover. The main obligations for high-risk systems enter into force on 2 August 2026; each article applies from its own date, not from the date the organisation gets certified.

TL;DR

Regulation (EU) 2024/1689 (the EU AI Act, “Reglamento Europeo de Inteligencia Artificial”), published in the Official Journal on 12 July 2024, sets obligations by risk tier (prohibited, high, limited, minimal) and by role (provider, deployer, importer, distributor, authorised representative). The obligations for high-risk systems (Annex III: biometrics, critical infrastructure, education, employment, essential public and private services, law enforcement, migration, justice, democratic processes) enter into force on 2 August 2026 and are the category that applies to most LLM projects in a medium-to-large enterprise. This post maps, article by article, the obligations relevant to a high-risk LLM system deployed on-premise: each article states its requirement, identifies which blog post already describes the technical piece that materialises it, and closes with an auditable checklist that a provider hands to a national supervisory authority. The Annex IV technical dossier is reconstructed by pointing its nine mandatory sections at the corresponding technical runbooks. Also covered: the Art. 6 classification and how to decide whether a system falls in as high risk, the Art. 5 prohibitions (what is excluded by construction), the GPAI obligations of Art. 53 that affect anyone building on base models (Llama, Mistral, DeepSeek, Qwen) rather than their own, the full timetable of application dates (5 Aug 2024 entry into force, 2 Feb 2025 prohibitions, 2 Aug 2025 GPAI, 2 Aug 2026 high risk Annex III, 2 Aug 2027 high risk Annex I and systemic GPAI), the Art. 99 penalty table (up to 35 M€ or 7% of worldwide turnover for Art. 5 violations, 15 M€ or 3% for high risk, 7.5 M€ or 1% for incorrect information) and the five frequent compliance traps. The editorial thesis: the technical architecture described in this blog directly covers between 70% and 85% of the Regulation’s technical requirements; the rest is documentary and procedural discipline (FRIA, CE marking, signed declaration of conformity, EU database registration, incident reporting within legal deadlines) built on top of technical artefacts that already exist but running on its own circuit.

The analogy: the type-approval dossier for a new vehicle

A vehicle manufacturer cannot sell a new car in the EU without passing WVTA (Whole Vehicle Type Approval). The process is public and standardised: the manufacturer prepares a technical dossier with dozens of chapters (brakes, emissions, active and passive safety, lighting, noise, weight, dimensions, recyclable materials, driver assistance devices), submits it to a type-approval authority or a notified technical service, which audits the file and, if everything adds up, issues the type approval. The manufacturer then stamps the E mark (E1 Germany, E9 Spain, and so on) and the CE/UNECE plate on every vehicle of that type produced in series. Each vehicle also carries a service book with mandatory inspections, and serious accidents or systemic defects are reported to the competent ministry, which can order recalls.

The EU AI Act adapts exactly this industrial model to high-risk AI software. The provider prepares the Annex IV dossier (nine mandatory sections) with the full technical documentation of the system, runs a conformity assessment (self-assessment for most Annex III cases, notified body for the more sensitive Annex I ones), signs the EU declaration of conformity, registers the system in the European database, and applies the CE marking to the system when it is placed on the market. From there on it must keep a live post-market monitoring system and report serious incidents to the market surveillance authorities of each Member State within legal deadlines ranging from 2 to 15 days depending on severity. Failing to comply, penalties reach 35 million euros or 7% of worldwide turnover depending on which article was breached.

The analogy matters because it bounds expectations: this is not a one-off compliance job, nor a badge you buy. It is an industrial type-approval process, with cadences, evidence, signatures and criminal liability. And most of the technical evidence the dossier asks for already exists in any serious system described in this blog: data lineage, OTel tracing, continuous evals, guardrails, incident-driven retrain, a responsible-use policy. What is missing is assembling it in the correct legal format.

How it fits with ISO 42001, NIS2 and ENS

Before dropping into the articles, a reminder of the editorial position from the post on ISO 42001:

Piece	Nature	Who operates it	Coverage
EU AI Act	Direct EU law	Provider + deployer + national surveillance authorities	AI systems on the EU market, segmented by risk
ISO/IEC 42001	Certifiable management standard	Organisation + certification body	AIMS, organisational governance
NIS2	Transposed cyber directive	Essential/important entities	Asset register, incident notification, supply chain
ENS (Esquema Nacional de Seguridad, Spain’s national security framework, RD 311/2022)	Spanish security regulation	Public sector + its suppliers	Categories B/M/A, certifiable

Implementing 42001 makes it easier to demonstrate articles 9-17 of the EU AI Act, but it is not equivalent to legal compliance. The table of legal obligations and the chain of criminal liability come from the Regulation, not from the standard. An organisation certified against 42001 that deploys a high-risk system without CE marking, without registration in the EU database, without a signed declaration of conformity and without a documented FRIA breaches the Regulation even with the certificate on the wall.

The four risk categories and the Art. 6 classification

The Regulation classifies systems into four risk tiers. The choice of category belongs to the provider and must be documented in the dossier, with technical and legal justification.

Category	Article	Examples	Consequence
Prohibited	Art. 5	Social scoring, manipulation, real-time biometrics with exceptions, indiscriminate facial scraping	Cannot operate in the EU under any circumstances
High risk	Art. 6 + Annex I + Annex III	Credit scoring, HR, education, critical infrastructure, non-real-time biometrics, justice, migration, health	Complies with Arts. 9-17, Annex IV dossier, CE marking, EU DB registration
Limited risk	Art. 50	Chatbots with humans as users, deepfakes, synthetic content	Transparency obligations towards the user
Minimal risk	Everything else	Spam filters, video game NPCs, content suggestions	No specific obligations; a voluntary code of conduct is recommended

The Art. 6 test for deciding whether a system is high risk:

Is it in Annex I? (products regulated by the listed harmonisation legislation: machinery, lifts, toys, medical devices, and so on). If the AI system is a safety component of an Annex I product, it is high risk.
Is it in Annex III? (eight areas: biometrics, critical infrastructure, education, employment, essential public/private services, law enforcement, migration/asylum, justice/democratic processes). If the system falls in any of those areas it is high risk, except if the Art. 6.3 exception is invoked (systems performing a narrow procedural task, improving the result of a previous human activity, detecting decision patterns without influencing the final decision, preparatory tasks).

The Art. 6.3 exception requires formal documentation justifying why it does not apply. In other words, even falling outside is not free: you have to demonstrate why.

For the typical LLM systems covered in this blog:

Customer support chatbot for banking, insurance or healthcare: probably high risk if it automates contractual decisions about the customer, limited risk if it only informs.
Internal HR assistant (CV screening): high risk (Annex III, employment area).
Medical assistant (diagnostic support): high risk (Annex III, healthcare services area).
Fraud detection system: high risk (Annex III, financial services area if it affects access to credit).
Code copilot for developers: minimal risk (does not affect third parties’ fundamental rights).
Internal LLM as a service with no productive use: minimal risk.

The category decision is not an opinion: it is documented and justified in the dossier.

Timetable of application

The obligations arrive in stages. The dates are inflexible:

Date	Applies
1 Aug 2024	The Regulation enters into force
2 Feb 2025	Art. 5 prohibitions + Art. 4 AI literacy obligations
2 Aug 2025	GPAI obligations (Art. 53) + governance + general penalties + designated national authorities
2 Aug 2026	Main high-risk obligations for Annex III + Art. 50 transparency to users
2 Aug 2027	High risk under Annex I (components of regulated products) + GPAI with systemic risk

2 August 2026 is the date that matters to most enterprise LLM projects. We are in June 2026: less than two months to go.

Article-by-article mapping

The sections below follow the structure of the Regulation. For each article the requirement is stated, the blog’s technical artefact that covers it is identified, and it closes with an auditable checklist.

Art. 5 — Prohibited practices (in force since 2 Feb 2025)

What it requires. It prohibits placing on the market, putting into service or using AI systems that:

Manipulate behaviour through subliminal or deceptive techniques that distort decision-making.
Exploit vulnerabilities related to age, disability or socio-economic situation.
Implement social scoring by public authorities.
Perform individual predictive policing based on profiling.
Perform indiscriminate facial scraping to build facial recognition databases.
Infer emotions in workplaces or education, except for medical or safety reasons.
Perform biometric categorisation inferring sensitive attributes (race, political opinion, sexual orientation, and so on).
Real-time remote biometric identification in public spaces by law enforcement, with strict exceptions (terrorism, kidnapping, missing persons) subject to prior judicial authorisation.

The blog’s stack. No piece of the blog facilitates these practices; the OSS catalogue described is oriented towards legitimate tasks. But the provider must explicitly document why the system does not fall under these prohibitions. It cannot be assumed.

Checklist.

Prohibition analysis documented per system, with a written statement of non-applicability.
If the system uses facial biometrics or emotion analysis: specific legal analysis with a formal opinion.
Annual legal review, or on any change of functionality.

Art. 6 — Classification of high-risk systems

What it requires. Determine whether the system is high risk by being in Annex I (safety component of a regulated product) or Annex III (8 areas). If it is in Annex III, assess the Art. 6.3 exception where applicable.

The blog’s stack. The forensic post and the six-stage pipeline describe systems that are typically high risk (multi-tenant chatbot affecting service decisions in a regulated sector).

Checklist.

Art. 6 analysis signed by the organisation’s legal officer.
If Art. 6.3 is invoked: formal documentation of the exception.
Re-assessment if the functionality changes (for example, the assistant moves from informing to deciding).

Art. 9 — Risk management system

What it requires. An iterative system, planned and executed across the whole lifecycle. Identify foreseeable risks, estimate risks under normal use and foreseeable misuse, evaluate emerging risks in post-market monitoring, adopt mitigation measures, communicate residual risks. Effectiveness testing is done under realistic conditions.

The blog’s stack.

The six-stage LLMOps pipeline, the iterative lifecycle.
Evals: the layer after tracing, testing under realistic conditions with golden sets.
Guardrails and safety in LLMs, operational mitigation measures.
Retrain: closing the loop, management of emerging risks via incident-driven retrain.

Checklist.

Risk management document per system, with identification, mitigation, and accepted residual risks signed off.
Periodic review procedure (at least annual, or on substantial change).
Link to the documented improvement loop.

Art. 10 — Data and data governance

What it requires. Training, validation and testing datasets that are relevant, representative, as free of errors and as complete as possible, taking into account the characteristics of the intended purpose. Document:

Data collection and selection.
Processing and annotation.
Biases identified as likely to affect fundamental rights or cause discrimination; measures to prevent them.
Identification of data gaps and how they are addressed.

The blog’s stack.

Data versioning with DVC and lakeFS, the four data artefacts plus end-to-end lineage.
RAG corpus curation: the active librarian, five layers: schema, dedup, PII, anti-contamination, lineage.
LLM Guard: Vault and Anonymize, runtime anonymisation with restitution.

Checklist.

Data governance document per dataset (training / RAG corpus / golden eval / enriched retrain).
Bias analysis by protected category with metrics (parity ratio, equalized odds, calibration).
PII / anonymisation / pseudonymisation procedure with measured F1.
Justification of representativeness for the intended context.
Verifiable chunk→trace lineage.

Art. 11 + Annex IV — Technical documentation

What it requires. A technical dossier with the nine Annex IV sections, drawn up before the system is placed on the market, maintained during operation, and available to authorities for ten years after the last operation. The nine sections:

General description of the system: name, version, purpose, integrator, intended hardware, instructions for use.
Detailed description of design and development: architecture, base models, training methods, design decisions with justification.
Information on monitoring, functioning and control: capabilities, limitations, expected accuracy, behaviour under normal use and foreseeable misuse.
Information on data: datasets used, sources, preparation methods, biases addressed.
Description of the monitoring system and metrics: traces, logs, dashboards.
Description of the QMS and the Art. 17 procedures.
FRIA where applicable (Fundamental Rights Impact Assessment, Art. 27).
Automatically generated logs that the system stores (Art. 12).
EU declaration of conformity under Art. 47, included.

The blog’s stack. It serves as a direct input for each section:

Annex IV section	Technical input from the blog
1. General description	Anatomy of the stack: 7 layers + seven deployment phases
2. Design and development	Six-stage LLMOps pipeline + continuous fine-tuning + modern alignment
3. Capabilities and limitations	Evals + LLM-as-judge
4. Data	Data versioning + RAG corpus curation
5. Monitoring	LLM tracing with OTel GenAI + prompt versioning
6. QMS	Procedures derived from ISO 42001
7. FRIA	Gap, see Art. 27 below
8. Logs	OTel tracing + retention and policies
9. Declaration of conformity	Documentary gap, see Art. 47 below

Checklist.

Annex IV dossier complete, versioned, dated, signed.
10-year retained access guaranteed (immutable / WORM storage).
Update procedure on substantial change.

Art. 12 + Art. 19 — Record-keeping (logs)

What it requires. A high-risk system must be technically capable of generating automatic logs during its operation. Those logs must allow:

Tracing how the system behaved over time.
Facilitating post-market monitoring (Art. 72).
Enabling investigation of serious incidents (Art. 73).
Supporting audits.

The provider must retain the logs for at least six months (or longer if national laws or the QMS require it). For remote biometric identification systems there are additional specific requirements.

The blog’s stack.

LLM tracing with OpenTelemetry GenAI, the canonical substrate. Every request emits a span with trace_id, gen_ai.* attributes, costs, latencies and guardrail decisions.
Prompt versioning: prompt_id + version travel as attributes.
Guardrails and safety in LLMs: gen_ai.guardrail.* attributes record every decision.
LLM Guard: spans per scanner with risk_score and action.
Data versioning: dataset_hash and model_version propagated.

Checklist.

OTel + backend (Tempo, Jaeger) running in production.
Minimum 6-month retention (24-36 months suggested for financial regulation).
WORM / immutable storage.
PII in logs redacted (via LLM Guard Vault or equivalent). Logs are not exempt from the GDPR.
Forensic query procedure with audited permissions.

Art. 13 — Transparency to deployers

What it requires. The provider gives the deployer instructions for use that are clear, complete and accessible, in comprehensible language, covering:

The provider’s identity.
Characteristics, capabilities, limitations (accuracy by category, technical specifications).
Foreseen changes to the system and its metrics.
Human oversight measures (Art. 14).
Expected computational resources and hardware.
When it applies, the expected lifetime of the system and of its maintenance.

The blog’s stack.

The OSS catalogue for LLMOps, which components and with what function.
OSS vs hyperscalers, lock-in analysis and documented dependencies.
Anatomy of an LLM request, capabilities and limitations at forensic level.

Checklist.

User manual in non-technical language for the deployer, plus a detailed technical manual.
Accuracy metrics by category with thresholds.
Change procedure with prior notification.

Art. 14 — Human oversight

What it requires. The system is designed to allow effective human oversight throughout the period of use, with interfaces and procedures that make it possible to:

Understand capabilities and limitations.
Detect malfunctions (automation bias awareness).
Decide not to use the system’s output, to override it, to reverse it.
For remote biometric identification: human verification before acting, by at least two people.

The blog’s stack.

Guardrails and safety, line 3 (Tool GR) with human-in-the-loop for destructive actions.
Evals, metrics on a human-accessible dashboard.
OTel tracing, Langfuse with auditable human sessions.

Checklist.

Oversight interface documented with use cases.
Override / abort capability with no technical restrictions.
Documented training for oversight personnel.
Metrics of the effectiveness of the oversight (override rate, false-negative rate of the oversight itself).

Art. 15 — Accuracy, robustness and cybersecurity

What it requires. High-risk systems are designed and developed to reach an appropriate level of accuracy, robustness and cybersecurity, and to perform consistently throughout their lifecycle. The relevant accuracy metrics are declared in the instructions for use. Resilience against:

Errors, faults and inconsistencies within the environment of use.
Feedback bias during operation (feedback loops).
Attacks that try to exploit the system’s vulnerabilities (data poisoning, model poisoning, model evasion, confidentiality attacks).
Technical and organisational measures to detect, respond to and resolve vulnerabilities.

The blog’s stack.

Quantisation fundamentals, accuracy vs efficiency with reported metrics.
Continuous batching + KV cache, operational robustness.
Guardrails: line 1 input + line 2 retrieval, defence against prompt injection and data poisoning via RAG.
LLM Guard: PromptGuard 2 + injection scanners, direct adversarial mitigation.
Evals: jailbreak resistance + adversarial, robustness metrics evaluated in CI.

Checklist.

Declared accuracy metrics: F1 by category, accuracy, calibration, RAG faithfulness, hallucination rate.
Robustness plan against adversarial inputs (Garak suite / Promptfoo redteam / PyRIT run periodically).
Cybersecurity plan: vulnerability management, patching of the stack (vLLM, its deps, CUDA), secrets rotation.
Analysis of potential feedback loops with drift monitoring.

Art. 17 — Quality management system (QMS)

What it requires. The provider has a written, systematic and proportionate QMS covering (without being limited to):

Regulatory compliance strategy.
Design, verification and quality control of the system.
Testing and validation procedures.
Data management.
The risk management system (Art. 9).
Post-market monitoring (Art. 72).
Incident reporting (Art. 73).
Communication with authorities, deployers and other stakeholders.
Records: documentation, log maintenance.
Resource management.
Accountability: management responsibilities.

The blog’s stack. The QMS is not code, but it leans on code.

ISO/IEC 42001 implemented (previous post) covers practically the whole content of Art. 17.
Six-stage LLMOps pipeline as the reference operating procedure.

Checklist.

QMS manual written, dated, signed, versioned.
Annual internal audit plan with criteria and records.
Management review agenda with signed minutes.
If 42001 is implemented: documented QMS-42001 mapping.

Art. 26 — Deployer obligations

What it requires. Whoever deploys the system (uses it under their own authority, not necessarily the developer) has obligations of their own:

Use the system in accordance with the instructions (Art. 13).
Assign competent, trained human oversight (Art. 14).
Ensure the input data under their control is appropriate.
Monitor operation and notify the provider on detecting problems or serious incidents.
Keep the logs under their control for at least 6 months.
Inform the affected persons when the system is used on them to make decisions (and, in an employment context, also consult their representatives).
For some Annex III cases: complete a FRIA (Art. 27).

The blog’s stack. In the case of the multi-tenant chatbot, the deployer is the client insurer. It must:

Accept the provider’s instructions (the consultancy’s) and sign the terms.
Configure human oversight on its side.
Notify the provider when it detects drift or a serious complaint.
Keep its own logs in addition to the provider’s.

Checklist (for the deployer).

Contract with the provider covering SLAs, responsibilities, exit plan.
Training programme for oversight personnel.
Incident notification procedure towards the provider.
Policy for informing affected persons (in the employment context, notification to representatives).
FRIA where applicable.

Art. 27 — Fundamental Rights Impact Assessment (FRIA)

What it requires. Applicable to deployers that are public bodies or private entities providing public services, or that use systems to assess credit score or life insurance. Before first use, the deployer carries out a FRIA documenting:

A description of the intended use.
Period and frequency of use.
Categories of affected persons.
Specific risks of harm identified.
Human oversight measures.
Mitigation measures should the risks materialise.

The FRIA is notified to the market surveillance authority. Substantial changes force an update.

The blog’s stack. The FRIA is a governance document, not a technical artefact. The blog does not cover it directly. But the technical input is:

The impact analyses from the ISO 42001 post, section A.5 are the natural starting point.
The metrics from the evals post on fairness by category and groundedness feed the risk section of the FRIA.

Checklist.

FRIA procedure documented, aligned with the AIIA in ISO 42005 (published as a complement).
FRIA carried out per system before first use.
Notification to the market surveillance authority.
Periodic review, plus on substantial change.

Art. 47 — EU declaration of conformity

What it requires. The provider draws up a written declaration of conformity per high-risk system, stating:

Identification of the system and the provider.
A statement that it complies with Arts. 8-15 + Art. 17.
Reference to the harmonised standards and common specifications applied.
Where applicable, the notified body and the certificate.
Place and date, signature and name of the authorised signatory.

It must be available to authorities for ten years. It is kept up to date.

The blog’s stack. A pure legal document. Template in Annex V.

Checklist.

Declaration of conformity signed by an authorised person before market placement.
Languages: at least the official EU language of the market where the system is placed.
Re-signing procedure on substantial change.

Art. 48 — CE marking

What it requires. A high-risk system carries the CE marking visibly, legibly and indelibly. For digital systems with no physical part, the marking is included in the documentation or the interface. If a notified body was involved, its number follows.

The blog’s stack. CE marking on a software system typically materialises in:

The product information or “About” page.
The official product documentation delivered to the deployer.
Metadata of the exposed API (custom HTTP header, OpenAPI info).

Checklist.

CE marking visible in the product interface or official documentation.
Notified body number attached where applicable.
Update procedure on substantial change.

Art. 49 — Registration in the European database

What it requires. Before placing on the market or putting into service a high-risk Annex III system (except area 2, critical infrastructure), the provider registers it in the EU database of high-risk AI systems managed by the Commission. Deployers that are public authorities also register their use. Most registration data is public (transparency towards the public).

The blog’s stack. A pure administrative procedure. No technical part beyond having the dossier ready.

Checklist.

Registration completed before first productive use.
Update on substantial change.
Portal access maintained (credentials, contact).

Art. 50 — Transparency to end users

What it requires. Applies to limited risk systems (and, complementarily, to some high-risk ones too):

Chatbots and AI assistants: the person interacting must know they are talking to an AI, unless it is obvious from the context.
Generated synthetic content (text, audio, image, video): marked as AI-generated in the output, in a machine-readable format.
Deepfakes: explicitly declare that the content is artificially generated or manipulated.
Emotion detectors or biometric categorisation: inform the affected persons.

The blog’s stack. Technical materialisation:

A UI banner in the chatbot saying “You are talking to an AI assistant”.
A disclaimer on every exportable response (PDF, email): “Generated by AI”.
Watermarking of the output (perplexity-based, model-fingerprint), optional but useful for deepfakes.
For generated audio, image or video, standard C2PA metadata.

Checklist.

Mandatory UI banner.
Disclaimer on exportable outputs.
If it generates visual content: C2PA marking or equivalent.
Procedure for use of the system on a person without their knowledge (for example, automated CV screening).

Art. 53 — Obligations of GPAI providers (in force since 2 Aug 2025)

What it requires. Providers of GPAI (general-purpose models trained with vast compute, typically foundational: Llama 4, Mistral, DeepSeek, Qwen, Gemma) must:

Maintain technical documentation of the model, accessible to the AI Office and national authorities.
Make information available to downstream providers that will integrate it.
Comply with EU copyright (Art. 4 of Directive 2019/790): an opt-out mechanism for rightsholders.
Publish a summary of the training content (Annex XI, copyright summary).

If the model has systemic risk (10^25 FLOPs threshold, or designated by the Commission), additional obligations apply (Art. 55): model evaluation, adversarial testing, incident reporting, cybersecurity.

The blog’s stack. For an organisation that uses GPAI models (Llama 4, Mistral) and does not train them from scratch:

It is not a GPAI provider; it is a downstream provider integrating GPAI into its system.
It must hold the GPAI technical documentation (Llama paper, Mistral docs) and reference it in its own Annex IV documentation.
Analysis of the specific GPAI licence (Llama Community License, Apache 2.0, and so on).
The post on modern alignment and continuous fine-tuning describe how a LoRA adapter on top of the GPAI does not turn the downstream party into a GPAI provider, as long as it does not train a new model from scratch.

Checklist (downstream provider).

Inventory of GPAI models used, with version, source, licence, referenced documentation.
Mapping of responsibilities between the upstream GPAI provider and us as downstream.

Art. 72 — Post-market monitoring

What it requires. A documented post-market monitoring system proportionate to the risk, collecting data on performance throughout the lifecycle, including interaction with other AI systems. It allows the provider to:

Assess continuous compliance with Arts. 8-15.
Adopt the necessary corrective measures.
Detect trends in real use (drift, abuse).

The monitoring plan is part of Annex IV and is maintained throughout the system’s life. The Commission publishes a template in 2026.

The blog’s stack.

OTel tracing + Langfuse, the base.
Continuous evals, operational metrics as online gates.
LLM-as-judge, judges over production sampling to detect degradation.
Incident-driven retrain, the closed improvement loop.

Checklist.

Post-market monitoring plan documented per system.
Operational metrics defined with thresholds and periodic review.
Corrective action procedure on alert.
Integration with Art. 73 (when an alert equals a serious incident).

Art. 73 — Serious incident reporting

What it requires. The definition of a serious incident (Art. 3(49)):

Death or serious harm to health.
Serious disruption of critical infrastructure.
Infringement of legal obligations intended to protect fundamental rights.
Serious damage to property or the environment.

The provider reports to the market surveillance authority of the Member State where the incident occurred. Deadlines:

Type of incident	Maximum deadline from becoming aware
General	15 days
Death	10 days
Critical infra affected, or widespread infringement	2 days

The first report may be preliminary; the complete one follows later. Internal investigation is mandatory, as is cooperation with the authorities. Corrective action is proportionate.

The blog’s stack. The technical flow:

OTel tracing provides the traceability for forensic investigation.
Guardrails and safety emits the canonical incident_event (category, severity, trace_id).
Incident-driven retrain materialises the corrective action.

Checklist.

Incident reporting procedure documented with deadlines and templates.
Designated person (typically DPO + AI Risk Owner) with responsibility and training.
Annual dry-run of the procedure (drill).
Technical integration between the guardrails / tracing layer and the notification channel.

The assembled Annex IV dossier: SVG of the complete file

The diagram shows the blog’s editorial asymmetry: seven of the nine Annex IV sections are covered directly by the technical stack. Only the FRIA (section 7) and the signed declaration of conformity (section 9, not shown in the SVG because it is a one-page document) are documentary gaps needing express administrative work. The main compliance effort is assembling and signing, not building from scratch.

Applied case: the multi-tenant chatbot assessed against the AI Act

We take the system from the forensic post, a multi-tenant customer support chatbot for insurers, and walk through it as the provider of the system.

Art. 6 classification: the chatbot helps customers understand products, check status and open tickets. It does not automate contractual decisions (it does not approve claims, it does not calculate premiums). Does it fall into Annex III area 8 (essential private services)? That depends on the use. If the insurer uses it only for informational support, it is limited risk (Art. 50 applies). If it uses it to assess claim declarations, it is high risk. Documenting the analysis is mandatory.

We assume high risk for the complete walkthrough:

Art. 5 prohibitions: written statement of non-applicability. ✓
Art. 9 risk management: per-system document with identified risks (hallucination, dialect bias, PII leakage, jailbreak), applied mitigations (RAG over a curated corpus, guardrails with 4 lines, LLM Guard Vault, continuous evals) and signed accepted residuals. ✓ (input: pipeline + guardrails + evals).
Art. 10 data governance: governance of the four datasets (training adapter, insurer RAG corpus, golden eval, enriched retrain) with biases analysed, PII anonymised, lineage in place. ✓ (input: data-versioning + rag-corpus-curation + LLM Guard).
Art. 11 + Annex IV: dossier with 9 sections drafted, signed, accessible for 10 years in a WORM bucket. ✓ (7 sections from the blog, 2 new).
Art. 12 + Art. 19 logs: OTel + Tempo + Langfuse with 24-month retention, PII redacted by Vault. ✓
Art. 13 transparency to deployers: user manual for the insurer plus a technical manual. ✓ (input: OSS catalogue + request anatomy).
Art. 14 human oversight: Langfuse + Grafana dashboard, human escalation protocol for critical cases, training for the insurer’s staff. ✓
Art. 15 accuracy, robustness, cybersecurity: F1 by category declared, Promptfoo redteam adversarial suite run monthly, stack cybersecurity plan (vLLM patching, secrets rotation). ✓
Art. 17 QMS: ISO 42001 implemented and certified. ✓
Art. 26 deployer: the contract with the insurer includes the deployer’s obligations. ✓
Art. 27 FRIA: the insurer carries out a FRIA before first use (it is a private essential-service entity). ✓ (deployer’s responsibility, the provider assists).
Art. 47 declaration of conformity: signed by the consultancy’s CTO before market placement. ✓
Art. 48 CE marking: visible in the chatbot interface and in the official documentation. ✓
Art. 49 EU DB registration: completed before first productive use. ✓
Art. 50 transparency to users: UI banner “You are talking to an AI assistant”, disclaimer on exportable responses. ✓
Art. 53 GPAI: Llama 4 documentation (the base model) referenced, plus EU copyright analysis and responsibility mapping. ✓
Art. 72 post-market monitoring: documented plan, OTel + continuous evals + retrain already running. ✓
Art. 73 incident reporting: procedure, designated owner, annual dry-run. ✓

Result: certifiable and deployable on the EU market on 2 August 2026. The key gaps (FRIA, CE marking, EU DB registration, declaration of conformity) are documentary work over technical artefacts that already exist, not new technical projects.

Penalties (Art. 99)

The penalty table is proportional to worldwide turnover or to an absolute cap, whichever is higher:

Violation	Penalty cap
Art. 5 (prohibited practices)	Up to 35 M€ or 7% of annual worldwide turnover
Other obligations (Arts. 8-22, 26-50, 72-73, and so on)	Up to 15 M€ or 3% of annual worldwide turnover
Incorrect or misleading information to authorities	Up to 7.5 M€ or 1% of annual worldwide turnover

For SMEs and startups the caps are the lower of the two figures (not the higher). The proportionality mitigation exists but requires formal demonstration.

In addition, national authorities can order:

Immediate suspension of the system on the market.
A mandatory recall.
Mandatory public communication of the penalty.

The five frequent compliance traps

Trap 1 — Assuming the GPAI model used already covers the obligations. The downstream provider remains responsible for the integrated system: neither Meta nor Mistral nor DeepSeek takes on the obligations of whoever builds on their models. The trap surfaces when the authority asks for the dossier and the team points at the Llama model card as if that were enough.

Trap 2 — Confusing ISO 42001 with EU AI Act conformity. Holding a 42001 certificate does not imply conformity: certification is not a FRIA, not CE marking, not EU database registration, not a signed declaration of conformity. Standardisation is progressing, but until ISO 42001 is published as a harmonised standard (it was not at the end of 2025), there is no presumption of conformity. The table of legal obligations runs on its own circuit.

Trap 3 — Forgetting incident reporting within the legal deadline. Fifteen days sounds long until an incident lands in the middle of the summer holidays. Two days for critical infrastructure is not negotiable. Without a documented procedure and an annual drill, the deadline is missed in silence. A penalty for misleading information (1% of worldwide turnover) follows if the incomplete reporting is discovered.

Trap 4 — Underestimating the deployer. The AI Act assigns obligations to both the provider and the deployer. A company that uses a hosted LLM integrated into its service (without developing it) is still a deployer with obligations of its own (Art. 26): human oversight, FRIA where applicable, notification to affected persons. The trap surfaces when the deployer assumes that “responsibility lies with the model provider”. It does not, not entirely.

Trap 5 — Leaving the FRIA until last. The FRIA (Art. 27) requires a fundamental rights impact analysis with qualitative dimensions (discrimination, privacy, social rights). It is not an afternoon’s document. It is carried out before first use, not after a problem is detected. Public deployers and private essential-service providers who leave it for “whenever they ask” take 4-8 weeks to produce a credible one, time they typically do not have when the inspection arrives.

What we have not covered (upcoming posts)

Concrete templates for each document: EU declaration of conformity (Annex V), full Annex IV dossier section by section, FRIA, post-market monitoring plan, initial serious incident report. Material for a post along the lines of “The EU AI Act compliance folder in 12 templates”.
Voluntary codes of practice published by the Commission under Art. 56, useful for limited-risk systems that want to demonstrate good behaviour without a legal obligation.
Comparative analysis of notified bodies for systems requiring third-party conformity assessment (mainly Annex I).
How compliance changes for LLM agents, systems with graduated autonomy, tool calling and the capacity to act. SC 42 and the AI Office are working on specific guidance.
The complete map of national authorities designated under Art. 70, plus the sectoral authorities that retain jurisdiction (AEPD for privacy, CNMV for financial services, Banco de España for banking, AESA for aviation).

References

Regulation (EU) 2024/1689 (EU AI Act) — Texto consolidado en EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689. Diario Oficial L 1689/12.7.2024.
EU AI Act Explorer (AI Act Service Desk, Comisión Europea): https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer.
AI Act Text portal (artificialintelligenceact.eu): artículos individuales con anotaciones.
Anexo IV — Technical documentation: estructura de los nueve apartados obligatorios.
Anexo V — EU declaration of conformity: plantilla obligatoria.
Anexo III — High-risk AI systems: las ocho áreas que clasifican un sistema como alto riesgo.
Anexo XI — Copyright training summary template: para GPAI providers.
NIST AI RMF 1.0 (2023) — https://www.nist.gov/itl/ai-risk-management-framework.
ISO/IEC 42001:2023 — sistema de gestión, complemento facilitador.
ISO/IEC 42005 — Impact assessment AI (publicada 2025 como guía técnica para FRIA).
Draft Commission guidance on serious incident reporting (2025) — borrador en consulta para Art. 73.

Iso-42001 on lo0 — Tech Blog

Virtual keys, budgets and limits in LiteLLM: the layer that decides who gets the GPU, and the four things the documentation gets wrong

TL;DR

You are here: the gateway as an administrative boundary

The analogy: the building’s key ring

The hierarchy, and the line that breaks it

Virtual keys: the complete life cycle

How they are stored

Rotation

What exactly happens when a budget runs out

Capacity limits: the v3 limiter

What the client sees

Identity: beyond the static key

Audit: what gets recorded

What this demonstrates to an auditor, and what it does not

Checklist

Traps and things that are not what they look like

Closing

See also

Sources

Technical controls: the ENS × ISO 42001 × EU AI Act cross-mapping over the on-premise LLM architecture

TL;DR

The analogy: the triple inspection of a critical building

ENS in 15 seconds

The five security dimensions and their AI mapping

The three blocks of measures

Technical mapping: key ENS measures × 42001 controls × EU AI Act articles

Operational framework — planning (op.pl)

Operational framework — access control (op.acc)

Operational framework — operation (op.exp)

Operational framework — external services (op.ext)

Operational framework — continuity (op.cont)

Operational framework — monitoring (op.mon)

Protection measures — communications (mp.com)

Protection measures — applications (mp.sw)

Protection measures — information (mp.info)

Protection measures — services (mp.s)

Master table of triple compliance — the 25 relevant controls consolidated

Applied case: multi-tenant chatbot for public administration

The chatbot’s 25 key technical capabilities consolidated

The five traps of triple compliance

What we have not covered (upcoming posts)

References

See also

ISO/IEC 42001: the operations manual for the AI system — how the AIMS fits over the on-premise LLM platform described in this blog

TL;DR

The analogy: the aircraft operations manual

ISO/IEC 42001 in 15 seconds

Distinction from neighbouring frameworks

The seven clauses (Annex SL): the mandatory table of contents

Clause 4 — Context of the organisation

Clause 5 — Leadership

Clause 6 — Planning

Clause 7 — Support

Clause 8 — Operation

Clause 9 — Performance evaluation

Clause 10 — Improvement

The 38 Annex A controls: the AI-specific catalogue

Cross-mapping: 38 controls ↔ blog posts

A.2 — AI policies (2 controls): PARTIAL

A.3 — Internal organisation (3 controls): GAP

A.4 — Resources (6 controls): COVERED

A.5 — Impact assessment (5 controls): PARTIAL

A.6 — AI system lifecycle (4 controls): COVERED

A.7 — Data for AI systems (5 controls): COVERED

A.8 — Information for interested parties (4 controls): COVERED

A.9 — Use of AI systems (3 controls): COVERED

A.10 — Third parties and customer relationships (4 controls): COVERED

The roles defined by the standard

Impact levels and proportionality

The seven minimum AIMS documents

Applied case: the blog’s multi-tenant chatbot → 42001 checklist

Cross-mapping with the EU AI Act, NIS2 and ENS

EU AI Act (Reg. 2024/1689) — seven directly aligned articles

NIS2 (Dir. 2022/2555) — three pillars with overlap

ENS (RD 311/2022)

The five usual certification traps

What we have not covered (upcoming posts)

References

See also

Operational framework — planning (`op.pl`)

Operational framework — access control (`op.acc`)

Operational framework — operation (`op.exp`)

Operational framework — external services (`op.ext`)

Operational framework — continuity (`op.cont`)

Operational framework — monitoring (`op.mon`)

Protection measures — communications (`mp.com`)

Protection measures — applications (`mp.sw`)

Protection measures — information (`mp.info`)

Protection measures — services (`mp.s`)