A spreadsheet is where AI model inventories go to die. It will hold the first 12 rows beautifully: the Anthropic Claude license your engineering team uses, the OpenAI tenant marketing bought, the Llama fine-tune the data-science group is running on a single GPU under someone's desk. Then the inventory grows. Versions split. Two people edit at once. The eval-status column drifts out of date because nobody updated it after the last Promptfoo run. The risk-tier column gets stale because a colleague forgot Article 27 FRIA was now triggered. By the time the auditor asks for evidence in month 11, the spreadsheet is a graveyard of stale assumptions and the AI Officer is rebuilding it from scratch the night before the audit. Lesson 020 is the schema that replaces the spreadsheet: twelve-plus fields a real inventory needs in May 2026, the four governance platforms competing for the L2 procurement budget (Credo AI, Holistic AI, Modulos, Trustible), the case for extending an existing CMDB instead, and the operational difference the Credo AI Python SDK makes versus a UI-only platform.

Why the Spreadsheet Fails - Five Decay Modes Every Inventory Hits

Every L1 program in 2024 and 2025 started its AI inventory in Excel or Google Sheets. The pattern was rational at small scale. Procurement had a list of vendors. Engineering had a list of model deployments. Combine the two, add a risk-tier column, sit it in front of the AI Officer, declare victory. By month six the spreadsheet has cracked along five predictable decay lines that any L2 governance lead can name.

Decay 1 - Drift. A model is upgraded by the vendor (GPT-4o becomes GPT-4o-2026-04-12; Claude 3.5 Sonnet becomes Claude 3.5 Sonnet v2). The inventory row says "GPT-4o" without a version pin. The eval evidence captured against the prior version is no longer the truth of the deployment. By the time someone notices, the audit-evidence retention has lost its connection to the production model.

Decay 2 - Version control. A spreadsheet has no native versioning. Changes happen invisibly. When the auditor asks "what was the risk-tier on 2026-02-15 for the contract-review assistant?" the program cannot answer. The Sheets revision history is too granular to be searchable; the Excel SharePoint history is too coarse to be useful.

Decay 3 - Multi-user editing. The intake-form lead, the procurement officer, the AI Officer, the engineering tech lead, the data-privacy lead, and the legal counsel all need write access. The spreadsheet either becomes locked-down read-only (and stale) or open-for-edit (and chaotic). The merge-conflict pattern that destroyed Word documents in the 2000s destroys AI inventories in the 2020s.

Decay 4 - Integration with downstream artifacts. The AI inventory is supposed to feed twelve downstream artifacts: the Article 11 + Annex IV technical file, the Article 27 FRIA register, the Article 72 post-market monitoring plan, the Article 73 incident-report templates, the ML-BoM (CycloneDX 1.7), the ISO 42001 A.6.2 risk register, the NIST AI RMF Map outputs, the procurement contract register, the GPAI exposure map, the eval scoreboard (Promptfoo / Garak / PyRIT / Inspect), the red-team report archive, and the EU AI Office database submissions under Article 71. A spreadsheet integrates with none of these natively. Every downstream artifact becomes a copy-paste exercise; every copy-paste is a source of error.

Decay 5 - Audit-evidence retention. When the auditor (Schellman, A-LIGN, BSI, KPMG, EY, Deloitte) shows up for the ISO 42001 surveillance audit or the EU AI Act conformity-assessment review, the evidence question is not "what does your inventory say today?" The question is "what did your inventory say on the day this model was deployed, and what was the chain of decisions that brought it to that state?" A spreadsheet without versioning, change-logs, and approval-trail captures cannot answer this question. The audit finding writes itself.

The takeaway is not that spreadsheets are bad. They are excellent for a 5-row pre-program inventory and a useful sketch for L1 conversations. They are wrong as the system of record for an L2 governance program. The schema below is what replaces them.

The Twelve-Plus Schema Fields a Real Inventory Needs

The schema below is the operational expansion of the AI inventory from a "list of models" to a "system of record that defends the program." Each field has an article or framework citation behind it. This is not theoretical schema design; it is the inventory that survives a regulator request, a third-party audit, and a Friday-evening incident response.

Field 1 - Model ID (Unique Identifier)

