AI Registry

An AI registry is the formal, authoritative record of the AI systems an organization has reviewed, approved, and taken responsibility for — typically capturing each system's owner, purpose, data access, risk classification, approval status, and lifecycle stage in one governed place. It's the system of record that governance decisions are actually made against: a system that's in the registry has been through some form of intake and review, and someone is accountable for it.

The terms "AI registry" and AI Inventory are often used interchangeably, and in some organizations they describe the same artifact. Where they're distinguished, the difference is one of function. An inventory is primarily about discovery and visibility — finding and listing every AI tool actually in use, including ones nobody formally approved. A registry is primarily about registration and control — a governed record where systems are entered through an intake process, assigned an owner and a risk tier, and tracked through approval, change, and retirement. In practice, an inventory feeds a registry: discovery surfaces what exists, and registration is how an organization brings each system under AI Governance.

A bank rolling out AI across several business lines is a clear example of where a registry does work an informal list can't. Before a new AI-assisted fraud tool goes live, it's registered: a named business owner, a documented purpose, the categories of data it touches (including payment records), a risk classification, and a recorded approval. When a regulator or internal auditor later asks which AI systems handle customer financial data and who signed off on each, the answer comes from the registry rather than from a scramble across teams.

The same pattern applies across other contexts: a hospital registering each clinical AI tool along with the PHI it can access and the human review attached to its outputs, an enterprise registering each AI agent along with its permissions and the person accountable for it, or a company tracking each AI use case separately even when several run on the same underlying model. Some regulatory regimes also involve formal registration of certain AI systems in official databases — the EU AI Act, for example, provides for registration of certain high-risk systems, with obligations that depend on the system category and the organization's role as provider or deployer. An internal registry doesn't replace any such external requirement, but it gives an organization the organized records those requirements tend to presuppose.

Organizations without a registry can still have lists — spreadsheets of approved tools, procurement records, a wiki page someone started. What's missing is a governed, current, single source of truth that ties each system to an owner, a risk level, and an approval decision. Without it, governance questions get answered by reconstruction: who owns this tool, was it reviewed, what data does it see, is it still in use.

Treating a one-time list of approved tools as a registry is a mismatch — a registry is only useful while it stays current, owned, and connected to the decisions made about each system.

A registry records what AI systems an organization has approved and what data they're permitted to touch. Questa AI doesn't function as an AI registry or discover AI systems on its own — that's the role of the registry and inventory processes themselves. Where Questa is relevant is the data-protection layer those registry entries refer to: for any registered system that handles sensitive data, Questa's entity-detection engine performs local redaction and masking of sensitive identifiers before that data reaches the AI model, functioning as a privacy firewall.

This gives the registry's data-handling fields something concrete to point to. An entry recording that a system touches sensitive data can also record how that exposure is controlled, and Questa's Blackbox recording and governance dashboard provide documented evidence of what was protected and when. Combined with support for local and self-hosted deployment, that lets a registered system carry a specific, verifiable answer for its data-exposure controls — while ownership, risk tiering, approval workflow, and lifecycle tracking remain functions of the registry itself.