How to Build an AI System Registry (And Why Regulators Will Soon Require One)

You Probably Use More AI Systems Than You Think

Ask a typical Singapore mid-size company's leadership team how many AI systems the organisation uses. The answer is almost always an underestimate — often dramatically so.

The underestimate has a predictable structure. Leadership counts the AI systems they chose deliberately and at an organisational level: the AI-powered analytics platform they approved and budgeted for, the chatbot they procured and launched, the AI writing assistant they standardised across the communications team. These are visible.

What leadership typically does not count: the GitHub Copilot subscription that four developers are paying for individually on their credit cards. The Microsoft 365 Copilot features that every employee now has access to following a licensing upgrade that was approved primarily for Teams improvements. The AI screening features embedded in the recruitment SaaS the HR team adopted two years ago. The AI categorisation in the accounting software that the finance team uses daily without thinking of it as "AI." The AI content recommendations in the email marketing platform. The AI-generated insights in the business intelligence dashboard that the sales team presents to management every Monday.

None of these are unusual. They are the AI stack of a typical modern Singapore company. And the vast majority of them are ungoverned — no documented accountability, no risk assessment, no review of what data they process, no human oversight protocol for their outputs.

What an AI System Registry Is

An AI system registry is a live, structured inventory of every AI system your organisation uses — whether built in-house, purchased as a SaaS product, or accessed via an API integration. "AI system" in this context means any system that uses machine learning, large language models, neural networks, or other AI techniques to generate outputs — predictions, recommendations, decisions, content — that affect your business operations or your interactions with customers, employees, or partners.

The registry is not a one-time audit exercise. It is a living document — updated when new AI systems are adopted, when existing systems are significantly updated, when the scope of AI use in a system changes, and on a regular review cycle regardless of changes.

Think of it as analogous to other governance registries that mature organisations maintain: an asset register for physical equipment, a data register for personal data under PDPA, a vendor register for third-party suppliers. The AI system registry applies the same discipline to artificial intelligence: you cannot manage risk, assign accountability, or demonstrate governance for systems you have not formally identified and documented.

For each AI system in the registry, you are capturing structured information across a defined set of fields — enough to understand what the system does, what governance applies to it, who is responsible for it, and when it was last reviewed. The specific fields matter and are covered in detail below.

Why Regulators Are Heading in This Direction

No Singapore law currently mandates an AI system registry by that name. But the regulatory direction is clear, and understanding it explains why building one now is the right strategic move.

ISO 42001 — the world's first AI management system standard, published December 2023, and adopted in Singapore as SS ISO/IEC 42001:2024 with SAC certification available from February 2025 — has requirements that make an AI inventory practically necessary. Clause 4.4 requires organisations to establish and maintain an AI management system, including determining all the processes needed for it. Clause 6.1 requires risk assessment of AI systems — which is impossible if you don't know what systems you have. Clause 8 requires operational controls applied to specific identified systems. The Statement of Applicability (SoA) maps controls to specific systems. None of these requirements are satisfiable without a structured inventory of AI systems.

IMDA's Model AI Governance Framework (May 2024) requires accountability structures for AI systems — named individuals responsible for specific AI systems and their governance. You cannot assign accountability for systems you haven't inventoried. The framework's requirement that organisations "determine the human-AI decision relationship" for each consequential decision-making AI system similarly presupposes knowing what those systems are.

The global direction is set by the EU AI Act — which imposes registration requirements for high-risk AI systems, use-case restrictions for certain AI applications, and transparency obligations for AI-generated content. While the EU AI Act does not directly apply to Singapore-only businesses, it is establishing the international benchmark for AI governance that Singapore's frameworks are closely aligned with. Singapore companies supplying to EU businesses or operating EU subsidiaries already have EU AI Act considerations. Others are a policy cycle away from similar local requirements.

What to Capture for Each AI System

The fields in your AI system registry should be consistent across all entries and structured enough to enable risk-based decision-making. Here is the minimum viable field set, with explanations of why each field matters:

System name and version. The name you call it internally, the vendor product name, and the current version or release date. Version matters because AI systems change significantly between releases — what you assessed for GPT-4 may not apply to GPT-4o or a subsequent model version.

Purpose.What does this AI system do in your organisation? Be specific. "AI assistant" is not sufficient. "AI-powered first-pass resume screening in our ATS, ranking candidates by keyword match and predicted tenure" is. The purpose description is what drives the risk assessment.

Deployment type. Is this built in-house (your own model or custom application)? A purchased SaaS product? A vendor-provided API integration? A consumer tool accessed via web browser? The deployment type determines where governance levers exist and what contractual protections are available.

Data processed.What data does this system process or have access to? Specifically: does it process personal data under Singapore's PDPA? Sensitive data categories (health, financial, biometric)? Confidential business data? The answer determines PDPA obligations and data governance controls required.

Decision influence. Does this system make decisions, inform decisions, or neither? What decisions? How consequential are they? A grammar checker influences writing style — low consequence. An AI system that screens job applications before any human sees them influences hiring decisions — high consequence. The decision influence field drives the human oversight requirements.

Risk tier. Assign each system a risk tier — low, medium, or high — based on its decision influence, the sensitivity of data it processes, and the potential harm from incorrect outputs. The tier drives the depth of governance required.

System owner. A named individual, not a team or a department. The owner is accountable for ensuring the system is governed appropriately — controls are in place, reviews happen, incidents are reported, the registry entry is kept current.

Last review date. When was this entry last reviewed and confirmed as accurate? Registry entries degrade in accuracy over time as systems change. A mandatory review date creates the discipline to keep the registry current.