A stable, namespaced identifier the organization controls. Format: org-tenant.system-name.model-instance (e.g., acme-eu.contract-review.claude-sonnet-prod, acme-eu.resume-ranker.gpt-4o-prod, acme-us.llama-finetune-marketing.v3). The identifier outlives the underlying vendor name; vendor consolidation, fork, or rebrand does not break the inventory's downstream references. The ID is the join key for every downstream artifact (ML-BoM, FRIA register, eval scoreboard, incident log).

Field 2 - Version (Semantic + Vendor)

Two version strings: (a) the organization's internal semver (1.4.2) tracking changes to the deployment surface (prompt updates, tool-config changes, fine-tune deltas); (b) the vendor's model version string verbatim (claude-3-5-sonnet-20241022, gpt-4o-2026-04-12, llama-3.1-405b-instruct). The two-string discipline keeps internal change control separate from upstream model evolution. When the vendor pushes a silent quality update, the vendor-string-change is detected by automated polling; the internal semver bumps for re-conformity review.

Field 3 - Owner (Business + Technical)

Two owners: the business owner (named individual accountable for use case, intended purpose, success criteria) and the technical owner (named individual accountable for deployment, monitoring, evals). Both have backup designees. This pairing matches ISO 42001 A.3 ("roles, responsibilities and authorities") and supports the Article 27 FRIA "responsible person" designation. The "owner is the AI team" anti-pattern fails on the first turnover.

Field 4 - Risk Tier

The EU AI Act tier with full citation: Article 5 prohibited, Article 6(1) high-risk (Annex I embedded product), Article 6(2) high-risk (Annex III stand-alone) with the specific Annex III paragraph numbered (§1 biometric, §2 critical infrastructure, §3 education, §4 employment, §5 essential services, §6 law enforcement, §7 migration, §8 administration of justice), Article 50 limited-risk transparency, or minimal-risk. Each tier carries different downstream obligations; the inventory row should make the tier explicit so the obligation set is unambiguous. Add an Article 51 column for any system built on a GPAI-with-systemic-risk model.

Field 5. Use Case + Intended Purpose

A one-sentence intended purpose statement aligned to the Article 3(12) "intended purpose" definition, plus a use-case category (customer-service chatbot, coding assistant, decision-support, content generation, embeddings, agentic workflow). The intended-purpose statement is what gets cited in the Article 13 instructions-for-use and the Article 26 deployer obligations. Drift between the inventory's intended purpose and the actual production use is one of the most common Mistake-2 audit findings.

Field 6 - Eval Status (Tool + Coverage)

Which evaluation tools cover the model, Promptfoo (now OpenAI-owned post Mar 9, 2026 acquisition), NVIDIA Garak (now under NVIDIA stewardship post April 2025 transfer), PyRIT (Microsoft), Inspect (UK AISI), OpenAI Evals, Anthropic's evals SDK, and the date of the last evaluation, the coverage scope (security, bias, hallucination, jailbreak, tool-use), the pass/fail rate, and the artifact link (eval-report storage URL). The eval-status column is not "yes / no"; it is "Promptfoo (security + jailbreak), last run 2026-05-10, 94% pass, report at evidence/eval/2026-05-10-contract-review.json".

Field 7 - Last Red Team (Date + Scope + Findings)

Date of the most recent red-team exercise, the scope (manual / automated / hybrid; framework: OWASP LLM Top 10 (2025), OWASP Agentic Top 10, MITRE ATLAS v5.4.0), the headline findings, the remediation status. Article 55(1)(a) requires this for designated GPAI providers; ISO 42001 A.6.1.3 expects it for high-risk systems. The "last red team: 2025-Q3" answer that an L1 program might tolerate is an audit finding at L2.

Field 8 - Data Lineage

Training data sources (for fine-tunes and internally-developed models), validation data sources, testing data sources, with provenance attestations. For commercial GPAI deployments the lineage points to the vendor's Article 53(1)(d) public training-data summary plus any RAG corpus the deployment uses. The field maps to Article 10 data and data governance for high-risk systems, ISO 42001 A.7 data governance, and NIST AI RMF Map 3 (categorization and characterization of AI risks). When the auditor asks "what is in the training data of the system that just produced a biased output," the inventory must point to an answer.

