Enterprise AI Governance Best Practices - Govern the Inventory of AI Models
Enterprise AI Governance Best Practices
Chapter 19. Govern the Inventory of AI Models
Why the AI Model Inventory Matters
The AI Model Inventory identifies the models the enterprise builds, buys, configures, fine-tunes, embeds, invokes, or relies on.
AI Models are important governance objects because they shape AI behavior, outputs, performance, limitations, risks, and accountability. A model may summarize, classify, predict, generate, recommend, retrieve, rank, detect anomalies, translate, reason over text, generate code, interpret images, process speech, or support agentic action.
The AI Model Inventory matters because the enterprise must know which models are in use, where they came from, who owns them, which use cases they support, which technical assets invoke them, which agents depend on them, which data shaped them, which evaluations were performed, which limitations are known, which versions are approved, and when they should be reassessed or retired.
However, model governance is not the same as Enterprise AI Governance. The AI Model Inventory is necessary but not sufficient. Models must be governed in relation to use cases, agents, AI Prompts, data, technical assets, vendors, locations, regulations, controls, outputs, incidents, and evidence.
What an AI Model Is
An AI Model is a computational capability that has been trained, configured, tuned, prompted, or otherwise prepared to perform AI-related tasks.
Models may include foundation models, large language models, small language models, machine-learning models, classification models, predictive models, recommendation models, image models, speech models, embedding models, ranking models, anomaly-detection models, forecasting models, generative models, and specialized domain models.
A model may be internally developed, open source, commercially licensed, vendor-hosted, cloud-provided, fine-tuned, retrieval-augmented, embedded inside a product, or exposed through an API. Some models are directly visible to the enterprise. Others are hidden behind vendor products or SaaS features.
The enterprise should govern models it builds and models it directly selects. It should seek appropriate visibility into vendor models where those models materially affect enterprise risk, data exposure, outputs, decisions, or obligations.
Minimum Information in the AI Model Inventory
The AI Model Inventory should capture enough information to govern model identity, source, ownership, versioning, approval, evaluation, limitations, and use.
At a minimum, an AI Model record should identify the model name, provider, owner, model type, model purpose, version, source, license, deployment pattern, hosting environment, supported AI Use Cases, related AI Agents, related technical assets, related AI Prompts, related Data and Information, training or fine-tuning data where known, evaluation results, known limitations, risk classification, approved uses, prohibited uses, location restrictions, regulatory obligations, controls, monitoring requirements, incident history, lifecycle state, review date, and evidence package.
The record should also distinguish whether the model is internally developed, vendor-provided, open source, fine-tuned, embedded, API-based, locally hosted, cloud-hosted, or part of a vendor product.
Model Source, Provenance, and Licensing
Model source and provenance are critical governance attributes.
The enterprise should know where the model came from, who developed it, who provides it, how it is licensed, whether it is open source or commercial, whether it has usage restrictions, whether it can be used for the intended purpose, whether it can process the intended data, and whether it can be deployed in the intended locations.
For internally developed models, the enterprise should understand the development process, training data, feature engineering, model architecture where relevant, evaluation history, approval records, and ownership.
For vendor-provided models, the enterprise should understand the provider, contractual terms, data-use terms, retention terms, regional processing, subprocessor involvement, model-change practices, logging options, security posture, and available documentation.
For open-source models, the enterprise should understand license terms, provenance, maintenance status, security concerns, model-card availability, community risk, modification history, and suitability for the intended use.
Model Versioning and Change Management
AI Models must be versioned and governed over time.
A model version can affect behavior, quality, risk, bias, accuracy, security, performance, latency, cost, and regulatory posture. A model that was appropriate for a use case at one point in time may become inappropriate after a version change, fine-tuning change, vendor update, AI Prompt change, data change, or change in intended use.
The AI Model Inventory should identify approved model versions and connect model changes to use cases, agents, technical assets, AI Prompts, testing evidence, approval records, incidents, and release records.
The enterprise should define which model changes require review. Material changes may include moving to a new model family, changing a foundation model, changing a fine-tuned version, changing embedding models, changing model configuration, changing hosting location, changing vendor model terms, changing safety behavior, or allowing a model to support a new high-risk use case.
Model Evaluation and Testing
AI Models should be evaluated and tested according to their intended use and risk.
Evaluation may include accuracy, reliability, robustness, bias, fairness, security, privacy, explainability, latency, cost, hallucination tendency, refusal behavior, safety behavior, retrieval quality, domain fit, and performance under expected and adverse conditions.
The required evaluation depth should depend on the model’s use. A model used for low-risk internal brainstorming may require limited review. A model used for customer-facing support, employee-impacting decisions, regulated recommendations, clinical support, financial analysis, legal review, or agentic action requires stronger evaluation, documentation, monitoring, and evidence.
Evaluation results should not sit outside the governance model. They should connect to AI Model records, AI Use Cases, AI Agents, technical assets, AI Prompts, Data and Information, Controls, Risks, and Evidence.
Model Limitations and Approved Uses
The AI Model Inventory should document known limitations and approved uses.
A model may have limitations related to domain knowledge, factual accuracy, recency, language support, jurisdictional understanding, bias, explainability, structured reasoning, privacy, security, code quality, hallucination, adversarial robustness, or sensitivity to prompt wording.
These limitations matter because the same model may be acceptable for one use and unacceptable for another. A model may be approved for internal productivity but not for customer-facing outputs. It may be approved for summarization but not for final decision-making. It may be approved for one jurisdiction but not another. It may be approved with human review but not autonomous action.
The AI Model Inventory should identify approved uses, prohibited uses, restricted uses, required controls, and required oversight patterns.
Relationship to AI Prompts, Data, and Context
Models do not operate alone. Their behavior is shaped by AI Prompts, data, and context.
A model may produce different outcomes depending on system prompts, developer prompts, user prompts, retrieval content, memory, configuration, tool instructions, temperature, safety settings, and workflow context. A model that performs well with one AI Prompt or RAG corpus may perform poorly with another.
For this reason, the AI Model Inventory should connect to the AI Prompt Inventory, Data and Information inventories, RAG corpora, knowledge sources, configuration records, and evaluation evidence. The enterprise should evaluate model behavior in the context in which the model is actually used, not only in abstract isolation.
This is especially important for agentic AI, where model behavior may influence tool calls, workflow decisions, escalations, and system actions.
Location and Vendor Considerations
Model governance must include location and vendor considerations.
A model may be hosted in one region, invoked from another, process data from a third, and affect stakeholders in a fourth. A vendor may provide different models or model behavior by region. A model may be unavailable, restricted, or unapproved in certain jurisdictions. Data-processing, retention, disclosure, and transfer obligations may depend on where model processing occurs.
The AI Model Inventory should connect models to hosting locations, processing locations, vendor records, contracts, subprocessors, applicable regulations, regulatory obligations, controls, and evidence.
This is especially important for API-based and vendor-hosted models, where the enterprise may not control infrastructure but remains accountable for approved use.
Lifecycle of an AI Model
The AI Model Inventory should manage lifecycle state.
Common lifecycle states may include proposed, under evaluation, approved for experimentation, approved for limited use, approved for production, active, restricted, deprecated, suspended, remediating, retired, rejected, or prohibited.
Lifecycle governance should include selection, evaluation, approval, deployment, monitoring, reassessment, change management, incident handling, restriction, retirement, and evidence retention.
Models should be reassessed when use cases change, AI Prompts change, data sources change, vendor terms change, model versions change, hosting locations change, performance degrades, incidents occur, obligations change, or risk classification changes.
Governance Questions the AI Model Inventory Should Answer
For aI Model Inventory, governance should answer what exists, who owns it, what is affected, which risks, obligations, controls, evidence, incidents, changes, and gaps require action.
Copyright for the International Foundation for Information Technology (IF4IT): 2008 - Present
Legal Disclaimers