Delivery Track
A delivery track describes how an AI initiative or AI product development task moves from request to implemented solution.
If the business funnel answers:
What business task are we solving and why?
then the delivery track answers:
How, through which AI products, artifacts, approvals, and participants do we implement it?
Different AI product types do not need the same delivery process. LLM scenarios, RAG services, ML models, code agents, process automation, and applied AI services have different stages, artifacts, readiness criteria, participants, and approvals.
Why the delivery track is needed
An AI portfolio can contain very different tasks: prompt selection for corporate LLM, connecting documents to RAG, piloting a code agent, deploying an ML model into a decision process, or building an applied service with LLM, RAG, OCR, and integrations.
They are all AI tasks, but implemented very differently.
If the company manages all of them in the same way, it gets too much bureaucracy for simple scenarios and too little control for complex solutions.
The delivery track solves this by keeping one management layer while allowing different implementation routes for different AI product types.
Core logic
1. One management logic
For all AI work, the company should know the owner, goal, expected impact, selected product or solution type, implementation status, key risks, next gate, and decision: continue, refine, scale, or stop.
2. Different delivery tracks
| AI product type | Delivery logic |
|---|---|
| LLM | Check whether the task can be solved through prompt and usage rules |
| RAG | Prepare knowledge, ingest it, test answer quality and updates |
| ML model | Check data, train model, test quality, add monitoring |
| Code agent | Configure access, code rules, change checks, and code review |
| Automation | Describe process, configure integrations, handle exceptions |
| Applied AI service | Build a product combining several platform capabilities |
Platform and applied delivery tracks
Delivery for platform products
Platform AI products are reusable capabilities used in many initiatives: corporate LLM, RAG platform, ML platform, code agent, agent platform, OCR/document recognition.
For them, delivery often means validating applicability to a scenario rather than developing a separate business application.
LLM can be relatively light:
describe task → choose prompt → test answers → approve constraints → give users instructions
RAG is already more complex:
collect documents → check quality → prepare knowledge base → ingest into RAG → test answers → approve sources → assign knowledge owner → agree updates and support
Delivery for applied AI services
An applied AI service is a user-facing product that can combine several AI components: LLM, RAG, OCR, ML model, agents, orchestrators, integrations, UI, roles, and access rights.
Its delivery is closer to full product development:
scenario → architecture → process design → development → integrations → testing → pilot → adoption → operations
This adds architecture, security, system owners, operations, support, business sponsor, and platform AI product owners.
Why one universal delivery track does not work
Different AI solutions have different complexity. Some only need prompt validation; others need a knowledge base, model training, or a full service with UI, integrations, and operations.
One universal process slows simple tasks down and under-controls complex ones.
Correct model:
Shared initiative rules, different delivery tracks for different AI product types.
What the delivery track describes
For each AI product type, the delivery track defines stages, artifacts, readiness criteria, AI function participants, business participants, adjacent functions, required approvals, risks, pilot readiness, adoption readiness, and handover readiness.
Different artifacts
| Solution type | Artifact examples |
|---|---|
| LLM scenario | prompt, test requests, quality criteria, user instruction |
| RAG | source list, knowledge base, update rules, answer quality tests |
| ML model | dataset, feature description, model metrics, test report, monitoring |
| Code agent | access rules, usage scenarios, code review process, constraints |
| Automation | process diagram, integrations, exception rules, roles and access |
| Applied service | specification, architecture, UX, API, integrations, testing, support model |
Different approvals
Approvals depend on solution type: LLM may need only process owner and AI function; RAG needs knowledge owner and source approval; ML needs data and decision process owners; code agents need IT, architecture, security, and repository owners; applied AI services need architecture, security, operations, system owners, and business sponsor.
Different participants
Depending on solution type, participants may include AI product owner, initiative lead, business sponsor, process owner, data owner, knowledge owner, architect, security, IT, operations, ML engineer, developer, analyst, support team, and end users.
The point is not to involve everyone everywhere, but to involve the right people at the right moment.
Place in the operating model
The delivery track sits between the AI initiative portfolio and the AI product portfolio. It connects the business need to the selected AI product and the implementation route.
Which task are we solving through which AI product and with which delivery track?
Short formula
The delivery track is the implementation route for an AI solution, depending on the AI product type.
It shows stages, artifacts, gates, approvals, participants, and how LLM delivery differs from RAG, ML, or applied AI service delivery.