Field 9 - ML-BoM Reference (CycloneDX 1.7)

A pointer to the CycloneDX 1.7 ML-BoM document for the deployment. CycloneDX 1.7 (released 2025) added native ML-BoM components, model, model-card, dataset, dataset-card, and integrates with CDXA attestation for supply-chain integrity. The ML-BoM is the machine-readable companion to the human-readable inventory row; it sits in the build pipeline and is regenerated on every deployment. The inventory row references the ML-BoM by hash; the ML-BoM references the inventory row by ID. Bidirectional pinning is the audit-defensible pattern.

Field 10 - GPAI Dependency (Foundation Model + Article 51 Status)

The upstream foundation model, vendor, version, and Article 51 status: GPAI-with-systemic-risk (designated), plain GPAI under Article 53, or below-GPAI-threshold. Also: GPAI Code of Practice signatory status (Anthropic, OpenAI, Google DeepMind, Microsoft, Mistral, Cohere = signatories; Meta, Alibaba, Baidu, DeepSeek = non-signatories; others pending). This field is the join key between the AI inventory and the GPAI exposure map (lesson 003 of the program). When the audit committee asks "what is our exposure if Meta is sanctioned under Article 55?" the answer is filtered on this column.

Field 11 - Retraining Cadence + Last Retrain Date

For internally-developed and fine-tuned models, the planned retraining cadence (quarterly, semi-annually, event-triggered) and the date of the last retrain. For commercial GPAI deployments, the vendor's update cadence and the date of the last vendor version change consumed in production. The field supports Article 72 post-market monitoring obligations and ISO 42001 A.6.2 risk-treatment evidence (the risk register should reflect post-retrain re-evaluation).

Field 12 - Post-Market Monitoring Status (Article 72)

For high-risk systems: the post-market monitoring plan status (drafted, approved, operating), the monitoring metrics (accuracy, fairness, drift, incident-rate), the cadence of monitoring review, the date of the last monitoring-data review, and the link to the most recent monitoring report. Article 72 obligates the provider of a high-risk AI system to maintain a post-market monitoring plan; the inventory row evidences that the plan exists, is current, and is producing data.

Extra Fields - The L2 Set

Beyond the twelve core fields, an L2 inventory adds: Article 27 FRIA status (where applicable, drafted, approved, operating, refresh due); Annex IV technical-file status (for high-risk systems, assembled, gap-list, evidence pack location); substantial-modification change log (Article 43(4), every change that crosses the substantial-modification threshold with the re-conformity decision documented); Article 73 incident link (if any incident has been linked to the system, the report ID); regulatory citations (the specific articles, recitals, annexes, ISO controls, NIST functions the system maps onto, supports the "cite once, link many" cross-walk pattern); contract reference (procurement contract ID); budget code (for FY allocation and cost-tracking).

The full schema is approximately 20 fields. Implementations vary in field naming but converge on the same operational set. The next section is about where to put it.

Governance Platform Comparison - Credo AI, Holistic AI, Modulos, Trustible

Four governance platforms dominated the L2 procurement conversation in 2026 buyer guides. Each has a distinct posture and an opinionated take on what the AI inventory is and what surrounds it. Below is the operational comparison your AI Officer's selection memo needs.

Credo AI - The CI/CD-Integrated Platform

Credo AI's positioning in 2026 sharpened around the May 2026 launch of the Credo AI Python SDK and the introduction of the GAIA AI-Powered Governance Assistant. Fast Company named Credo AI to the 2026 Most Innovative Companies list (#6 in Applied AI) on the basis of these releases. The Python SDK is the operational difference. Where the UI-only governance platforms require a human to log in, populate fields, and click approve, the SDK turns those steps into pipeline operations: the model registers itself on deployment, the inventory updates itself on model version change, the eval status updates itself when the Promptfoo run completes, the FRIA-required flag triggers from the risk-tier classification.