Control status. Which governance controls apply to this system, and are they implemented? For organisations using ISO 42001, this links to the SoA. For others, it documents the specific controls in place — human approval workflow, bias testing, performance monitoring, incident response.

Vendor contact (for third-party systems).For SaaS and API tools: the vendor name, your account representative, and the vendor's security and privacy contact. Needed when incidents occur or when you need to query changes to the AI system's behaviour.

The Tiering Approach: Not All AI Needs the Same Governance

Attempting to apply the same governance intensity to every AI system in your organisation is both impractical and unnecessary. A grammar checker and an AI system making credit decisions are not equivalent governance problems. The tiering approach applies governance proportionate to risk.

Low risk: AI systems whose incorrect outputs have minimal consequences. Examples: grammar and spelling checkers, meeting transcription and summarisation (no consequential decisions downstream), AI-powered search and retrieval within a knowledge base, image resizing and formatting tools with AI features. These require registry entries and basic monitoring but not intensive oversight controls.

Medium risk: AI systems that influence consequential decisions but where human review is routine and errors are typically detectable and correctable. Examples: AI-assisted financial transaction categorisation (human accountant reviews before journal entries are posted), AI-generated customer service responses (reviewed before sending for complex cases), AI-powered sales lead scoring (sales team exercises judgment on AI recommendations). These require documented human oversight protocols, performance monitoring, and regular review.

High risk: AI systems that make or heavily influence consequential decisions affecting individuals, with limited human review before the decision takes effect. Examples: HR screening AI that filters candidates before any human reviews the application, credit decision AI that approves or declines applications, medical diagnostic AI, security AI that takes autonomous action (blocking accounts, flagging transactions for fraud). These require the most rigorous governance: mandatory human-in-the-loop for all decisions above a certain threshold, bias assessment, performance monitoring with drift detection, incident response protocols, and regular independent review.

The tiering should be reviewed whenever the purpose of an AI system changes, whenever its deployment scope expands significantly (a pilot used by 5 people becoming a system used by 500), or whenever new risk factors are identified (a data breach affecting the system's training data, a discovered bias in its outputs).

Third-Party AI in the Registry: You Cannot Opt Out of Governance

The most common objection to comprehensive AI registry-building is: "We don't need to register AI tools we don't own."

This is a mistake with real consequences. If your organisation uses an AI system — regardless of who built it, where it runs, or who pays for it — the governance obligation for its use within your organisation is yours. Under Singapore's PDPA, the obligation to protect personal data processed by a third-party tool on your behalf sits with you, not with the vendor. Under ISO 42001, the AI management system covers all AI systems used within your organisation's scope. Under IMDA's governance framework, accountability for AI decisions affecting your customers or employees is yours regardless of whether the AI is from an external vendor.

For SaaS and API tools, the registry entry should document: the vendor name and specific product, the AI features your organisation uses (note: many SaaS products have AI features that are enabled by default but which your teams may not know they are using), the data the tool processes, your contractual protections (does the vendor agreement cover data processing under PDPA? Does the vendor commit to not training their models on your data?), and your monitoring approach (how do you know if the tool's behaviour changes?).

The discovery exercise for third-party AI is itself valuable. Many organisations discover during registry-building that employees are using AI tools that process sensitive company data in ways not covered by any data processing agreement, or that AI features in existing tools are enabled without the organisation's knowledge. The registry exercise is often the first time these situations are identified and addressed.

Maintaining the Registry: The Ongoing Discipline

Building a registry once is useful. Building a process that keeps it current is what makes it a governance asset.

The most common reason AI system registries become inaccurate is not malice or neglect — it is the speed of AI adoption. New tools are adopted informally, AI features are added to existing SaaS products without announcement, developers integrate new AI APIs without central oversight. The registry built in January may be missing five systems by April.

The counter-measures are procedural. First, integrate the AI registry into procurement. Any purchase of a new software tool — at any price point, for any team — should trigger a question: "Does this tool include AI features?" If yes, a registry entry is created before the tool is deployed, not after. This applies even to low-cost tools and individual subscriptions that teams are paying for themselves, if those tools process company or customer data.

Second, establish a quarterly review cycle for all registry entries. Each system owner reviews their entry and confirms it is accurate or updates it. Systems with no owner (where the original owner has left or changed roles) are flagged for reassignment. New AI features added to existing tools since the last review are added to the relevant entry.

Third, designate a registry owner — an individual who is accountable for the registry's overall accuracy, currency, and completeness. This is typically a compliance, technology, or risk function. The registry owner does not need to own every AI system; they own the registry as a governance instrument and ensure the processes around it function.

Fourth, include the registry status in your regular governance reporting. Board or leadership committee reporting on AI governance should include: the number of registered AI systems, the distribution by risk tier, any high-risk systems added or identified in the period, and any incidents related to registered AI systems. This creates organisational visibility and accountability for the registry beyond the team maintaining it.

The AI system registry is the starting point, not the endpoint, of operational AI governance. With the registry in place, risk assessments become possible. Accountability becomes assignable. Human oversight protocols can be scoped to the systems that need them. Incident response can be planned for the specific failure modes of specific systems. ISO 42001 certification becomes achievable because the management system has a documented, structured foundation.

Without the registry, every other AI governance activity is either targeted at the visible, deliberate AI systems (missing the informal and embedded ones) or so broad as to be impractical. The discipline of knowing what AI you use, documented in a maintained registry, is the prerequisite for governing it well. VerityOS's AI governance platform includes structured AI system registry capability — enabling Singapore organisations to build, maintain, and act on their AI inventory as part of a complete governance workflow.