AI System Lifecycle Management Procedure

Document control

Document ID: B-006

Author(s): GRC & Compliance Team

Version: 1.0

Date: 09-Nov-2026

Disclaimer:

This controlled document is intended for authorized SecureXcel use. It may not be reproduced, distributed, quoted, or disclosed outside its approved audience without prior authorization from the document owner.

Document Details

Revision History

1. INTRODUCTION

1.1 Purpose (A.6.1.1 Objective, 8.1)

The core purpose of this procedure is to define the structured, controlled, and accountable process for the design, development, deployment, operation, and maintenance of all Artificial Intelligence (AI) systems. It ensures that the organization integrates Responsible AI objectives (e.g., fairness, safety, robustness) and risk mitigation measures into every stage of the AI system life cycle, thereby meeting the organization's operational planning and control requirements (8.1).

1.2 Scope (A.6.2.1 Objective)

This procedure applies to:

• All AI Systems: The entire life cycle of any new AI system (developed internally or procured externally) within the AIMS scope.
• Material Enhancements: Any significant modification or change to an existing AI system (6.3).
• AI System Life Cycle Stages: Covering requirements, design, development, testing, deployment, operation, monitoring, maintenance, and decommissioning.

1.3 Objectives (A.6.1.2)

The primary objectives are to ensure:

1. 1. Objective Integration (A.6.1.2): Explicitly identify, document, and integrate Responsible AI objectives into the design, development, and operation processes.
2. 2. Compliance and Control (8.1): Establish criteria and controls (A.6.2.2-A.6.2.8) for all life cycle processes, ensuring actions determined in planning (Clause 6) are implemented.
3. 3. Documentation (A.6.2.3, A.6.2.7): Maintain comprehensive documented information for system design, development choices, and technical assumptions, appropriate for all categories of interested parties.
4. 4. Verification and Validation (A.6.2.4): Define and document specific measures and criteria to confirm the AI system meets both its functional requirements and its Responsible AI objectives before deployment.

2. ROLES, RESPONSIBILITIES, AND AUTHORITIES

3. PHASE 1: PLANNING AND DESIGN (A.6.2.2, A.6.1.2)

This phase ensures a solid foundation is established, integrating strategic objectives and risk mitigation requirements before any coding or data manipulation begins.

3.1 Requirements and Specification Documentation (A.6.2.2)

The AI System Owner must specify and document requirements for the new AI system, including the rationale for its development (e.g., business case, customer request). Requirements must be documented across the following categories:

• Functional Requirements: The tasks the AI system must perform.
• Data Requirements: How the model will be trained and the necessary data acquisition processes (B-007: Data Management).
• Responsible AI Objectives: Mandatory inclusion of specific, measurable objectives (e.g., minimum score for minority groups, maximum acceptable error rate). (A.6.1.2)
• Operational Requirements: Target performance criteria (e.g., latency, processing duration), reliability, and human oversight needs.
• Technical / Performance Requirements: Quantifiable performance thresholds the system must meet, including target accuracy, precision, recall or equivalent quality metrics; latency and throughput targets (e.g., maximum response time, minimum transactions/messages processed per second); and scalability limits under peak load (A.6.2.2).
• Hardware and Infrastructure Requirements: The minimum compute, memory, storage, and network parameters (e.g., GPU/CPU class, deployment environment - cloud/on-prem/edge) necessary to meet the Technical/Performance Requirements above. These parameters are carried forward and finalized as specific component choices during Design and Architecture Documentation (Section 3.3, A.6.2.3).
• Ethics, Safety and Governance Requirements: Explicit safety constraints and known prohibited or out-of-scope uses; the required human oversight and override authority (A.9.3); and the internal governance approvals (e.g., AI System Owner sign-off, and AIGC approval for High-Risk systems per B-003) that must be obtained before the system may proceed to Phase 2. This is in addition to, and formalizes, the Responsible AI Objectives above.

3.2 Initial Risk and Impact Review Gate

The AI System Owner must ensure the following mandatory assessments are completed and considered:

1. 1. AI System Impact Assessment (B-003): The potential impacts on individuals and society (A.5) must be completed.
2. 2. AI Risk Assessment (6.1.2): The risk assessment must be initiated, using the Impact Assessment results as the foundation for identifying consequences.
3. 3. Responsible Objectives Formalization (A.6.1.2): The required Responsible AI objectives (e.g., Fairness, Robustness, Transparency from AIMS Annex C) must be derived from the risk and impact findings and formalized as measurable technical requirements.

