Roles and responsibility in a project

Target audience: everyone | Prerequisites: 1.5 Anatomy of an AI-automated system

What you'll learn

After this document you will be able to:

• name the five roles that must exist in every AI automation project (delegating work to an AI model);
• say which decisions each role makes and what happens when a role goes unfilled;
• place these roles both in a small and in a large team;
• explain why responsibility for an AI error stays with humans and why decisions are worth writing down.

In plain terms

In an AI project there is one person who knows what is needed, one who does it, and one who checks — as in a kitchen: someone must decide the menu, someone must cook, and someone must taste before serving. Even when all three are one and the same cook, the roles don't disappear: the menu decision, the cooking, and the taste check must still happen. A chain where no one tastes before serving is not an efficient kitchen — it is a risk.

Five roles, five people (or fewer)

Document 1.5 left one question open: someone must be responsible for every part of the system. The parts themselves, however, neither decide nor configure — people do.

1. The sponsor or owner — knows what problem is being solved

What they do. Knows the business problem — where time and money disappear — and defines what value is created: what gets automated, what does not, and within what limits. They don't have to know the technology; they do have to know the business.

Which decisions they make. What problem is solved and what success is; how big the budget is; where a human must step in; whether the system goes live.

When the role is missing. The system gets built on the principle of “something with AI, the benefit will come on its own” — a solution looking for a problem, and in the end no one carries responsibility for the decisions.

2. The builder or technician — assembles the system

What they do. Sets up the system: connects the parts into a working whole and makes sure the whole stays together. They don't have to be a programmer — with no-code tools (visual environments where the system is assembled by clicking) even an office IT enthusiast can manage.

Which decisions they make. Which tools are used; what happens when the model doesn't answer or the result fails the check (the fallback); where the system's limits are.

When the role is missing. At the first breakdown or necessary change the system stands still: no one understands how the parts fit together and no one dares change anything.

3. The content designer — writes what “good” means

What they do. Writes the prompt (the instruction given to the model) and words the criteria that distinguish a good result from a mediocre one. This role doesn't require technical skill but domain expertise: the best content designer is often precisely the person who knows the field.

Which decisions they make. What a “good result” means in this company; which examples to attach to the instructions; what rules apply — tone, language, what the system must never do.

When the role is missing. All the decisions fall to the model — the result is mediocre and a little different every time. Everyone feels that “something isn't right,” but no one can say what to fix.

4. The reviewer — the human in the loop

What they do. Reviews the results before they reach the customer, partner, or another system — and must be able to say “no” and send the work back. This is human-in-the-loop (a workflow in which a human approves the result before it is used).

Which decisions they make. Whether this concrete result goes forward; what goes to manual processing; when there are so many errors that the system must be temporarily stopped.

When the role is missing. The error reaches the customer before anyone sees it — a hallucination (an answer the model states confidently but that is false) becomes a sent letter or a number entered into the system. How to build the loop and the limits into the system is taught more thoroughly by 3.5 Safety: limits and human-in-the-loop.

5. The maintainer — keeps the system running after launch

What they do. Watches that the system works even when the project ended long ago: costs, quality, and changes — including in tools and models that someone updates without their knowledge.

Which decisions they make. Whether the system still works as well as promised; when to intervene; when to replace a part or retire the system.

When the role is missing. The system quietly decays: costs creep up, quality slips, and someone notices only when a customer complains.

In one line:

Small business vs larger team

In plain terms: roles are not job titles but responsibilities. In a small company one person wears several hats at once — but the hats don't disappear: someone must still fill every role. In a large team each hat gets its own head.

In a three-person company: the owner is at once the sponsor and the maintainer (they decide and watch costs and quality), the tech-minded employee is the builder, the most experienced specialist is the content designer — and everyone is a reviewer now and then.

In a larger team the roles become job titles: product owner (the sponsor), developer (the builder), content designer — the person responsible for the prompts — a quality assurance owner, and an operations maintainer. The more people, the more important the agreements about who may change whose prompt and who approves — team standards are covered by 5.2 Team workflows and standards.

