Mission 001 · Target Vision & Operating Model

In 30 seconds

Before individual tools are introduced, a shared target vision is needed: which use cases are pursued, who is responsible, which risk classes apply and how value can be measured. Scattered pilots thus become a steerable approach.

Why it matters

Without a shared target vision, isolated silo solutions emerge whose value, risk and operation no one has an overview of. Responsibility remains unclear, and the same use case is solved in several different ways.

An operating model defines how AI initiatives are assessed, approved, operated and measured — turning experiments into a repeatable practice.

Editorial assessmentThe most common mistake is not the wrong model, but missing decision criteria: without a clear threshold for when a pilot may go into production, good demos remain demos forever.

The core architecture questions

Which use cases do we deliberately pursue — and which do we deliberately not?
Who decides on the approval, operation and shutdown of an AI initiative?
Which risk classes exist, and which obligations are tied to them?
How do we measure value — both functionally and economically?
Which capabilities and which AI Literacy need to be built up?

Typical patterns

AI Inventory: a maintained register of all AI applications, agents and models.
Use-Case Portfolio: use cases assessed by value, risk and maturity.
Roles & Responsibilities: clear assignment of owner, operation and approval.
Risk Classes: graded obligations depending on impact and autonomy.
Value Measurement: value per use case instead of blanket hope.

Common misconceptions & anti-patterns

Tools first, target vision never.
Every department pilots in isolation, without a shared inventory.
Success is measured by activity instead of business value.
Responsibility ends at the proof of concept.

Practical review questions

Can we name all productive AI applications — including those responsible?
Is there a clear threshold for when a pilot may go into production?
Is a measurable value defined per use case?
Who may stop an initiative — and on what basis?

Link to the end-to-end worked example

Who is accountable for the service agent, what goal does it pursue — and which decisions is it allowed to make?

A named owner is accountable for operation, approval and shutdown; the initiative is listed in the AI inventory.
Goal and benefit are defined in measurable terms (e.g. faster, more traceable case handling) — not “more AI”.
A clear boundary: the agent may propose and prepare, but may only trigger defined actions after human approval.
A risk class determines which obligations (approvals, logging) apply to precisely this case.

To the full worked example: service agent

Link to the reference architecture

This mission is the bracket around all the others: it defines which initiatives come into being at all and under which obligations they pass through the remaining architecture missions.

Mission 004 Identity limits scope of action Mission 005 Quality becomes measurable