3.3 AI System Design and Architecture Documentation (A.6.2.3)

The Development Team Lead must document the AI system's design and architecture choices based on the approved requirements, including:

• Technical Choices: Machine learning approach (supervised vs. unsupervised), learning algorithm, and model type (B.6.2.3).
• Security and Privacy: Specific security threats considered (e.g., data poisoning, model stealing) and how the design mitigates them.
• Interface: How the output will be presented and how humans will interact with the system (B.6.2.3).
• Hardware and Software: Specification of necessary components and computational resources (A.4.5).
• Accuracy: The chosen model type, learning algorithm, and architecture must be capable of meeting the accuracy, precision, and recall targets set in Section 3.1 (Technical/Performance Requirements).
• Scalability: The design must accommodate the projected growth in data volume, transaction throughput, and user load (A.4.5) without requiring a fundamental re-architecture.
• Latency: The design must be capable of meeting the latency and throughput targets set in Section 3.1 under expected production load, including peak conditions.
• Adaptability: The design must support retraining, fine-tuning, or reconfiguration as data distributions, threat patterns, or business requirements evolve (Section 7.1, Change Management), without requiring a full system rebuild.
• Observability: The design must include the logging, monitoring, and metrics hooks necessary to support Live Operation and Monitoring (Section 6.2) and Event Log Recording (A.6.2.8) from the point of first deployment.

4. PHASE 2: DEVELOPMENT AND V&V (A.6.1.3, A.6.2.4)

This phase focuses on executing the design, ensuring controls are in place during coding and training, and formally verifying that the system meets all criteria.

4.1 Processes for Responsible Design and Development (A.6.1.3)

The Development Team Lead ensures the following processes are implemented during development:

• Change Control: A formal change control process is applied to any alteration of the architecture, data requirements, or key objectives (6.3).
• Data Management: Strict adherence to the Data Management processes (AIMS-B-007) for data acquisition, quality assurance, and preparation (A.7).
• Expertise and Training: Ensuring the development team possesses the necessary expertise (data scientists, domain experts) and training (7.2, B.4.6).

4.2 Verification and Validation (V&V) (A.6.2.4)

The V&V Team must define and document the specific verification and validation measures and specify criteria for their use. This documentation includes:

• Testing Methodologies: Selection of testing methodologies and tools (B.6.2.4).
• Test Data Selection: Criteria for selecting test data, ensuring it is representative of the intended domain of use and addresses known bias issues (A.7.4).
• Responsible AI Evaluation: A mandatory plan to evaluate the AI system against the Responsible AI objectives (A.6.1.2) defined in 4.2. This includes reliability, acceptable error rates, and metrics for assessing interpretation ability (B.6.2.4).
• Data Validation: Verification, ahead of and independent from model testing, that the datasets used for V&V meet the Data Quality Requirements defined in AIMS-B-007 (Appendix B) - including completeness, consistency, and representativeness - before those datasets are accepted for use in any test cycle (A.7.4).
• Robustness and Stress Testing: Adversarial testing, edge-case testing, and load/stress testing to confirm the system degrades safely and predictably outside its normal operating envelope, consistent with the Robustness objective defined in AIMS Annex C.
• Ethical and Regulatory Compliance Auditing: Independent review confirming the system's V&V results satisfy applicable legal and regulatory requirements (e.g., DPDPA 2023, TRAI/DoT) and the organization's Responsible AI Policy, with sign-off from Legal & Compliance and, for High-Risk systems, the AI Ethics Committee (AI-003).

4.3 V&V Gate and Certification (A.6.2.4)

Before proceeding to deployment, the system must pass the V&V Gate:

1. 1. Execution: The V&V Team executes the plan against the defined criteria.
2. 2. Nonconformity: Where the AI system cannot meet the documented criteria (especially Responsible AI objectives), the AI System Owner must re-evaluate the intended use or performance requirements (B.6.2.4).
3. 3. Certification: The V&V Team formally certifies that the system meets all documented requirements, including acceptable error rates and performance metrics. This certification is a prerequisite for the Deployment Approval Gate.

4.4 Continuous V&V Across the AI System Lifecycle (A.6.2.4)

V&V is not a single pre-deployment checkpoint: it is a continuous framework that operates across the entire AI system life cycle. This procedure implements that continuity as follows:

