Principles
Value at the heart of every decision
AI is adopted not for technology, fashion, polished executive slide decks, or pilot count. Every decision — product launch, initiative selection, stage transition, scaling, or stop — must link to expected or confirmed business value.
Practical meaning: if an initiative or AI product has no clear value hypothesis, it should not receive resources.
Anti-pattern: "Let's deploy an AI agent because everyone is doing agents" or "A vendor demoed a new AI product yesterday — let's roll it out here."
Right approach: start with the business problem, the outcome owner, and a testable effect hypothesis.
Broken process + AI = broken process
If a report is assembled from different data every time, an automated reporting skill will not make it reliable. If recruiting has no standards for evaluating candidates, an HR agent will not make scoring fair or reproducible. If it is unclear where documents live, and who is responsible for keeping them current, RAG will not turn chaos into knowledge.
Practical meaning: before launching an AI product or implementing an AI initiative, you need to ensure the as-is process is mature enough: data is well structured, documented, and kept current; decision rules and process owners are captured in policies; and metrics, quality standards, exceptions, result control, and accountability for errors are in place.
Anti-pattern: a team automates a report that different employees assemble from different sources and with different logic — so AI quickly and consistently produces unrepresentative numbers. In another, RAG is connected to accumulated files with no owner of freshness, no unified structure, and no update rules — and the assistant confidently answers from outdated, contradictory documents.
Right approach: do not automate a broken process. First describe it to a minimally sufficient level, assess its maturity and reproducibility, fix what is broken if needed — and only then add AI as an amplifier for search, generation, analysis, or automation.
AI products address task classes, not one-off requests
The company should aim not to build a unique solution for every separate idea, but to develop reusable AI products that address recurring classes of business problems.
An AI product must answer not only "what task are we solving now?" but also "what class of similar tasks can this product cover next?"
Practical meaning: the same product stack can cover dozens of use cases: knowledge search, document generation, inquiry analysis, request processing, forecasting, and automation of routine operations.
Anti-pattern: each department gets its own agent, separate RAG for the knowledge base, separate models, separate integration, and support logic.
Right approach: identify recurring task patterns and turn them into shared AI products that initiatives from different departments can be routed to.
One business funnel, different delivery tracks
All AI products and AI initiatives should follow one management logic with the stages "Evaluation," "Delivery," "Awaiting impact," "Operations readiness," and "Completed" — with possible rejection at any stage. That lets the company see the full portfolio, compare initiatives, manage priorities, and decide by shared rules.
- 1Evaluation
- 2Delivery
- 3Awaiting impact
- 4Operations readiness
- ✓Completed
Technical implementation should not be the same for every type of AI product. RAG, ML models, AI agents, process automation, language assistants, and developer tools need different delivery tracks: different requirements for data, testing, integrations, quality, security, support, and readiness criteria.
Practical meaning: the business funnel answers "where is the initiative from a management and value perspective?" The delivery track answers "how do we technically bring this solution to result?"
Anti-pattern: every AI initiative is forced into one universal project template — same stages, same artifacts, same readiness criteria — whether the work is RAG, an ML model, an agent, or automation.
Right approach: keep one business funnel for portfolio management, but use different delivery tracks to implement different classes of AI products.
Control proportional to risk
Not every AI initiative needs heavy approval. Review depth and stage gates should depend on the level of risk and novelty, not apply equally to everything.
- Low risk, standard scenario — fast path (self-service), minimal approvals.
- Medium risk — trust-but-verify mode: limited pilot with human-in-the-loop checks and impact control.
- High risk or significant impact — strategic review with security, compliance, architecture, and data.
- Unacceptable risk — the initiative does not launch.
Practical meaning: the same control layer should not slow down both a small departmental experiment and a system that affects customers or regulatory reporting.
Anti-pattern: every idea — from an internal knowledge-base chatbot to credit scoring — goes through the same heavy committee and waits months for approval.
Right approach: classify initiatives upfront by risk and novelty, then route them through different control paths, from self-service to strategic review.
Federated responsibility model
Effective AI adoption should be neither fully centralized nor fully decentralized.
With full centralization, every initiative goes only through the AI function. That creates control but quickly leads to queues, bottlenecks, and loss of business context.
With full decentralization, teams adopt AI on their own. That brings speed but leads to duplicated products, shadow IT, extra load on infrastructure and budgets, security risks, and no path to scale.
The federated model combines both approaches:
- The AI function owns the rules of the game, methodology, technical expertise, infrastructure, product stack, stage gates, training, and adoption support.
- The business owns idea generation, domain expertise, task definition, pilot participation, and confirmation of business impact.
- IT, architecture, security, compliance, and data are not external approvers but full participants in the operating model.
Practical meaning: the AI function should not do everything itself. It should build a system in which the business can adopt AI safely and deliberately.
Anti-pattern: the AI office collects ideas, runs pilots, convinces the business to use the result, and tries to prove impact — all on its own.
Right approach: the business owns the problem and impact; the AI function owns the adoption model, products, and scaling rules.
Adjacent functions are part of the operating model
Architecture, information security, compliance, IT, data, and operations should not join only at the end, when the solution is almost ready. They directly affect whether AI can be adopted and must be embedded in the process from early stages.
Practical meaning: an initiative should pass upfront checks on data, access, architecture, security, integrations, and support.
Anti-pattern: the pilot was shown successfully to the business, but then it turned out it could not be deployed in production because of security constraints, missing data ownership, or inability to support it.
Right approach: adjacent functions participate in stage gates and help reduce risk early rather than slow adoption down.
Training and promotion are part of adoption, not an afterthought
An AI solution is adopted not when it is technically live, but when users understand how to apply it at work, use it regularly, and give feedback for product evolution.
Practical meaning: training, AI champions, support for first initiatives, and feedback collection should be built into the operating model.
Anti-pattern: the team shipped an assistant, posted a link in chat, and considered adoption complete.
Right approach: plan training, first application scenarios, business owners, and usage metrics in advance.
Impact is confirmed, not declared
Expected value for an initiative must turn into confirmed impact or a clear management decision: scale, refine, stop, or move to another format.
Practical meaning: after deployment, an initiative should not simply disappear from the portfolio. You need to know whether the solution is used, whether it delivered impact, who confirmed the result, and whether it can be scaled.
Anti-pattern: "We deployed an AI assistant" is treated as success on its own.
Right approach: success is not launch — it is regular use and confirmed benefit.
Market signals
The operating model principles align with what major consulting firms and industry standards (BCG, McKinsey, Bain, NIST) published in 2024–2026.
| Principle | What the market says | Sources |
|---|---|---|
| Value at the heart of every decision | Only ~5% of companies capture significant value from AI (BCG) and ~6% (McKinsey) — the rest deploy without value | BCG: The Widening AI Value Gap, 2025 · McKinsey: The State of AI, 2025 |
| Broken process + AI = broken process | AI success depends on data, processes, and change owners; without operational discipline, technology scales errors, divergent interpretations, and unstable solutions | BCG: Closing the AI Impact Gap, 2025 · Bain: Building the Foundation for Agentic AI, 2025 |
| AI products address task classes | Value comes not from isolated pilots or "many small wins," but from a few reusable scenarios and rethinking end-to-end workflows | BCG: Agents Accelerate AI Value, 2025 · BCG: The Widening AI Value Gap, 2025 |
| One business funnel, different delivery tracks | A single portfolio with shared prioritization, but different horizons and delivery modes (BCG "Deploy–Reshape–Invent" model) | BCG: AI @ Scale (Deploy–Reshape–Invent) · BCG: The Widening AI Value Gap, 2025 |
| Control proportional to risk | Routing by risk and novelty into 4 lines: self-service / trust-but-verify / strategic review / prohibited | BCG: AI Risk Management Needs a Better Model, 2026 · BCG: Responsible AI, 2026 · NIST AI RMF |
| Federated responsibility model | Strict centralization for risk and control, a federated (hub-and-spoke) model for delivery and diffusion; federated as the target state | McKinsey: The State of AI, 2025 |
| Adjacent functions are part of the operating model | Security, control, and data are built in from the start, not bolted on later | Bain: How to Architect for Agentic AI, 2025 · Bain: Building the Foundation for Agentic AI, 2025 |
| Training and promotion are part of adoption | ~70% of AI success is people and process, not the algorithm (BCG 10-20-70); investing in training raises adoption coverage from ~30% to ~60% | BCG: Closing the AI Impact Gap, 2025 · McKinsey: The State of AI, 2025 |
| Impact is confirmed, not declared | Tracking clear KPIs is the #1 practice by EBIT impact (McKinsey), yet ~60% of companies don't track financial AI KPIs at all (BCG) | McKinsey: The State of AI, 2025 · BCG: Closing the AI Impact Gap, 2025 |