AI governance for a private LLM platform: ISO/IEC 42001, NIST AI RMF and the controls behind them

ISO/IEC 42001 and NIST AI RMF for an internal LLM platform

ISO/IEC 42001:2023 specifies requirements for an AI management system, the policies, roles, risk process, controls and reviews through which an organisation governs the AI it develops, provides or uses. NIST’s AI Risk Management Framework 1.0 and its Generative AI Profile, NIST AI 600-1, describe the same risk work in four functions and suggest concrete actions for generative AI. For a company that runs its own LLM platform, both turn AI governance into a short list of technical controls: an inventory of models and use cases, access rights tied to roles, a query log with a retention rule, evaluation records for every model change, an incident process and records of suppliers.

This guide maps both to those controls and their evidence for a platform serving 500 to 2,000 employees. It describes ISO/IEC 42001 only from what ISO publishes openly.

What ISO/IEC 42001 specifies, from ISO’s public pages

ISO/IEC 42001:2023 was published on 18 December 2023 as edition 1 by the joint committee ISO/IEC JTC 1/SC 42. ISO’s page says it “specifies requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System (AIMS) within organizations.” Its FAQ calls it a management system standard that uses the Plan-Do-Check-Act method, and sets it apart from ISO/IEC 22989, 23053 and 23894, which cover AI terminology and concepts, a framework for AI systems that use machine learning, and guidance on AI risk management.

ISO’s explainer on the standard, as read on iso.org in October 2026, lists the areas in which ISO/IEC 42001 defines requirements. They are leadership and organisational context, AI policy and objectives, risk management for AI systems, data governance and system lifecycle controls, transparency and information provision, performance evaluation and monitoring, and continual improvement.

Certification is voluntary. ISO’s explainer says it “is carried out by independent certification bodies, which may be accredited by national accreditation bodies”, and states that ISO does not certify organisations. ISO/IEC 42006:2025, published in July 2025, sets the additional requirements for bodies that audit and certify AI management systems according to ISO/IEC 42001, and builds on ISO/IEC 17021-1. For the platform team, this means records that an internal or certification audit can inspect, such as who approved a use case, which model version answered, what was tested before a change and how an incident was closed.

NIST AI RMF 1.0 and the Generative AI Profile

NIST released the AI RMF 1.0 on 26 January 2023 and describes it as “intended to be voluntary, rights-preserving, non-sector-specific, and use-case agnostic”. It organises the work in four functions. Govern “cultivates and implements a culture of risk management within organizations” and runs through the other three. Map establishes the context of an AI system’s risks, Measure assesses them, and Manage allocates resources to them. Each function breaks down into categories and subcategories, such as GOVERN 1.6: “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.”

NIST published NIST AI 600-1, the Generative Artificial Intelligence Profile, on 26 July 2024. It lists 12 risks that are unique to generative AI or made worse by it, among them confabulation, data privacy, information security and value chain and component integration, and suggests actions with identifiers such as GV-1.6-003. As of October 2026, NIST’s AI RMF page says the AI RMF 1.0 “is being revised as part of the White House AI Action Plan”; the framework itself expects a review with formal input from the AI community no later than 2028. ISO/IEC 42001 is the standard an organisation can be certified against; the NIST subcategories and suggested actions make a workable checklist for its controls.

AI governance requirements mapped to platform controls

Most governance requirements are implemented in the directory service, the gateway in front of the models, the serving layer, the retrieval index and the ticket system. The table pairs each requirement with its control and the record a reviewer can inspect.

ISO requirement areas from ISO’s explainer on ISO/IEC 42001 (iso.org); subcategories from NIST AI 100-1 (AI RMF 1.0, January 2023); action IDs from NIST AI 600-1 (July 2024). Controls and evidence are our examples.

Our guide to prompt injection and LLM security covers the security tests that belong in the evaluation and incident rows.

Our Private AI/ML service builds the platform with a query log, data and permissions management, so security and legal see who accesses what. Describe your models, use cases and number of users in the form below.

Model and use-case inventory: a worked example for 1,500 users

Take a company of 1,500 staff running a private LLM platform on two GPU servers on-premise, with three open-weight models behind one gateway. Six use cases are approved: drafting and translation for all staff, search over internal policies with RAG, contract summaries for the legal team, a code assistant for 80 developers, ticket classification in the service desk and an HR FAQ for employees.

Each use case gets one inventory entry. It holds the purpose, the business owner, the directory group of its users, the data classes allowed in prompts and in the retrieval index, the model and its exact version, the serving engine version, the evaluation set and its last result, a risk rating and the next review date. NIST’s GV-1.6-003 adds data provenance and the “underlying foundation models, versions of underlying models, and access modes”. Record the checkpoint and its revision, the quantisation, the system prompt version and the index version, since each changes the answers.