• Pre-Deployment (Sections 4.2-4.3): Initial data validation, verification measures, performance/robustness testing, and ethical/regulatory auditing are executed and certified at the V&V Gate.
• Operational (Section 5.2): Performance Monitoring, Drift Detection, and Security Monitoring function as continuous, real-time validation that the certified V&V criteria continue to be met in production.
• Change-Triggered (Section 6.1): Any non-trivial change (retraining, patch, new functionality) triggers a formal Re-V&V (A.6.2.4) against the same data validation, robustness, and ethical/regulatory criteria defined in Section 4.2, before re-deployment.
• Periodic (Section 8.4, AIMS-B-003): Independent of any trigger, V&V criteria and results are re-examined at the annual AI System Impact Assessment interval to confirm they remain fit for purpose.

Together, Sections 4.2 through 6.1 and 8.4 form a single, continuous V&V loop rather than a one-time gate; the V&V Team and AI System Owner are jointly accountable for ensuring no phase of the life cycle operates without active or recently-certified V&V coverage.

5. PHASE 3: DEPLOYMENT AND OPERATION (A.6.2.5, A.6.2.6)

This phase controls the system's release to the production environment and establishes the ongoing monitoring and support mechanisms.

5.1 Deployment Planning and Readiness (A.6.2.5)

The Deployment & Operations Team documents a formal Deployment Plan which ensures that all appropriate requirements are met prior to release:

• Release Criteria: Mandatory sign-offs (e.g., V&V Certification, Management Approval).
• Environment Validation: Testing the system in the target environment (e.g., cloud, edge) to account for differences (B.6.2.5).
• Rollback Plan: A documented, tested plan for immediately reverting the system to a safe or previous version in case of failure or adverse impact.
• Model Packaging and Containerization: The trained model and its runtime dependencies are packaged into a versioned, reproducible artifact (e.g., container image) prior to release, with the artifact version recorded against the V&V Certification (4.3).
• Serving Infrastructure: The compute, scaling, and resilience configuration (e.g., autoscaling policy, redundancy, failover) required to serve the model at the performance targets set in Section 3.1 is provisioned and tested.
• API Layer Development: The interfaces (APIs) through which the AI system is invoked are documented, version-controlled, and include input validation consistent with the Intended Use Boundaries (AIMS-B-003).
• Monitoring and Observability Setup: Dashboards, alerting, and metrics collection required to support Section 5.2 (System Operation and Monitoring) and Event Log Recording (5.3) are configured and verified as operational before go-live.

5.2 System Operation and Monitoring (A.6.2.6)

The Deployment & Operations Team defines and documents the necessary elements for the ongoing operation, ensuring the system continues to operate as intended:

• Performance Monitoring: Continuous monitoring of technical performance (success rates, confidence rates) and criteria related to stakeholder expectations (B.6.2.6).
• Drift Detection: Monitoring for concept or data drift and defining the trigger threshold for mandatory retraining (B.6.2.6).
• Support and Repair: Defining processes for error response, repair, updates, and customer support service levels.
• Security Monitoring: Continuous monitoring for AI-specific security threats (e.g., data poisoning on continuous learning models) and non-AI threats (B.6.2.6).
• AIOps and Predictive Maintenance: Where warranted by system criticality, the Deployment & Operations Team applies AIOps techniques - using machine learning models over real-time operational data (logs, metrics, traces) - to predict degradation or failure before it occurs, and to trigger automated or human-reviewed remediation (e.g., pre-emptive scaling, retraining trigger, alert escalation), transitioning operation from purely reactive repair toward proactive, data-driven decision-making.

5.3 Event Log Recording (A.6.2.8)

The Deployment & Operations Team ensures that event log recording is enabled, at minimum when the AI system is in use, to support traceability and troubleshooting.

• Log Content: Logs must capture the time, date, production data inputs, and outputs that fall outside the intended operation range (B.6.2.8).
• Log Categories: At minimum, four categories of event logs are recorded: (1) Model Inference Logs - inputs, outputs, and confidence scores for each prediction; (2) Data Pipeline Logs - data ingestion, transformation, and quality-check outcomes (AIMS-B-007); (3) User Interaction Logs - human overrides, escalations, and interface actions (A.9.3); and (4) Infrastructure Logs - compute, network, and serving-platform events supporting the Monitoring and Observability Setup (5.1).
• Phased Enablement: Logging is enabled progressively across the life cycle: recommended (not yet production-scale) during Development (4.1) to support debugging; mandatory for all four log categories during V&V (4.2-4.3) to support certification evidence; mandatory and continuous from first production use through Operation (5.2) and Maintenance (6.1); and retained in read-only archival form after Decommissioning (6.3).
• Retention: Logs must be retained according to data retention policies and legal requirements (A.6.2.8).

