Compliance Framework Alignment
ISO/IEC 42001:2023 — Annex A.3.2 (AI roles and responsibilities) ISO/IEC 42001:2023 — Annex A.5.2 & A.5.3 (AI system impact assessment) ISO/IEC 42001:2023 — Annex A.6.2.3 (Documentation of AI system design) EU AI Act (Regulation (EU) 2024/1689) — Art. 5, Art. 6 & Annex III, Art. 50 This register is an operational template to help you inventory and risk-tier AI systems. It is not legal or compliance advice; classifications should be confirmed with your governance and legal teams.
ACME ANALYTICS PVT LTD AI SYSTEM INVENTORY & REGISTER
Effective Date [Effective Date]
Register Reference AIR-2026-01
Review Cadence Annually
Accountable Owner Priya Nair, Chief AI Officer (Chief AI Officer )ID System Purpose Owner Provider Data categories Model type EU AI Act tier Lifecycle Impact assessment Human oversight Next review AIS-001 Applicant Screening Assistant Ranks job applicants against role criteria to shortlist candidates. Head of Talent Acquisition — CVs, contact details (personal data), assessment scores Gradient-boosted classifier + LLM re-ranking — — — Recruiter reviews and can override every shortlist decision — AIS-002 Customer Support Chatbot Answers billing and account queries in-app Head of Support Foundation-model Chat transcripts, account IDs (incl. personal data) LLM (retrieval-augmented) Limited (Art. 50) Production Complete — 12 January 2026 Escalation to human agent on request or low confidence 12 January 2027 AIS-003 Demand Forecasting Engine Predicts weekly stock demand per warehouse Supply Chain Lead In-house Sales history, inventory levels (no personal data) Time-series regression Minimal Production Not required Planner reviews forecast before purchase orders 01 March 2027
1. Purpose and Scope of the Register
This register is the single authoritative record of every artificial-intelligence system that Acme Analytics Pvt Ltd develops, procures, deploys or materially relies upon. It exists to give the organisation a defensible, up-to-date view of where AI is in use, who is accountable for it, and how each system is classified for risk. The register aligns with the documentation and accountability expectations of ISO/IEC 42001:2023 and supports risk-tiering under Regulation (EU) 2024/1689 (the EU AI Act). Every system meeting the definition in Clause 2 must be recorded here before it enters production use.
2. Definition of an AI System
For the purposes of this register, an AI system is a machine-based system that, for explicit or implicit objectives, infers from the inputs it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. This includes in-house models, third-party AI products, and applications built on top of general-purpose or foundation models accessed through an API. Simple deterministic automation with no inferential or learned component falls outside scope and need not be registered.
3. Register Contents and Required Fields
Each entry must capture, at minimum: a unique system identifier and name; the purpose and intended use; the accountable business owner; the provider and build type (in-house, third-party vendor, or foundation model); the categories of data used, with personal data flagged explicitly; the model or technique type; the EU AI Act risk classification; the current lifecycle stage; the impact-assessment status and date; the human-oversight measure in place; and the next scheduled review date. Incomplete entries are treated as open governance items until the missing fields are supplied.
4. Accountability and Ownership
Priya Nair, Chief AI Officer (Chief AI Officer ) holds overall accountability for the completeness and accuracy of this register, consistent with the allocation of AI roles and responsibilities under ISO/IEC 42001:2023 Annex A.3.2. Each registered system also names a business owner who is responsible for keeping that entry current, ensuring the recorded oversight measures operate as described, and escalating material changes. Ownership must be reassigned promptly whenever staff change roles so that no system is left without a named accountable person.
5. EU AI Act Risk Classification
Every system is assigned to one of four tiers. Prohibited systems are those falling within the banned practices of Article 5 of the EU AI Act and must not be operated. High-risk systems are those captured by Article 6 together with the use cases listed in Annex III (for example biometrics, employment, essential services, education and law enforcement), and attract the full obligations for high-risk AI. Limited-risk systems are those triggering the transparency duties of Article 50, such as chatbots and generated or manipulated content. Minimal-risk systems carry no specific obligations under the Act. Where a classification is uncertain, the more stringent tier is recorded until a formal determination is made.
6. Personal Data and Data Categories
The data categories consumed by each system must be listed, and any use of personal data must be flagged so that it can be reconciled with the organisation's data-protection records. Where a system processes personal data, the register entry should cross-reference the relevant records of processing and, where required, the associated data-protection impact assessment. Recording data lineage in this way supports both the resource-documentation controls of ISO/IEC 42001:2023 and the organisation's wider privacy obligations.
7. AI System Impact Assessment
Systems classified as high-risk, and any system processing personal data or otherwise capable of materially affecting individuals or groups, must undergo an AI system impact assessment before production deployment, in line with ISO/IEC 42001:2023 Annex A.5.2 and A.5.3. The register records whether an assessment is not started, in progress, complete or not required, together with its date. A system may not advance to the production lifecycle stage while a required impact assessment remains outstanding.
8. Human Oversight Measures
For each system the register records the specific human-oversight measure in force, describing how a competent person can understand, monitor, intervene in, override or halt the system's operation. For high-risk systems these measures must be commensurate with the risk, level of autonomy and context of use, consistent with Article 14 of the EU AI Act, and must be designed so that oversight is genuinely effective rather than nominal. Oversight arrangements form part of the responsible-use expectations of ISO/IEC 42001:2023 Annex A.9.2.
9. Lifecycle Stage Tracking
Each entry records the system's current lifecycle stage — design, development, testing and validation, production, or retired. Movement between stages, particularly the transition into production and eventual decommissioning, must be reflected in the register promptly, since risk classification, oversight needs and review frequency can all change as a system matures. Retired systems are retained in the register with their status updated rather than deleted, preserving the historical record.
10. Third-Party and Foundation-Model Providers
Where a system is supplied by a third-party vendor or built on a foundation model, the register identifies the provider and the nature of the dependency. Responsibilities between Acme Analytics Pvt Ltd and the provider must be clearly allocated, and the organisation should retain sufficient documentation from the provider to support its own classification and oversight obligations. This reflects the allocation-of-responsibilities expectations for third parties under ISO/IEC 42001:2023 Annex A.10.2.
11. Review Cycle and Currency
The register is reviewed on a annually basis, and each individual entry carries its own next-review date. Reviews confirm that the recorded purpose, classification, ownership, oversight measures and lifecycle stage remain accurate, and that any new systems introduced since the last cycle have been added. Material changes to a system — a change of purpose, model, data, provider or risk profile — trigger an out-of-cycle review of that entry regardless of the scheduled date.
12. Change Control and Version History
Changes to the register itself are version-controlled. Each published version carries the reference and effective date shown above, and superseded versions are retained so that the state of the inventory at any past point can be reconstructed. New system entries, reclassifications and retirements are made through the organisation's change-control process rather than by ad-hoc edits, ensuring changes are reviewed and attributable.
13. Documentation and Audit Evidence
The register, together with the underlying impact assessments, provider documentation and oversight records it references, constitutes primary evidence of the organisation's AI governance. It is made available to internal audit, and to competent authorities where lawfully required, to demonstrate that AI systems are inventoried, classified and overseen in a controlled manner. Supporting records are retained in accordance with the organisation's records-retention schedule.
14. Review, Approval and Maintenance
This register is approved by the accountable owner and maintained as a living record. It takes effect on the date shown above and remains in force until superseded by a later version. Questions about a specific entry should be directed to that system's named business owner; questions about the register as a whole should be directed to Priya Nair, Chief AI Officer .
Approved by (Accountable Owner)
Priya Nair, Chief AI Officer
______________________
Reviewed by
Rahul Menon, DPO
______________________