Bir Ecosystem Deploys AI Operating System to End Redundant Bot Builds

Presentation by Valeh Nabiyev, Pasha Holdings — Ai4

Ai4

Enterprise AI initiatives fail because decentralized teams repeatedly rebuild foundational plumbing rather than running on a unified operating system that decouples business demand from technical friction.

AI-assisted summary of Presentation by Valeh Nabiyev, Pasha Holdings — original source. Check the original for full context.

Source published: 2026-08-19

Detailed notes

## Background Published on YouTube by the channel Ai4 on August 19, 2026, this presentation features Valeh Nabiyev, Chief Data & AI Officer at Bir Ecosystem. The session description highlights that most AI initiatives fail because organizations are ill-equipped to scale them, introducing the Enterprise AI Operating System as a practical framework to turn AI into a durable organizational capability.

## TL;DR Drawing from his experience scaling AI across banking, fintech, and e-commerce verticals at Bir Ecosystem, Valeh Nabiyev explains how fragmented, project-based AI delivery created severe engineering bottlenecks and redundant solutions like four separate HR assistants. To solve this, he outlines the Enterprise AI Operating System, an architectural framework built across five interdependent capabilities: Operating Model, Intelligence Factory Platform, Universal AI Gateway, Knowledge Foundation, and the Human Layer. The framework decouples shared governance and technical plumbing from stream-aligned product teams, ensuring adoption is constrained only by business demand rather than enterprise friction. Nabiyev concludes with a mandate for enterprise leaders to shift away from managing isolated use cases and instead design systems that compound organizational intelligence over time.

## Atmosphere & style The presentation carries the pragmatic, hard-won authority of an executive speaking directly from the operational trenches rather than an ivory tower. Nabiyev balances self-deprecating humor about real-world enterprise missteps—such as multiple teams unknowingly rebuilding the same tools—with crisp, rigorous architectural diagrams. Watching it feels like a focused, lucid strategic briefing that strips away generative AI hype to address the unglamorous realities of governance, workflow adoption, and institutional design.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=iwz087lDRfg&t=4s) The primary challenge in enterprise AI quickly shifts from validating whether isolated use cases can be built to delivering AI at the speed and scale the business demands. - [02:39](https://www.youtube.com/watch?v=iwz087lDRfg&t=159s) Siloed, project-by-project delivery leads to massive redundancy, such as separate business units independently building identical internal assistants. - [06:40](https://www.youtube.com/watch?v=iwz087lDRfg&t=400s) The true bottleneck in enterprise AI adoption is organizational and architectural friction rather than limitations in frontier models or algorithms. - [06:40](https://www.youtube.com/watch?v=iwz087lDRfg&t=400s) Just as ERP standardized business operations and cloud standardized software delivery, modern enterprises require an operating system layer to standardize machine intelligence. - [09:46](https://www.youtube.com/watch?v=iwz087lDRfg&t=586s) Scaling AI requires an operating model where central teams provide shared infrastructure and guardrails while business product teams maintain end-to-end ownership of value creation. - [11:57](https://www.youtube.com/watch?v=iwz087lDRfg&t=717s) An AI platform should function as an 'Intelligence Factory' that standardizes the lifecycle from build to reuse, preventing product teams from rebuilding platform plumbing. - [11:57](https://www.youtube.com/watch?v=iwz087lDRfg&t=717s) A Universal AI Gateway decouples client applications from underlying model endpoints, enforcing consistent security, PII masking, routing, and auditing across the enterprise. - [14:27](https://www.youtube.com/watch?v=iwz087lDRfg&t=867s) Knowledge must be treated as an enterprise-wide asset ('Data Governance 2.0') so organizational context compounds over time instead of fragmenting across isolated RAG pipelines. - [16:10](https://www.youtube.com/watch?v=iwz087lDRfg&t=970s) Closing the widening absorption gap between AI capabilities and enterprise adoption requires redesigning workflows and decision rights rather than relying on generic training portals. - [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) The five pillars of the Enterprise AI Operating System are tightly interdependent; missing any single pillar causes the entire architecture to fail. - [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) AI leadership must evolve from approving individual projects to four systemic mandates: designing system architecture, governing intelligence, measuring business value, and compounding organizational capability.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=iwz087lDRfg&t=4s) Transforming Bir Ecosystem: From Isolated Use Cases to an Operating System

Valeh Nabiyev, Chief Data & AI Officer at Bir Ecosystem, introduces his journey over the past year: shifting AI from disconnected, one-off use cases into a core, dependable organizational capability. Bir Ecosystem operates across three distinct verticals—banking, fintech/payments, and e-commerce—in Azerbaijan, handling millions of daily customer transactions. In Azerbaijani, the word *"Bir"* means "one," a central metaphor that anchors the entire presentation on creating a single, unified enterprise system.

```mermaid flowchart LR accTitle: Bir Ecosystem Verticals A["Bir Ecosystem"] --> B["Banking"] A --> C["Fintech & Payments"] A --> D["E-Commerce"] ```

Like most modern organizations, the team started by tackling immediate business problems: deploying customer support bots, debt collection assistants, chatbots, and internal knowledge assistants. Six months earlier, Nabiyev notes, he would have proudly presented slides showing these successful implementations as proof of a thriving AI transformation. However, once business stakeholders witnessed real impact, demand surged dramatically. The challenge instantly shifted from asking *"Can we build an AI use case?"* to confronting a fundamental scaling question: *"Can we build AI as fast and as extensively as the business requires?"*

- Bir Ecosystem encompasses banking, payments/fintech, and e-commerce in Azerbaijan. - Initial successful deployments spanned customer support, debt collection, and enterprise knowledge assistants. - Business demand rapidly outpaced the capacity to deliver bespoke, project-by-project solutions.

---

