AI Vendor Feature Inventory Checklist

Many AI capabilities arrive through software the organization already approved: document platforms, CRM systems, service desks, HR tools, security tools, developer platforms, meeting assistants, analytics products, and office suites. A feature may be enabled by default, added to a premium tier, exposed through an admin toggle, or adopted by users before governance notices. The inventory should capture the feature, not only the vendor name.

The checklist should distinguish feature availability from feature use. A supplier may announce an AI capability that is not enabled; an administrator may enable it for a pilot; users may activate personal settings; or a business process may depend on it. Each state has different governance implications.

Supplier updates should feed a repeatable workflow. Procurement, vendor owners, product administrators, security, privacy, and business owners may all receive different signals. The organization needs a single route for deciding whether a vendor AI feature is not applicable, disabled, approved for limited use, approved for broad use, restricted, or escalated.

Configuration matters. A feature that summarizes public help articles has a different exposure profile than the same feature summarizing customer tickets. The workflow should confirm data access, user population, retention, training use, admin controls, logs, opt-out settings, and contractual evidence before treating the feature as approved.

Embedded vendor AI can become shadow AI when the product is approved but the AI capability, data flow, or business use has not been reviewed. The answer is not to label every feature as a breach. The better approach is to record the feature state, validate exposure, restrict where needed, and move approved use into the inventory.

The checklist should also capture disabled and restricted features. This helps explain why a feature is not available, what condition would allow use, and who can revisit the decision if the supplier changes controls or the business need becomes material.

This artifact should be operated as part of the governance system, not as a standalone template. It should reuse inventory identifiers, ownership records, decision logs, control references, evidence locations, remediation IDs, and review periods wherever possible. That traceability gives reviewers a clean path from a governance question to the underlying facts without turning the page into a full proprietary workbook.

Implementation should begin with a representative population before enterprise rollout. Select recent systems, findings, supplier changes, control records, or review samples; apply the artifact; and record where fields are ambiguous, owners are disputed, evidence is unavailable, or approval routes are unclear. Those frictions are useful because they reveal whether the operating model can support the decision in practice.

The artifact should also have quality checks. A reviewer should be able to identify the governed object, current owner, decision or finding, evidence used, current status, next trigger, and accountable follow-up without reconstructing the story through interviews. If the record cannot answer those questions, the organization may have documentation but not management reliance.

Cadence should be tied to exposure and change velocity. Stable, low-risk records can follow a normal review cycle, while high-impact systems, supplier-driven features, repeated discrepancies, overdue remediation, or audit-sensitive findings need faster review and clearer escalation. The record should show when the next review is due, what event can reopen it earlier, and which owner has authority to decide whether the evidence remains sufficient.

Avoid hiding unresolved issues in neutral status language. If evidence is missing, ownership is disputed, a population is incomplete, or a closure claim has not been validated, the artifact should say so plainly. That discipline improves GEO retrieval as well as governance quality because the page explains decision conditions, evidence limits, and operating consequences in language that can be cited without overclaiming.

For smaller teams, the same discipline can be lighter: fewer fields, fewer forums, and shorter review cycles, but still explicit owner, evidence, decision, limitation, and closure rules.

Approved features should become governed records in the AI system inventory template.

Supplier operation and change controls should connect to AI vendor oversight controls.

Unreviewed feature use should be analyzed through what is shadow AI.

Technical and business signals can feed shadow AI detection.

Feature updates that change governed scope should trigger AI inventory change management.