Who plays which role in an AI project
When an AI project stalls, what is missing is rarely a skill and usually a responsibility. Six roles carry a project: business ownership, domain expertise, data ownership, IT and integration, privacy and law, and project steering. The two most important are organisational, not technical: ownership and the domain. Those are exactly the ones least often formally named, because people assume IT covers them. The most important lever is a named business owner: a person who decides what a tolerable error is and who looks after launch. Roles that belong to nobody by name are left undone in operation.
The First Question Is Not Which Tool
In many AI projects the first hour goes to models and tools: which system, which vendor, which platform. That is the comfortable question because it looks like progress. The question that really matters sounds less spectacular: who owns what when we go live.
Tools are interchangeable, roles are not. A project can swap the model without tipping over. It tips over the moment an important role sits empty and nobody notices, because everyone assumes someone else has it. Data access, the exception case, the legal basis, operation after launch: behind each of these stands a role, and if it stays empty, the work stays undone.
An AI project rarely fails because a role is filled badly. It fails because a role belongs to nobody.
That is why it pays to clarify the roles before the build, as a simple list with names behind it. Where you stumble on a name, you have found a gap before it costs money.
The Six Roles in an AI Project
Six roles carry an AI project. In small cases one person may take several, but each must be deliberately assigned.
Business ownership. The person accountable for the result: who decides what a tolerable error is, who approves exceptions and who looks after launch. Without them the best system becomes an orphan. This role sits in the business, not in IT alone.
Domain expertise. The people who truly know the case: the typical flows, the rare edge paths, the question of when an answer is good enough. They supply real examples and judge quality. Without their judgement the project builds past reality.
Data ownership. Whoever decides on access, currency and quality of the required data and stands behind it. This role clarifies which data exists, which version is authoritative and how gaps are handled.
IT and integration. Whoever connects the system to the existing stack, sets up access and carries technical operation with permissions and monitoring. A prototype lives without them, an operation does not.
Privacy and law. Whoever clears the legal basis, checks data processing and minimisation and keeps the rights of data subjects in view. Depending on the data this role ranges from advisory to co-deciding, but it belongs at the table before building.
Project steering. Whoever holds dates, decisions and hand-overs together, so nothing falls between the roles. A side role in small efforts, the glue that binds the other five in larger ones.
| Decision | Who owns it | Who feeds in |
|---|---|---|
| What is a tolerable error | Business ownership | Domain expertise |
| Which data, on which legal basis | Privacy and law | Data ownership |
| How it is integrated and operated | IT and integration | Business ownership |
| When a human takes over | Domain expertise | Business ownership |
Where Roles Are Left Undone
Roles rarely go missing because someone declines them. They go missing because nobody explicitly takes them. Four patterns recur, and all four are visible before the build.
Business ownership stays open most often. You ask who decides in the error case and get the name of a department. A department decides nothing, a person does. Data ownership is left undone in the same way when data "comes later" and nobody releases it. Privacy and law are often called only shortly before launch, once the case is long built and a rejection would be expensive.
| Role | How you notice it is missing | What helps |
|---|---|---|
| Business ownership | a department answers in the error case, not a name | name one person, before the build |
| Data ownership | data comes later, nobody releases it | bring the data owner to the table early |
| Privacy and law | review only shortly before launch | involve from the start, not at the end |
| IT and integration | prototype runs, but nothing is connected | involve IT from day one on access |
The good news: all four gaps are organisational. They cost no budget, only an honest round in which every role gets a name.
The Roles Checklist
Before you start an AI project, answer these five questions. If you get no name for one, you have found the gap before it surfaces in operation.
- Who owns the result, by name, not as a department?
- Who knows the case in the domain and is reachable across the project?
- Who releases the data and stands behind its quality?
- Who integrates and operates technically, with permissions and monitoring?
- Who clears the legal basis, and before the build, not after?
Core sentence: a role that belongs to nobody by name is not a role but a gap, and it announces itself in operation, when it is most expensive.
Common Misconceptions
- AI projects are IT's business.
- IT builds and operates, but ownership, domain judgement and data release sit in the business. Without those roles the best build lacks its foundation.
- One person can fill every role at once.
- In small cases a person may share several roles, but each must be deliberately assigned. Unnamed does not mean automatic, it means left undone.
- Privacy comes in at the end.
- Too late. Clearing the legal basis only before launch risks the whole case being inadmissible as built, and the work wasted.
Questions and Responses
- Can one person hold several roles?
- Yes, often sensible in small efforts. What matters is only that each role is deliberately assigned. It becomes a problem when a role is not combined but simply forgotten.
- Does ownership belong to IT or the business?
- To the business, where the value arises. IT owns build and operation, but the question of what a tolerable error is and when a human takes over can only be answered by the business.
- When must privacy join the table?
- From the start. The legal basis decides whether the case may be built at all. You want that answer before the build, not shortly before launch.
Sources and Evidence
No external statistics or unverified client results are asserted as verified. Legal and data questions are cleared case by case against the deployed stack.