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
Answer-engine summary
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
Related canonical writing
AI SDLC··9 min read
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.
AI SDLC··10 min read
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 SDLC··8 min read
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 Governance··10 min read
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.