GV-1.6-002 asks organisations to define in policy any inventory exemptions for generative AI systems embedded in application software; our guide to shadow AI policy and controls covers those tools. If HR later asks to pre-screen job applications with the platform, that is a new use case with a new risk entry, because analysing and filtering job applications is listed in Annex III, point 4(a), of the AI Act.

Access rights, query logging and retention

Access follows the directory. Each use case has a directory group, the gateway issues keys per application and team, and RAG retrieval checks the user’s document permissions at query time, so an answer draws only on files the user is allowed to open. Administrator rights on the gateway, the log store and the model registry go to named people, in line with GOVERN 2.1, which asks for roles and responsibilities to be documented.

The query log records, per request, the user or application, the time, the use case, the model and its version, and the prompt and answer or only their metadata, as the policy decides. Logged prompts can contain personal data, so the retention period is set per use case together with data protection. For deployers of high-risk AI systems, Article 26(6) of the AI Act requires the logs the system generates automatically to be kept for at least six months, to the extent they are under the deployer’s control, unless applicable Union or national law, in particular Union data protection law, provides otherwise; for Annex III uses this applies from 2 December 2027. Restrict read access to the log itself and log that access too. The mechanics of keys, budgets and logging are in our guide to an LLM gateway for a company.

Engineering by our partner Vixen.UNO covers access rights, query logging and protection against prompt injection on the platform. Send us the controls your ISO/IEC 42001 project asks for through the form below, with your current setup.

Evaluation records, incidents and supplier records

MEASURE 2.1 asks that “Test sets, metrics, and details about the tools used during TEVV are documented”, and GV-1.5-003 suggests a document retention policy that keeps the history of test, evaluation, validation and verification. On the platform this means a fixed regression set per use case, run before every change of model, prompt or serving engine, with results and approver stored with the release. Our guide to LLM evaluation before model upgrades covers the metrics and the release procedure.

For incidents, add an AI category to the ticket system you already run. Typical cases are a wrong answer that fed a decision, a document shown to the wrong user, an injected instruction in a retrieved document and harmful output. GV-4.3-002 asks organisations to define the minimum set of criteria for an incident report, such as system ID, title, reporter and date of the incident, and GV-1.5-002 suggests after-action reviews of incident response.

Suppliers of an on-premise platform include the model publishers, the open-source projects behind the serving engine and the vector database, the hardware vendors, the engineering partner and any external API provider. GV-6.1-007 suggests an inventory of all third parties with access to organisational content and lists of approved generative AI technology and service providers. GV-6.2-002 asks for incidents involving third-party generative AI data and systems to be documented, “including opendata and open-source software”. For each supplier, record the component, its version and source, its licence and the channel through which it publishes security advisories.

Roles in AI governance for an LLM platform

GOVERN 2.3 places responsibility for decisions about AI risks with executive leadership, and GOVERN 2.1 asks for roles and lines of communication to be documented. A company of 200 to 2,000 staff can combine roles, as long as each one has a named holder.

Example allocation; responsibility and documentation of roles from NIST AI 100-1, GOVERN 2.1 and 2.3; leadership as a requirement area from ISO’s explainer on ISO/IEC 42001.

How ISO/IEC 42001 relates to the EU AI Act

The AI Act sets legal obligations by role and by use, while ISO/IEC 42001 is a voluntary standard for how an organisation manages AI. For an internal assistant used for drafting, search and summaries, two obligations apply today: measures to support the development of AI literacy of the staff who use it (Article 4, applicable since 2 February 2025) and, where the use fits them, the transparency duties of Article 50 (applicable since 2 August 2026). The high-risk rules, with the deployer obligations of Article 26, attach only to uses listed in Annex III. Under the AI Act as amended by Regulation (EU) 2026/1744, in force since 27 July 2026, they apply to those uses from 2 December 2027. The inventory shows which use case falls into which category. Which obligations apply to a given use case is a legal assessment for the company’s legal department, and our guide to EU AI Act deployer obligations sets out the articles and dates.

What we do

Our Private AI/ML service builds private LLM platforms on-premise or in an EU Tier-3 data centre in Lithuania, with engineering by our partner Vixen.UNO. The service includes protection against prompt injection, data and permissions management, and logging of queries and answers, so that security and legal see who accesses what, and how. External APIs are enabled only by your explicit decision and are visible in the query log. We deliver the technical part and train your team to run the platform; the legal compliance assessment stays with your legal department, and any certification is done by an independent certification body. How we handle data during a project, and the certificates of the data centres where hosted solutions run, are set out on our security and compliance page.

FAQ