Concrete examples of what the Python SDK buys you that the UI cannot: (1) CI/CD integration, the model registry, the inventory row, the eval link, and the approval workflow all advance as the CI pipeline runs, with no manual UI touch; (2) automated inventory updates on deployment-every kubectl apply that lands a new model version triggers an inventory mutation, with the change-log captured automatically; (3) programmatic policy enforcement, policies (e.g., "no model deployed to production without a passing PyRIT run in the last 30 days") become guard-rails enforced at the CI/CD gate, not human checklists; (4) cross-platform integration: the SDK calls Credo AI from ML platforms (MLflow, Vertex, SageMaker, Databricks), from internal CMDBs (ServiceNow, BMC, Lansweeper), and from incident-management tooling (PagerDuty, ServiceNow ITSM). GAIA, the AI assistant overlay on top, gives the AI Officer a natural-language query interface, "show me every model deployed to EU production this quarter without a Promptfoo run in the last 60 days", that produces the same result as a 200-line custom query against the underlying data.

Trade-offs: Credo AI is the most opinionated platform in the comparison. Programs that prefer a thin governance layer over their existing tooling sometimes find the platform pushes specific workflow patterns. The SDK requires engineering investment to integrate cleanly; programs without ML platform engineering capacity will spend on integration cost. Pricing is on the higher end of the L2 market.

Holistic AI - Bias Testing + LLM Evaluation + Shadow AI Discovery

Holistic AI's posture is multi-product: a bias-testing library (the open-source Holistic AI library, the commercial Holistic AI platform) plus an LLM evaluation engine plus a shadow-AI discovery module that scans SaaS, IdP logs, and browser telemetry for unsanctioned AI tools. The shadow-AI module integrates with the lesson 019 intake-form pattern, when the discovery scan finds a new SaaS-embedded model, the platform routes it into the intake-form workflow automatically.

For an inventory perspective, Holistic AI sits well with organizations that have a strong bias-and-fairness governance posture (e.g., financial services, HR-tech, healthcare). The bias-testing library is mature and used in Schellman / A-LIGN ISO 42001 audit evidence for A.6.1 (impact assessment) and A.6.2 (risk treatment). The shadow-AI module is the operational tool that complements the intake form and prevents the "we didn't know that team was using it" gap. Trade-off: the platform is less programmatic than Credo AI; the SDK story is narrower; CI/CD integration is achievable but requires more custom work.

Modulos - The Deepest EU AI Act Feature Coverage

Modulos's posture is EU-AI-Act-native. The platform was built around the Article 11 + Annex IV technical-file workflow, the Article 27 FRIA process, the Article 9 risk-management-system requirements, the Article 10 data-governance requirements, the Article 13 instructions-for-use generation, and the Article 71 EU AI Office database submissions. 2026 buyer guides repeatedly identify Modulos as the platform with the deepest EU AI Act feature coverage: every article and annex has a workflow, a template, a citation map, and a reporting output.

For an EU-headquartered or EU-deployment-heavy program, Modulos's EU-AI-Act-native posture is a competitive advantage. The platform handles GPAI exposure (lesson 003), Annex III tiering (lesson 002), FRIA (lesson 009), post-market monitoring (Article 72), substantial-modification logs (Article 43(4)), and Article 71 database submissions in a single integrated workflow. The Article 73 incident-reporting clocks (10 / 2 / 15 days) are built into the platform's incident-management module.

Trade-offs: Modulos's depth in the EU AI Act comes at the cost of breadth elsewhere. NIST AI RMF, ISO 42001, and U.S. state laws (Colorado AI Act, NYC Local Law 144) have lighter coverage. Programs whose primary regulatory regime is not the EU AI Act will find the value proposition narrower. Pricing reflects the EU enterprise positioning.

Trustible - The Registry + Governance Workflow

Trustible's posture is the AI registry plus the governance workflow that surrounds it. The platform leans on policy enforcement, vendor risk scoring, regulatory-update monitoring, and audit-evidence assembly. The product was designed around the Govern-Map-Measure-Manage cycle of the NIST AI RMF and the policy-control-evidence cycle of ISO 42001. For a U.S.-based program with a mixed regulatory exposure (state AI laws, NIST, sectoral regulators), Trustible's posture fits.

The vendor-risk-scoring module is one of the platform's distinguishing features: every foundation-model vendor is scored on Code-of-Practice signatory status, Article 51 designation, disclosure quality, regulatory posture, and incident history. The score updates automatically as the regulatory landscape moves (e.g., when a vendor moves from non-signatory to signatory, when the Commission designates a new model). Trade-offs: less depth in the eval-and-red-team tooling integration than Credo AI; less EU-AI-Act-native than Modulos; less bias-and-fairness-centric than Holistic AI.

