Organised by the delivery chain, not by a sales funnel
This page describes responsibilities. It is not a staff list, and it does not show headcount or reporting lines.
An AI project has four parts: work out what is actually needed, make the model and the data work, get the system running in a real environment, and keep it useful after go-live. Someone owns each part, but the same people stay with one project from beginning to end. Handing a project over mid-way loses context, and in AI delivery context is most of what makes the result work.
So read this as "who is responsible for what", not "who reports to whom".
- Scenario mapping, data readiness review
- Feasibility judgement and risk notes
- Proposal, milestones, itemised quotation
- Acceptance criteria and evaluation set
- Model selection, fine-tuning, inference deployment
- Document parsing, chunking, retrieval chain
- Data cleaning and labelling standards
- Failure-case analysis and tuning
- Front-end, back-end and system integration
- Containerised deployment and cloud architecture
- Permissions, logging, monitoring, backups
- Camera and production-line integration
- Training and documentation handover
- Knowledge-base upkeep and content operations
- Usage dashboards and analysis
- Incident response and GEO monitoring
Who owns which direction
Owner means accountable for the outcome; the others join according to scope
| Direction | Owner | Usually also involved | Judged by |
|---|---|---|---|
| Large-model applications | Algorithms & Data | Engineering & Deployment | Pass rate on the agreed evaluation set |
| Industrial AI | Algorithms & Data | Engineering, Requirements | Miss and false-positive rates measured on the line |
| Software development | Engineering & Deployment | Requirements & Solution | Feature checklist and acceptance cases |
| Cloud services | Engineering & Deployment | Operations & Support | Availability, restore drill, cost report |
| SaaS and operations | Operations & Support | Engineering, Requirements | Activity and retention, release cadence |
| GEO optimisation | Operations & Support | Requirements & Solution | Citations and mentions in AI answers |
Three things the chart does not show
Held by a fixed routine rather than by somebody's sense of responsibility
Solution review
Every project is reviewed before it starts. The point is not how to build it, but whether it should be built.
- Is the data obtainable, sufficient, clean enough
- Which number decides success
- What current technology cannot do, stated on the spot
Quality acceptance
AI deliverables are not accepted on "the demo looked good". They are scored against an evaluation set.
- The evaluation set is agreed with the client during design
- Failure cases are classified: data, retrieval or model
- If the line is not reached we say so; we do not quietly lower it
Incident response
After go-live, response times are those agreed in advance, and responsibility sits with a person, not a group chat.
- Monitoring and alerting configured during deployment, not after an outage
- Response times and escalation written into the contract or the operations agreement
- Each incident produces a review; the fixes go into the next release
Roles we deliberately do not have
Saying what is absent is more useful than listing titles
Not on the chart
Why
The people who scope a project are the ones who later maintain it, so nothing gets promised just to win a signature. Scheduling is done by the people doing the work, and there is no extra layer relaying messages in between. Anything outside our capability is declined during the proposal stage with the reason stated.