What should be tested in an AI system?
Test prompts, retrieval results, tool calls, model outputs, business rules, safety constraints, data permissions, latency, cost, and human-review behavior.
Capability briefing
AI SDLC
Executive brief
The AI SDLC is a delivery model for AI systems where prompts, data, models, retrieval, evaluations, releases, monitoring, and governance are treated as production engineering assets.
Definition
The AI SDLC adapts software delivery practices for AI systems that depend on prompts, models, data, retrieval, evaluation, and monitoring.
Why it matters
AI systems need repeatable testing, release controls, and observability because behavior can shift as data and models change.
Where this matters in enterprise decisions
AI SDLC decisions matter when organizations need to move AI from experiments into production without losing quality, auditability, security, or delivery speed.
Q&A for leaders
Common business questions
These answers are visible on the page and mirrored in structured data so search engines and answer engines can parse the same information human readers see.
What belongs in AI CI/CD?
Versioned prompts, evaluation datasets, policy checks, security scanning, deployment approval, rollback plans, and monitoring configuration should be part of the release path.
How should model changes be handled?
Model updates should trigger regression evaluation, risk review when needed, staged rollout, telemetry comparison, and documented release decisions.
How does the AI SDLC connect to governance?
Governance should define the required controls by risk level, while the SDLC implements them as repeatable engineering and release practices.
Common failure modes
- Prompt changes are made manually without versioning or evaluation.
- Teams cannot reproduce why an AI output changed after a model or data update.
- Monitoring only tracks uptime and misses quality, safety, cost, and exception drift.
- Governance reviews happen outside delivery, creating delays and weak evidence.
Architecture and governance implications
- AI SDLC should create evidence for approvals, releases, incidents, exceptions, and model changes.
- It requires collaboration between product, engineering, data science, architecture, security, risk, and operations.
- Controls should be embedded in delivery tools and ceremonies rather than handled as separate paperwork.
Related capabilities
Connected expertise areas
Practical resources
checklist
AI SDLC production readiness checklist
A production-readiness checklist covering AI evaluation, release controls, monitoring, ownership, security, support, and rollback.
Related canonical writing
How Many Agents Can One Person Answer For?
Agent output can scale much faster than the reviewed, defensible judgement available to accept it. Safe team design starts by pricing that supervisory capacity.
Hiring for the Stack, Paying for the Context
Swiss employers are pricing tools, locations, and engineering seats while underpricing the institutional context, specification work, and accountability that regulated data delivery requires.
The Record You Cannot Refactor
Why AI lifecycle evidence must be captured while systems are designed, tested, approved, released, and monitored—before models, prompts, suppliers, and people move on.
How to Build an AI-Ready Engineering Organization
An AI-ready engineering organization can attribute, verify, reconstruct, and defend every AI-assisted change through evidence, controls, and accountable ownership.
What AI Did Not Make Cheaper
AI has made software generation cheaper, but verification, evidence, security, accountability, and regulatory defensibility remain the real enterprise cost.
AI Changes Software Engineering, Part 1: The Bottleneck Has Moved
Part 1 of a three-part field guide on how AI changes software engineering: code generation accelerates, but the bottleneck moves toward architecture, evaluation, governance, ownership, and judgment.
AI Changes Software Engineering, Part 2: AI Exposes Enterprise Fault Lines
Part 2 of the AI software engineering series: AI exposes existing enterprise weaknesses, changes requirements, raises the cost of architecture mistakes, turns testing into evaluation, and moves governance into runtime.
AI Changes Software Engineering, Part 3: The New Operating Model
Part 3 of the AI software engineering series: why AI adoption becomes an operating-model problem, what the emerging AI engineering stack looks like, and what leaders should ask Monday morning.
Enterprise AI Adoption: Why Most Programs Stall Between Pilot and Production
Why enterprise AI adoption often stalls between promising pilots and durable production: the bottleneck is usually data, governance, ownership, workflow integration, and operating model maturity rather than model quality alone.
Why Most Public Sector AI Strategies Fail During Implementation
Most governments now have AI strategies, principles, and playbooks. The harder question is whether they have the delivery machinery to turn those documents into safe production systems.