[02:39](https://www.youtube.com/watch?v=iwz087lDRfg&t=159s) The Scaling Bottleneck and the "Four HR Assistants" Problem

Looking beneath the surface of individual AI deployments revealed massive, repetitive engineering overhead. Delivering a single use case demanded a lengthy checklist: model selection, PII masking, data access evaluation, system integration, and prompt engineering. Because each initiative operated as a siloed effort, engineering teams repeatedly rebuilt the same underlying components—gateways, evaluation harnesses, knowledge pipelines, governance approvals, and deployment pipelines—for distinct business problems.

This fragmented approach culminated in an absurd realization: four different vertical business units within the company had independently built four separate HR assistants to answer employee questions. As Nabiyev wryly observes, *"It's funny now, but it was not funny at that moment."* The teams had not failed or acted maliciously; they simply delivered what their business unit requested. The absence of shared platforms made duplicating work the organizational default.

```mermaid flowchart TD accTitle: Redundant Siloed AI Implementations subgraph Siloed["Fragmented Delivery Model"] U1["Vertical 1: HR Assistant"] --- C1["PII / Gateway / Eval / Infra"] U2["Vertical 2: HR Assistant"] --- C2["PII / Gateway / Eval / Infra"] U3["Vertical 3: HR Assistant"] --- C3["PII / Gateway / Eval / Infra"] U4["Vertical 4: HR Assistant"] --- C4["PII / Gateway / Eval / Infra"] end ```

---

[06:40](https://www.youtube.com/watch?v=iwz087lDRfg&t=400s) Shifting Focus: The Enterprise AI Operating System

The primary bottleneck in enterprise AI adoption is rarely the technology, frontier models, or algorithms themselves; rather, it is enterprise friction—legacy architectures, fragmented workflows, and bureaucratic inertia. When product teams spend the majority of their time building foundational infrastructure instead of business logic, scaling stalls. The primary objective became clear: drastically reduce the time, cost, and effort required to move any AI concept from idea to production.

Nabiyev emphasizes that enterprise AI cannot be bought off the shelf through vendor platforms. Just as ERP standardized core business operations and cloud computing standardized software delivery, modern enterprises require an operating system layer for machine intelligence. The rate of AI adoption must be constrained solely by business demand, never by internal enterprise friction.

- Buying vendor platforms is straightforward; designing organizational architecture to scale them is the true challenge. - The Enterprise AI Operating System removes friction across five structural capabilities: Operating Model, Platform, Gateway, Knowledge Foundation, and Human Layer.

---

[09:46](https://www.youtube.com/watch?v=iwz087lDRfg&t=586s) Capability 1: Operating Model & Clear Decision Rights

The first and most critical component is the operating model, designed specifically to eliminate decision ambiguity. Without well-defined governance, product owners face constant friction trying to determine who approves deployments, manages policies, oversees model risk, ensures human-in-the-loop oversight, or coordinates incident response.

```mermaid flowchart LR accTitle: AI Operating Model Governance Triad A["Technology Teams"] -->|"Build & Maintain"| B["Shared Platform & Standards"] C["Business Product Teams"] -->|"Own & Drive"| D["Business Value & Metrics"] E["Risk & Control Teams"] -->|"Assure & Validate"| F["Policy & Governance"] ```

A core tenet of this framework is that AI cannot scale through centralized project delivery. Instead, the central team provides strategic direction, guardrails, and shared infrastructure, while business product teams maintain ownership of end-to-end value creation. If accountabilities at the operating model layer are ambiguous, every technological layer built on top inevitably wobbles.

- The central team establishes direction, guardrails, and shared infrastructure. - Business product teams own value and business outcomes. - Risk and compliance functions assure policies, model auditability, and controls.

---

[11:57](https://www.youtube.com/watch?v=iwz087lDRfg&t=717s) Capabilities 2 & 3: The Intelligence Factory and Universal AI Gateway

The second capability is the AI Platform, structured as an "Intelligence Factory" rather than an R&D lab. This factory standardizes a unified lifecycle from inception to operations: build, evaluate, certify, deploy, observe, learn, and reuse. Referencing the principles of *Team Topologies*, Nabiyev stresses that stream-aligned business delivery teams must never be forced to build bespoke platform and governance plumbing; their energy must remain dedicated to shipping business capabilities.

```mermaid flowchart LR accTitle: Universal AI Gateway Architecture subgraph Clients["User Surfaces"] S1["Assistants"] S2["Workflows"] S3["Customer Apps"] end

subgraph Core["Control Plane"] GW["Universal AI Gateway Policy, PII Masking, Routing, Auditing"] end

subgraph Models["Model Providers"] M1["Frontier LLMs"] M2["Open Source Models"] M3["Custom ML Models"] end

Clients --> GW GW --> Models ```

The third capability is the Universal AI Gateway, which eliminates per-project negotiations over model routing, security policies, and access control. Regardless of whether front-end surfaces interact with internal assistants, automated workflows, or customer-facing applications, every request routes through a single control plane. This gateway enforces unified guardrails and security policies across all underlying models—whether proprietary frontier LLMs, open-source weights, or internal machine learning services.

- Standardized intelligence factory lifecycle: build, evaluate, certify, deploy, observe, learn, reuse. - Aligns with *Team Topologies* by freeing stream-aligned teams from platform engineering. - Central gateway decouples diverse application front-ends from backend model endpoints.

---

[14:27](https://www.youtube.com/watch?v=iwz087lDRfg&t=867s) Capability 4: Knowledge Foundation (Data Governance 2.0)

While the AI industry has shifted its attention toward autonomous agents, the foundational principle of "garbage in, garbage out" remains entirely operative. Organizations make a critical mistake when they assign individual AI engineering teams to scrape disparate business data and build isolated RAG pipelines.

Knowledge must be managed as an enterprise-wide capability—effectively "Data Governance 2.0." Whether structured as context graphs, enterprise knowledge graphs, or standardized Context RAG pipelines, internal data assets must be centrally governed and refined. By establishing a continuous feedback loop, the enterprise knowledge base compounds in accuracy and depth over time rather than being reconstructed for each new application.

- Isolated RAG pipelines built by project-level data scientists create fragmented, brittle knowledge. - Centralized knowledge architecture compounds organizational context into a reusable enterprise asset.

---

[16:10](https://www.youtube.com/watch?v=iwz087lDRfg&t=970s) Capability 5: The Human Layer and Closing the Adoption Gap

The final, essential capability is the Human Layer. A widening gap exists between the rapidly accelerating curve of AI capabilities and the comparatively flat line representing what an enterprise can actually absorb. Closing this gap cannot be accomplished through superficial town halls, generic training portals, or broadcast emails.

```mermaid flowchart TD accTitle: Closing the Enterprise Absorption Gap AI["Accelerating AI Capabilities"] -.-> Gap["Absorption Gap"] Org["Flat Organizational Absorption"] -.-> Gap Gap --> Solution["Human Layer Interventions"] Solution --> R1["Redesigned Roles & Human-Agent Collaboration"] Solution --> R2["Clear Decision Thresholds (When to Escalate)"] Solution --> R3["Certified Role-Based Champions"] Solution --> R4["Incentives Tied to Workflow Adoption (Not Logins)"] ```

Closing the absorption gap requires a fundamental redesign of workflows and decision rights: establishing precisely when an agent is empowered to act autonomously versus when human intervention is mandatory. Business leaders must possess sufficient AI fluency to redesign their team workflows, supported by certified champions embedded within functional units. Success metrics must track concrete workflow adoption rather than vanity login counts.

- Generic training portals fail to drive organizational absorption. - Workflows must define explicit human-agent decision boundaries and escalation triggers. - Incentives and metrics must align directly with real operational adoption.

---

[17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) The Cohesive System Test and the New Leadership Mandate

The five pillars of the Enterprise AI Operating System form an indivisible whole; removing any single component causes the broader enterprise architecture to collapse. A company can succeed at individual workstreams and still fail overall if the capabilities are not developed and matured in unison.

| Missing Capability | Failure Mode and Consequence | |:--- |:--- | | **No Operating Model** | The platform becomes just another tool with zero accountability or ownership. | | **No Platform** | Teams revert to rebuilding fundamental capabilities from scratch for every use case. | | **No Gateway** | Scaling introduces catastrophic security, cost, and governance risks. | | **No Knowledge Foundation** | Deployments result in agents that are highly articulate yet factual hallucinations ("articulate and wrong"). | | **No Human Layer / Adoption** | The most expensive failure mode: full technical deployment with zero business change. |

Nabiyev concludes by challenging enterprise technology leaders to abandon the outdated posture of managing use-case approvals, overseeing isolated projects, and reporting vanity activity. The modern AI leadership mandate is defined by four core verbs:

- **Design** the system architecture as an act of leadership, not merely technical execution. - **Govern** intelligence by establishing decision rights while keeping humans accountable. - **Measure** tangible business value and operational outcomes. - **Compound** organizational capability so that every single delivery leaves the enterprise systematically stronger.

## Notable quotes > Most AI initiatives don't fail because of the technology—they fail because organizations aren't designed to scale them. — Valeh Nabiyev

> [00:04](https://www.youtube.com/watch?v=iwz087lDRfg&t=4s) Can we build an AI use case? — Valeh Nabiyev

> [00:04](https://www.youtube.com/watch?v=iwz087lDRfg&t=4s) Can we build AI as fast and as extensively as the business requires? — Valeh Nabiyev

> [02:39](https://www.youtube.com/watch?v=iwz087lDRfg&t=159s) It's funny now, but it was not funny at that moment. — Valeh Nabiyev

> [06:40](https://www.youtube.com/watch?v=iwz087lDRfg&t=400s) Buying vendor platforms is straightforward; designing organizational architecture to scale them is the true challenge. — Valeh Nabiyev

> [06:40](https://www.youtube.com/watch?v=iwz087lDRfg&t=400s) The rate of AI adoption must be constrained solely by business demand, never by internal enterprise friction. — Valeh Nabiyev

> [14:27](https://www.youtube.com/watch?v=iwz087lDRfg&t=867s) garbage in, garbage out — Valeh Nabiyev

> [14:27](https://www.youtube.com/watch?v=iwz087lDRfg&t=867s) Data Governance 2.0 — Valeh Nabiyev

> [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) articulate and wrong — Valeh Nabiyev

> [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) The most expensive failure mode: full technical deployment with zero business change. — Valeh Nabiyev

> [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) Design the system architecture as an act of leadership, not merely technical execution. — Valeh Nabiyev

> [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) Compound organizational capability so that every single delivery leaves the enterprise systematically stronger. — Valeh Nabiyev

## Mentioned Valeh Nabiyev, Bir Ecosystem, Pasha Holdings, Ai4, Azerbaijan, Team Topologies, Enterprise AI Operating System, Universal AI Gateway, Context RAG

## Video description Valeh Nabiyev - Chief Data & AI Officer, Bir Ecosystem

Most AI initiatives don't fail because of the technology—they fail because organizations aren't designed to scale them. In this session, I'll introduce the Enterprise AI Operating System: a practical framework for turning AI into an organizational capability and creating business value at scale.

[Source](https://www.youtube.com/watch?v=iwz087lDRfg)

中文简报

Bir Ecosystem部署AI操作系统以终结重复构建Bot的局面企业AI项目之所以失败，是因为去中心化团队在反复重构底层基础设施，而不是基于一套将业务需求与技术摩擦解耦的统一操作系统来运行。 Valeh Nabiyev结合其在Bir Ecosystem将AI规模化拓展至银行、金融科技和电商领域的经验，阐明了碎片化、基于项目的AI交付模式如何导致严重的工程瓶颈和重复建设（例如各自独立开发了四个HR助手）。为解决这一问题，他提出了企业级AI操作系统（Enterprise AI Operating System），该架构框架由五个相互依存的能力构成：运营模型（Operating Model）、智能工厂平台（Intelligence Factory Platform）、通用AI网关（Universal AI Gateway）、知识底座（Knowledge Foundation）以及人类层（Human Layer）。该框架将共享治理与技术底层管道从业务流对齐的产品团队中解耦出来，确保AI的落地仅受业务需求驱动，而不受企业内部摩擦的限制。Nabiyev最后呼吁企业领导者摆脱管理孤立用例的模式，转而设计能够随着时间推移使组织智能持续产生复利的系统。企业AI的核心挑战迅速从验证单个孤立用例是否可行，转变为以业务所要求的速度和规模交付AI。 (0:04) 孤岛式、按项目逐个交付的模式会导致大量重复建设，例如不同业务单元各自独立开发功能相同的内部助手。 (2:39) 企业应用AI的真正瓶颈在于组织和架构层面的摩擦，而非前沿模型或算法本身的限制。 (6:40) 正如ERP标准化了业务运营、云计算标准化了软件交付一样，现代企业需要一个操作系统层来标准化机器智能。 (6:40) 规模化扩展AI需要建立一种运营模式：由中心团队提供共享基础设施与规范边界，而业务产品团队则全权负责价值创造的端到端闭环。 (9:46)

Reading summary

Valeh Nabiyev argues that enterprise AI adoption stalls not from algorithmic limitations, but from organizational friction and duplicated engineering. Scaling AI across complex ecosystems requires moving past isolated use cases to establish a unified enterprise operating system. The Scaling Bottleneck of Isolated Delivery (2:39) In deploying initial AI solutions across banking, fintech, and e-commerce, Bir Ecosystem initially succeeded with targeted tools such as customer support bots, debt collection assistants, and internal knowledge search. However, as business demand rapidly surged, the bespoke, project-by-project delivery model exposed major operational inefficiencies. Engineering teams had to repeatedly re-engineer foundational plumbing—including model selection, PII masking, data access evaluation, and deployment harnesses—for each distinct business problem. This fragmented approach culminated in four separate vertical business units independently engineering four distinct HR assistants to answer internal employee questions. Nabiyev highlights this redundancy to show that enterprise friction—legacy structures, siloed workflows, and lack of shared platforms—serves as the real bottleneck to scale, rather than the capabilities of underlying frontier models. Standardized Platforms and the Universal Gateway (9:46) To eliminate decision ambiguity and engineering duplication, the operating framework establishes a clear governance triad. The central team provides architecture, guardrails, and shared infrastructure; business product teams maintain ownership of end-to-end value and metrics; and risk teams validate policies and model auditability. This setup removes platform-building burdens from stream-aligned product teams, adhering to core Team Topologies principles. Technical execution centers on an "Intelligence Factory" and a Universal AI Gateway. The factory standardizes the complete lifecycle—build, evaluate, certify, deploy, observe, learn, and reuse—treating AI delivery as an operational pipeline rather than an R&D experiment. Concurrently, the universal gateway routes all assistant, workflow, and customer application requests through a single control plane. This enforces unified PII masking, policy compliance, and auditing across both proprietary frontier LLMs and open-source models. Treating Enterprise Knowledge as Compounding Infrastructure (14:27) Nabiyev cautions against the common misstep of assigning individual project teams to scrape disconnected data and assemble bespoke retrieval-augmented generation (RAG) pipelines. Because the principle of 'garbage in, garbage out' persists in the era of autonomous agents, fragmented RAG setups create fragile, disconnected islands of knowledge. Instead, knowledge management must operate as centralized "Data Governance 2.0." By organizing enterprise information into standardized context graphs and enterprise knowledge graphs, organizations establish a shared feedback loop. This architecture allows the underlying context layer to compound in accuracy, depth, and utility over time, serving multiple applications without redundant data engineering. Overcoming the Human Absorption Gap (16:10) A critical barrier in AI transformation is the widening gap between rapidly expanding model capabilities and the relatively static capacity of enterprises to absorb change. Nabiyev contends that broad-brush interventions, such as company-wide town halls, generic training portals, and broadcast communications, fail to close this divide. Bridging the absorption gap requires redesigning operational workflows and setting strict boundaries for human-agent collaboration. Organizations must clearly delineate when an agent can act autonomously versus when human intervention is mandatory. To sustain this transition, companies must embed certified AI champions within functional units and replace vanity metrics, like portal login counts, with incentives tied directly to measurable workflow adoption. Nabiyev stresses that the operating model, platform, gateway, knowledge foundation, and human layer form an indivisible system where neglecting any single pillar triggers systemic failure. Modern AI leadership must move away from approving isolated use cases and instead design compounding architectures that leave the enterprise structurally stronger with each deployment.

精炼阅读摘要

Valeh Nabiyev 提出，企业规模化应用人工智能的核心瓶颈不在于算法模型本身，而在于内部架构与流程的摩擦；企业必须从孤立的项目交付转向构建涵盖治理模型、平台底座、安全网关、知识基座与组织吸收能力的“企业级人工智能操作系统”。烟囱式交付与工程重复建设瓶颈 (2:39) Bir Ecosystem 在阿塞拜疆跨足银行业务、金融科技与支付以及电子商务三大垂直领域，每日处理数百万笔客户交易。Nabiyev 介绍，团队最初专注于解决具体的业务问题，接连部署了客服机器人、催收助手和企业内部知识库。然而，随着各业务部门看到实际成效，业务需求呈爆发式增长，交付模式迅速遭遇规模化瓶颈：团队不再受困于“能否构建某个用例”，而是面临“能否以业务需要的速度和规模进行交付”的挑战。深入分析发现，单点项目的交付伴随着巨大的重复工程开销。每个新用例上线都需要单独处理模型选型、个人身份信息（PII）脱敏、数据访问评估、系统集成与提示词工程，工程团队不断为不同业务场景重复造轮子。这种烟囱式交付导致四个独立的垂直业务单元各自开发了四套完全相同的人事问答助手。Nabiyev 强调，这并非工程师失职，而是因为缺少跨业务的共享平台，使重复劳动成为组织惯性下的默认选择。阻碍技术扩展的真正瓶颈并非前沿算法，而是遗留架构与碎片化流程所造成的企业摩擦。企业级AI操作系统与权责治理模型 (6:40) Nabiyev 指出，如同 ERP 系统标准化了企业业务运营、云计算标准化了软件基础设施一样，现代企业在人工智能时代同样需要一层能够标准化机器智能的基础系统。企业级 AI 能力无法仅靠向外部供应商采购现成软件来解决，核心难点在于建立支撑规模化落地的组织架构，确保技术的应用速度完全取决于业务需求，而非受制于内部沟通与治理阻力。该系统的第一大支柱是明确的运营与治理模型（Operating Model），其核心目的在于消除决策权模糊带来的损耗。Nabiyev 主张，AI 的规模化绝不能依赖中心化团队去逐一承包项目交付，而是由中央团队负责技术战略方向、安全护栏并提供共享平台底座；业务产品团队负责端到端的业务指标与实际价值创造；风险与合规部门则专门负责政策校验、模型可审计性与控制措施。若运营模型中的权责界定不清，构建其上的所有技术底座都将陷入动摇。智能工厂标准流程与通用AI网关 (11:57) 在技术架构层面，系统由 AI 平台与通用 AI 网关两大支柱提供支撑。平台层被定位为“智能工厂”（Intelligence Factory）而非研发实验室，它将 AI 生命周期标准化为构建、评估、认证、部署、观测、学习与复用七大环节。Nabiyev 援引《团队拓扑》（Team Topologies）的组织理念指出，直面业务交付的敏捷团队不应被迫自行搭建底层平台和治理管道，其精力必须完全聚焦于交付业务功能。通用 AI 网关（Universal AI Gateway）则作为全集团唯一的集中控制平面，消除了每个独立项目就模型路由与安全规范开展单独谈判的工程成本。无论是内部助手、自动化工作流还是面向客户的应用，所有前端请求均统一经由该网关路由。网关统一部署合规策略、数据脱敏、流量调度与审计追踪，灵活调度前沿专有大模型、开源权重模型以及内部机器学习系统，从而实现应用端与后端模型端点的彻底解耦。知识治理2.0与组织吸收鸿沟 (14:27) 在数据层面，Nabiyev 提醒业界即使在自主智能体（Agent）时代，“垃圾进，垃圾出”的基本定律依然完全适用。企业常见的重大失误是让各个分散的工程团队自行抓取孤立业务数据去搭建拼接式的检索增强生成（RAG）管道，这会导致知识资产碎片化且极度脆弱。知识必须作为全局能力进行系统化管理，即升级至“数据治理 2.0”。无论是企业知识图谱、上下文图谱还是标准化的上下文 RAG 管道，都必须集中治理，并建立持续反馈回路，让企业的组织知识随时间推移不断沉淀复合。在组织人员层面，技术能力的快速跃升与企业实际业务吸收能力之间的差距正急剧扩大。Nabiyev 认为，单纯依靠全员宣讲、通用在线培训平台或全员邮件无法跨越这一“吸收鸿沟”。企业必须从底层重构工作流，严格界定智能体自主执行的决策边界与人工介入的升级阈值；在业务单元中派驻经过认证的职能业务带头人，并将绩效激励机制与真实的工作流重构紧密绑定，彻底摆脱仅考核登录量等虚荣指标的粗放做法。 Nabiyev 总结强调，治理模型、工厂平台、安全网关、知识基座与组织吸收五大能力构成了不可分割的统一系统；缺少任何一环都将引发灾难性后果——例如没有知识基座会导致智能体在事实层面产生严重幻觉，而缺乏组织吸收则意味着投入高昂技术成本却无法带来任何实际业务改变。现代企业技术领导者的职责必须发生根本转变，从传统的项目审批与指标汇报者，转变为设计系统架构、治理机器智能决策权、衡量业务实质价值并推动组织能力持续复合沉淀的领导者。

Detailed notes — zh

## Background 本视频由 Ai4 频道于 2026 年 8 月 19 日发布在 YouTube 平台上。视频记录了 Bir 生态系统首席数据与 AI 官 Valeh Nabiyev 的主题演讲，主要探讨了绝大多数 AI 项目受阻于组织架构而非底层技术的现实，并系统介绍了如何通过“企业级 AI 操作系统”将 AI 转化为可扩展的组织核心能力以实现商业价值。 ## TL;DR 演讲围绕企业如何从“零散用例探索”跨越到“组织级 AI 规模化能力”展开，直击多业务线各自为战、重复开发底层能力的痛点。Valeh Nabiyev 提出了涵盖运营模型、统一平台、网关控制、知识底座和人才组织层的“企业级 AI 操作系统”五大支柱架构，旨在消除组织内部的摩擦与壁垒。他强调该系统的不可分割性，指出若缺乏协同机制，技术落地将沦为空谈，并呼吁科技领导者从单点项目管理转向系统架构设计、智能治理与能力复合沉淀。 ## Atmosphere & style 整场演讲风格务实、坦诚且极具系统性架构思维。演讲者毫无保留地复盘了“重复构建 4 次 HR 助手”等典型踩坑案例，用生动的组织摩擦对比打破了盲目追逐大模型参数的行业浮躁。叙事节奏层层递进，既有对平台工程与团队拓扑的硬核剖析，又充满对组织机制与人机协作转型的深刻洞察，为企业技术管理者带来了一场直击痛点的实战复盘。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=iwz087lDRfg&t=4s) 企业 AI 转型的核心目标，在于从单点零散用例与碎片化项目开发，彻底跨越到打造组织可长期依赖的核心基础能力。 - [01:58](https://www.youtube.com/watch?v=iwz087lDRfg&t=118s) 单点开发模式不可持续：随着业务需求爆发，各自为政导致严重资源浪费，Bir 生态系统内部曾因缺乏复用机制而先后重复开发了 4 次 HR 员工助手。 - [06:40](https://www.youtube.com/watch?v=iwz087lDRfg&t=400s) 企业规模化 AI 的真正瓶颈并非算法或大模型技术本身，而是遗留流程、数据孤岛与治理缺失所造成的“企业组织摩擦”。 - [06:40](https://www.youtube.com/watch?v=iwz087lDRfg&t=400s) 正如 ERP 标准化了企业运营、云计算标准化了软件开发，企业级 AI 操作系统的本质是为全企业的“机器智能”建立标准化交付底座。 - [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) 运营模型（支柱一）：AI 无法依靠中心化团队集中交付实现规模化，必须建立“中央团队定方向设护栏建共享底座、业务团队负责商业价值”的协作模型。 - [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) 统一平台（支柱二）：AI 团队需从“科研实验室心态”转向“工业化智能工厂”，通过清晰的团队拓扑分工，严禁业务团队重复编写底层平台与治理代码。 - [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) 统一网关（支柱三）：所有上游应用与下游商业、开源或传统模型的调用，必须统一接入控制平面，集中实施访问权限、路由调度与安全护栏。 - [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) 知识底座（支柱四）：摒弃为每个聊天机器人单独做 RAG 的烟囱做法，必须将企业语料治理与上下文图谱作为通用能力集中管理与持续迭代。 - [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) 人工与组织层（支柱五）：技术演进速度远超企业吸收能力，必须围绕人机协作重塑审批权责与业务考核机制，单纯发邮件和做培训无法弥合落地鸿沟。 - [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) 系统的不可分割性：五大支柱环环相扣，缺失网关会导致合规失控，缺乏知识底座会导致幻觉，缺失人员吸收层则会导致“技术部署完毕而业务毫无改变”。 - [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) 技术领导力范式转移：新时代科技领导者的核心职责不再是管项目与报进度，而是“设计系统架构、治理智能决策、衡量商业价值、复合沉淀能力”。 - [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) 获取前沿 AI 技术的渠道本身已不再具备差异化壁垒，企业真正的护城河在于将 AI 转化为可扩展组织能力的机制与速度。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=iwz087lDRfg&t=4s) 转型背景：从“零散用例”走向“组织级能力” 来自阿塞拜疆 Bir 生态系统（Bir Ecosystem）的数据与 AI 负责人 Valeh Nabiyev 登台开场。他指出，在过去一年中，他的核心工作就是推动企业 AI 实现根本性跨越——从单纯落地单点用例与碎片化项目，转变为打造组织能够真正依赖的核心能力。Nabiyev 直言，今天不仅要分享成功的经验，更要毫无保留地讲述“事情走向偏差甚至失控的时刻”，因为这是当下绝大多数企业都会踩中的共同陷阱。整场演讲围绕一个核心命题展开：如何在 20 分钟内建立起一套面向可扩展 AI 的“企业级操作系统”（Enterprise AI Operating System）。在进入具体的系统架构之前，Nabiyev 简要介绍了 Bir Ecosystem 的业务背景。该生态系统坐落于阿塞拜疆，旗下涵盖三大截然不同的核心业务板块：银行业务（Banking）、金融科技与支付（Fintech & Payments）以及电子商务（E-commerce）。整个生态每天承载数以百万计的客户交易。他特别埋下了一个伏笔：在阿塞拜疆语中，“Bir”的意思正是“一”（One），这一概念与后续构建统一 AI 系统的逻辑紧密呼应。 ```mermaid flowchart TD accTitle: Bir Ecosystem 业务架构 subgraph Bir["Bir Ecosystem (阿塞拜疆，每日数百万交易)"] direction LR B["银行板块 (Banking)"] F["金融科技与支付 (Fintech & Payments)"] E["电子商务 (E-commerce)"] end ``` --- ### [01:58](https://www.youtube.com/watch?v=iwz087lDRfg&t=118s) 业务爆炸与重复造轮子：不可持续的碎片化开发 Bir 生态系统起初的 AI 探索与大多数公司毫无二致，都是从构建典型用例切入：客服助手、催收支持、各类知识库问答以及员工助手。项目落地迅速且成效显著。半年前如果有人询问 AI 转型的进展，团队会自豪地展示漂亮的 PPT 和业务指标。然而，商业成果引起业务部门的广泛关注后，真正的挑战接踵而至：各个业务线蜂拥而至，要求交付越来越多、速度越来越快的用例。需求不再是 5 个或 20 个，而是呈爆发式增长。企业面临的核心矛盾瞬间发生质变：从“我们能不能做出 AI 用例？”变成了“我们能否以业务所需的速度和规模批量构建 AI？”拆解单个用例的落地过程就会发现，每个项目背后都充斥着大量繁重且孤立的工程动作：模型选型、PII 隐私数据脱敏、数据接入、系统集成以及 Prompt 工程等。不同业务线在各自为政地重复实现网关、评估、知识检索、合规审批与部署等底层组件。这种分散开发导致了极具讽刺意味的资源浪费：Nabiyev 透露，他们事后发现，组织内部的不同垂直业务线为了响应各自业务部门的需求，竟然在没有复用任何组件的情况下，先后重复开发了 **4 次 HR 员工助手**。这并非某个人犯了错误，而是组织在“默认模式”下的必然结果。 ```mermaid flowchart LR accTitle: 单点烟囱式开发带来的重复浪费 subgraph UseCases["多业务线独立开发 (各自为战)"] UC1["业务 A: 催收/客服"] UC2["业务 B: HR 助手 #1"] UC3["业务 C: HR 助手 #2"] UC4["业务 D: HR 助手 #3 & #4"] end subgraph RedundantWork["重复构建的底层能力 (未复用)"] RW1["PII 脱敏与权限接入"] RW2["模型选型与 Prompt 工程"] RW3["评估、网关与部署流水线"] end UseCases --> RedundantWork ``` --- ### [06:40](https://www.youtube.com/watch?v=iwz087lDRfg&t=400s) 破局之道：以组织级操作系统打破企业摩擦 Nabiyev 强调，当前 AI 行业将过多精力聚焦在前沿大模型和前沿技术上，但大企业真正的瓶颈从来不是 AI 本身，而是企业内部的“组织摩擦”（Enterprise Friction）——陈旧的遗留流程、孤立的系统以及缺乏治理的协作模式。一线业务交付团队将过多精力耗费在平台底层建设而非业务创新上。因此，团队确立了明确的目标：大幅降低任何 AI 用例从“想法到生产落地”（Idea to Production）所需的成本、精力和时间。实现这一目标靠的不是采购更多外部平台（“买平台从来不是难事”），而是设计出一种能够将 AI 从零散项目转化为“可重复能力”的组织架构。正如 ERP 标准化了企业运营、云计算标准化了软件开发，当前时代必须为“机器智能”（Intelligence）构建标准化底座。AI 规模化推广的速度，应当且只能受限于“业务需求本身”，绝不能受阻于企业的内部阻力。 - **历史技术层演进对比**： - **ERP 时代**：标准化了企业的业务运营流程。 - **云原生时代**：标准化了现代软件的构建与部署方式。 - **AI 操作系统时代**：标准化企业级智能与组织协同能力。 --- ### [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) 五大支柱架构：消除五大企业摩擦 Nabiyev 提出了由五大机制构成的“企业级 AI 操作系统”（Enterprise AI Operating System），每个组件精准消除一种企业摩擦： ```mermaid flowchart TD accTitle: 企业级 AI 操作系统五大支柱 subgraph AI_OS["Enterprise AI Operating System (五大核心支柱)"] direction TB P1["1. 运营模型 (Operating Model) 消除决策模糊与权责不清"] P2["2. 统一平台 (AI Platform) 消除重复造轮子，构建智能工厂"] P3["3. 统一网关 (Gateway Control) 消除多头管控，统一策略与安全"] P4["4. 知识底座 (Knowledge Foundation) 消除知识孤岛，实现数据治理 2.0"] P5["5. 人才与组织层 (Human Layer) 消除吸收壁垒，重塑人机协作工作流"] end ``` #### 1. 运营模型（Operating Model）：消除决策模糊运营模型被刻意置于首位，因为其核心是消除“谁负责什么、谁做决策”的权责模糊性。它涵盖了企业级组合管理、价值归属界定、标准交付生命周期以及模型风险、人工介入（Human-in-the-loop）、可审计性与事件响应机制。Nabiyev 强调了一条硬性原则：“AI 绝不可能通过中心化集中交付来实现规模化。”正确的模式是：**中央团队定方向、设护栏、建共享能力；业务产品团队负责商业价值；技术团队搭平台；风控与合规团队做保障**。 #### 2. AI 平台（AI Platform）：告别单点实验室，迈向智能工厂该能力旨在解决每个用例重复构建基础架构的痛点。AI 团队必须从“科研实验室心态”转变为“工业化智能工厂心态”，建立从想法到生产的一体化生命周期：构建、评估、认证、部署、观测、学习与复用。Nabiyev 引用了《Team Topologies》（团队拓扑）一书的理论，强调必须将团队清晰划分为业务流动团队（Stream-aligned）、平台团队（Platform）、赋能团队（Enabling）与复杂子系统团队，**严禁业务流动团队自行去编写平台级和治理级的底层代码**。 #### 3. 统一网关（Gateway）：统一管控平面与策略执行以往每个项目各自对接模型、谈判权限与开发风控规则，导致治理失控。统一网关要求无论上游是员工助手、前台客服还是业务应用，下游接入的是前沿商业模型、开源大模型还是传统机器学习模型，所有请求必须经过唯一的控制平面（Control Plane），在此处集中实施访问控制、安全护栏（Guardrails）与请求路由。 #### 4. 知识底座（Knowledge Foundation）：数据治理 2.0 Nabiyev 指出，当前行业热炒 Agent 而忽视了“垃圾进，垃圾出”（Garbage in, Garbage out）的铁律依然成立。早期他们让算法工程师为每个聊天机器人单独做 RAG、找业务拉数据，这是完全错误的单点模式。知识底座必须作为组织级的通用能力来集中管理，构建闭环系统让上下文图谱（Context/Knowledge Graph）与企业语料在每次业务交互中越变越强。 #### 5. 人工层与组织吸收力（Human Layer）：弥合技术与落地的鸿沟屏幕上展示了一条急速上升的黄线（AI 技术能力的演进速度，无需组织同意即在飞速攀升）与一条平缓的灰线（企业组织实际的吸收转化能力）。两条曲线之间的垂直差距，才是 AI 转型的真正战役。Nabiyev 尖锐地指出，这种差距绝不可能靠“建个培训网站、开一场全员大会（Town Hall）或发几封宣导邮件”来弥合。必须通过深层机制变革：围绕“人机协作”重构业务岗位与审批权责、培养能够自主设计团队工作流的业务领导者、在各职能嵌入业务冠军（Champions）、重塑考核激励机制，并以实际工作流中的采纳深度（而非单纯的系统登录率）来衡量成效。 --- ### [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) 系统的不可分割性与技术领导力的新使命 Nabiyev 给出了检验企业是在构建“统一操作系统”还是仅仅在做“分散工作流”的压力测试方法：抽离五大能力中的任意一项，系统就会全面崩塌： - **失去运营模型**：平台退化为无人负责的普通工具； - **失去统一平台**：团队退回各自造轮子的泥潭； - **失去统一网关**：业务规模扩张直接变成安全合规灾难，成本彻底失控； - **失去可信知识底座**：只会得到“口齿伶俐却满嘴胡话”（Articulate and wrong）的 AI Agent； - **失去人员吸收层**：将遭遇最昂贵的失败——“所有技术部署就绪，业务没有任何改变”。企业哪怕在每个单项上分别取得成功，若无法将它们作为一个协同系统一同成熟演进，整体转型依然会失败。最后，Nabiyev 向在场的科技领导者发出呼吁：过去那种“管项目、批用例、报进度”的旧领导力模式，只会让企业陷入竖井孤岛。新时代的技术领导力由四个核心动词定义： 1. **设计系统（Design the system）**：系统架构设计本质上是领导力行为，而非纯技术行为； 2. **治理智能（Govern intelligence）**：明确决策机制与人类的最终问责边界； 3. **衡量价值（Measure value）**：将技术转型牢牢锚定在最终商业结果上； 4. **复合沉淀（Compound capability）**：确保每一次交付都能让组织的基础能力变得更加强大。他以一句总结结束演讲：“获取 AI 技术的渠道本身已经不再具备差异化优势，企业真正的核心竞争力，在于你能将这些技术转化为怎样的组织能力。” ## Notable quotes > [00:04](https://www.youtube.com/watch?v=iwz087lDRfg&t=4s) 事情走向偏差甚至失控的时刻 — Valeh Nabiyev > [01:58](https://www.youtube.com/watch?v=iwz087lDRfg&t=118s) 我们能不能做出 AI 用例？ — Valeh Nabiyev > [01:58](https://www.youtube.com/watch?v=iwz087lDRfg&t=118s) 我们能否以业务所需的速度和规模批量构建 AI？ — Valeh Nabiyev > [06:40](https://www.youtube.com/watch?v=iwz087lDRfg&t=400s) 买平台从来不是难事 — Valeh Nabiyev > [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) AI 绝不可能通过中心化集中交付来实现规模化。 — Valeh Nabiyev > [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) 中央团队定方向、设护栏、建共享能力；业务产品团队负责商业价值；技术团队搭平台；风控与合规团队做保障 — Valeh Nabiyev > [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) 垃圾进，垃圾出 — Valeh Nabiyev > [09:09](https://www.youtube.com/watch?v=iwz087lDRfg&t=549s) 建个培训网站、开一场全员大会（Town Hall）或发几封宣导邮件 — Valeh Nabiyev > [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) 口齿伶俐却满嘴胡话 — Valeh Nabiyev > [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) 所有技术部署就绪，业务没有任何改变 — Valeh Nabiyev > [17:36](https://www.youtube.com/watch?v=iwz087lDRfg&t=1056s) 获取 AI 技术的渠道本身已经不再具备差异化优势，企业真正的核心竞争力，在于你能将这些技术转化为怎样的组织能力。 — Valeh Nabiyev ## Mentioned Valeh Nabiyev, Bir Ecosystem, Pasha Holdings, Ai4, Team Topologies, ERP, RAG, AI Agent ## Video description Valeh Nabiyev - Chief Data & AI Officer, Bir Ecosystem Most AI initiatives don't fail because of the technology—they fail because organizations aren't designed to scale them. In this session, I'll introduce the Enterprise AI Operating System: a practical framework for turning AI into an organizational capability and creating business value at scale. [Source](https://www.youtube.com/watch?v=iwz087lDRfg)

Source quotes

[0:04] Valeh Nabiyev: 事情走向偏差甚至失控的时刻 [1:58] Valeh Nabiyev: 我们能不能做出 AI 用例？ [1:58] Valeh Nabiyev: 我们能否以业务所需的速度和规模批量构建 AI？ [6:40] Valeh Nabiyev: 买平台从来不是难事 [9:09] Valeh Nabiyev: AI 绝不可能通过中心化集中交付来实现规模化。 [9:09] Valeh Nabiyev: 中央团队定方向、设护栏、建共享能力；业务产品团队负责商业价值；技术团队搭平台；风控与合规团队做保障 [9:09] Valeh Nabiyev: 垃圾进，垃圾出 [9:09] Valeh Nabiyev: 建个培训网站、开一场全员大会（Town Hall）或发几封宣导邮件 [17:36] Valeh Nabiyev: 口齿伶俐却满嘴胡话 [17:36] Valeh Nabiyev: 所有技术部署就绪，业务没有任何改变 [17:36] Valeh Nabiyev: 获取 AI 技术的渠道本身已经不再具备差异化优势，企业真正的核心竞争力，在于你能将这些技术转化为怎样的组织能力。

Source quotes

Valeh Nabiyev: Most AI initiatives don't fail because of the technology—they fail because organizations aren't designed to scale them. [0:04] Valeh Nabiyev: Can we build an AI use case? [0:04] Valeh Nabiyev: Can we build AI as fast and as extensively as the business requires? [2:39] Valeh Nabiyev: It's funny now, but it was not funny at that moment. [6:40] Valeh Nabiyev: Buying vendor platforms is straightforward; designing organizational architecture to scale them is the true challenge. [6:40] Valeh Nabiyev: The rate of AI adoption must be constrained solely by business demand, never by internal enterprise friction. [14:27] Valeh Nabiyev: garbage in, garbage out [14:27] Valeh Nabiyev: Data Governance 2.0 [17:36] Valeh Nabiyev: articulate and wrong [17:36] Valeh Nabiyev: The most expensive failure mode: full technical deployment with zero business change. [17:36] Valeh Nabiyev: Design the system architecture as an act of leadership, not merely technical execution. [17:36] Valeh Nabiyev: Compound organizational capability so that every single delivery leaves the enterprise systematically stronger.

Original transcript

[0:04] Uh good afternoon. Uh I am Val Nabiv. I'm lead data and AI in BCO system. So for the last [0:12] year my job was turn AI from use case from just implementing of use cases and projects to their [0:21] uh capability on which our organization can really rely on. So I want to tell you today's story [0:31] uh including the moment it went wrong even uh because I believe it is most company's story at [0:40] the moment. So 20 minutes only one idea uh about building the operating system for scalable AI. [0:54] So before we are going to the uh content itself to the architecture uh let me spend one minute [1:03] about explaining what the organization we are speaking about and what is the organization we [1:08] are trying to transform. So uh it is B ecosystem it's located in Azorban. You can scan QR if you [1:19] want more details. Inside of this organization there are three verticals. It is banking fintech [1:28] let's say uh payment and e-commerce. So totally different businesses and millions and millions of [1:35] uh customer transactions every day. uh and one small detail in Azerbaj beer means one [1:44] just keep in mind we will come to this later so uh in in my next let's say uh slides so [1:58] where we started we started as most organizations started we we build use cases we built use cases [2:07] it's customer support, depth collection, I don't know, chat bots, uh, knowledge assistant, [2:15] uh, other assistants as well. Yeah. Uh, and by the way, we did it really good. If you ask me, [2:24] uh, I don't know 6 months ago, uh, what's your AI transformation? How is going, I will show [2:31] you slide like that and even some figures and say that this is our AI transformation. [sighs] But uh [2:39] we did it. We have impact and business noticed. And what happens next? Next business start ask [2:48] if we can do more and more use cases and we can if we can do it fast. I mean it's [2:59] business respondent the way you want that they respond. Yeah. So uh it's not five use cases, [3:07] it's not 20 use cases. Um it was a lot. Yeah. Uh and the question in that moment changed. [3:18] question changed from the can we build AI uh can we uh build AI use cases to the real problematic [3:32] question not only of us but as I said of the all companies uh can we build AI as fast and [3:40] as much as business needs. So to answer that to answer that question uh uh we really need [3:52] to go to the details of one one AI use case in our organization. So as you see yeah there are [4:04] uh one AI use case and a lot of actions uh which we we should perform for delivering [4:13] of that of that use case. Uh we should make model selection we should make PII ask masking uh which [4:23] previous speaker picked a little bit. uh we should understand which correct data to uh access assess [4:30] uh we we should do integrations prompt engineering etc. Yeah. A lot of things to be done for just one [4:39] use case. Yeah. Uh and when we are doing the this use case it's the same st we engineering separate [4:52] and separate times. I will explain how we yeah this is more illustrative. So we have different [5:01] use cases and each time we are doing spending effort to implement the uh same capabilities [5:10] same components of the use cases. So gateway evaluation, knowledge, approval, deployment, [5:17] uh different business problems, same engineering and sometimes it got it got even more funny. [5:32] So we realized in some moment that in our business they they didn't something wrong by the way. Yeah. [5:42] uh they're just delivering the request of the business. It's a different vertical [5:48] and they're implementing what business ask uh and we realized that we we made [5:54] four times HR assistant and it's funny now but it was not funny at that moment. So and [6:06] uh the problematic side that it was not reused and any component would not reused [6:12] but more or less it is about the same thing answering employees questions. [6:19] um it is a it is a point I would like to highlight and pose a little bit to give you a chance to [6:26] think about it that uh it was not accident it is was the default regime let's say and [6:40] where was the bottleneck we in this conference we heard a lot about use cases about their [6:46] technologies about their models about the frontier models I don't know but the bottle real bottleneck [6:54] is not AI itself the real bottleneck is enterprise of course we are speaking about not very small [7:02] companies we speak about bigger companies uh with some legacy processes uh and legacy systems so and [7:16] our goal after realizing I mean of that moment that for HR assistant that we're spending that [7:24] stream align team spending a lot of time to implement platform capabilities not AI itself [7:32] uh that our goal at that moment became very obvious for us that we should reduce cost we [7:42] should reduce effort and time required to take any use case from idea to production. [7:51] Um I will argue on that statement that is a problem of their uh a lot of companies. Uh [8:01] uh this things three things it's not not a model you deploy not a platform you buy uh we buy plenty [8:10] platforms you see some of them today. uh by buying of these platforms is not the hard thing. Yeah. Uh [8:20] uh it is a system you design the organizational architecture that turns AI from a collection of [8:26] projects into repeatable capability. Uh if you go a little bit back, every era had um [8:36] uh one of these layers. I I will explain what I mean. uh ERP standardized how we run operations [8:44] if you remember. Yeah. So cloud standardized how we build software at all. Uh this is that [8:52] layer that layer for intelligence and um I will put simply the speed of AI adoption should be [9:01] limited only by business demand uh never by enterprise friction which I mentioned before. [9:09] Um and it has it uh I will explain next which five parts I'm proposing to to build this one [9:25] system. Yeah I said in the beginning about beer it means one. So it's a like trick to to to help you [9:37] remember this word. Uh yeah going to the topic the whole system on one slide five mechanisms [9:46] each removing one source uh and related to the one enterprise enterprise friction an operating model [9:56] first you see that decides a platform that builds a gateway that controls a knowledge foundation Um [10:10] so I will not go we have limited time [10:15] uh on this slide one by one I will go a little bit deep dive to the operating model [10:24] uh [clears throat] this not just first it's deliberately the first capability but because I [10:31] think that it's where we should we should that uh the friction it removes it is decision ambiguity. [10:39] Who doing what? Who responsible for what? Uh to the to whom this product owner should go to [10:45] make a decision [clears throat] and this is more than who decide. It is their enterprise portfolio [10:53] uh and uh how value ownership is assigned. It is delivery life cycle. Every AI product follows [11:00] from idea to production. its policy, model risk, human oversight, auditability, incident response. [11:11] So uh and one principle we hold hard AI does not scale through central delivery. It's it's [11:22] not works. The the center sets should set direction cards and share capabilities. So [11:30] business product teams own the value. Technology builds a platform. Risk and control assure it. As [11:36] you see from picture, if accountability here is ambiguous, so everything above it wobbles with [11:45] decision rights in place, you can industrialize the building uh itself. Yeah. So it's about [11:57] uh AI platform. next capability the it's it's related to the [12:03] friction when we we're rebuilding the same capabilities for every and every use case [12:10] uh it's like intelligence factory uh because that's a posture not a lab it's a factory [12:17] uh one life cycle from idea to production uh build evaluate certify deploy observe learn and reuse [12:31] So [12:36] I'm really don't want to spend time on that. The main idea here is that uh you uh you should deep [12:49] dive and build the process there what we are doing at the moment. So to check gates that no [12:57] team doing platform things. Do you remember this book for team topologies? Uh it's about digital [13:08] engineering teams where teams divided between stream aligned platform enabling and complicated [13:14] subsystem teams. So don't allow to the stream aligned teams doing platform and governance work. [13:25] because they shouldn't they should focus on their delivering business capability three I [13:31] will switch to their capabilities three uh it's a gateway uh the friction attributes negotiation [13:37] access routing and controls projects by project every AI experience uh can look different an [13:44] assistant a work customer product but every request passes through one gateway it's where [13:50] policy is enforced assesses control requests are rooted. So it's not really matters what you have [14:00] on the right side. Yeah, it can be any model. It can be frontier, open source, ML model. Uh [14:09] and on the left side every it it can be any surface there. What matters that your control [14:16] pan should should be one and your guard rails and controls should be implemented from one place. [14:27] The first one underestimated one. Yeah. Three four years ago we all speak about data governance. We [14:37] all speak about importance of accountability of data. Now we all speak about agentki and [14:43] forgot that this garbage in garbage out still works. So in the knowledge side the important [14:53] thing that it's to make this a circle process that in every circle knowledge becoming strong [15:02] stronger and stronger and knowledge is not part of their agent development. knowledge [15:09] is a part of their enterprise capability. So your team which developing AI chatbot we did [15:17] it when we we developed AI chatbot first our data scientists working with rax and trying to [15:26] uh gather data from businesses and now we are uh changing it that it is it's [15:35] like data governance 2.0 zero. It's very rude analogy but it's like data governance. So you [15:41] should create this knowledge it's different names here context graph knowledge graph. So [15:50] uh context rack so a lot of terminology but uh meaning same knowledge of your organization [16:00] and it should be managed centrally not like use case by use case. It's a mistake we did. [16:10] And the last most important [16:16] I will not say that one of these capabilities are more important [16:20] than another. They are all important at the same time. One not works with other. But [16:28] uh we we we think that we should invest a lot of our effort to this. It is human [16:34] layer. It enables that every business team able to build and absorb AI successfully. Uh the amber [16:42] line you see there uh is what AI can do. It keeps stiffening without your permission. The gray line [16:48] is what your organization can actually absorb. That vertical gap is a real transformation. It's [16:55] not closed by what you are believe doing. It's not closed by training portal and a town hall or [17:03] another communication letter. Uh it closes through mechanisms roles generally redesigned around human [17:11] agent collaboration decision making redesigned who approves what when an agent acts when an [17:17] human must leaders fluent enough to design their own team's work skills certified by role champions [17:25] embedded in functions. incentives aligned and adoption measured in real workflows not login. [17:36] Um so deploying technology is really easy half now why is this so hard that this five are one system. [17:53] So here's a test of whether you are building an operating system of five work streams. Uh remove [18:00] any of these capabil any of this capability and see what happens. Uh the platform becomes [18:07] another tool. Nobody's accountable for no platform back to every team rebuilding the foundations. No [18:15] gateway scale itself becomes the risk. Uh cost split trail. If no trusted knowledge, [18:24] you get agents that are articulate and wrong. No adoption, the most expensive failure of [18:33] all. Everything deployed, nothing changed. A company can succeed at each piece separately [18:41] and still fail. The capabilities have to be designed together and matured together. [18:50] When is there something bigger? [18:56] Oh, we have less time. So, I will I will switch to the next [19:09] um I I will like to address this to the people in this room. We are not alone. It's last day. [19:19] Yeah. So uh but uh the old technology leadership mandate managing projects approve use cases report [19:31] activity is exactly how we I am personally also end up with a thousand of pillars. I [19:38] believe you also did the new mandate has four verbs. Design the system architecture [19:45] now is a leadership act not a technical one. Govern intelligence decide how decision gate [19:51] made where humans stay accountable. Measure value all the transformation to business out [19:57] business outcomes and compound capability make every delivery leaves organization stronger [20:06] because access to AI will not differentiate [20:12] already the what differentiate it's what you turn uh it into. [20:23] Thank you. And the last if you would like to connect you can scan. I will [20:30] be happy to discuss in more details this framework or any questions. [20:36] I don't know if you have further question if we can pick up if any.