Internal CMDB Extension - When It Actually Makes Sense

The fifth option in any 2026 selection memo is "extend the existing CMDB": ServiceNow CMDB, BMC Helix, Lansweeper, or an internal asset-management system already in operation for IT-asset governance. The case for CMDB extension is real and is the right call in three specific scenarios.

Scenario A - Small portfolio. If the organization has fewer than 20 AI systems and the trajectory is "growing slowly," the engineering and licensing cost of a dedicated platform exceeds the benefit. A ServiceNow CMDB extended with AI-specific custom fields (the twelve-plus schema above as ServiceNow CIs), tied into the existing change-management workflow, can do the job at marginal cost.

Scenario B - Deep existing CMDB investment. If the organization has a mature ServiceNow CMDB with disciplined CI relationships, automated discovery, and integration with the broader IT operations stack, the AI inventory naturally extends that investment. The relationships matter, "this AI model depends on this Kubernetes cluster, which sits on this AWS account, which is owned by this business unit", and a CMDB tracks those relationships natively. A dedicated AI governance platform may not.

Scenario C - Low regulatory complexity. If the organization is not deploying in the EU, has no Annex III high-risk systems, and has low GPAI-with-systemic-risk dependency, the regulatory-content depth of Credo AI / Holistic AI / Modulos / Trustible is excess capacity. A CMDB extension covers the operational inventory; the FRIA and post-market-monitoring workflows can be handled in adjacent GRC tooling.

The case against CMDB extension is also real. The CMDB does not natively handle eval scoreboards, red-team report archives, FRIA workflows, GPAI exposure mapping, Article 73 incident reporting against statutory clocks, or the cross-walk reporting that an L2 program needs at audit time. CMDB extension scales until the regulatory and audit demands outpace the CMDB's depth, at which point the migration cost is non-trivial.

Credo AI Python SDK vs. UI-Only Platforms - The Operational Difference

The Credo AI Python SDK launch in 2026 is significant beyond the marketing line because it changes the unit economics of AI governance work. A UI-only governance platform is governed by human throughput: the number of inventory updates, eval reviews, FRIA refreshes, and incident logs a human can complete per week. An SDK-driven platform is governed by pipeline throughput: every deployment becomes a governance event automatically, and human time is reserved for exceptions, escalations, and judgment calls.

What this looks like in practice for an inventory program:

UI-only pattern. Engineer deploys a model version change. Engineer remembers (or doesn't) to open the governance platform, find the inventory row, update the version field, attach the new eval report, and update the change log. Reviewer approves. Audit-evidence retention happens through the platform's UI. The pattern works for 10 deployments per week; it breaks for 100. Human errors accumulate. The "did the engineer remember to update the platform?" question becomes the audit risk.

SDK pattern. Engineer deploys via CI/CD. The pipeline step credoai.inventory.update(model_id, version, eval_report_path) runs automatically. The inventory updates. The change log captures the diff. The approval workflow notifies the reviewer. The reviewer either approves in the UI or the policy engine auto-approves based on policy (e.g., "minor semver bump + passing eval + same vendor model string = auto-approve"). The audit-evidence retention is automatic. The "did the engineer remember?" question disappears.

The SDK pattern is what the L2 program needs to scale beyond 20-30 AI systems. The UI pattern is fine for a small portfolio but does not survive growth without proportional headcount increase. The selection memo should explicitly cover the SDK-vs-UI question because the operating-cost difference compounds over time.

What the SDK does not solve: judgment calls. The intended-purpose statement, the risk-tier assignment, the FRIA approval, the substantial-modification decision under Article 43(4). These remain human decisions. The SDK reduces the time spent on mechanical work so the human time can be reserved for judgment work. This is the right reallocation; UI-only platforms force human time onto the mechanical work and leave less for judgment.

Cross-Walks - ISO 42001, NIST AI RMF, EU AI Act

The schema and platform choices should cross-walk cleanly to the three framework regimes the L2 program serves simultaneously.

ISO/IEC 42001:2023 Annex A. Control A.6.2 (risk treatment) expects an asset-level register that supports treatment decisions; the AI inventory is the asset register. Control A.10 (third-party relationships) expects per-vendor risk evidence; the GPAI dependency field with Code-of-Practice signatory status carries this. Control A.3 (roles, responsibilities, authorities) expects named ownership; the dual business/technical owner field carries this. Control A.7 (data governance) expects data-lineage evidence; the data-lineage field carries this.

NIST AI RMF 1.0. Function Map 1 (context establishment) expects the use-case + intended-purpose record; the inventory's use-case field carries this. Map 2 (categorization) expects a risk-tier classification; the risk-tier field carries this. Map 3 (data characterization) expects data-lineage evidence. Map 4 (third-party risk) expects vendor risk evidence; the GPAI dependency + Code signatory field carries this. Measure functions expect eval evidence; the eval-status and red-team fields carry this. Manage functions expect treatment, monitoring, and incident-response evidence; the post-market monitoring and incident-link fields carry this.

EU AI Act. Article 11 + Annex IV technical file is assembled from inventory data for every high-risk system. Article 27 FRIA uses the risk-tier + use-case + data-lineage + impact-affected-population fields. Article 71 EU AI Office database registration uses the model ID + provider + intended purpose + risk-tier + post-market monitoring status. Article 72 post-market monitoring uses the monitoring status field. Article 43(4) substantial-modification logs use the change-log field. Article 73 incident reporting uses the incident-link field with the 10 / 2 / 15-day clocks tracked against the report date.

The cross-walk discipline matters because the inventory is one artifact serving three audit conversations simultaneously. Write the schema once; map it three times; let the platform output the framework-specific views on demand.

The L2 Artifact Set - Three Documents the Program Owes

Lesson 020 produces three artifacts the L2 program owes by the end of Q1:

Artifact 1 - The inventory schema document. A formal schema specification covering every field, the data type, the allowed values, the validation rules, the cross-walk to ISO 42001 / NIST AI RMF / EU AI Act, the source-of-truth field (which system populates which field), and the refresh cadence. The schema document is the contract between governance, engineering, procurement, and audit. It is reviewed annually and after any major regulatory development (Omnibus VII follow-on, new Commission interpretive notes, new Annex III adjustments under Article 7).

Artifact 2 - The platform-selection memo. A memo covering the comparison above, Credo AI, Holistic AI, Modulos, Trustible, internal CMDB extension, with the organization's specific scoring against the criteria (regulatory exposure, portfolio size, SDK requirement, audit posture, integration depth, cost). The memo concludes with the selection and the rationale, signed by the AI Officer and the Chief Risk Officer. The memo is the audit-defensible answer to "why did you pick this platform?" eighteen months later.

Artifact 3 - The CI/CD integration architecture. A technical architecture document showing how the inventory platform integrates with the ML platform (MLflow, Vertex, SageMaker, Databricks), the CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins, Azure DevOps), the eval tooling (Promptfoo, Garak, PyRIT, Inspect), the incident-management tooling (PagerDuty, ServiceNow ITSM), and the existing CMDB. The architecture document is what the engineering team builds against. It captures the auth model, the data-flow direction, the failure modes, and the policy-engine integration. Without this document, the platform selection has no implementation plan.

Six Common Mistakes - And the Audit-Defensible Counter-Stances

Mistake 1 - Spreadsheet Sprawl

The first mistake is the cumulative effect of every team building its own spreadsheet. Engineering has one. Procurement has one. Legal has one. The data science group has one. None reconcile. The audit committee asks for "the inventory" and gets four answers. The fix is the single system of record (platform or extended CMDB) with role-based views into the same underlying schema. Different teams see different fields; everyone is editing the same data.

Mistake 2 - No GPAI Dependency Field

An inventory that lists the deployment but not the upstream foundation model cannot answer the audit-committee question "what is our exposure if Anthropic / OpenAI / Meta is sanctioned?" The GPAI dependency field with Article 51 status and Code-of-Practice signatory status is the join key to the GPAI exposure map and the source of the answer. Programs that built the inventory in 2024 without this field are reworking the schema in 2026.

Mistake 3 - No ML-BoM Reference