Who is responsible when AI errs?

In plain terms: the apology the customer hears is not spoken by the model — your company speaks it. The model has no contract, no signature, no registration — so it cannot carry responsibility either. The responsible party is the human who put the system into use, and the company in whose name the result circulates.

This is not scaremongering but the starting point of system building. If an automated letter promises a customer something that should not have been promised, or a wrong amount reaches accounting, the human and the company still answer for it — the customer, the bank, and the law turn to you, not to the model. That is exactly why the checkpoint exists in the system: since responsibility stays with you, the result must pass a check before leaving — a human or an automated rule, depending on how expensive the error can be. The reviewer and the maintainer are not “extra people” but the places where responsibility concretely lives.

A second truth: the roles, the decisions, and their reasoning are worth writing down — who decided what gets automated; who approved that prompt; what happens if the system errs. When someone leaves or the system is about to change, no one has to remake decisions from scratch or guess why something was done exactly that way. The prompt, in this sense, is a company asset to be versioned and managed — how, 2.6 Managing prompts as an asset teaches; 5.7 Responsibility, ethics, and governance looks at the question of governing the system — governance (the set of rules defining who may make which decisions).

One more responsibility question: when the system sends customer data to an external AI model, the company is responsible for that data too — we look at this in document 3.7 Security: keys, data, malicious instructions.

A step-by-step example: a role-based decision at an accounting firm

A made-up “Number Bureau” — a small accounting firm: owner Anu, five accountants, and Jaak — an office administrator by title, in practice always the one at the company's software.

The problem: invoices arrive by email from clients, and their data must be extracted before entry into the accounting software — who, what, amount, VAT. One invoice takes about three minutes, and about two hundred invoices come in a day.

The decision emerges role by role:

1. Anu, as sponsor, sets the scope. What gets automated is the preparation — extracting invoice data and drafting the entry — not the decisions. She also writes down what will not be automated: approving payment orders in the client's bank and filing tax declarations. Money movement and data submitted to the law — the responsibility is too great to delegate, even if it were technically possible.
2. Jaak, as builder, assembles a workflow (a sequence of automated steps) with ready-made tools. A new invoice in the inbox is the trigger (the event that sets the workflow running); the system reads the attachment, collects the fields, and puts the draft into the accountant's review queue. An unclear invoice goes straight to manual processing.
3. The accountants, as content designers, write the prompts themselves. Only they know what a correct entry looks like: they put examples of correct entries and rules into the instruction — for example, “if the VAT rate is missing from the invoice, don't guess; mark it for review.”
4. An accountant, as reviewer, checks every invoice. The draft sits on screen next to the invoice; approving is one click, rejecting takes two. Exceptional cases stay entirely with the human.
5. Jaak, as maintainer, watches costs and quality weekly — how many drafts were rejected and why. Anu reviews a summary monthly and decides whether to extend the scope (for example, to sales invoices).

The result: the human time per invoice drops from three minutes to about half a minute, and the accountants' day is freed for the work the machine must not do — talking to clients and resolving exceptions. And if Jaak ever leaves, the system doesn't disappear with him: it is written down who decided what, where the prompts live, and who maintains it.

Summary

• Five roles: sponsor/owner, builder/technician, content designer, reviewer, and maintainer — each answers one question: why, how, what is good, does this go forward, and will it still work tomorrow.
• The roles don't disappear even when people repeat — in a small company one person wears several hats, but every role must be filled; in a large team they become job titles.
• Responsibility for an AI error always stays with the human and the company — the customer and the law turn to you, not to the model. This is not scaremongering but the reason the checkpoint exists in the system.
• Roles, decisions, and prompts are worth writing down — when someone leaves or the system is changed, it is clear who decided what and why.

What's next?

• previous → 1.5 Anatomy of an AI-automated system
• next level → 2.1 Toward a good prompt: structure, role, example, output format — Level 1 is now complete; the next level starts here
• back → handbook index