How do you build an AI system inventory for compliance?

Build it from discovery signals, not from a survey, and capture enough fields per system to answer an auditor without a follow-up conversation. Surveys produce the systems people remember to report. Discovery produces the estate. In most enterprises the second is several times the size of the first, and the gap is where every unassessed risk sits.

Capture these fields per system: internal identifier, business owner, technical owner, purpose, model provider and version, deployment surface, data classes processed, whether personal or special category data is involved, autonomy level, connected tools and MCP servers, downstream systems it can write to, regulatory classification under applicable law, date of last impact assessment, date of last adversarial test, human oversight design, and planned decommission date.

Two fields carry disproportionate weight. Connected tools, because that set defines blast radius and is the field most inventories omit entirely. And decommission date, because AI systems accumulate: prototypes reach production, get forgotten, and keep serving traffic against a model version nobody has evaluated in a year.

Populate from OAuth grants, cloud API billing, code repositories, model gateway logs, and browser and extension telemetry. Reconcile against the survey rather than replacing it, since owners supply purpose and data classification that logs cannot.

Then keep it live. A quarterly refresh of a register that changes weekly is a snapshot, and auditors increasingly ask how the inventory is maintained rather than what it contains.

Akto Atlas maintains the discovery half continuously for employee AI usage and connected agents, and Akto Argus covers homegrown agentic and LLM applications in production.

An inventory assembled the month before an audit is a document. Auditors can tell.