Your engineering team is shipping features with AI models they found on Hugging Face. Your data science group is testing LLMs through third-party APIs. Your support team just integrated a chatbot someone built in a hackathon. None of these assets appear in your CMDB, your security scans, or your compliance documentation.
This isn't innovation. It's technical debt with a countdown timer.
Scope: What This Guide Covers
This guide helps you build and maintain an AI asset registry that works within existing governance frameworks. You'll get specific steps for cataloging models, APIs, and AI-enabled services, and mapping them to the controls you already enforce for traditional software components.
This guide does NOT cover AI model development practices, MLOps toolchains, or data science workflows. The focus here is governance: knowing what AI assets you have, where they came from, and whether they meet your security and compliance requirements.
Key Concepts and Definitions
AI Asset: Any machine learning model, large language model API, AI-enabled service, or pre-trained model weight file that processes data or makes decisions in your environment. This includes:
- Downloaded model files (Hugging Face, GitHub, internal repos)
- API integrations (OpenAI, Anthropic, Cohere, etc.)
- Embedded AI features in SaaS products
- Internal models trained by your data science team
AI Registry: A centralized inventory tracking every AI asset's provenance, approval status, data classification clearance, and mapped compliance requirements. Think of it like your container registry, but for models and AI services.
Blind Spot Debt: The accumulated risk from untracked AI assets. JFrog's analysis showed a 7X spike in malicious models. If you can't inventory your AI assets, you can't scan them, patch them, or revoke them when threats emerge.
Requirements Breakdown
Your AI registry must satisfy existing control requirements, not create parallel governance:
ISO/IEC 27001:2022 Annex A.8.1 (Asset Management): AI models are information processing assets. They require the same identification, ownership, and acceptable use documentation as your application servers.
SOC 2 Type II CC6.1 (Logical Access): If an AI model accesses customer data, you need the same access reviews and approval workflows you apply to database credentials or API keys.
NIST CSF v2.0 ID.AM-1 (Asset Inventory): "Physical devices and systems within the organization are inventoried." Extend this to include AI models deployed on those systems.
PCI DSS v4.0.1 Requirement 12.3.1: Maintain an inventory of system components. If your AI model touches cardholder data (fraud detection, payment routing), it's a system component.
The pattern: your existing frameworks already require asset inventories. AI models aren't exempt just because they're new.
Implementation Guidance
Phase 1: Discovery (Weeks 1-2)
Start with what you can instrument immediately:
API Gateway Logs: Parse your gateway logs for calls to known AI service endpoints (api.openai.com, api.anthropic.com, etc.). Export unique endpoints and the teams making calls.
Dependency Scanning: Run your existing SBOM tools against repositories. Look for packages like transformers, langchain, openai, anthropic, or model files (.pt, .ckpt, .safetensors, .onnx).
SaaS Audit: Review your SaaS contracts and user analytics. Many tools now embed AI features (Salesforce Einstein, Zendesk AI, GitHub Copilot). These count as AI assets if they process your data.
Self-Reporting: Send a one-question survey to engineering leads: "What AI models or APIs does your team use?" You'll get 60-70% coverage from this alone.
Phase 2: Registry Schema (Week 3)
Build your registry with these minimum fields:
| Field | Purpose | Example |
|---|---|---|
| Asset ID | Unique identifier | ai-asset-1847 |
| Asset Type | Model file, API, embedded service | API Integration |
| Source | Where it came from | OpenAI GPT-4 API |
| Owner | Team responsible | customer-support-eng |
| Data Classification | Highest data class it touches | PII, PCI |
| Approval Status | Vetted, pending, blocked | Vetted |
| Compliance Scope | Which frameworks apply | SOC 2, PCI DSS |
| Last Reviewed | Governance review date | 2024-01-15 |
Store this in your existing CMDB or asset management system. Don't build a separate database.
Phase 3: Policy Enforcement (Weeks 4-6)
Automated checks prevent blind spot accumulation:
Pre-Deployment Gate: Add a check to your CI/CD pipeline. Before deploying any service, scan for AI dependencies. If found, verify the model appears in your registry with "Vetted" status. Block deployment otherwise.
API Monitoring: Configure your gateway to alert (or block) calls to AI service endpoints not in your registry. This catches shadow AI usage in real-time.
Quarterly Access Reviews: Treat AI assets like privileged accounts. Every quarter, confirm with asset owners: still in use? Still approved? Data classification unchanged?
Vendor Risk Assessments: When an AI API vendor appears in your registry, trigger your standard third-party risk assessment. Many companies lack formal AI governance policies, so don't assume your vendors have their house in order.
Common Pitfalls
Pitfall: Treating AI governance as a separate program. Don't create new committees, new approval workflows, or new compliance documentation. Map AI assets to existing controls and use existing processes.
Pitfall: Blocking everything by default. If your registry process takes three weeks, engineers will route around it. Set a 48-hour SLA for "Pending" to "Vetted" transitions for common models (GPT-4, Claude, Llama 2).
Pitfall: Ignoring embedded AI in SaaS. Your CRM's new "AI insights" feature processes customer data. If you wouldn't let that vendor query your database directly, you shouldn't let their AI model do it either.
Pitfall: No deprecation process. Models get replaced. APIs get sunset. Your registry needs a workflow for marking assets as deprecated and confirming dependent services have migrated.
Quick Reference Table
| Task | Frequency | Owner | Tool/Process |
|---|---|---|---|
| Scan repos for AI dependencies | Every commit | CI/CD pipeline | SBOM scanner + custom rules |
| Review API gateway logs for new AI endpoints | Weekly | Security Engineering | SIEM alert for unknown endpoints |
| Vet new AI assets | Within 48h of request | Security + Compliance | Standard vendor risk assessment |
| Access review for all AI assets | Quarterly | Asset owners | Same process as privileged access |
| Update registry for deprecated assets | When announced | Engineering leads | Ticket in asset management system |
| Report AI asset inventory to auditors | Annually (or per audit) | Compliance Manager | Export from CMDB |
Your AI registry isn't a research project. It's an extension of asset management you're already doing. Build it now, before the next audit asks you to produce an AI inventory you don't have.
