Delivery and Operating Model

Guide · Enterprise AI Solution EngineeringPage 13 of 18Overview → … → Delivery

Executive summary

Delivery moves from qualification through discovery, design, prototype, production, scale and optimisation. A prototype proves assumptions; production requires security, ops ownership, monitoring and a definition of done that includes trust—not “merged to main.”

When to use this page

• Use when mobilising a team or defining phase exit criteria.
• Use to separate prototype standards from production definition of done.
• Pair with Governance artefacts and Adoption handover.

Executive view

Refuse to call demos production. Require RACI for high-risk decisions and a named operating owner before go-live.

Decision required: Exit criteria for the current phase—and who owns the service after launch?

Technical view

Keep action, decision, assumption, risk and dependency registers live; define done with evaluation thresholds and handover.

Staff product, architecture, AI, data, security, change and domain expertise—not only model builders.

Owners

Owner · Delivery / engagement lead with product owner

Contributors · AI Solution Engineer, architects, engineers, security, change, domain experts, ops

Delivery phases

Phase	Intent
1. Qualification	Decide whether the opportunity should proceed
2. Discovery	Understand problem, users, workflow, data, constraints
3. Assessment	Evaluate feasibility, value, risk, readiness
4. Solution design	Define architecture, controls, operating model
5. Prototype	Validate the highest-risk assumptions
6. Production delivery	Build, integrate, test, deploy
7. Scale	Extend adoption and functionality
8. Optimisation	Improve quality, cost, reliability, value

Prototype versus production

A prototype proves an assumption.

A production system requires security, reliability, scalability, support, monitoring, documentation, recovery, governance, cost control and ownership.

Delivery team

A typical team may include product owner, AI Solution Engineer, enterprise architect, AI engineer, data engineer, cloud engineer, software engineer, UX designer, security specialist, responsible AI lead, business analyst, change lead and domain expert.

RACI

Define who is Responsible, Accountable, Consulted and Informed for requirements, architecture, data approval, security, model selection, evaluation, release, monitoring and incident response.

Core project registers

Maintain action, decision, assumption, risk, issue, dependency, stakeholder, change and document registers.

Definition of done

A feature is not complete until it meets functional, security, privacy and evaluation thresholds, observability and documentation requirements, operational handover and product-owner approval.

Decision required

Current phase and exit criteria must be explicit; prototype assumptions must be testable; definition of done must include trust and ops handover.

Case study: financial-services assistant

Prototype validates retrieval quality and citation trust with ten power users. Production definition of done adds SSO, security trimming, DPIA sign-off, golden-set thresholds, on-call runbook and named ops owner in the service organisation.

Output

Phase plan with exit criteria, prototype assumption list, RACI for high-risk decisions, live registers, and a definition of done that includes evaluation thresholds and operational handover.

Common failure modes

• Calling a demo “production”
• No RACI for model and data decisions
• Registers that nobody updates
• Done = “merged to main”
• No handover to an operating team

Solution Engineer checklist

Solution Engineer checklist

• Current phase and exit criteria explicit
• Prototype assumptions listed and testable
• RACI agreed for high-risk decisions
• Registers live and reviewed
• Definition of done includes trust and ops

Practical exercise

Write a one-page definition of done for your next release. Include the evaluation threshold that would force a stop.

Key takeaways

• Phases need exit criteria; demos are not production.
• RACI and registers keep decisions recoverable.
• Done includes security, evaluation, docs and ops handover.
• Name an operating owner before go-live.

What to do next

1. Continue with Adoption and change management.
2. Align runbooks with Evaluation and observability.
3. Use 8D Deliver for roadmap and benefits ownership.