Entities
Entities define the management layer of the operating model: what the company 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 portfolio view: 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 | Purpose | Owner | Links |
|---|---|---|---|
| AI idea | Capture initial demand or hypothesis | Initiator, business | Can become an AI initiative |
| AI initiative | Manage business problem, value, status, and decisions | Business owner, AI function | Has usage description, product, stage, risks, impact |
| AI product | Provide reusable capability for a class of tasks | AI product owner | Used by many initiatives |
| Delivery track | Define implementation path for the AI product type | AI product owner, delivery lead | Sets stages, artifacts, checks, participants |
| Gate | Check readiness for transition | AI function, committee, relevant functions | Allows or blocks initiative movement |
| Artifact | Record state, decision, or readiness evidence | Stage owner | Supports gate decisions |
| Risk | Determine control depth and constraints | Security, compliance, data, architecture, business | Affects route and required checks |
| Impact | Link adoption to measurable benefit | Business owner, finance, AI function | Exists as expected and confirmed impact |
2. Relationship Model
This diagram matters more than a long field list. It shows that the operating model manages movement from business problem to confirmed outcome, not isolated documents.
3. Initiative Lifecycle
The business funnel is unified for all AI initiatives:
Delivery tracks can differ. RAG, ML models, AI agents, process automation, and applied AI services require different checks, artifacts, and participants. The management path should be unified, not the technical implementation route.
4. These Are Not The Same Kind Of Thing
The common mistake is to throw everything into one bucket. The operating model has different classes of objects.
| 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, risk, artifact | Why the initiative can or cannot move forward |
| Outcome objects | Expected impact, confirmed impact, scale decision | 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.
5. Core Model
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.
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.
6. Implementation And Control
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 |
Gate
A gate is not a committee for ceremony. It is a transition rule: can the initiative move forward?
A gate checks minimum readiness: owner, problem, selected AI product, data assessment, risks, pilot criteria, and support model.
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 should affect gates, participants, required artifacts, pilot constraints, and adoption decisions.
7. Impact
Impact is not a promise in a slide deck. It is a measurable benefit that can be checked after adoption.
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.
8. Cardinality
| 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 |
9. 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.
10. Correct Assembly
A strong entity model looks like this:
This set of entities turns AI from scattered experiments into 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.
11. 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.