AI Operations · Topic 2 of 8
AI Solution Development Lifecycle
Auditing the AI lifecycle: design, development, validation, deployment, monitoring and decommissioning, MLOps, model documentation and acquired AI.
- 5 min
- The lifecycle includes decommissioning; retirement must be controlled.
- Gates before production must exist even in agile, iterative work.
- Model registry plus experiment tracking give reproducibility and traceability.
What it is
The AI solution lifecycle runs from design through development, deployment and monitoring to decommissioning. It looks like the familiar system development lifecycle, but adds stages for data, model training and validation, and it loops: models are retrained and redeployed many times.
The auditor evaluates the lifecycle and its inputs and outputs for compliance and risk: are there defined stages, are the right gates in place, is each stage documented, and do algorithms and models stay aligned to business objectives and policy throughout?
How it works
Lifecycle stages and audit focus
| Stage | Key outputs | What the auditor checks |
|---|---|---|
| Design | Use case, requirements, risk tier, impact assessment | Approved business case and requirements; risk assessed before build |
| Data preparation | Approved datasets, datasheets | Data input requirements met; privacy approval |
| Build and train | Model, experiment records | Method chosen for a documented reason; experiments tracked |
| Validate | Validation report | Independent review against thresholds set in design |
| Deploy | Release approval, deployment record | Formal sign-off; deployed version matches validated version |
| Monitor | Dashboards, alerts, reviews | Thresholds monitored; owners act on breaches |
| Retrain | New version | Treated as a change, retested and approved |
| Decommission | Retirement record | Model removed, access revoked, data and model handled per retention |
Methodologies
AI development is usually iterative: teams experiment, compare models and refine. Agile methods are common. This is acceptable as long as gates still exist before production and the documentation keeps up.
MLOps (machine learning operations) applies DevOps ideas to AI: automated pipelines for training, testing, deployment and monitoring, with a model registry that stores each model version with its metadata. For generative AI, similar practices manage prompts, retrieval sources and evaluation sets.
| MLOps element | Audit value |
|---|---|
| Model registry | One source of truth for versions, owners, status and approvals |
| Experiment tracking | Shows which data, code and parameters produced each model |
| Automated test gates | Evidence that every release ran the required tests |
| Pipeline access controls | Shows who can push a model to production |
Automation helps the auditor: a well-configured pipeline produces consistent evidence for every release. But the auditor must test the pipeline configuration too, because a gate that can be skipped is not a control.
Model documentation
A model card summarises a model's purpose, intended users, training data, performance (including across groups), limitations and conditions for use. Combined with datasheets and validation reports, it lets a reviewer understand the model without the developers in the room.
Independent validation
For high-risk models, someone independent of the developers should validate the model: check the method, data, performance, bias and limitations. This mirrors model risk management practice in banking. Validation by the same team that built the model is a common finding.
Aligning algorithms to objectives and policy
The auditor checks that the objective the model optimises matches the business objective and policy. A model that maximises sales conversion may push unsuitable products to vulnerable customers, which conflicts with conduct policy. The design documents should show this trade-off was considered.
Acquired and vendor AI
When AI is bought, the lifecycle still applies, but the evidence comes partly from the vendor. The auditor expects the organization to obtain model documentation, test the solution on its own data before use, control configuration, and monitor vendor updates. Vendor and supply chain management is covered in the risk management page.
Decommissioning
Retiring a model is a controlled step. The auditor checks that a retired model is removed from production and from any integrations, its credentials and API keys are revoked, dependent processes have a replacement or manual fallback, and data and model files are retained or destroyed per policy. A retired model still answering requests through a forgotten integration is a classic finding.
A worked example
An auditor reviews a fraud model release. The model registry shows version 4 was validated and approved, but the production endpoint is running version 5, which a developer deployed after a late fix. No validation or approval exists for version 5.
The auditor concludes the deployment gate can be bypassed. The finding is a control design weakness in the pipeline, not just one bad release. The recommendation is to enforce approval in the pipeline so that only approved registry versions can be deployed.
How the exam asks about this
- "Which is the BEST evidence that the deployed model is the one that was validated?" A comparison of the production model version with the approved version in the model registry.
- "Who should perform validation of a high-risk model?" A function independent of the developers.
- "What is the GREATEST risk when an AI model is decommissioned?" That it remains accessible or active through integrations, or that dependent processes have no fallback.
What to remember for the exam
- The lifecycle includes decommissioning; retirement must be controlled.
- Gates before production must exist even in agile, iterative work.
- Model registry plus experiment tracking give reproducibility and traceability.
- High-risk models need validation independent of the builders.
- Test the pipeline itself; a skippable gate is no control.
Comparing the production version with the approved version is the single most useful lifecycle test. If they differ, every other piece of validation evidence describes a different model.
Common mistakes
Treating AI like a one-time project. Models are retrained and redeployed; the lifecycle loops.
Accepting developer self-validation for high-risk models. Independence is the point of validation.
Ignoring bought AI. Vendor AI still needs testing on the organization's data and change monitoring.
Check yourself
What is a model card?
A short document describing a model's purpose, intended use, training data, performance across groups, limitations and conditions for use.
Why does an auditor care about the MLOps pipeline configuration?
Because the pipeline enforces gates; if a gate can be skipped or changed without control, test evidence cannot be relied on.
What should happen when a model is decommissioned?
It is removed from production and integrations, its access is revoked, dependent processes have a fallback, and its data is retained or destroyed per policy.
Topic 2 of 8 in AI Operations
Test yourself on AI Operations
The full ISACA AAIA question bank has 750 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISACA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.