the bit that actually does the thinking. not the app, not the chatbot, not the agent — the weights. people confuse these constantly.
A trained artifact performing inference by mapping inputs to outputs. A model is a component of a system, not a system itself. Each distinct model (including fine-tunes) requires its own Model Card entry in ART-01. The distinction between model, system, and application is not semantic pedantry — it is the foundation on which governance obligations, risk assessments, and regulatory classifications are built.
Why It Matters
The single most common source of confusion in enterprise AI governance is the conflation of model, system, and application. When the board asks “how many AI models do we have?” and nobody can answer, the problem is not inventory — it is definitional. People use “model” to mean the trained weights, the API endpoint, the application, the chatbot, and the vendor product interchangeably. Each of these is a different thing with different governance requirements.
A model is the trained artifact — the weights, parameters, and architecture that map inputs to outputs. GPT-4 is a model. Claude is a model. Llama 3 is a model. ChatGPT is not a model; it is a system that uses a model. Microsoft Copilot is not a model; it is an application that orchestrates multiple models. This distinction determines who is the provider, who is the deployer, which risk assessment applies, and what documentation is required.
The EU AI Act draws this distinction explicitly. Art. 3 defines “AI model” and “AI system” as separate concepts with separate obligation sets. Confusing them means misclassifying your regulatory obligations. The NIST AI RMF similarly distinguishes between model-level and system-level governance. An organisation that governs “AI” as a monolithic concept without distinguishing models from systems will create governance structures that are either too broad (treating every model as a system) or too narrow (governing the system while ignoring the models inside it).
The Stress Test
Your AI governance team asks each business unit to register their AI models. Marketing registers “ChatGPT” (a product, not a model). Finance registers “our fraud detection system” (a system, not a model). Engineering registers “the Llama model we fine-tuned” (correct — a model). Customer service registers “our chatbot” (an application, not a model).
Your registry now contains products, systems, models, and applications, all labelled as “models.” You cannot determine how many distinct models you run, which models are in which systems, which models share training data, or which models are fine-tunes of which base models. Your governance framework is built on a taxonomy that your organisation has not adopted. The registry exists. The inventory does not.
In the Wild
A European bank conducted an AI inventory as part of its EU AI Act preparation. The initial count identified 23 “AI systems.” When a governance consultant decomposed those systems into their component models, the count rose to 67 distinct models. A single customer service chatbot used five models: a foundation model for generation, an embedding model for semantic search, a reranking model for relevance ordering, a classification model for intent routing, and a moderation model for safety filtering.
Each of these models had different provenance (three were open-source, one was proprietary, one was fine-tuned in-house), different licences, different update cycles, and different failure modes. The bank had been governing the chatbot as one thing. It was five things, each requiring its own Model Card, risk assessment, and monitoring plan.
You cannot govern what you have not decomposed. The system-level view is necessary but insufficient. Model-level governance is where the operational controls actually attach.
The EU AI Act (Art. 3) defines “AI system” (para. 1) and “general-purpose AI model” (para. 63) as distinct concepts with distinct obligation sets. A model provider has transparency obligations under Art. 53: technical documentation, copyright policy compliance, and a sufficiently detailed summary of training data. A system provider has the full high-risk obligation set: risk management (Art. 9), data governance (Art. 10), human oversight (Art. 14), and conformity assessment (Art. 43).
Organisations that conflate model and system risk misclassifying their obligations. An organisation using a third-party model API is a system deployer, not a model provider. An organisation that fine-tunes that model may become a model provider. The classification depends on the distinction being clear.
The regulation cares about the difference between a model and a system. If your governance framework does not, your compliance programme has a structural gap.
Multiple enterprises reported incidents where their AI vendor silently updated the underlying model version. OpenAI, Anthropic, and Google have all updated model versions behind the same API endpoint. For organisations that did not track model versions in their governance documentation, this meant their risk assessments, evaluation results, and compliance documentation referred to a model that was no longer running in production.
The practical impact: evaluation benchmarks became invalid (the new model version might perform differently on the tests that justified deployment), safety assessments became stale (the new version might have different failure modes), and regulatory documentation became inaccurate (the documented model was not the deployed model).
If your governance documentation says “GPT-4” but your vendor has silently moved to GPT-4o, your risk assessment describes a model that no longer exists in your system. Model version tracking is not optional.
How to Govern It
Define model, system, and application. Then build your governance on those definitions.
Within the AI Enterprise Control Index, model governance spans multiple layers and shields:
- AI Engineering (L5) — The primary control layer. Every distinct model requires a Model Card entry in the ART-01 registry: model name, version, provenance, training data summary, evaluation results, known limitations, and intended use. Fine-tuned variants are new models, not versions of the base model.
- Supply Chain (S3) — Model provenance tracking: where did the model come from, who trained it, what licence governs its use, and how are version updates communicated? Vendor models require contractual provisions for version change notification.
- GRC (S1) — Risk assessment at the model level, not just the system level. Each model has its own failure modes, bias profile, and regulatory classification. The system-level risk assessment aggregates model-level assessments but does not replace them.
- Observability (S4) — Model-level monitoring: performance metrics, drift detection, and version verification for each model in the system. A system-level health check that does not decompose to model-level metrics cannot identify which component is degrading.
- Applications & Agents (L4) — System architecture documentation showing which models are components of which systems, how they interact, and what happens when one fails. The system is the governance boundary; the models are the governed components.
When It’s Relevant
Every AI governance programme. The model-system-application taxonomy is foundational. Without it, your registry is a list of names, your risk assessments target the wrong level of abstraction, and your compliance programme cannot determine which obligations apply to which teams.
Model-level governance is critical when:
- Your systems use multiple models and you need to track each one’s provenance, version, and performance
- You are classifying your EU AI Act obligations and need to distinguish model provider from system deployer
- Your vendor updates model versions and you need to detect when your governance documentation becomes stale
- An incident occurs and you need to determine which model in which system caused the failure
- You are building an AI inventory and need a consistent taxonomy across business units
Related Terms
References
- [1] European Parliament and Council (2024) Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act), Article 3: Definitions. Official Journal of the European Union.
- [2] Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I.D. and Gebru, T. (2019) ‘Model Cards for Model Reporting’, Proceedings of FAT* 2019, pp. 220–229.
- [3] NIST (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology, U.S. Department of Commerce.
- [4] OECD (2024) AI Principles: Definitions of an AI system. Organisation for Economic Co-operation and Development.
- [5] Board of Governors of the Federal Reserve System (2011) Supervisory Guidance on Model Risk Management (SR 11-7). Washington, D.C.
- [6] Bommasani, R., Hudson, D.A., Adeli, E., et al. (2021) ‘On the Opportunities and Risks of Foundation Models’, arXiv preprint, arXiv:2108.07258.
- [7] Liang, P., Bommasani, R., Lee, T., Tsipras, D., Soylu, D., et al. (2023) ‘Holistic Evaluation of Language Models’, Transactions on Machine Learning Research.
AI Enterprise Control Index v6.0 · Glossary · June 2026 · i-DEPOT 158508 (BOIP) · CC BY-NC-ND 4.0
By Jeroen Janssen, Apparens