Entities

Entities define the management layer of the operating model: what the AI function accepts into work, how it evaluates demand, through what it implements solutions, where it controls risk, and how it records outcomes.

A shared entity model lets the AI function, business, IT, data, architecture, security, and leadership work from one shared picture of the world: from initial demand to confirmed impact. Without it, initiatives cannot be compared consistently, decisions cannot follow common rules, and the company cannot see where value is being created or where the process is stuck.

---

1. Entity Map

Entity	Class	Purpose	Owner
AI idea	Demand	Capture initial demand or hypothesis.	Initiator, business.
AI initiative	Demand	Manage business problem, value, status, and decisions.	Business owner, AI function.
AI product	Implementation	Provide reusable capability for a class of tasks.	AI product owner.
Delivery track	Implementation	Define implementation path for the AI product type.	AI product owner, delivery lead.
Gate	Control	Check readiness for transition.	AI function, committee, relevant functions.
Artifact	Control	Record state or readiness evidence.	Stage owner.
Risk	Control	Determine control depth and constraints.	Security, compliance, data, architecture, business.
Impact	Outcome	Link adoption to measurable benefit.	Business owner, finance, AI function.

---

2. Four Classes of Objects

The common mistake is to throw everything into one bucket. The operating model's entities split into four classes, and each is managed differently.

Class	Includes	Management meaning
Demand objects	AI idea, AI initiative.	What the business wants to change.
Implementation objects	AI product, delivery track.	Through what and how it will be implemented.
Control objects	Gate, artifact, risk.	Why the initiative can or cannot move forward.
Outcome objects	Impact (expected and confirmed).	What changed for the business.

If these classes are not separated, the platform becomes one giant 80-field form: the user cannot tell whether they are filling in an idea, project plan, risk questionnaire, or impact report.

The entities below are described along these four classes.

---

3. Demand objects: idea and initiative

AI idea

An AI idea is an initial hypothesis: "AI may help here." It does not need to be complete, proven, or ready for delivery.

At minimum, an idea needs a problem, initiator, business area, and preliminary value expectation. Everything else can be clarified later.

AI initiative

An AI initiative is the main unit for managing demand and value. It appears when an idea has enough structure to be evaluated.

An initiative should contain business problem, result owner, current process, expected impact, users, constraints, business-funnel status, and routing decision.

An initiative is not necessarily a classic project. It may become a quick pilot, connection to an existing AI product, full development effort, experiment, or part of a larger program.

Inside the initiative, it is still important to describe usage: who the user is, what action they perform, what data is needed, what result they receive, and how quality is checked. This is not a separate entity; it is a required view of the initiative.

For example, "adopt AI in HR" is too vague. "Compare resumes with a vacancy profile by agreed criteria and give the recruiter an explainable shortlist" is a usable description inside an initiative.

An initiative moves through one business funnel shared by all initiatives — with rejection possible at any stage. The funnel status is a property of the initiative, not a separate entity; how exactly the initiative moves through the stages is described in Processes.

---

4. Implementation objects: product and delivery track

AI product

An AI product is a reusable capability used to implement a class of initiatives: corporate LLM, RAG platform, ML platform, code agent, document AI, automation platform, or applied AI service.

An AI product should have an owner, scope, constraints, onboarding rules for new scenarios, support model, roadmap, and usage metrics.

Delivery track

The delivery track answers: how exactly will the chosen solution be built, tested, and adopted. The same business-funnel stage Delivery means different work depending on solution type:

Solution type	What the delivery track checks
LLM scenario	Prompt, constraints, answer quality, user instruction.
RAG	Sources, knowledge freshness, access rights, search and answer quality.
ML model	Data, features, training, metrics, monitoring, drift.
AI agent	Actions, access, constraints, logging, human-in-the-loop.
Process automation	Process map, integrations, exceptions, roles, result control.
Applied AI service	UX, API, architecture, integrations, operations, support.

---

5. Control objects: gate, artifact, risk

Gate

A gate is not a committee for ceremony. It is a transition rule: can the initiative move forward? A gate belongs to a transition between stages, not to a page in a document, and it relies on artifacts as readiness evidence.

What exactly is checked at each transition — owner, clear problem, selected AI product, data assessment, risks, pilot criteria, support model — is defined in Processes.

Artifact

An artifact is evidence of state. Not "a document because the process says so," but the trace of a decision: initiative card, usage description, risk review, architecture review, pilot plan, impact report.

A good artifact answers one question: what decision can now be made?

Risk

Risk determines control depth. An internal LLM scenario for drafts and an agent with access to production systems should not follow the same route.

Risk affects gates, participants, required artifacts, pilot constraints, and adoption decisions.

---

6. Outcome object: impact

Impact is not a promise in a slide deck. It is a measurable benefit that can be checked after adoption.

1. 1Expected impact
2. 2Pilot / adoption
3. 3Measure actual result

Status	Management decision
Impact confirmed	Scale or support
Impact not confirmed	Refine, stop, or change the initiative description

Example:

• Expected impact: reduce analytical brief preparation time from 2 hours to 30 minutes.
• Confirmed impact: after the pilot, average time fell to 35 minutes across 20 tasks.
• Management decision: scale to similar departments or improve source quality.

Without impact as an entity, the operating model becomes activity tracking: how many ideas were collected, pilots launched, and meetings held.

---

7. How entities connect

Value is not created by a single entity, but by the links between them. The base rules:

Link	Rule
AI idea → AI initiative	Not every idea becomes an initiative.
AI initiative → AI product	An initiative may use one or several AI products.
AI product → AI initiative	One AI product serves many initiatives.
AI product → delivery track	A product may have a standard delivery track.
Gate → transition	A gate belongs to a transition between stages.
Artifact → gate	An artifact supports readiness or records a decision.
Risk → control	Higher risk means deeper review.
Impact → decision	Confirmed impact leads to scaling, support, refinement, or closure.

---

8. Anti-Pattern

A weak operating model looks like this:

• ideas are collected in a shared spreadsheet;
• pilots launch without one business funnel;
• AI products are bought separately from demand;
• usage inside initiatives is not described;
• gates are replaced by meetings;
• risks are reassessed from scratch every time;
• impact is discussed after the fact and without baseline metrics.

The AI function becomes a dispatcher of chaos: accepting requests, chasing approvals, collecting status manually, and failing to prove that AI adoption changes the business.

---

9. Correct Assembly

Assembled together, the entities form a managed path for the initiative — from business problem to decision:

1. 1Business problem
2. 2AI idea
3. 3AI initiative
4. 4AI product
5. 5Delivery track
6. 6Gate: delivery admission
7. 7Pilot / implementation
8. 8Gate: ready for impact
9. 9Impact measurement
10. 10Final decision

This assembly matters more than a long field list: the operating model manages movement from business problem to confirmed outcome, not isolated documents. That is how AI stops being scattered experiments and becomes a managed portfolio — the company can see what came from the business, which AI product implements it, which risks constrain movement, and what impact was achieved after adoption.

---

10. Short Formula

Operating model entities are the shared language for managing AI adoption: from idea and initiative to product, delivery, risk, and confirmed impact.

Short version:

Roles show who manages AI. Entities show what exactly the operating model manages.