DYAP 0204 min read + 15–25 min practice

The Complete AI Project Lifecycle

Expanded 24 October 2026 · DYAP learning resources · Examples are illustrative, not reported classroom results.

Saved in this browser. Completion is your own learning record.

An AI project is a managed lifecycle—not a model-training event. Strong projects connect a human need with data, design, evaluation, deployment, monitoring and governance.

Editorial learning illustration for The Complete AI Project Lifecycle — Visual guide · Use the flow from inputs and evidence to models, outputs and human decisions.

Learning objectives

What you will be able to do

Explain the complete ai project lifecycle accurately in your own words.
Recognise how the concept appears in real AI products and professional work.
Identify an important limitation, risk or evaluation requirement.
Apply the concept through a practical activity and knowledge check.

Core explanation

Build the right mental model

Discovery defines the user, decision, expected value and unacceptable harm. Feasibility checks data, technical capability, legal constraints and workflow readiness. A small pilot should test the riskiest assumptions before major investment.

Development includes data preparation, model or vendor selection, user experience, security controls and evaluation. Deployment introduces ownership, documentation, incident response and change management.

Operation monitors quality, drift, cost and impact. Retirement is also part of the lifecycle: systems should be removed when they no longer provide value, cannot meet requirements or are replaced.

Begin with a service problem and a baseline

An AI project starts with a need, not a model purchase. State who has the problem, what a useful outcome looks like and how it is handled today. A searchable document, a clearer form or a deterministic rule may solve it more simply. Record the current workflow so the proposed system can be compared with something real rather than with an imagined absence of help.

Define scope and exclusions. A course FAQ assistant might explain published procedures but must not decide grades or invent exceptions. Name the owner of the content and the person responsible for approving release. If nobody owns corrections, an initially useful assistant can become a source of outdated instructions.

Develop with evidence gates

Collect only the information needed for the task and establish that it can be used. Inspect quality, versioning and missing values before training or configuring a model. For a retrieval assistant, document preparation and access boundaries may matter more than model training. For supervised learning, define labels, splits and a baseline before tuning.

Use a prototype to test the workflow, not to declare the project complete. Evaluate normal, difficult and out-of-scope cases; inspect failures and revise the design. Decide acceptance criteria in advance so the team does not quietly lower the standard after seeing results. Keep the final evaluation independent of repeated development decisions.

Release is a change in responsibility, not the end

Deployment introduces permissions, reliability, monitoring and support obligations. Start with a bounded rollout where failures can be noticed and corrected. Explain the system’s limits to users, provide an escalation route and record versions. Decide what happens during an outage and who can disable the system. A release without a fallback can turn a small failure into a prolonged service problem.

Continue monitoring after launch because source documents, users and surrounding tools change. Retire an obsolete system deliberately: remove unnecessary credentials, explain the replacement workflow and handle retained data according to policy. NIST’s governance, mapping, measurement and management functions apply across the lifecycle rather than as a single final checklist.

Discovery

Define the problem, user, value, constraints and risks.

Pilot

A limited experiment designed to test important assumptions.

Operation

Monitor, support, secure and improve the deployed system.

Retirement

Safely remove a system and manage retained data or dependencies.

Illustrative example

Worked example: a fictional workshop FAQ project

Problem: participants repeatedly ask where to find room locations and preparation instructions. Baseline: a maintained FAQ page with a search box. Proposed AI scope: answer questions using that approved page and link to the relevant section. Exclusions: personal records, attendance decisions, unpublished schedule changes and automatic messaging.

Data stage: the content owner gives each FAQ entry a title and revision date, removes obsolete instructions and confirms publication rights. Prototype stage: a retrieval step selects relevant entries and a model drafts a short answer. If no entry supports the answer, it says the information is unavailable and points to the coordinator.

Evaluation stage: the team prepares fictional questions for clear matches, ambiguous room names, missing information and a source containing an irrelevant instruction. Acceptance requires preserving dates and exceptions, citing a supporting entry, declining unsupported requests and not following instructions embedded in retrieved content. These are proposed criteria, not claimed test results.

Rollout stage: an identified coordinator reviews a bounded pilot, with the original FAQ page available as a fallback. Monitoring records failures without unnecessarily storing participant details. When an event is cancelled, the source and cached content must be updated, and checks repeated. The system can be paused if it keeps presenting an obsolete location.

The lifecycle view makes the project bigger than a chat interface, but it also reveals when AI is unnecessary. If a clearer FAQ solves the problem adequately, retaining that simpler baseline is a successful outcome rather than a failed AI project.

Apply your learning

Practical activity

Spend 5 minutes choosing a fictional low-risk task and writing the current non-AI baseline, intended users and one measurable outcome.
Spend 5 minutes listing approved inputs, exclusions, content owner and release approver.
Spend 5 minutes writing five evaluation cases, including one missing-information case and one out-of-scope request.
Spend 5 minutes defining a rollout limit, fallback, review trigger and retirement action.

Compare with an explained example answer

For a workshop FAQ, a suitable outcome is that a visitor can locate the correct published room instruction, rather than “the chatbot sounds helpful”. A baseline can be a reorganised FAQ with keyword search. Approved inputs are the published event details; personal attendance records are excluded.

A missing-room question should produce an explicit gap rather than a guess. A request to change attendance status should be refused or directed to the authorised process. A bounded pilot can retain the ordinary FAQ as fallback, repeat checks after schedule changes and revoke unused service access when the assistant is retired.

Your plan is complete when each stage has an owner, evidence or a decision rule. It is not complete merely because all stages have names. If you cannot explain how a failure would be detected and corrected, improve the plan before proposing release.

Write your answers in a learning journal. The value comes from connecting the concept to your own profession.

Knowledge check

Test your understanding

Q1Why keep a non-AI baseline?

Answer: It shows whether the AI design adds enough useful benefit to justify cost and complexity. A simpler solution may meet the need.

Q2Why is deployment not the final lifecycle stage?

Answer: Sources, users and dependencies change. The system needs monitoring, corrections, version management, fallback and eventual retirement.

Q3What distinguishes an acceptance criterion from a claimed result?

Answer: A criterion states what must be demonstrated. A result records what a particular evaluation actually showed. Listing criteria does not establish that they were met.

Reflection

If you cannot explain the answer without reading it, revisit the core explanation and example before continuing.

Continue with authoritative sources

Important industry resources

These links lead to official organisations, industry laboratories or established open-source learning projects.

External resource