Without a CycloneDX 1.7 ML-BoM reference, the inventory is a human-readable record without a machine-readable companion. Supply-chain attestation (CDXA), Article 15 cybersecurity evidence, and the build-pipeline integration all suffer. The fix is to generate the ML-BoM in the CI pipeline and pin the inventory row to the ML-BoM hash bidirectionally.

Mistake 4 - No Article 73 Incident Link Field

When a serious incident occurs (Article 73 10-day clock for death; 2-day clock for widespread fundamental-rights infringement or critical-infrastructure disruption; 15-day clock for other serious incidents), the inventory should immediately link the system row to the incident report ID. Without the field, the post-incident reconstruction work cannot reliably trace which models, which versions, which deployments were implicated. The inventory becomes the time-stamped evidence chain.

Mistake 5 - No Substantial-Modification Log

Article 43(4) substantial-modification re-conformity decisions need to be captured against the inventory row. Programs that capture them in a separate change-management system (and never reconcile) cannot evidence the decision trail at audit time. The fix is a substantial-modification change log column with the date, the change scope, the substantial-modification determination, the re-conformity decision, and the approver. Every change above a defined threshold gets a row.

Mistake 6 - Static Schema That Doesn't Refresh as Articles Evolve

The regulatory landscape moves. Annex III is adjustable under Article 7. Omnibus VII shifted the Annex III stand-alone timeline to Dec 2, 2027 and the Annex I embedded-product timeline to Aug 2, 2028 (while leaving the GPAI enforcement Aug 2, 2026 untouched). New Commission interpretive notes arrive. New Code-of-Practice signatories emerge. A schema frozen at L1 design will be obsolete by the second annual audit. The fix is a quarterly schema review on a fixed cadence, plus an event-triggered review on any major regulatory development, with the schema-document version pinned to the change history.

Key Takeaways

• Spreadsheets fail along five decay lines. Drift, version control, multi-user editing, integration with downstream artifacts, audit-evidence retention. The spreadsheet is the right L1 sketch; it is the wrong L2 system of record.
• The twelve-plus schema fields are operational, not theoretical. Model ID, version (internal + vendor), dual owners, risk tier (with Annex III paragraph), use case + intended purpose, eval status (tool + coverage), last red team (date + scope + findings), data lineage, ML-BoM reference (CycloneDX 1.7), GPAI dependency (foundation model + Article 51 status + Code signatory), retraining cadence, post-market monitoring status: plus FRIA status, Annex IV status, substantial-modification log, and incident link for L2.
• Four governance platforms compete for L2 budget in 2026. Credo AI (CI/CD-integrated, Python SDK, GAIA assistant, Fast Company Most Innovative 2026 #6 Applied AI); Holistic AI (bias testing + LLM evaluation + shadow AI discovery); Modulos (deepest EU AI Act feature coverage); Trustible (registry + governance workflow + vendor risk scoring).
• Internal CMDB extension is the right call in three scenarios. Small portfolio; deep existing CMDB investment; low regulatory complexity. It is the wrong call when the regulatory or audit demands outpace CMDB depth.
• The Credo AI Python SDK changes the unit economics of governance. CI/CD integration, automated inventory updates on deployment, programmatic policy enforcement, cross-platform integration. UI-only platforms cap at human throughput; SDK-driven platforms scale at pipeline throughput.
• The inventory schema cross-walks to three regimes. ISO 42001 A.6.2 + A.10 + A.3 + A.7; NIST AI RMF Map 1-4 + Measure + Manage; EU AI Act Articles 11, 27, 43(4), 71, 72, 73 + Annex IV. Write once; cite three times.
• The L2 artifact set is three documents. The inventory schema document; the platform-selection memo; the CI/CD integration architecture. All three sit in the program's evidence pack.
• Six mistakes every L2 program faces. Spreadsheet sprawl; no GPAI dependency field; no ML-BoM reference; no incident-link field; no substantial-modification log; static schema with no refresh cadence.
• The selection memo answers a question that lives 18 months. Why did you pick this platform? Signed by the AI Officer and CRO; archived; revisited annually.
• Aug 2, 2026 GPAI enforcement and Dec 2, 2027 Annex III stand-alone applicability both stress-test the inventory. The GPAI dependency field is the readiness lever for the first date; the risk-tier field with Annex III paragraph is the readiness lever for the second. The inventory built today should anticipate both.