6. PHASE 4: MAINTENANCE AND DECOMMISSIONING

This phase covers the system's entire operational life and its eventual, controlled end.

6.1 Change Management and Updates (6.3)

Any planned change to the operational AI system (e.g., model retraining, security patch, new functionality) must adhere to a formal change management process (6.3), including:

• Impact Review: A mandatory review of the change's impact on the initial AI System Impact Assessment (AIMS-B-004).
• Re-V&V: Non-trivial changes require a formal re-execution of the relevant Verification and Validation tests (A.6.2.4) before re-deployment.

6.2 Technical Documentation Review (A.6.2.7)

The AI System Owner is responsible for ensuring the AI System Technical Documentation (including design, assumptions, limitations, and usage instructions) is kept up to date and accurate throughout the maintenance phase (B.6.2.7). This documentation must be updated after every non-trivial change (A.6.2.7).

• Engineering / Development Team: Full technical documentation - architecture, model type and training methodology, data lineage (AIMS-B-007), and V&V records (4.2-4.3) - to support maintenance, retraining, and Re-V&V (6.1).
• GRC, Audit, and Regulators: Risk and Impact Assessment linkage (AIMS-B-003), Responsible AI Objective results (Annex C), Statement of Applicability control mapping, and V&V Certification records, sufficient to demonstrate conformity at audit.
• Customers and End Users: Plain-language description of intended use, known limitations, and human oversight/override mechanisms (A.9.3), consistent with the Availability of Impact Assessment Evidence provisions (AIMS-B-003 Section 3.11).
• Operations / Support Team: Runbooks, monitoring and alert thresholds (5.2), rollback procedures (5.1), and escalation paths, sufficient to operate and support the system without engineering intervention for routine events.

6.3 Decommissioning (8.1)

When the AI system reaches the end of its useful life or is no longer aligned with the organization's objectives, a formal Decommissioning Plan must be executed:

• Data Disposal: Formal process for the secure disposal or archival of all training, validation, and production data sets (AIMS-B-007: Data Management).
• Archival: Controlled archival of the final AI System Technical Documentation and V&V Certification records for a defined period (7.5.3).

7. PROCESS MAP: AI SYSTEM LIFE CYCLE FLOW

8. APPENDIX A: RESPONSIBLE AI OBJECTIVES CHECKLIST (A.6.1.2)

The AI System Owner must select and define quantifiable objectives based on the risk and impact findings in Phase 1.

9. APPENDIX B: V&V GATE CERTIFICATION CHECKLIST (A.6.2.4)

Mandatory checklist to be completed by the V&V Team and signed off by the AI System Owner before the system passes the V&V Gate (5.3).

10. APPENDIX C: AI SYSTEM TECHNICAL DOCUMENTATION OUTLINE (A.6.2.7)

The Development Team Lead maintains this documentation set throughout the life cycle, ensuring all elements are available to relevant interested parties (users, partners, regulators).

11. APPENDIX D: OPERATIONAL MONITORING PLAN (A.6.2.6)

The Deployment & Operations Team uses this plan to define the continuous monitoring criteria for operational AI systems.

12. CONTINUAL IMPROVEMENT OF THE PROCEDURE (10.1)

This procedure itself is subject to continual improvement (10.1). The Head of Technology & Development (in consultation with the AIMS Manager) shall recommend updates based on the following:

1. 1. V&V Failure Analysis: Analysis of V&V Gate failures (5.3) that result in significant delays, indicating that the initial Requirements and Specification (4.1) phase requires more rigorous input criteria.
2. 2. Audit Feedback (9.2): Internal audit observations related to the consistency of Event Log Recording (6.3) or adherence to the Decommissioning Plan (7.3).
3. 3. Process Effectiveness (9.1): Review of Operation and Monitoring metrics (Appendix D) where recurrent drift or performance issues suggest that the Development Processes (5.1) need to mandate new controls (e.g., more robust data augmentation techniques).

More in AI lifecycle, suppliers and operations

• AI System Resources Management Procedure
• AI Model Card and User Documentation
• Supplier and Third-Party AI Assessments